Useful Request for Comments (RFCs)
Request For Comments (RFCs) are documents published by the Internet Engineering Task Force (IETF) which describe internet operations and protocols. Some are published standards, others are on their way to be standards. Other RFC are published on an experimental or informational basis. There is even some humour.Listed on this page are some prominent RFCs associated with topics covered in the book. If you need a deep understanding of an internet protocol or intend to write software that includes a protocol, the RFCs are the place to start. The principal that drives the IETF is interoperability, meaning that software that follows RFCs has a very good chance of working with other software written by different vendors.
Core Internet Email
RFC 1035 Domain Names – Implementation and Specification
This is the core internet standard on DNS. There are many more associated RFCs but this is where to start. A solid understanding of DNS is essential for understanding email and by extension, deliverability.
RFC 5321 Simple Mail Transfer Protocol
This is where the SMTP protocol is defined, including the 5321.MAILFROM field (also known as the return-path, envelope header, or the bounce address). An understanding of the SMTP protocol is essential for diagnosing many deliverability problems.
RFC 5322 Internet Message Format
This is where the core structure of email messages is defined, including the 5322. From field. This is the visible From address you see in messages. A solid understanding of this RFC is also essential.
RFC 5598 Internet Mail Architecture
This RFC is informational and acts as a lexicon for describing how internet mail works. This is touched on this in the book, when the technical terms for email servers and clients are covered. However, there are many more technical terms and distinctions which are very useful to understand if you plan on having a technical conversation about email.
Multi-purpose Internet Mail Extensions (MIME)
RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
RFC 4021 Registration of Mail and MIME Header Fields
RFC 4288 Media Type Specifications and Registration Procedures
RFC 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
RFC 2387 The MIME Multipart/Related Content-type
While you may take sending a single message with file attachments, inline images, html, and plain text for granted – there was a lot of work done to get internet email to that point. If you intend to write any piece of code which generates or parses MIME encoded messages, I would strongly advise that you familiarise yourself with these RFCs first. A good understanding of MIME, and specifically how boundaries work, is essential for diagnosing certain types of deliverability problems.
Email Authentication
RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
This is the base DKIM specification. DKIM has a lot more associated RFCs of proposed additions and improvements. That’s mainly because for a long time, DKIM was seen as the solution to many problems. That changed a bit when DMARC appeared.
RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
This is where SPF is defined. There is a lot more to the SPF protocol than was covered in the book. Deliverability people need a thorough understanding SPF to do their work properly.
RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
A good understanding of DMARC is needed to correctly understand the symptoms of a mis-configured DMARC deployment.
RFC 7930 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows
This RFC describes the deliverability problems that DMARC can cause when the recipient has their mail programmatically forwarded to another destination. The short answer is SPF alignment gets broken because the forwarder’s IP address is not listed in the (aligned) SPF record. Any process that alters the message subject, body, or certain headers will cause DKIM to break. If you are doing anything with DMARC, understanding the forwarding problem is crucial.
RFC 8601 Message Header Field for Indicating Message Authentication Status
This is the RFC behind the Authentication-Results header. It is probably of academic interest to anyone but those who need to write software that references it.
RFC 8617 The Authenticated Received Chain (ARC) Protocol
ARC is an experimental protocol which is intended to help DMARC overcome indirect mail-flows (i.e., forwarding) between trusted parties. It’s too advanced to cover in the book but you should know about it if you need to do anything with DMARC.
Transport Encryption
RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security
RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
RFC 8460 SMTP TLS Reporting
RFC 8561 SMTP MTA Strict Transport Security (MTA-STS)
Transport (the connection between two machines) encryption is briefly touched upon the book. These RFCs go into a lot more detail about developments in that area. Many modern transport encryption schemes are designed for the modern world, not the world of trust the early internet evolved from. Consequently most of these schemes break interoperability by implementing enforcing, as opposed to opportunistic encryption. Deliverability problems caused by transport encryption are mainly the result of either it not being set up properly at one end, or one end trying to force a particular type of encryption or encryption protocol.
1-click unsubscribe
RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
RFC 8058 Signaling One-Click Functionality for List Email Headers
There are thousands of RFCs. This page will be periodically updated with prominent RFC that may be useful to people in the deliverability field. Ken reads all of the RFCs so you do not have to!