SHOULD is a requirement. It means that you have to do it unless you know some specific reason that the requirement doesn't apply in your case. "I don't want to" is not a valid excuse, "I don't see a reason to" isn't either.

IIRC this particular rule is a SHOULD because MUAs often send messages without a Message-ID to their submission server, and the submission server adds one if necessary. https://www.rfc-editor.org/rfc/rfc6409.html#section-8.3 The SHOULD lets those messages be valid. Low-entropy devices that can't generate a good random ID are rare these days, but old devices remain in service, so the workaround is IMO justified.

The official definition of SHOULD per RFC2119:

  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course.

My take, as a postmaster for hosting company, who don't have any sympathy to gmail (that should be visible from my comments history): Message-ID is absolutely MUST in production e-mails. You can send your test stuff without it, but real messages always have it. Not having Message-ID's causes lot of fun things. All somewhat competent software is capable to add Message-ID's, so lack of it is good indication of poorly made custom (usually spamming) solution.

Rspamd and spamassassin have missing MID check in their default rules, I am sure that most antispam software is same.

Exactly. Message-ID is not required.

An unrelated frustration of mine is that Message-ID really should not be overridden but SES for instance throws away your Message-ID and replaces it with another one :(

I would read this as a requirement for email to be 'legit' and not classified as spam.

Sure, you can send email with whatever headers you want, use weird combos, IP addresses, reply-to, and it might be still a technically valid email, but not something that should land in people's inboxes.

Also, a payment processor not testing their email on the most popular email provider in the world is quite ridiculous.

SHOULD = You are strongly recommended to do this, but it’s not absolutely required.

- In most cases, you are expected to follow it.

- You can choose not to follow it, but you must have a very good reason.

For example, RFC 7231 say that there should be DATE header but some embedded devices have no real-time clock so it ok not to implement.

As indicated in the RFC, it uses another RFC[0] to define those words. Here's the relevant excerpt from that one:

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
                may exist valid reasons in particular circumstances to ignore a
                particular item, but the full implications must be understood and
                carefully weighed before choosing a different course.

I know you're looking for "pedant points" but the specification generally take a backseat to implementation. If Message-ID is expected out here where the rubber meets the road, then you are the squeaky wheel in this scenario for not including it.

The only messages I receive without one are spam/phishing. I check because they're not recognised by notmuch, so I don't see them otherwise.

And the definition of "SHOULD" (from RFC 2119) is "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

Having said that, I regret my original characterization of the Message-ID header as a "requirement" and have updated the blogpost to be fair to all sides.

Thank you for bringing this up.

GMail SHOULD handle your messages, not MUST.

> That says SHOULD, not MUST, so how is it a requirement?

Battle with spam has been for long part just trying to algorithmically fingerprint the scam bots and reject the message if it looks like it wasn't sent by "real" mail server/client.

So a lot of things that are optional like SPF/DKIM are basically "implement this else your mail have good chance of being put into spam automatically".

The reason that European tech sucks is that people in Europe are open to such arguments. If an engineer in the US started talking about SHOULD vs MUST, some PM would just give them that "what the fuck did I just listen to" face, spend the next few minutes gently trying to convince them that the customer experience matters more than the spec, and if they fail, escalate and get the decision they want.

For example, why does Google handle this differently for consumer and enterprise accounts? Well it's Google so the answer could always just be "they are disorganized" but there's a good chance that in both cases, it was the pragmatic choice given the slightly different priorities of these types of customers.

The reason it’s recommended is that it’s useful for detecting when an email you receive is already in your mailbox, so that you don’t accumulate duplicates. Otherwise one would have to compare the complete email, which probably no MUA does. Another reason is that replies can include a reference to the original message, so that it can be properly threaded by MUAs.

So these are mostly quality-of-life reasons, it’s not a reason to reject an email.

You SHOULD follow the wording of the RFC, you MUST follow Google's interpretation of the RFC.

That is the difference.

You're totally right. I've updated the blog to reflect this. Thank you!

Standard RFC naming, optional field.

The HTTP User-Agent header is also optional, but if you omit it, something like half of all endpoints will respond with a 500 error code.

Also email as a protocol (SMTP) predates RFC5322 by 25 years or so.

Avoid SHALL, SHOULD and all other crap, use Elon MUST.