by J.D. Falk
Director of Product Strategy, Receiver Services
The IETF — the Internet Engineering Task Force — is, simply put, the standards body for the internet. As a body, they’ve been responsible for nearly every technical protocol that makes the internet work, from TCP/IP and SMTP to more recent developments like IPv6 and OAuth.
It was a beautiful week to be in Anaheim, even in the ring of hotels surrounding Disneyland — temperatures above 70 degrees F., clear blue Southern California skies, while more than a foot of snow landed on Denver. But the 1,200 attendees of the IETF’s 77th meeting spent most of their time inside fluorescent-lit meeting rooms, engaged in deep engineering debates.
IETF is kind of the opposite of TED, that famous gathering of fast-talking deep thinkers. It still involves some of the smartest people in the world, but IETF meetings are rarely the place to introduce new ideas; it’s where things that have been considered, debated, and usually tried and proven get put down on paper for others to comment upon and refine and eventually implement.
YAM is a good example. Half-jokingly titled Yet Another Mail Working Group, its’ purpose is to take long-established email-related RFCs which are still labeled as Draft Standard or Proposed Standard, and push them along the process towards being a full Internet Standard without making any substantial changes. So what started primarily as a set of minor updates to widely-implemented protocols that were defined years ago has quickly become a complex exercise of finding and discussing flaws in IETF approval processes. There’s very little disagreement about the content of the documents; the debate is how to prove that there’s agreement, and whether that much proof is necessary.
Why is this important, when the basic email standards are already accepted in all the software that matters? The RFC Editor reminds us that many RFCs “do not represent any kind of standard”, so being a full standard has some serious cachet amongst both standards geeks and the engineers who actually write the code based on those standards. And, documents this old & widely implemented sometimes have typos or mistakes which need fixing, or unclear sections in need of better explanation. More than anything else, though, I think it’s a way to say “yep, this is done, let’s move on.”
ARF, the de facto standard abuse reporting format used by nearly every known complaint feedback loop, was already nearly done before being brought to the IETF within a new working group called MARF, which stands for Mail Abuse Reporting Format. The MARF working group’s first meeting took place in Anaheim last Tuesday afternoon. I presented an overview of the history and purpose of feedback loops, and much of the discussion during the session concerned the overlap between ARF and a similar proposal within the wireless world.
It’s now nearly certain that the Abuse Reporting Format, as currently defined in a document called draft-ietf-marf-base, will soon become a Draft Standard RFC essentially unchanged — which is great news for the dozens of mailbox providers already sending ARF messages (many with help from Return Path), and the hundreds of sites receiving and parsing the reports (again, many with help from Return Path). It’s a textbook example of the IETF process: the community came up with an idea, tested it, demonstrated interoperability, and now this established (but still emerging) standard will be published & distributed alongside all the other official internet standards documents. After that, the group plans to add an optional extension to ARF intended for reporting DKIM failures, and move the ARF RFC to full Internet Standard status.
Another development of interest to the email community is Jeff MacDonald’s proposal for a new series of extended SMTP reply codes, documented in draft-macdonald-antispam-registry. Jeff has collated the spam-related SMTP replies from most of the major ISPs, and created a list of codes specific to each category. For example, 4.8.7 would denote a temporary rejection due to excessive complaints, while 5.8.8 is permanent — for both that message, and future messages from the same source.
These are extended reply codes, as defined in RFCs 3463 and 5248, so they’d appear after the base reply code — so the second example above would appear as something like “550 5.8.8 example.com is permanently blocked due to complaints”. Right now, the only extended reply code appropriate for blocking spam or other badness is 5.7.1, which doesn’t inherently provide much additional information. In this independent submission (meaning it hasn’t been taken up by a working group yet), Jeff would like to create a standard way for receiving MTAs to indicate why a message was rejected and whether the next message will be treated the same way, beyond what they’re already saying in the text portion of the reply. That would make it easier for ESPs like our partner e-Dialog, where Jeff works, to automatically respond in the appropriate fashion.
What remains to be seen, in this case, is whether any MTA developers will implement it — either for receiving messages, or when sending. Even if they do, it may be years before these codes become commonplace. So for the moment, while this initiative is worth watching, there’s not much for anyone to do right away unless you’d like to participate in the inevitable interoperability experiments.
These are just three examples of what happened at IETF last week. Most of the attendees were more interested in topics other than email delivery and reporting: there were long meetings about peer-to-peer cacheing, vCard, multipath routing, automatic configuration of hosts, IPv4/IPv6 translation, DNS security, geolocation, and much more. Many of the conversations were clearly fascinating to the people who are interested in the topic, and horribly boring to everyone else. But even when bored, I felt privileged to have the opportunity to participate in this process, and I’m very glad that other people care so much about some of these topics — so I don’t have to.
For more information about IETF meetings, working groups, and processes, see ietf.org.