4 ms·

You can argue that you not obligated to use message-id but if you don't use it you should blame only yourself that your messages are not accepted. In requiring

You can argue that you not obligated to use message-id but if you don't use it you should blame only yourself that your messages are not accepted. In requiring message-id I would side with google (though in general I think they anti-spam is too aggressive and lacks ways to report false positives). Full RFC compliance (as in not only MUST but also SHOULD unless you have a very good reason) is the easiest part of making sure your emails will be delivered.

pilif 8mo ago
On the other hand, by erroneously treating a SHOULD as a MUST, I would say that Google is the one who's not RFC-compliant
- deleted 8mo ago
  [deleted]
- FactolSarin 8mo ago
  Google is rejecting it to ensure incoming messages aren't spam. SHOULD means "you should do this unless you have a really, really good reason not to." Do they have a good reason not to? It doesn't seem so, meaning Viva is in the wrong here.
  - davoneus 8mo ago
    No, SHOULD is defined in the RFC, not by colloquial usage. Google is on the wrong, regardless of their "safety" intent. After all, linguistics is full with examples of words that are spelled the same, but have different meaning in different cultures. I'm glad the RFC spelled it out it for everyone.
    - ragall 8mo ago
      The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.
      - pamcake 8mo ago
        When producing a message, it SHOULD have the id. With or withot it is compliant. On the other end, we may receive messages with or without. Both are valid. We MUST therefore accept both variations. The second one is a consequence of the former. So yes Google is the violating party.
      - HDThoreaun 8mo ago
        No it doesnt lmao. It's quoted all over this thread and clearly is not in any way like a MUST
      - Dylan16807 8mo ago
        RFC speak requires you to think for a while about skipping a SHOULD. It doesn't require strong justification.
    - shadowgovt 8mo ago
      if Google's choices are protecting users, they can't be in the wrong. That's the reality of a shared communications infrastructure regardless of what the docs say. When the docs disagree with the reality of threat-actor behavior, reality has to win because reality can't be fooled.
  - fmbb 8mo ago
    Spam senders don’t have pseudorandom number generators?
    - Avamander 8mo ago
      They're more likely to put in the least amount of effort or care the least about the reasons how the header is used later on.
