Maybe the standards documents you are used to differ from RFCs, but here is the official language:

   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.
SHOULD is effectively REQUIRED unless it conflicts with another standards requirement or you have a very specific edge case.

I just don't understand how you get from the text you pasted to "required". Nowhere does it say that anything is effectively required. Words have meaning.

> the full implications must be understood and carefully weighed before choosing a different course.

In this case, the full implication is that your email might be undeliverable. "Should" indicates that the consequences for this fall on the entity that is deviating from the thing they "should" be doing.

You should wear sunscreen to the beach. Its recommended as a good way to prevent sunburn. However, the beach police aren't going to come get you for not wearing it. You just might get a sunburn if you don't plan accordingly with other sun countermeasures.

> the full implications must be understood and carefully weighed before choosing a different course.

Note the use of the word "must" used twice there. Barring a sufficiently good reason and accepting the consequences, this becomes a very poorly worded "required".

The spec would have been far better starting with SHALL and then carving out the allowance for exceptions.

No, its not a "required"... It means someone may have reasons not to use something, and so spec implementors need to allow for circumstances where it is not present.

Those reasons can be anything. Legal, practical, technological, ideaological. You don't know. All you know is not using it is explicitly permitted.

"permitted" is a pretty empty word in the given context. Because dropping such emails is equally "permitted". Sure, there will be no arrests made, but there will be consequences. And those are what this article is about.

If that's your line, then I am equally permitted to send random binary blobs along the way. Not a crime, so totally permitted. They'll just drop the connection.

Buuut I don't think that is at all relevant to the discussion at hand.

> You don't know. All you know is not using it is explicitly permitted.

In theory, if they are truly following the specification, you know they thought hard about all the consequences.

I think the pushback in the comments comes from the commonsense feeling that this... didn't happen here.

I don't even know how you got to "used twice" tbh. Both your own comment AND the post you quoted from only have a single "must".

The only thing that text demands is understanding and carefully weighing the implications. If, having done that, you conclude that you don't want to then there is absolutely nothing in the spec stopping you. Maybe the spec would have been better off putting more stuff in SHALL and less in SHOULD, but as written that is definitely not the case.

Nope, it's exactly what it says: RECOMMENDED.

Any time any document (standards or otherwise) says something is recommended, then of course you should think it through before going against the recommendation. Going from their verbiage to:

> SHOULD is effectively REQUIRED unless it conflicts with another standards requirement or you have a very specific edge case.

is a fairly big leap.

"The full implications must be understood and carefully weighed before choosing a different course." (emphasis mine)

i.e. you are required to have a good reason not to do it.

Can you start actually reading what you quote? "The implications must be understood and weighed" does not mean "you are required to have a good reason not to do it". I can know of the Message-ID field, understand what it's used for, and carefully weigh the possible lack of interoperability against the effort required, concluding that I'm too lazy to do it right now. I have then understood and carefully weighed the implications before choosing a different course, but I don't have a good reason to.

Words mean things, especially in standard texts. You can't just carelessly rewrite sentences using not-quite-synonyms like you're doing here.

Oh, and that "must" is not a "MUST". Had the text said "The full implications MUST be understood ..." it would have been a proper requirement by the standard, but this lower-case "must" is just normal part of prose and not the magical "MUST" word which formally imposes a requirement.

This very clearly says that SHOULD is not effectively REQUIRED at all, and is fact nothing more than RECOMMENDED. Really not sure how you misinterpreted this so badly

It's not required but they need to understand the implications. In this case the implication is that Google drops the mail. So clearly they didn't understand the implications.

Yes, but this might be googles fault for not respecting/missinterpretating the spec.

So you agree that calling it a requirement is wrong?

You should read it again.

Are you recommending they read it again or requiring it?

required means it must exist, not that it may or may not exist depending on the reason