RFCs
A few days ago, Google started notifying (some) Google Workspace customers of updated spam filter/blocking changes coming to the Gmail email service. They’re moving to more proactively block emails that have headers violating RFC 5322, and it is believed that this is an attempt to help prevent DKIM replay attacks. Read on to learn more about what this means and how it could impact email senders.In the notification below, they indicate that they’ve sent this only to Workspace users they think may be impacted by this change, but truth be told, it affects the entire internet, as it could impact anyone sending email messages to any user at a Google-hosted mailbox.The notification: We’re writing to let you know about an upcoming change to your Gmail services. Gmail will start rejecting messages that are non-compliant with Internet Message Format standards and contain more than one single-instance email header as of April
Here is the scenario. Maybe you’ve just gotten a bounce message that looks like this:Aug 25 11:20:24 s1 postfix/smtp[26906]: 98299221BB: to=, relay=gmail-smtp-in.l.google.com[142.250.141.27]:25, delay=1.2, delays=0.04/0.77/0.2/0.21, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[142.250.141.27] said: 550-5.7.1 [206.125.175.2] Our system has detected that this message is not RFC 550-5.7.1 5322 compliant: duplicate headers. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please review 550 5.7.1 RFC 5322 specifications for more information. j6-20020a637a46000000b0042b3a763e76si3563504pgn.127 – gsmtp (in reply to end of DATA command))Or perhaps it looks like this:Aug 25 12:48:59 s1 postfix/smtp[14180]: C90492056B: to=, relay=aspmx.l.google.com[142.250.141.27]:25, delay=0.69, delays=0.08/0/0.39/0.22, dsn=5.7.1, status=bounced (host aspmx.l.google.com[142.250.141.27] said: 550-5.7.1 [206.125.175.2] Our system has detected that this message is not RFC 550-5.7.1 5322 compliant: 550-5.7.1 Multiple ‘From’ headers found. 550-5.7.1 To reduce the amount of spam sent to Gmail, this message has been 550-5.7.1 blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=RfcMessageNonCompliant 550 5.7.1 and review RFC 5322 specifications for more information.
Last week I talked about one-click unsubscribe and why I don’t think it’s a great process. Basically, my concern is bot clicks. I’ve seen it happen too many times — email security software will scan an email message body and follow all the links in the message. This triggers a one click unsub and can result in people falling off of an email list. Does it happen in the millions? Possibly not, but when it happens to the client when trying to send to themselves, and suddenly their CEO or CMO is mad that messages are no longer be received, it results in a client angry at a CRM or ESP platform. It’s pain, and it’s self-inflicted pain, and a smart sending platform should try to prevent this pain.TL;DR? One click should really be two click. Go read my prior “hot take” for more details.Anyway, a couple of ISP/MBP (mailbox…
Every once in a while we’ll see a rejection from Yahoo that says RFCs 554 5.0.0 Message not accepted due to failed RFC compliance. What does that mean and what can we do about it? It really does mean exactly what it says on the label: there’s something about the message that is not in compliance with any number of RFCs and are not going to accept the message in its current state. When trying to help a colleague diagnose the issue I came up with a list of things to check. Troubleshooting in the email Is there any high ASCII without quoted printable or Base64 encoding in the body or the headers?Is there a Date header? Is there any duplication in header fields?Is there a bare IP address in a link somewhere?Are the line lengths inside the message shorter than 998 characters?Are lines correctly terminated with CR/LF?Is the DKIM…
Independent Submission M. Kucherawy, Ed. Request for Comments: 7489 Category: Informational E. Zwicky, Ed. ISSN: 2070-1721 Yahoo! March 2015 Domain-based Message Authentication, Reporting, and Conformance (DMARC) Abstract Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, […]
Network Working Group P. Resnick, Ed. Request for Comments: 5322 Qualcomm Incorporated Obsoletes: 2822 October 2008 Updates: 4021 Category: Standards Track Internet Message Format Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the […]
Network Working Group J. Klensin Request for Comments: 5321 October 2008 Obsoletes: 2821 Updates: 1123 Category: Standards Track Simple Mail Transfer Protocol Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official […]
DELIVTERMS: The weekly series here on Spam Resource that defines deliverability terminology. Today, I’m going to talk about the Friendly From.What is the friendly from? It’s not quite its own separate header, but it is a field in your from header. It is the text that goes next to your email address in the from header.If the from address header in my email looks like this:From: Al Iverson That means that the from address is aiversontestmail@wombatmail.com and the “friendly from” is “Al Iverson.”Some systems enclose the friendly from in quotes, like this:From: “Al Iverson, not a lawyer” This helps prevent formatting glitches in some cases, like if you include a comma in your friendly from. In that case, if you don’t put the whole thing in quotes, there’s a good chance recipients could end up with a very funky looking from address, depending on how their mail application or webmail…