7 ms·

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"

by Arnt 8mo ago

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

L_226 8mo ago
As someone who does systems engineering, the only valid requirements include the word "shall".
- stackskipton 8mo ago
  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.
  - josephg 8mo ago
    > … when dealing with ancient protocols I’m doing some work with an email company at the moment. The company has been in the email space for decades. Holy moly email is just full of stuff like this. There is an insane amount of institutional knowledge about how email actually works - not what the specs say but what email servers need to actually do to process real emails and deal with real email clients and servers. The rfcs try to keep up, but they’re missing a lot of details and all important context for why recommendations are as they are, and what you actually need to do to actually process real email you see in the wild. (And talk to the long tail of email software). This conversation makes me think about cornering some of the engineers with a microphone. It’d be great to talk through the specs with them, to capture some of that missing commentary.
    - gessha 8mo ago
      The Computer History Museum [1] has a YouTube channel where they post interesting interviews. You can pitch it to them. [1] https://computerhistory.org/ https://computerhistory.org/
- opto 8mo ago
  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
  - Arnt 8mo ago
    Happily, the meanings in RFCs are clearly specified, see https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119. Note "the full implications must be understood and carefully weighed before choosing a different course". Gmail and the other big hosters have full-time spam teams who spend a lot of time weighing implications, so I assume the implications of this was weighed.
    - patmorgan23 8mo ago
      And EVERY rfc has a paragraph talking about rfc 2119 in the preamble.
      - prerok 8mo ago
        I guess that's why nobody reads it. /s
    - SAI_Peregrinus 8mo ago
      I feel like "SHOULD" and "SHOULD NOT" are redundant. You end up having to assume someone else treated them as a "MAY". If you control all the endpoints in a private implementation you can just deviate from the standard & not implement a MUST, it's your private implementation. There's thus no difference in public implementations between "SHOULD" and "MAY", and no difference in internal implementations between any of the words. They are therefore redundant, requirements are either mandatory or optional, there's no middle.
- sas224dbm 8mo ago
  "shall" and "must"
st_goliath 8mo ago
> "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.
- Arnt 8mo ago
  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.
  - shadowgovt 8mo ago
    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 8mo ago
      How is not having a message-id a security risk? It seems that Gmail is being pedantic for no reason
      - geocar 8mo ago
        > 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.
almosthere 8mo ago
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 8mo ago
  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.
BeetleB 8mo ago
> 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.
- seb1204 8mo ago
  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.
  - aunderscored 8mo ago
    RFC language is expmicltly defined in 2119[0]. Any other interpretation is incorrect. [0] https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119
    - Alive-in-2025 8mo ago
      Thank you for that. So should is optional, people!
      - sisve 8mo ago
        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.
      - strken 8mo ago
        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".
SecretDreams 8mo ago
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 8mo ago
  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.
deleted 8mo ago
[deleted]
gerdesj 8mo ago
SHOULD is not MUST
Aldipower 8mo ago
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 8mo ago
>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.
5o1ecist 8mo ago
[flagged]

by Arnt 8mo ago

L_226 8mo ago

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

stackskipton 8mo ago
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.
- josephg 8mo ago
  > … when dealing with ancient protocols I’m doing some work with an email company at the moment. The company has been in the email space for decades. Holy moly email is just full of stuff like this. There is an insane amount of institutional knowledge about how email actually works - not what the specs say but what email servers need to actually do to process real emails and deal with real email clients and servers. The rfcs try to keep up, but they’re missing a lot of details and all important context for why recommendations are as they are, and what you actually need to do to actually process real email you see in the wild. (And talk to the long tail of email software). This conversation makes me think about cornering some of the engineers with a microphone. It’d be great to talk through the specs with them, to capture some of that missing commentary.
  - gessha 8mo ago
    The Computer History Museum [1] has a YouTube channel where they post interesting interviews. You can pitch it to them. [1] https://computerhistory.org/ https://computerhistory.org/
opto 8mo ago
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
- Arnt 8mo ago
  Happily, the meanings in RFCs are clearly specified, see https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119. Note "the full implications must be understood and carefully weighed before choosing a different course". Gmail and the other big hosters have full-time spam teams who spend a lot of time weighing implications, so I assume the implications of this was weighed.
  - patmorgan23 8mo ago
    And EVERY rfc has a paragraph talking about rfc 2119 in the preamble.
    - prerok 8mo ago
      I guess that's why nobody reads it. /s
  - SAI_Peregrinus 8mo ago
    I feel like "SHOULD" and "SHOULD NOT" are redundant. You end up having to assume someone else treated them as a "MAY". If you control all the endpoints in a private implementation you can just deviate from the standard & not implement a MUST, it's your private implementation. There's thus no difference in public implementations between "SHOULD" and "MAY", and no difference in internal implementations between any of the words. They are therefore redundant, requirements are either mandatory or optional, there's no middle.
sas224dbm 8mo ago
"shall" and "must"

st_goliath 8mo ago

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

Arnt 8mo ago
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.
- shadowgovt 8mo ago
  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 8mo ago
    How is not having a message-id a security risk? It seems that Gmail is being pedantic for no reason
    - geocar 8mo ago
      > 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.

almosthere 8mo ago

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 8mo ago
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.

BeetleB 8mo ago

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

seb1204 8mo ago
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.
- aunderscored 8mo ago
  RFC language is expmicltly defined in 2119[0]. Any other interpretation is incorrect. [0] https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119
  - Alive-in-2025 8mo ago
    Thank you for that. So should is optional, people!
    - sisve 8mo ago
      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.
    - strken 8mo ago
      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".

SecretDreams 8mo ago

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 8mo ago
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.

deleted 8mo ago

[deleted]

gerdesj 8mo ago

SHOULD is not MUST

Aldipower 8mo ago

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 8mo ago

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

5o1ecist 8mo ago

[flagged]