[Arnt]

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.

[BeetleB]

> SHOULD is a requirement.

I once had a job where reading standards documents was my bread and butter.

SHOULD is not a requirement. It is a recommendation. For requirements they use SHALL.

My team was writing code that was safety related. Bad bugs could mean lives lost. We happily ignored a lot of SHOULDs and were open about it. We did it not because we had a good reason, but because it was convenient. We never justified it. Before our code could be released, everything was audited by a 3rd party auditor.

It's totally fine to ignore SHOULD.

[dsl]

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.

[dodobirdlord]

Assuming we’re talking about RFC 2119, it’s important not to collapse the distinction between SHOULD and MAY, which is there for a reason. MAY elements are legitimately optional, SHOULD elements are there for a reason and are disregarded at one’s own risk.

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

To validly disregard a SHOULD, you need to (a) fully understand the implications, and (b) accept them.

Any time someone disregards a SHOULD and then complains about the result, they are necessarily in the wrong. Either they didn’t fully understand the implications, or they don’t actually accept them.

[cmsefton]

Agreed. We use RFC language at work for documents, and whenever I see someone using the word SHOULD, I always ask what is the MAY where you don't need to do the thing? If they can't think of one, then make it a MUST. SHOULD always means there are valid reasons to not do it.

[Arnt]

FYI slightly over 10% of RFCs contain at least one occurrence of SHALL. Even that small minority uses other words for most requirements.

[calvinmorrison]

Email is about standards like browsers were about standards in 2017...

[Foobar8568]

Could was yeah nice to have. Should, was yeah the system shall have it, but it's ok if not. Shall : ffs we will hunt you and kill you if you don't implement it.

[seb1204]

Yes, except there seems to be a move on the best words from SHALL to MUST and from SHOULD to MAY. IANAL but I recall reading this in e.g. legal language guidance sites.

[st_goliath]

> "I don't want to" is not a valid excuse

for the client. If you're implementing a server, "the client SHOULD but didn't" isn't a valid excuse to reject a client either.

You can do it anyway, you might even have good reasons for it, but then you sure don't get to point at the RFC and call the client broken.

[geocar]

> isn't a valid excuse to reject a client either.

Yes it absolutely is: https://www.rfc-editor.org/rfc/rfc2119 is quite clear.

    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.

If the client SHOULD do something and doesn't, and your server does not know why, you SHOULD disconnect and move on.

If the server has considered fully the implications of not having a Message-ID header, then it MAY continue processing.

In general, you will find most of the Internet specifications are labelled MUST if they are required for the protocol's own state-processing (i.e. as documented), while specifications are labelled SHOULD if they are required for application state-processing in some circumstances (i.e. other users of the protocol).

[Veserv]

You are describing MAY.

“MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional… An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)”

Note how it explicitly calls out interoperation with implementations that do or do not implement MAY. As a exception that proves the rule, we can reasonably assume that not interoperating with a system ignoring a SHOULD rule is a correct implementation and it is the fault of whoever is not implementing SHOULD.

[Arnt]

Hearsay has it that the reason is spam. Spam messages are said to have massively higher chances of minor RFC violations when they arrive at the destination server.

[L_226]

As someone who does systems engineering, the only valid requirements include the word "shall".

[stackskipton]

As someone else who does System Engineering, when dealing with ancient protocols, "shall" is extremely difficult barrier to get over since there is always ancient stuff out there and there might be cases not to do it, esp if it's internal communication.

"SHOULD" is basically, if you control both sides of conversation, you can decide if it's required looking at your requirements. If you are talking between systems where you don't control both sides of conversation, you should do all "SHOULD" requirements with fail back in cases where other side won't understand you. If for reason you don't do "SHOULD" requirement, reason should be a blog article that people understand.

For example, "SHOULD" requirement would be "all deployable artifacts SHOULD be packaged in OCI container". There are cases where "SHOULD" doesn't work but those are well documented.

[opto]

In a completely different field, navigating ships at sea, the Collision Regulations which define how people must conduct ships at sea, they use the words "Shall" and "May" to differentiate legal requirements and what may just be best practice. "Should" intuitively means something more like "May" to me

[sas224dbm]

"shall" and "must"

[almosthere]

The original email RFC is also completely unaware of how bad spam is. Sure it might mention it but it's not really AWARE of the problem. The truth is, companies like Google, Microsoft and a few others have de-facto adjusted the minimum requirements for an email. Signing, anti-spam-agreements, etc.. are the true standard if you want an email to get from point a to b. (none of which are going to be REQUIRED in the RFC)

[phs318u]

Given the amount of time that has passed, the big email companies have had many years to jointly update the RFC according to their experienced reality. They haven't done so and the way you describe how they effectively work together to adjust the minimum requirements (outside the RFC) is de-facto use of market power to the exclusion of other players.

[5o1ecist]

That's not what the word "should" means, though.

"Should" is a lot closer to "better do it this way" than "you must do it this way". While "must" implies a mandatory-ness, "should" does not.

Or take it from perplexity:

"Must" normally expresses strong obligation/necessity: something is required, with little or no choice.

"Should" is softer and usually expresses recommendation, expectation, or what is right/appropriate, not a strict requirement.

[Aldipower]

It isn't a requirement. SHOULD is conditional. MUST is _not_ conditional.

Sure, you can argue, if you require that the email reach their destination, it is required to set this. ;-)

But I am totally with the OP here. SHOULD was never a requirement, just a recommendation that is maybe better to follow.

[croes]

>It means that you have to do it unless you know some specific reason that the requirement doesn't apply in your case.

But that means a valid reason could exist and Google would block those mails too.

[SecretDreams]

Should = internal target

Must = external requirement

I cannot fathom how you think should* would act as a requirement in any sense of the world.

[Arnt]

If you read RFC 2119, you'll see that the definition of SHOULD includes the word must. Perhaps it's easier to understand if I rephrase it as: "If you understand the issue and its consequences, SHOULD means optional. If you don't, SHOULD is equivalent to MUST."

Message-ID has maybe half a dozen types of problem. If you know all of them, leaving it out is up to you.

[gerdesj]

SHOULD is not MUST