Tool to audit multiple header emails - recent Google notification

[phyxiis]

Today (at least for us) we were notified of a Google change where any emails being received with multiple headers (ie. To: alex@example.com  To: john@example.com  NOT To: alex@example.com, john@examle.com)  will now be rejected by Google. We've been given a month before Google implements this, without any tool that tells us who is sending these.

So the question posed in several communities is: is there a tool to find these malformed emails so that we can either A) notify the sender/vendor that they'll be rejected unless they reconfigure their email system or B) internal systems that may be using this malformation and we need to either update those systems completely or just reconfigure them.

(rhetorical) I haven't looked at the NDA documentation yet, but I'm not sure this type of change would even be in there. (rhetorical)

[paul113]

Hopefully, they will get a bounce message telling them it was rejected.

[phyxiis]

That’s assuming those senders can receive pounds emails, my primary worry it’s for unmonitored internal systems that send emails/alerts only and do not receive emails or they’re basically vanity email accounts that don’t actually exist

[cryptochrome]

Could you share the complete text of that announcement? We have not received a notification like this, and I would be interested in learning more and what exactly they mean. 

[icrew]

Here’s the announcement we got:

Dear EDU Administrator,

We’re writing to let you know about an upcoming change to your institution's Gmail services. Starting April 24, 2023, Gmail will begin rejecting messages that contain more than one RFC-mandated single instance header in order to better protect you from spam and abuse.

What does this mean for your institution?

If vendors and other institutions your school or university communicates frequently with are currently sending messages with multiple headers, the messages will start being rejected with the error message: “This message is not RFC 5322 compliant,” starting April 24, 2023.

For context, email headers are a set of lines that precede the body of an email message. They contain information about the sender, recipient, subject, the message's route to the recipient's inbox, and how to interpret the body (text, html, image). They also provide information that can be used to verify the authenticity of a message. Therefore, rejecting messages that contain multiple headers protects you from malicious duplicate header exploitation.

The Internet Official Protocol Standards: Internet Message Formats [Request For Comments (RFC) 5322] states that a message must have at most one instance of each of the following headers:

• To
• Cc
• Subject
• Date
• From
• Sender
• Reply-To
• Bcc
• Message-ID
• In-Reply-To
• References

Note: Please see RFC Editor’s Internet Message Format RFC 5322 document for additional information on the headers that are standards-compliant.

What do you need to do?

We recommend distributing this message to vendors and other institutions your school or university communicates frequently with to avoid being impacted by this effort. For more information on support please see Prevent mail to Gmail users from being blocked or sent to spam.

We thank you for your patience and understanding as we make this important change.

Thanks for choosing Google Workspace.

– The Google Workspace Team

[cryptochrome]

Interesting. Thanks for sharing. So they do send out bounce emails, from what I can gather. I am not sure I would worry too much about this, as rejecting emails not conforming to RFC standards is quite common nowadays. Whoever is still sending these "malformed" emails is either having a lot of deliverability issues already or is probably a scammer. 

[phyxiis]

Or possibly a currently working internal system that sends alerts that doesn’t/can’t receive bounced messages. Without Google offering some insight into knowing what will be affected, it’s kind of frustrating. And realistically it’ll probably be nothing that is affected, but worth knowing that

[cryptochrome]

Well the "insight" is there. Everything will be affected that sends "malformed" email, e.g. that don't conform with the official email standards defined in various RFCs. Specifically, if senders put in multiple headers of the same type that are only allowed to exist once, as per RFC. Google's email listed all of them. 

I am surprised Google has let emails like that go through in the past, actually. Most email servers (and email clients) wouldn't know what to do with an email that contains, for example, three different "To:" headers. Who is the actual recipient here? Which mailbox should I deliver this mail to? All three? Just one? Which one?

I would assume these types of emails are extremely rare. You will probably only see them from self-coded things where the developer didn't know what they were doing or most likely, in a malicious context. 

No established email client or mail server would construct emails like that. And most email providers will block this. 

[phyxiis · Accepted solution]

As far as I can tell and have discussed with others in the community, there doesn't seem to be any way to preemptively find these messages. I believe our stance will just be that we'll need to question why the vendor isn't following proper email etiquette, and if any internal systems are sending these malformed emails, then address those once we realize we're not receiving them anymore.