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

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

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

Email History through RFCs

Many aspects of email are a lot older than you may think.
There were quite a few people in the early 1970s working out how to provide useful services using ARPANET, the network that evolved over the next 10 or 15 years into the modern Internet.
arpanet3
They used Requests for Comment (RFCs) to document protocol and research, much as is still done today. Here are some of the interesting milestones.
April 1971 [rfc 114]RFC 114 A File Transfer Protocol.[/rfc] One of the earliest services that was deployed so as to be useful to people, rather than a required part of the network infrastructure, was a way to transfer files from one computer to another. In the [rfc 114]earliest versions[/rfc] of the service I can find it could already append text to an existing file. This was soon used for sending short messages, initially to a remote printer from where it would be sent by internal mail, but soon also to a mailbox where they could be read online.
August 1971 [rfc 221]RFC 221 A Mail Box Protocol, Version-2[/rfc] had this prescient paragraph:

Read More