It's not necessarily the support person's fault. I worked in support way back when. There were some long-standing issues that needed only minor work to fix that engineering management didn't get, didn't care about or just wouldn't prioritize. Engineers weren't free to work on what wasn't prioritized. Acknowledging a problem and leaving the ticket open doomed to be unsolved forever negatively affected my performance rating. I had to respond with this sort of cheery everything's fine message and write it off as a customer issue, even though I didn't believe it.
replyExactly. This minutiae is all so weird. Email as a formal specification does not work, and the industry as a whole has accepted that for decades now. It's not possible to filter spam from valid traffic without applying a truckload of heuristics and leveraging an ever growing set of auxiliary signals (SPF, DKIM, yada yada).
replyTo wit: basically everything in this world is a "SHOULD", at best. The rules are a conversation.
Then why does my email program reliably distinguish spam from ham without any server-side filtering involved?
replyIf you have a client app that you think is reliably filtering spam, then to be blunt: you aren't receiving any spam, at least to first approximation. My stack of stuff on my three decade old personal account has a 95%+ hit rate (something I might naively be tempted to label as "reliably filtering spam"), and I see see more spam than signal in the inbox.
replyGMail, on the other hand, is damn close to 100%. And it does it through excruciating application of heuristics like "don't trust agents that don't set SHOULD headers".
I'm just speculating, but probably because you're on an email provider that isn't a big enough target to worry about the persistent threat-actor model.
replyGoogle is a big enough target to justify spending the resources on dedicated attacks against their infra. Other providers may simply get less spam because their email domain shows up less often in the sources attackers use to pick targets.