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.
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.
But the RFC language clearly anticipates there are situations and good reasons leading to a message that does not include a message-id. Google therefore would be rejecting RFC-compliant emails, and they are the ones who have to justify themselves.
Theoretically, anyway, I expect in practice they'll just ignore the issue or have their own good reason. But they should accept emails with no message-id; there it does strain the imagination to see why lacking an ID would make a message unreadable or undeliverable.
There are indeed such situations. Two situations AFAICR, and neither of them apply to when you connect to someone else's MX.
Gmail rejects the vast majority of compliant messages, I think they've stated in public that they reject >99.9% of messages, and hearsay has it that the percentage for with minor errors like this is even higher.
There are good reasons why a message might be unreadable. For example, message-id is often used by the threading algorithms in MUAs and IMAP servers, and many don't test whether their threading code handles ID-less messages. I use one that deduplicates by ID, what do you think it does when the ID is empty or missing? I don't know, I haven't tested and I'm not going to.
- `MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.`
- `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.`
- `MAY: This word, or the adjective "OPTIONAL", mean that an item is truly optional.`
In practical terms:
- MUST: It's always a failure to do this. E.g. you MUST have some form of stored energy in your car for it to propel itself down the highway.
- SHOULD: If you don't do this, it's likely to cause failures unless you really know the situation is one of great exception and have thought about what else this change may affect. E.g. you SHOULD maintain a large distance between yourself and then next vehicle on the highway (an example of an exceptional case might be a standstill backup on the highway).
- MAY: This is something which is actually optional and has negligible impacts to successful operation if you do/don't. E.g. you MAY activate cruise control instead of always manually operating the accelerator.
For your car example as-is it'd probably best be MUST unless there is expectation one might reasonably consider their car exploding a valid scenario. In the real world where the car doesn't actually blow, it'd probably be that you MAY leave your keys in the ignition rather than SHOULD/MUST.
Is that what the spec says? Or is this something that Google decided, by making an optional feature a requirement when interoperating with their systems?
It is something Google decided. SHOULD means the other party should anticipate may not. The party examining a SHOULD and deciding not to do something is obviously not required to consider incompetence of other RFC readers as a reason to global replace SHOULD with SHALL before examining requirements.
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.
So if I send an email that lacks a feature that MUST be there, will the email police come get me? At a certain point, looking for an analogy stops making sense I think.
I mean, kind of, yeah? If you're sending traffic that fails to meet the MUST requirements, you're probably going to be marked as malicious traffic and eventually wind up on spam/bot lists. If you fail to do the SHOULD things, you might find yourself in some odd edge cases of your peers and experience behavior you didn't expect.
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.
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.
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.
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.
Google probably did parse these messages as well-formed before inspecting them and deciding to drop them based on the lack of this field. The RFC imposes no mandatory obligation to deliver messages just because they are well-formed.
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.
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.
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.
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.
Pulling exact quotes out, SHOULD means "there may exist valid reasons in particular circumstances to ignore a particular item" while MAY means "an item is truly optional."
I don't think this can be interpreted as simply "should is optional".
Well… yes… no… SHOULD means that you must either do the thing or understand the consequences of not doing it. That's not simply optional, the two options are to ① spend time on writing code and ② spend time on learning the consequences. Either way you need to think hard and spend time. And that's why the definition of SHOULD includes the word "must".
> but the full implications must be understood and carefully weighed before choosing a different course.
In other words, you better have a damn good reason for deciding not to do it.
And (possibly even more to the point), you must decide not to do it, rather than simply throwing code at the wall until most emails make it through unscathed.
I think that is a bit to easy. MAY is described ar optional.
SHOULD - Should really be there. It's not MUST, you can ignore it but do not come crying if your email is not delivered to some of your customers !
you should have though about that before.
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.