> Who's in the right

I don't think either are. The payment processor should be sending it, but, at least according to the RFC, it is incorrect to reject an email that doesn't have it. I suspect the reason it is SHOULD, and not MUST is for backwards compatibility with software that predates the RFC that adds the message-id header.

Maybe there is a correlation between missing that header and being spam, but then it should go to the spam folder, not be outright rejected.

----------------------------

The experience with support is also similar to experiences I've had with support at many companies. I provide enough details that an engineer could probably easily fix the problem, but the support representative just dismisses it, and it is doubtful an engineer even hears about it.

▲

askldfhalkdfh 4 hours ago | parent | next [-]

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.

▲

ajross 8 hours ago | parent | prev [-]

Exactly. 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).

To wit: basically everything in this world is a "SHOULD", at best. The rules are a conversation.

▲

jonathanstrange 7 hours ago | parent [-]

Then why does my email program reliably distinguish spam from ham without any server-side filtering involved?

	▲	ajross 5 hours ago \| parent \| next [-]
		If 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. GMail, 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".
	▲	shadowgovt 6 hours ago \| parent \| prev [-]
		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. Google 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.