RFC decoded
Finding the right document is harder than reading it. Search for the SMTP specification and you land on RFC 821, which still calls itself an Internet Standard while the document that replaced it twice over is labelled one rung lower. Every current email RFC here, the ones that have been quietly amended since publication, and every sentence in each that actually binds an implementation.
Try 821 and 7489 are numbers people are still handed. Both have been replaced.
Every current email RFC
Most of the email stack never leaves Proposed Standard and never needs to. Maturity level says how far a document travelled through the process, not whether it is the one in force, and the two come apart often enough that the label is the last thing worth reading on an RFC.
Transport
1870SMTP Service Extension for Message Size DeclarationThe SIZE extension, which lets a server advertise its maximum message size and lets a client declare the size up front.Internet Standard2034SMTP Service Extension for Returning Enhanced Error CodesThe ENHANCEDSTATUSCODES extension, by which a server advertises that its replies carry RFC 3463 codes.Proposed Standard2920SMTP Service Extension for Command PipeliningCommand pipelining: sending a group of SMTP commands without waiting for each reply.Internet Standard3030SMTP Service Extensions for Transmission of Large and Binary MIME MessagesCHUNKING and BDAT: transferring a message as sized chunks instead of as dot-terminated text.Proposed Standard3461Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)Delivery Status Notifications: how a sender asks for a receipt, and how a receiver is required to answer.Draft Standard3463Enhanced Mail System Status CodesEnhanced mail system status codes: the three-part numbers like 5.1.1 that carry more meaning than a bare 550.Draft Standard3464An Extensible Message Format for Delivery Status NotificationsThe report format a bounce actually uses: a multipart message with a machine-readable part carrying the status code, the reporting MTA and the failed recipient.Draft Standard3885SMTP Service Extension for Message TrackingProposed Standard3886An Extensible Message Format for Message Tracking ResponsesProposed Standard4468Message Submission BURL ExtensionProposed Standard4865SMTP Submission Service Extension for Future Message ReleaseProposed Standard5321Simple Mail Transfer ProtocolThe SMTP protocol itself: how a client and server open a session, identify themselves, hand over an envelope and a message, and what each reply code means.Draft Standard6152SMTP Service Extension for 8-bit MIME TransportThe 8BITMIME extension, which lets a client send message bodies with the high bit set instead of encoding them into 7-bit ASCII.Internet Standard6522The Multipart/Report Media Type for the Reporting of Mail System Administrative MessagesThe multipart/report media type: the container every delivery notification and abuse report is built from.Internet Standard6531SMTP Extension for Internationalized EmailSMTPUTF8: the extension that allows non-ASCII addresses in the envelope.Proposed Standard6710Simple Mail Transfer Protocol Extension for Message Transfer PrioritiesProposed Standard7504SMTP 521 and 556 Reply CodesAdds reply codes 521 and 556 so a host can say plainly that it does not accept mail at all, rather than accepting and discarding it.Proposed Standard7505A "Null MX" No Service Resource Record for Domains That Accept No MailThe null MX record: a single MX pointing at "." to say a domain accepts no mail at all.Proposed StandardMessage format
2045Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message BodiesThe first MIME document: Content-Type, Content-Transfer-Encoding and the header fields that let a message carry something other than plain ASCII text.Draft Standard2046Multipurpose Internet Mail Extensions (MIME) Part Two: Media TypesThe MIME media types: text, image, audio, multipart and the rules for each.Draft Standard2047MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII TextEncoded-words: how to put non-ASCII text into a header, such as a subject line or a display name.Draft Standard2049Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and ExamplesDraft Standard2183Communicating Presentation Information in Internet Messages: The Content-Disposition Header FieldContent-Disposition: whether a part should be shown inline or offered as an attachment, and what to call it.Proposed Standard2231MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and ContinuationsProposed Standard2387The MIME Multipart/Related Content-typeProposed Standard2392Content-ID and Message-ID Uniform Resource LocatorsProposed Standard2557MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)Proposed Standard3676The Text/Plain Format and DelSp ParametersProposed Standard4289Multipurpose Internet Mail Extensions (MIME) Part Four: Registration ProceduresBest Current Practice5147URI Fragment Identifiers for the text/plain Media TypeProposed Standard5322Internet Message FormatThe format of the message itself: headers, the blank line, the body, and the rules for folding, comments and addresses.Draft Standard5536Netnews Article FormatProposed Standard5537Netnews Architecture and ProtocolsProposed Standard6657Update to MIME regarding "charset" Parameter Handling in Textual Media TypesProposed Standard6838Media Type Specifications and Registration ProceduresBest Current Practice6854Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header FieldsAmends RFC 5322 to allow group syntax in the From: and Sender: header fields.Proposed Standard8098Message Disposition NotificationMessage Disposition Notifications: the read receipt, and the rules for asking for one and answering.Internet Standard8315Cancel-Locks in Netnews ArticlesProposed Standard9057Email Author Header FieldAn Author header field, distinguishing who wrote a message from who sent it.Experimental9694Guidelines for the Definition of New Top-Level Media TypesBest Current PracticeAuthentication
5863DomainKeys Identified Mail (DKIM) Development, Deployment, and OperationsDeployment guidance for DKIM: key management, selector strategy, and what to sign.Informational6008Authentication-Results Registration for Differentiating among Cryptographic ResultsProposed Standard6376DomainKeys Identified Mail (DKIM) SignaturesDKIM: signing selected headers and the body with a key published in DNS, so a receiver can verify the message was not altered and came from a domain that holds the key.Internet Standard6377DomainKeys Identified Mail (DKIM) and Mailing ListsWhat mailing lists do to DKIM signatures, and which list behaviours preserve a signature.Best Current Practice6541DomainKeys Identified Mail (DKIM) Authorized Third-Party SignaturesExperimental7208Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1SPF: a DNS record listing which hosts may use a domain in the envelope sender, and how a receiver evaluates it.Proposed Standard7372Email Authentication Status CodesAssigns enhanced status codes for authentication failures, so a rejection can say it was DMARC rather than something generic.Proposed Standard7960Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email FlowsA survey of the ways indirect mail flows break DMARC, and what can and cannot be done about each.Informational8301Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)Retires SHA-1 and 1024-bit RSA as acceptable DKIM choices, raising the floor to SHA-256 and 2048-bit keys.Proposed Standard8463A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)Adds Ed25519 as a DKIM signing algorithm alongside RSA.Proposed Standard8553DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node NamesCleans up the convention of putting underscores in DNS names, such as _dmarc and _domainkey, and registers them properly.Best Current Practice8601Message Header Field for Indicating Message Authentication StatusThe Authentication-Results header: how a receiver records what its own authentication checks concluded.Proposed Standard8616Email Authentication for Internationalized MailHow SPF, DKIM and DMARC behave when domains and local parts are internationalised.Proposed Standard8617The Authenticated Received Chain (ARC) ProtocolARC: a chain of signatures that lets an intermediary record what authentication looked like before it modified a message.Experimental9989Domain-Based Message Authentication, Reporting, and Conformance (DMARC)DMARC: ties SPF and DKIM to the domain a recipient actually sees in From:, and lets that domain publish what a receiver should do when neither aligns.Proposed Standard9990Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate ReportingThe aggregate report: the daily XML a receiver sends back describing what it saw from your domain and what it decided.Proposed Standard9991Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure ReportingThe failure report: a per-message report sent when authentication fails, carrying far more of the message than an aggregate report.Proposed StandardTransport security
3207SMTP Service Extension for Secure SMTP over Transport Layer SecuritySTARTTLS: the SMTP extension that upgrades a plaintext session to TLS after the connection is open.Proposed Standard7672SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)DANE for SMTP: using DNSSEC-signed TLSA records to state which certificate an MX host will present.Proposed Standard7817Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related ProtocolsUpdated rules for checking the certificate a mail server presents: which names count as a match and which no longer do.Proposed Standard8314Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and AccessMakes implicit TLS the default for message submission and retrieval, rather than starting in the clear and upgrading.Proposed Standard8460SMTP TLS ReportingTLS-RPT: a DNS record asking receivers to report TLS negotiation failures they had while delivering to you.Proposed Standard8461SMTP MTA Strict Transport Security (MTA-STS)MTA-STS: a way for a receiving domain to publish, over HTTPS, that senders should require TLS and a valid certificate for its MX hosts.Proposed Standard8689SMTP Require TLS OptionREQUIRETLS: lets a sender mark an individual message as one that must not be delivered without TLS, even if that means bouncing it.Proposed Standard8997Deprecation of TLS 1.1 for Email Submission and AccessDeprecates TLS 1.0 and 1.1 for mail submission and access, leaving 1.2 as the floor.Proposed StandardInternationalization
6530Overview and Framework for Internationalized EmailThe framework for internationalised email: what has to change across the whole stack for non-ASCII addresses to work.Proposed Standard6532Internationalized Email HeadersAllows UTF-8 directly in message headers, rather than encoded into ASCII with RFC 2047 encoded-words.Proposed Standard6533Internationalized Delivery Status and Disposition NotificationsDelivery status notifications for internationalised mail, so a bounce can carry a non-ASCII address.Proposed Standard6856Post Office Protocol Version 3 (POP3) Support for UTF-8Proposed Standard6857Post-Delivery Message Downgrading for Internationalized Email MessagesProposed Standard6858Simplified POP and IMAP Downgrading for Internationalized EmailProposed Standard9755IMAP Support for UTF-8Proposed StandardSubmission and access
1939Post Office Protocol - Version 3POP3: downloading mail from a server, usually deleting it as it goes.Internet Standard1957Some Observations on Implementations of the Post Office Protocol (POP3)Informational2449POP3 Extension MechanismProposed Standard4954SMTP Service Extension for AuthenticationThe AUTH extension: how a client authenticates to a submission server, and which mechanisms are offered.Proposed Standard5248A Registry for SMTP Enhanced Mail System Status CodesThe IANA registry of enhanced mail system status codes, and the process for adding one.Best Current Practice6186Use of SRV Records for Locating Email Submission/Access ServicesSRV records that tell a mail client where to find submission and access services for a domain.Proposed Standard6409Message Submission for MailMessage submission: why mail from a user's client goes to port 587 under authentication, separately from server-to-server relay on 25.Internet Standard8437IMAP UNAUTHENTICATE Extension for Connection ReuseProposed Standard9051Internet Message Access Protocol (IMAP) - Version 4rev2IMAP version 4rev2: reading and managing mail that stays on the server, across multiple clients.Proposed StandardReporting and feedback
2369The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header FieldsThe List-Help, List-Unsubscribe, List-Post and related headers that let a mail client offer list commands directly.Proposed Standard2919List-Id: A Structured Field and Namespace for the Identification of Mailing ListsList-Id: a stable identifier for a mailing list that survives the list changing address.Proposed Standard5965An Extensible Format for Email Feedback ReportsThe Abuse Reporting Format: the structure of a feedback loop report sent when a recipient marks a message as spam.Proposed Standard6449Complaint Feedback Loop Operational RecommendationsOperational recommendations for running and consuming complaint feedback loops at scale.Informational6591Authentication Failure Reporting Using the Abuse Reporting FormatHow to report an authentication failure using the abuse reporting format, as distinct from reporting spam.Proposed Standard6650Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)How feedback loops should be created and consumed: who subscribes, what is redacted, and what a sender is expected to do.Proposed Standard6692Source Ports in Abuse Reporting Format (ARF) ReportsProposed Standard8058Signaling One-Click Functionality for List Email HeadersOne-click unsubscribe: the List-Unsubscribe-Post header that lets a mail client unsubscribe without the user visiting a page.Proposed StandardAnti-abuse and operations
2142Mailbox Names for Common Services, Roles and FunctionsReserves role mailboxes such as abuse@, postmaster@ and security@ for every domain that runs a service.Proposed Standard5068Email Submission Operations: Access and Accountability RequirementsOperational guidance on submission: what a network, a provider and a sender should each do so that mail is accountable.Best Current Practice5782DNS Blacklists and WhitelistsHow a DNS blocklist must behave: the query format, the reply convention, and the test entries every conformant list has to carry.Informational6471Overview of Best Email DNS-Based List (DNSBL) Operational PracticesHow a DNS blocklist should be operated: listing criteria, delisting, transparency and how to shut one down.Informational6647Email Greylisting: An Applicability Statement for SMTPGreylisting: temporarily rejecting a first delivery attempt from an unknown sender and accepting the retry.Proposed StandardArchitecture
1123Requirements for Internet Hosts - Application and SupportThe 1989 host requirements document, which includes the mail section that much later practice still rests on.Internet Standard2181Clarifications to the DNS SpecificationProposed Standard5598Internet Mail ArchitectureA map of the whole email architecture and the vocabulary for it: MUA, MSA, MTA, MDA, and the boundaries between them.Informational7766DNS Transport over TCP - Implementation RequirementsProposed Standard9210DNS Transport over TCP - Operational RequirementsBest Current PracticeWhere this comes from
The metadata is parsed from the RFC Editor's index, which is what records status, what a document replaced, and what has amended it since. The requirements are extracted from the RFC text itself: every sentence carrying an RFC 2119 keyword, with the section it came from. Only the uppercase keywords count, because a lowercase "must" is prose and binds nobody.