Reading RFCs

We mention RFCs quite a lot, both explicitly (RFC 6376 is the specification for DKIM) and implicitly (the 822.From aka bounce address aka return path).

And we have local copies of a bunch of them to make them easy to refer to (SMTP, MIME, Carrier Pigeons …).

They use quite a lot of jargon and implicit information and metadata that’s not really explained terribly clearly anywhere, rather picked up from experience using them.

But now Mark Nottingham has written a great intro “How to Read an RFC“.

It’s good. If you ever need to refer to RFCs you should go and read it.

Related Posts

Does email have a guarantee of delivery?

A client asked me earlier this week what SLAs ISPs provided for email delivery. The short answer is that there isn’t a SLA and that the only guarantee is that the email will get there when it gets there.
But as I was mentioning this to Steve, he pointed out that there was a recent change in the RFCs for email. In both RFC 821/2 and RFC 2821/2 (the original email related RFCs and the update in the early 2000’s) the RFCs stated that once a receiving MTA accepted an email that that MTA was required to either delivery the mail or generate an asynchronous bounce. While this isn’t a standard SLA, it does mean that a 2xy response after DATA meant the email would either be delivered to the user or be sent back to the sender. Despite the RFC requirements some receivers would still drop mail on the floor for various reasons, sometimes intentionally and sometimes not.
RFC 5321/2, the current SMTP standard, still says that once a server accepts the mail it must not lose that mail ‘for frivolous reasons.’ The RFC goes on to admit, though, that in recent years, SMTP servers are under a range of attacks and dropping mail on the floor is not frivolous in those cases.
 

Read More

10 things every mailer must do

A bit of a refresh of a post from 2011: Six best practices for every mailer. I still think best practices are primarily technical and that how senders present themselves to recipients is more about messaging and branding than best practices. These 6 best practices from 2011 are no longer best, these days, they’re the absolute minimum practices for senders.

If you can’t manage to do these, then find someone who can.

Read More

Email Standards Updated

This morning I received notification that the IETF had approved RFC5321 and RFC5322. These two RFCs are standards track and are updating the current email standards RFC821/822 and RFC2821/2822.
MailChannels has a description of the changes between 2821/2822 and 5321/5322. While the new RFCs obsolete the old ones, they are more a clarification than actual changes to the protocols. Dave Crocker had this to say about the new documents.

Read More