by J.D. Falk
This week, the Internet Engineering Task Force (IETF) published a number of what they call "RFCs," which originally meant "Requests for Comment" — the standards documents which specify the technical underpinnings of the internet. Two of these, numbered 5321 and 5322, replace earlier documents defining the very core of internet email.
On the surface, each of these seem surprisingly simple; one aims "…to transfer mail reliably and efficiently," while the other defines itself as "…a definition of what message content format is to be passed between systems." Yet without general industry-wide acceptance of (and compliance with) these standards, internet email simply would not exist.
This week also marks ten years since the death of Jon Postel, who arguably had more influence over the creation of the internet than any other single person. One of Jon's most enduring recommendations is to "be conservative in what you send and liberal in what you receive," which Vint Cerf (who had only slightly less influence over the early internet), described as "…a reminder that in a multi-stakeholder world, accommodation and understanding can go a long way towards reaching consensus or, failing that, at least toleration of choices that might not be at the top of everyone's list."
This philosophy is the root of all email, from the earliest standards discussions to the latest theories of authentication, reputation, and deliverability.
The earliest discussions about email standards culminated in August of 1982, when a predecessor to the IETF published RFCs 821, written by Jon Postel, and 822, in which Dave Crocker updated earlier drafts dating all the way back to 1973. With these documents, email between disparate systems became possible, and increasingly common — so that now, with the click of a button, we can take it for granted that a message sent from an Apple iPhone in Denver can pass unchanged through multiple relays and be read by someone running Microsoft Outlook in Berlin.
Actively used standards evolve over time, from those early versions through the familiar 2821 and 2822 in 2001, and now these latest updates. Along the way, some concepts that made sense at the time have faded into obsolescence: for example, RFC 821 included a feature that would display a message on the recipient's screen if they were logged in (very much like today's instant messaging), or email it to them if they weren't. (Imagine if the spammers got hold of that!) Newer ideas, such as MIME (which allows the HTML email so many of today's users are fond of) or sender authentication, have been added in separate documents intended to augment the existing infrastructure — without creating unnecessary incompatibilities.
During these past ten years, many people have concluded that what Jon Postel and Dave Crocker and other smart people defined in 1982 was inherently insecure, inadequate for today's business needs. They say (quite correctly) that it was obviously desined for a non-commercial internet which hasn't existed in decades, with a level of trust that we cannot rely upon today. Yet it is impressive that so many of those early ideas still apply, and still work exactly as intended.
In his more recent role as Senior Technical Advisor to the Messaging Anti-Abuse Working Group (MAAWG), our friend Dave Crocker often reminds us that the purpose of a standard is to define the set of operations required for interoperability — and in this light, RFCs 822 and 821 have succeeded wonderfully.
If someone wants to build something else on top of those core requirements later, they can. Clearly many have. But if they ignore Jon Postel's urging to "be conservative in what you send and liberal in what you receive," they may find that they have made themselves incompatible with the rest of the internet.
That's the inherent power of a standard, whether dry and technical and suitable for coding (like an RFC) or based on a review of business practices like the requirements for a whitelist like Return Path's Sender Score Certified, or a special sending channel like Goodmail's CertifiedEmail. Those who comply with the standard can interoperate effectively with everyone else who complies with the standard. Those who don't, can't. It's worth noting that Jon recognized this possibility early on, and wrote about it in RFC 706 in 1975 — predicting the rise of local blacklists and rate limiting, neither of which were regularly needed in email systems until twenty years later.
The American business instinct is often to send (or sell) extremely liberally, only considering the consequences when sales decline. This practice defies standards for interoperability, and is thus incompatible with the rest of the internet — but it's the state that many email marketers and other inadvertent spammers find themselves in before they start asking for help.
Following the RFCs, many technologists (including myself) would tell them that a well-designed sending-side email server must be conservative, sending only correctly-formed messages which comply with all standards, and a well-designed receive-side email server should be liberal, allowing for minor variances in how the standards are interpreted. This is how our predecessors' technology interoperated in 1982, and it's how everybody's technology interoperates today.
Instead, starting at a higher level, the saner elements of the anti-spam community will tell them that a well-designed email marketing campaign must be conservative, sending only messages that are relevant and desired in the eyes of the recipient — and when it is, this conservatism is rewarded by a liberal receiving policy, allowing those messages through to the inbox.
As you can see, Postel's deceptively simple philosophy permeates the network. Perhaps there is something to be learned for other aspects of our global society as well.
A slightly different version of this article was originally published by Return Path, and is reproduced here with permission.
