Most of the time, in my experience, when one encounters a situation like this in Internet tech (i.e. "why is this suggestion treated like a hard requirement?"), this is the answer: "because attackers found a way to exploit the lack of the suggestion's implementation in the wild, so it is now a hard requirement."

The standards, to my observation, tend to lag the CVEs.

Side-note: If someone has built a reverse-database that annotates RFCs with overriding CVEs that have invalidated or rendered harmful part of the spec, I'd love to put that in my toolbox. It'd be nice-to-have in the extreme if it hasn't been created yet.

▲

atherton94027 6 hours ago | parent [-]

How is not having a message-id a security risk? It seems that Gmail is being pedantic for no reason

▲

geocar 6 hours ago | parent | next [-]

> How is not having a message-id a security risk?

CVE classify a lot of things that have nothing to do with security.

Not having a Message-ID can cause problems for loop-detection (especially on busy netnews and mailing lists), and with reliable delivery status notification.

Dealing with these things for clients who can't read the RFC wastes memory and time which can potentially deny legitimate users access to services

> It seems that Gmail is being pedantic for no reason

Now you know that feeling is just ignorance.

▲

hsbauauvhabzb 5 hours ago | parent [-]

So add a message id at the first stop, or hard ban the sender server version until they confirm. A midway point that involves a doom switch is not a good option.

	▲	geocar 3 hours ago \| parent [-]
		> So add a message id at the first stop That should have already happened. Google is not the "first stop". > hard ban the sender server version until they confirm SMTP clients do not announce their version. Also I don't work for you, stop telling me what to do. > A midway point that involves a doom switch is not a good option. No shit. That's almost certainly a big part of why Google blocks messages from being transited without a Message-ID.

▲

shadowgovt 3 hours ago | parent | prev [-]

Because in practice it showed up for a period of time as a common thing in spam-senders. They were trying to maximize throughput and minimize software maintenance costs, so they leave out things that the spec says are optional. But that makes "a commonly-implemented optional thing was left out" into a stronger spam signal.

Is it still a strong spam signal? Hard to say. Sources disagree. But as with laws, heuristics, once added, are often sticky.