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 6 hours ago | parent | next [-]

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

	▲	jonas21 6 hours ago \| parent \| next [-]
		There are dozens of spam and security settings that admins can change in the Google Workspace console, presumably because different businesses have different requirements. So in practice, there's not just two sets of rules in gmail -- there's probably thousands or millions (however many combinations of settings are actually in use).
	▲	Avamander 5 hours ago \| parent \| prev [-]
		Other anti-spam implementations also punish the lack of Message-ID. There are tools online that highlight this as an issue. This here is a trivial case of simply not testing deliverability at all.

▲

psychoslave 6 hours ago | parent | prev [-]

In my experience, email is an unreliable way to communicate any time-bounded critical information. When I want to be sure an email was transmitted on either side, the only reliable way to ensure this is to use a distinct channel to validate reception and confirm content.

That is, when some hotline tell me that they just sent and email with the information, I ensure they hold the line until I got the actual email and checked it delivers the relevant information to fulfill the intended process. And when I want to make sure an email was received, I call the person and ask to check, waiting until confirmation.

It’s not that much SMTP/IMAP per se as the whole ecosystem. People can legitimately get fatigue of "is it in my junk directory", "it might be relayed but only after the overloaded spam/junk analyzer accept it", or whatever can go wrong in the MUA, MSA, MTA, MX, MDA chain. And of course people can simply lie, and pretend the email was sent/received when they couldn’t bother less with the actual delivery status.

There are of course many cases where emails is fantastic.

	▲	SoftTalker 5 hours ago \| parent [-]
		Email is an unreliable way to communicate any information, in the strictest sense of the word "reliable." The protocol does not guarantee that any email will be delivered, nor does it guarantee that failure will be detected. It's a good-faith effort. The bits could drop on the floor at any point and you might never know.