- ragall 8mo ago
  The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.
  - alistairSH 8mo ago
    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. So, it's fairly explicit that the sender should use message-id unless there's a good reason to not do so. The spec is quiet about the recipients behavior (unless there's another spec that calls it out).
    - throw7 8mo ago
      Not a specification but "Be liberal in what you accept?" comes to mind. (which I always personally hated but i'm just one shoveler).
      - ragall 8mo ago
        Postel's law was a precept of the Internet of the 80's and 90's, when due to the primitive software engineering practices at that time, implementations couldn't be tested properly. That lead to many cases of poor interoperability, and it's no longer a good idea: for example, when HTML 5 was designed, they decide to put into the spec how to deal with the frequent errors like mismatched closing tags, etc... because all major implementations were "liberal" in what they accepted, but each in a different way.
- bawolff 8mo ago
  Did i miss the part of the RFC that says google must accept every message? Pretty sure the RFC allows email providers to reject any message they feel like.
- citrin_ru 8mo ago
  RFC cannot force a mail server to accept spam. You may argue that requiring message-id is a bad anti-spam policy but it does reduce amount of spam. In my observations around a half or messages without message-id are spam. I would not use personally this as the only reason to reject a message but I understand why someone may choose to do.
Waterluvian 8mo ago
What is the point of SHOULD then? (No seriously, I’m asking; are there examples of where it’s actually different from a MUST)? Also this reminds me of something I read somewhere a long time ago: when specifying requirements don’t bother with SHOULD. Either you want it or you don’t. Because if it’s not a requirement, some people won’t implement it. I guess the one time it’s good is if you want an optional feature or are moving towards requiring it. In this case Google has decided it’s not an optional feature.
- jagged-chisel 8mo ago
  MUST means omission is unacceptable. SHOULD means MUST unless you have a good, well-reasoned excuse.
  - Brian_K_White 8mo ago
    Incorrect. Not required is not required. You do not need to supply rationale or get agreement by anyone else that your reasons are good in their opinion and not just in your opinion. Should just means the thing is preferred. It's something that is good and useful and helpful to do. That is not "must unless you can convince me that you should be excused".
    - jagged-chisel 8mo ago
      RFC2119 “ 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.”
      - Brian_K_White 8mo ago
        I don't know if you thought you were validating or invalidating my argument, but this says exactly what I said. Further, not only the presense of the words "should" and the doubling down with "recommended", also the absense of the words "must" or "required" or "shall" is pointed. Because those words are used elsewhere. When something is actually required, those words are used, and so when they are not used, it is meaningful. It means no one is free to put their own words into the authors mouths and say "well they didn't say it but obviously they pretty much meant required" when they so pointedly chose not to say required. And it's not a technicality. A thing either is or is not required. There are no other states. The spec does not require it, and so for Google to require it, Google is not adhering to the spec. Since the spec does not require it, you can't say either that it falls under "full implications". "full implications" cannot include "Some servers might require it", because that would be circular logic. No server can require it in the first place.
RHSeeger 8mo ago
> if you don't use it you should blame only yourself that your messages are not accepted I think it's a gray area - If the receiver declines your message because "Message-id" is required - then I blame the receiver; because that's not true - If the receiver declines your message because "most systems do include it, and it's lack of presence is highly correlated with spam email", then it's on the sender Admittedly, the end result is the same.
- mbreese 8mo ago
  I think it's the latter. But, in either case, you're right in that you get the same result. Now, let's assume that if it is the latter (it's spam related), and Google were to accept the message, but then internally bin the message, it would be worse. At least in this case, they are bouncing the message. Because of this, the sender is at least aware that the message wasn't delivered. Also, the author was able to get their mail delivered to a personal gmail.com address. The issue was with a Google Workspace custom email domain. This further makes me think of this as a security/spam related issue. Google is clearly capable of processing the message without a Message-id, they are just refusing for business customers. My takeaway is that I think that Google is doing the least-wrong thing. And by being explicit in how they are handling it, it at least made the debugging for the author possible. Also note: in a quick reading of RFC5321 (SMTP), rejecting messages for "policy reasons" is an acceptable outcome. I'm not sure if it applies completely here. The author should probably also be taking into account RFC5321 (SMTP) instead of just 5322 (message format).
  - pyrale 8mo ago
    > Also, the author was able to get their mail delivered to a personal gmail.com address. The issue was with a Google Workspace custom email domain. This further makes me think of this as a security/spam related issue. Google is clearly capable of processing the message without a Message-id, they are just refusing for business customers. That's the annoying part to me. An email is an email. By applying different rules for rejection on different mailboxes, gmail creates a system where it's harder for would-be implementers to test compliance. If tomorrow gmail creates a new type of mailbox, will there be a third set of rules to have your message delivered?

pilif 8mo ago

On the other hand, by erroneously treating a SHOULD as a MUST, I would say that Google is the one who's not RFC-compliant

deleted 8mo ago
[deleted]
FactolSarin 8mo ago
Google is rejecting it to ensure incoming messages aren't spam. SHOULD means "you should do this unless you have a really, really good reason not to." Do they have a good reason not to? It doesn't seem so, meaning Viva is in the wrong here.
- davoneus 8mo ago
  No, SHOULD is defined in the RFC, not by colloquial usage. Google is on the wrong, regardless of their "safety" intent. After all, linguistics is full with examples of words that are spelled the same, but have different meaning in different cultures. I'm glad the RFC spelled it out it for everyone.
  - ragall 8mo ago
    The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.
    - pamcake 8mo ago
      When producing a message, it SHOULD have the id. With or withot it is compliant. On the other end, we may receive messages with or without. Both are valid. We MUST therefore accept both variations. The second one is a consequence of the former. So yes Google is the violating party.
    - HDThoreaun 8mo ago
      No it doesnt lmao. It's quoted all over this thread and clearly is not in any way like a MUST
    - Dylan16807 8mo ago
      RFC speak requires you to think for a while about skipping a SHOULD. It doesn't require strong justification.
  - shadowgovt 8mo ago
    if Google's choices are protecting users, they can't be in the wrong. That's the reality of a shared communications infrastructure regardless of what the docs say. When the docs disagree with the reality of threat-actor behavior, reality has to win because reality can't be fooled.
- fmbb 8mo ago
  Spam senders don’t have pseudorandom number generators?
  - Avamander 8mo ago
    They're more likely to put in the least amount of effort or care the least about the reasons how the header is used later on.
ragall 8mo ago
The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.
- alistairSH 8mo ago
  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. So, it's fairly explicit that the sender should use message-id unless there's a good reason to not do so. The spec is quiet about the recipients behavior (unless there's another spec that calls it out).
  - throw7 8mo ago
    Not a specification but "Be liberal in what you accept?" comes to mind. (which I always personally hated but i'm just one shoveler).
    - ragall 8mo ago
      Postel's law was a precept of the Internet of the 80's and 90's, when due to the primitive software engineering practices at that time, implementations couldn't be tested properly. That lead to many cases of poor interoperability, and it's no longer a good idea: for example, when HTML 5 was designed, they decide to put into the spec how to deal with the frequent errors like mismatched closing tags, etc... because all major implementations were "liberal" in what they accepted, but each in a different way.
bawolff 8mo ago
Did i miss the part of the RFC that says google must accept every message? Pretty sure the RFC allows email providers to reject any message they feel like.
citrin_ru 8mo ago
RFC cannot force a mail server to accept spam. You may argue that requiring message-id is a bad anti-spam policy but it does reduce amount of spam. In my observations around a half or messages without message-id are spam. I would not use personally this as the only reason to reject a message but I understand why someone may choose to do.

Waterluvian 8mo ago

What is the point of SHOULD then? (No seriously, I’m asking; are there examples of where it’s actually different from a MUST)? Also this reminds me of something I read somewhere a long time ago: when specifying requirements don’t bother with SHOULD. Either you want it or you don’t. Because if it’s not a requirement, some people won’t implement it. I guess the one time it’s good is if you want an optional feature or are moving towards requiring it. In this case Google has decided it’s not an optional feature.

jagged-chisel 8mo ago
MUST means omission is unacceptable. SHOULD means MUST unless you have a good, well-reasoned excuse.
- Brian_K_White 8mo ago
  Incorrect. Not required is not required. You do not need to supply rationale or get agreement by anyone else that your reasons are good in their opinion and not just in your opinion. Should just means the thing is preferred. It's something that is good and useful and helpful to do. That is not "must unless you can convince me that you should be excused".
  - jagged-chisel 8mo ago
    RFC2119 “ 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.”
    - Brian_K_White 8mo ago
      I don't know if you thought you were validating or invalidating my argument, but this says exactly what I said. Further, not only the presense of the words "should" and the doubling down with "recommended", also the absense of the words "must" or "required" or "shall" is pointed. Because those words are used elsewhere. When something is actually required, those words are used, and so when they are not used, it is meaningful. It means no one is free to put their own words into the authors mouths and say "well they didn't say it but obviously they pretty much meant required" when they so pointedly chose not to say required. And it's not a technicality. A thing either is or is not required. There are no other states. The spec does not require it, and so for Google to require it, Google is not adhering to the spec. Since the spec does not require it, you can't say either that it falls under "full implications". "full implications" cannot include "Some servers might require it", because that would be circular logic. No server can require it in the first place.

RHSeeger 8mo ago

> if you don't use it you should blame only yourself that your messages are not accepted I think it's a gray area - If the receiver declines your message because "Message-id" is required - then I blame the receiver; because that's not true - If the receiver declines your message because "most systems do include it, and it's lack of presence is highly correlated with spam email", then it's on the sender Admittedly, the end result is the same.

mbreese 8mo ago
I think it's the latter. But, in either case, you're right in that you get the same result. Now, let's assume that if it is the latter (it's spam related), and Google were to accept the message, but then internally bin the message, it would be worse. At least in this case, they are bouncing the message. Because of this, the sender is at least aware that the message wasn't delivered. Also, the author was able to get their mail delivered to a personal gmail.com address. The issue was with a Google Workspace custom email domain. This further makes me think of this as a security/spam related issue. Google is clearly capable of processing the message without a Message-id, they are just refusing for business customers. My takeaway is that I think that Google is doing the least-wrong thing. And by being explicit in how they are handling it, it at least made the debugging for the author possible. Also note: in a quick reading of RFC5321 (SMTP), rejecting messages for "policy reasons" is an acceptable outcome. I'm not sure if it applies completely here. The author should probably also be taking into account RFC5321 (SMTP) instead of just 5322 (message format).
- pyrale 8mo ago
  > Also, the author was able to get their mail delivered to a personal gmail.com address. The issue was with a Google Workspace custom email domain. This further makes me think of this as a security/spam related issue. Google is clearly capable of processing the message without a Message-id, they are just refusing for business customers. That's the annoying part to me. An email is an email. By applying different rules for rejection on different mailboxes, gmail creates a system where it's harder for would-be implementers to test compliance. If tomorrow gmail creates a new type of mailbox, will there be a third set of rules to have your message delivered?