Resources / RFC library
The RFCs that define email, current and cited.
Email is not one spec. It is dozens of interlocking RFCs, and many "explainers" still cite obsolete ones. This is a working catalog of 475 RFCs across the whole stack, each marked current, informational, obsolete, or historical, linked to the source.
475 RFCs catalogued 315 current Catalog last verified 2026-06-21
RFCs by category
How the 475 catalogued RFCs distribute across the stack. Bars are scaled to the largest category.
Mail architecture & transport
The overall internet mail model and message-handling architecture.
| RFC | Title | Status |
|---|---|---|
| RFC 821 1982 | Simple Mail Transfer Protocol The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772. Obsoleted by RFC 2821. smtphistoricalobsoleteiana:mail-parameters | Obsolete |
| RFC 974 1986 | Mail routing and the domain system This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. Obsoleted by RFC 2821. smtpdnshistoricalobsolete | Obsolete |
| RFC 1123 1989 | Requirements for Internet Hosts - Application and Support This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. smtpiana:mail-parameters | Current |
| RFC 2142 1997 | Mailbox Names for Common Services, Roles and Functions This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. | Current |
| RFC 5321 2008 | Simple Mail Transfer Protocol This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions.… | Current |
| RFC 5322 2008 | Internet Message Format This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text… | Current |
| RFC 5598 2009 | Internet Mail Architecture Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex… | Informational |
SMTP & submission
The transport protocol and its extensions: how mail moves between servers.
| RFC | Title | Status |
|---|---|---|
| RFC 1425 1993 | SMTP Service Extensions This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. Obsoleted by RFC 1651. smtpobsolete | Obsolete |
| RFC 1426 1993 | SMTP Service Extension for 8bit-MIMEtransport This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP. Obsoleted by RFC 1652. smtpmimeobsolete | Obsolete |
| RFC 1427 1993 | SMTP Service Extension for Message Size Declaration This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. Obsoleted by RFC 1653. smtpobsolete | Obsolete |
| RFC 1651 1994 | SMTP Service Extensions This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. Obsoleted by RFC 1869. smtpobsolete | Obsolete |
| RFC 1652 1994 | SMTP Service Extension for 8bit-MIMEtransport This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. Obsoleted by RFC 6152. smtpmimeobsolete | Obsolete |
| RFC 1845 1995 | SMTP Service Extension for Checkpoint/Restart This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. smtpiana:mail-parameters | Informational |
| RFC 1869 1995 | SMTP Service Extensions This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. Obsoleted by RFC 2821. smtpobsolete | Obsolete |
| RFC 1870 1995 | SMTP Service Extension for Message Size Declaration This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. smtpiana:mail-parameters | Current |
| RFC 1985 1996 | SMTP Service Extension for Remote Message Queue Starting This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. smtpiana:mail-parameters | Current |
| RFC 2033 1996 | Local Mail Transfer Protocol SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. smtp | Informational |
| RFC 2197 1997 | SMTP Service Extension for Command Pipelining This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Obsoleted by RFC 2920. smtpobsolete | Obsolete |
| RFC 2645 1999 | ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. smtpiana:mail-parameters | Current |
| RFC 2821 2001 | Simple Mail Transfer Protocol This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. Obsoleted by RFC 5321. iana:mail-parameters | Obsolete |
| RFC 2852 2000 | Deliver By SMTP Service Extension This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. smtpiana:mail-parametersiana:sieve-extensions | Current |
| RFC 2920 2000 | SMTP Service Extension for Command Pipelining This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. smtpiana:mail-parameters | Current |
| RFC 3030 2000 | SMTP Service Extensions for Transmission of Large and Binary MIME Messages This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. smtpmimeiana:mail-parameters | Current |
| RFC 3207 2002 | SMTP Service Extension for Secure SMTP over Transport Layer Security This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. smtpsubmissiontlsiana:mail-parameters | Current |
| RFC 3848 2004 | ESMTP and LMTP Transmission Types Registration This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. iana:mail-parameters | Current |
| RFC 4141 2005 | SMTP and MIME Extensions for Content Conversion A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white). In a store-and-forward environment, it… smtpmimeiana:mail-parameters | Current |
| RFC 4356 2006 | Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail. One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user… iana:mail-parameters | Current |
| RFC 4409 2006 | Message Submission for Mail This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay and final delivery are unaffected, and continue to use SMTP over port 25. When conforming to this document, message submission… Obsoleted by RFC 6409. smtpsubmissionobsolete | Obsolete |
| RFC 4468 2006 | Message Submission BURL Extension The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to… smtpsubmissioniana:mail-parameters | Current |
| RFC 4865 2007 | SMTP Submission Service Extension for Future Message Release This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are… smtpiana:mail-parameters | Current |
| RFC 5952 2010 | A Recommendation for IPv6 Address Text Representation As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a… iana:mail-parameters | Current |
| RFC 6152 2011 | SMTP Service Extension for 8-bit MIME Transport This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. smtpmimeiana:mail-parameters | Current |
| RFC 6409 2011 | Message Submission for Mail This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay is unaffected, and continues to use SMTP over port 25. When conforming to this document, message submission uses the protocol… smtpsubmissioniana:mail-parameters | Current |
| RFC 6710 2012 | Simple Mail Transfer Protocol Extension for Message Transfer Priorities This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. smtpiana:mail-parameters | Current |
| RFC 6729 2012 | Indicating Email Handling States in Trace Fields This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as… iana:mail-parameters | Current |
| RFC 7293 2014 | The Require-Recipient-Valid-Since Header Field and SMTP Service Extension This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This… smtpiana:email-authiana:mail-parametersiana:message-headers | Current |
| RFC 7504 2015 | SMTP 521 and 556 Reply Codes This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate… smtpdsn | Current |
| RFC 8494 2018 | Multicast Email (MULE) over Allied Communications Publication (ACP) 142 Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in… iana:mail-parameters | Informational |
| RFC 8689 2019 | SMTP Require TLS Option The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required.… smtptlsiana:mail-parametersiana:message-headers | Current |
| RFC 9422 2024 | The LIMITS SMTP Service Extension This document defines a LIMITS extension for the Simple Mail Transfer Protocol (SMTP), including submission, as well as the Local Mail Transfer Protocol (LMTP). It also defines an associated limit registry. The extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol… smtpiana:mail-parameters | Current |
Authentication (SPF, DKIM, DMARC, ARC, BIMI)
Proving a domain authorized the mail, and reporting on it.
| RFC | Title | Status |
|---|---|---|
| RFC 4405 2006 | SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers… spfhistoricalobsoleteiana:mail-parameters | Historical |
| RFC 4406 2006 | Sender ID: Authenticating E-Mail Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the… spfhistoricalobsolete | Historical |
| RFC 4407 2006 | Purported Responsible Address in E-Mail Messages This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community. spfhistoricalobsolete | Historical |
| RFC 4408 2006 | Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the… Obsoleted by RFC 7208. spfobsolete | Obsolete |
| RFC 4870 2007 | Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) "DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email. This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the… Obsoleted by RFC 4871. dkimhistoricalobsolete | Obsolete |
| RFC 4871 2007 | DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert… Obsoleted by RFC 6376. dkimobsolete | Obsolete |
| RFC 5451 2009 | Message Header Field for Indicating Message Authentication Status This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. Obsoleted by RFC 7001. authentication-resultsobsoleteiana:email-auth | Obsolete |
| RFC 5518 2009 | Vouch By Reference This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. authentication-resultsdnsiana:message-headers | Current |
| RFC 5585 2009 | DomainKeys Identified Mail (DKIM) Service Overview This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for… dkim | Informational |
| RFC 5617 2009 | DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise… dkimhistoricalobsoleteiana:email-auth | Historical |
| RFC 5863 2010 | DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations… dkim | Informational |
| RFC 6008 2010 | Authentication-Results Registration for Differentiating among Cryptographic Results This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. iana:email-auth | Current |
| RFC 6212 2011 | Authentication-Results Registration for Vouch by Reference Results This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. iana:email-auth | Current |
| RFC 6376 2011 | DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the… dkimmailing-listiana:message-headers | Current |
| RFC 6377 2011 | DomainKeys Identified Mail (DKIM) and Mailing Lists DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). This memo documents an Internet Best Current Practice. dkimmailing-list | Current |
| RFC 6541 2012 | DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. This document defines an Experimental Protocol for the Internet community. dkimiana:email-auth | Informational |
| RFC 6651 2012 | Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. arffblanti-abusedkim | Current |
| RFC 6652 2012 | Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. arffblanti-abusespf | Current |
| RFC 7001 2013 | Message Header Field for Indicating Message Authentication Status This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to… Obsoleted by RFC 7601. authentication-resultsobsolete | Obsolete |
| RFC 7208 2014 | Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains… spfiana:message-headers | Current |
| RFC 7281 2014 | Authentication-Results Registration for S/MIME Signature Verification RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication- Results header field for S/MIME-related signature checks. authentication-resultssmimeiana:email-auth | Informational |
| RFC 7372 2014 | Email Authentication Status Codes This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures. This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document. dsnanti-abuseauthentication-results | Current |
| RFC 7410 2014 | A Property Types Registry for the Authentication-Results Header Field This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. Obsoleted by RFC 7601. authentication-results | Obsolete |
| RFC 7489 2015 | Domain-based Message Authentication, Reporting, and Conformance (DMARC) Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to… Obsoleted by RFC 9989. dmarcobsolete | Obsolete |
| RFC 7601 2015 | Message Header Field for Indicating Message Authentication Status This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to… Obsoleted by RFC 8601. authentication-resultsobsoleteiana:email-auth | Obsolete |
| RFC 7960 2016 | Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's… dmarcmailing-list | Informational |
| RFC 8301 2018 | Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. dkim | Current |
| RFC 8463 2018 | A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm. dkim | Current |
| RFC 8601 2019 | Message Header Field for Indicating Message Authentication Status This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to… authentication-resultsiana:email-authiana:message-headers | Current |
| RFC 8616 2019 | Email Authentication for Internationalized Mail Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This… spfdkimdmarcauthentication-resultsinternationalization | Current |
| RFC 8617 2019 | The Authenticated Received Chain (ARC) Protocol The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication… dkimarcauthentication-resultsmailing-listiana:email-authiana:message-headers | Informational |
| RFC 8904 2020 | DNS Whitelist (DNSWL) Email Authentication Method Extension This document describes an email authentication method compliant with RFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords. This document does not consider blacklists. anti-abusednswlauthentication-resultsdnsiana:email-auth | Informational |
| RFC 9091 2021 | Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains Domain-based Message Authentication, Reporting, and Conformance (DMARC), defined in RFC 7489, permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail-receiving organization can use to improve mail handling. DMARC distinguishes the portion of a name that is… Obsoleted by RFC 9989. dmarcobsolete | Obsolete |
| RFC 9989 2026 | Domain-Based Message Authentication, Reporting, and Conformance (DMARC) This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use… dmarciana:email-auth | Current |
| RFC 9990 2026 | Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified… dsndmarc | Current |
| RFC 9991 2026 | Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports", or "failed message reports", which provide details about individual messages that failed to authenticate… arffblanti-abusedmarc | Current |
Anti-abuse, DNSBLs, feedback loops
Spam control, blocklists and allowlists, greylisting, and abuse reporting.
| RFC | Title | Status |
|---|---|---|
| RFC 2505 1999 | Anti-Spam Recommendations for SMTP MTAs This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. smtpspamanti-abuse | Current |
| RFC 2635 1999 | DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. This memo provides information for the Internet community. spamanti-abuse | Informational |
| RFC 3098 2001 | How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. This memo provides information for the Internet community. spamanti-abuse | Informational |
| RFC 3865 2004 | A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. smtpanti-abuseiana:mail-parametersiana:message-headers | Current |
| RFC 5068 2007 | Email Submission Operations: Access and Accountability Requirements Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve… smtpsubmissionanti-abuse | Current |
| RFC 5782 2010 | DNS Blacklists and Whitelists The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used… anti-abusednsbldnswldns | Informational |
| RFC 5965 2010 | An Extensible Format for Email Feedback Reports This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. arffblanti-abuse | Current |
| RFC 6449 2011 | Complaint Feedback Loop Operational Recommendations Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry… arffblanti-abuse | Informational |
| RFC 6471 2012 | Overview of Best Email DNS-Based List (DNSBL) Operational Practices The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by… anti-abusednsbldns | Informational |
| RFC 6647 2012 | Email Greylisting: An Applicability Statement for SMTP This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. smtpanti-abusegreylisting | Current |
| RFC 6650 2012 | Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can… arffblanti-abuse | Current |
Delivery status & feedback (DSN, MDN, ARF, FBL)
Bounces, read receipts, abuse reports, and feedback loops.
| RFC | Title | Status |
|---|---|---|
| RFC 1891 1996 | SMTP Service Extension for Delivery Status Notifications This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both… Obsoleted by RFC 3461. smtpdsnobsolete | Obsolete |
| RFC 1892 1996 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. Obsoleted by RFC 3462. mimedsnobsolete | Obsolete |
| RFC 1893 1996 | Enhanced Mail System Status Codes There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes… Obsoleted by RFC 3463. dsnobsolete | Obsolete |
| RFC 1894 1996 | An Extensible Message Format for Delivery Status Notifications This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. Obsoleted by RFC 3464. dsnobsolete | Obsolete |
| RFC 2034 1996 | SMTP Service Extension for Returning Enhanced Error Codes This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. smtpdsniana:mail-parameters | Current |
| RFC 3461 2003 | Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that… smtpdsniana:mail-parametersiana:sieve-extensions | Current |
| RFC 3462 2003 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to… Obsoleted by RFC 6522. mimedsnobsolete | Obsolete |
| RFC 3463 2003 | Enhanced Mail System Status Codes This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. dsn | Current |
| RFC 3464 2003 | An Extensible Message Format for Delivery Status Notifications This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status… dsn | Current |
| RFC 3885 2004 | SMTP Service Extension for Message Tracking This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. smtpmessage-trackingiana:mail-parameters | Current |
| RFC 3886 2004 | An Extensible Message Format for Message Tracking Responses Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This… mimemessage-tracking | Current |
| RFC 3887 2004 | Message Tracking Query Protocol Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the… message-tracking | Current |
| RFC 3888 2004 | Message Tracking Model and Requirements Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message… message-tracking | Informational |
| RFC 5248 2008 | A Registry for SMTP Enhanced Mail System Status Codes The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status… dsn | Current |
| RFC 6522 2012 | The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all… mimedsn | Current |
| RFC 8098 2017 | Message Disposition Notification This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications… mimemdn | Current |
Mailing lists & unsubscribe
List headers and one-click unsubscribe.
| RFC | Title | Status |
|---|---|---|
| RFC 2369 1998 | The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or… headersmailing-list | Current |
| RFC 2919 2001 | List-Id: A Structured Field and Namespace for the Identification of Mailing Lists Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list… headersmailing-list | Current |
| RFC 8058 2017 | Signaling One-Click Functionality for List Email Headers This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field. headersmailing-listunsubscribeiana:message-headers | Current |
MIME & content
How message bodies, attachments, and media types are structured.
| RFC | Title | Status |
|---|---|---|
| RFC 1341 1992 | MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. Obsoleted by RFC 1521. mimeobsolete | Obsolete |
| RFC 1521 1993 | MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. Obsoleted by RFC 2045. mimeobsolete | Obsolete |
| RFC 1766 1995 | Tags for the Identification of Languages This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. Obsoleted by RFC 3066. internationalizationobsolete | Obsolete |
| RFC 2045 1996 | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies This initial document specifies the various headers used to describe the structure of MIME messages. mime | Current |
| RFC 2046 1996 | Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types This second document defines the general structure of the MIME media typing system and defines an initial set of media types. mime | Current |
| RFC 2048 1996 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and… Obsoleted by RFC 4288. mimeobsolete | Obsolete |
| RFC 2049 1996 | Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. mime | Current |
| RFC 2110 1997 | MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. Obsoleted by RFC 2557. mimeobsoleteiana:message-headers | Obsolete |
| RFC 2111 1997 | Content-ID and Message-ID Uniform Resource Locators The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. Obsoleted by RFC 2392. mimeuriobsolete | Obsolete |
| RFC 2231 1997 | MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. mimeheadersinternationalization | Current |
| RFC 2387 1998 | The MIME Multipart/Related Content-type This document defines the Multipart/Related content-type and provides examples of its use. mime | Current |
| RFC 2392 1998 | Content-ID and Message-ID Uniform Resource Locators The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. mimeuri | Current |
| RFC 2557 1999 | MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same… mimeiana:message-headers | Current |
| RFC 2646 1999 | The Text/Plain Format Parameter This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. Obsoleted by RFC 3676. mimeobsolete | Obsolete |
| RFC 2912 2000 | Indicating Media Features for MIME Content This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. mime | Current |
| RFC 3676 2004 | The Text/Plain Format and DelSp Parameters This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations,… mime | Current |
| RFC 3798 2004 | Message Disposition Notification This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs)… Obsoleted by RFC 8098. mimemdnediobsoleteiana:message-headers | Obsolete |
| RFC 4288 2005 | Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Obsoleted by RFC 6838. mimeobsolete | Obsolete |
| RFC 4289 2005 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. mimeobsolete | Current |
| RFC 6838 2013 | Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. mime | Current |
| RFC 6839 2013 | Additional Media Type Structured Syntax Suffixes A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der",… mime | Informational |
| RFC 9239 2022 | Updates to ECMAScript Media Types This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation… mime | Informational |
Message format & headers
The header fields and message syntax every mail carries.
| RFC | Title | Status |
|---|---|---|
| RFC 822 1982 | STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of… Obsoleted by RFC 2822. headersobsolete | Obsolete |
| RFC 1342 1992 | Representation of Non-ASCII Text in Internet Message Headers This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC 822 message headers. Obsoleted by RFC 1522. mimeheadersinternationalizationobsolete | Obsolete |
| RFC 1522 1993 | MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521. Obsoleted by RFC 2045. mimeheadersinternationalizationobsolete | Obsolete |
| RFC 1806 1995 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community. Obsoleted by RFC 2183. headersobsolete | Obsolete |
| RFC 2047 1996 | MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. mimeheadersinternationalization | Current |
| RFC 2068 1997 | Hypertext Transfer Protocol -- HTTP/1.1 The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. Obsoleted by RFC 2616. iana:message-headers | Obsolete |
| RFC 2076 1997 | Common Internet Message Headers This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. headers | Informational |
| RFC 2183 1997 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). headers | Current |
| RFC 2616 1999 | Hypertext Transfer Protocol -- HTTP/1.1 HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. Obsoleted by RFC 7230. iana:message-headers | Obsolete |
| RFC 3282 2002 | Content Language Headers This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. headersinternationalization | Current |
| RFC 3834 2004 | Recommendations for Automatic Responses to Electronic Mail This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is… headersiana:message-headers | Current |
| RFC 3864 2004 | Registration Procedures for Message Header Fields This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. headersiana:message-headers | Current |
| RFC 4021 2005 | Registration of Mail and MIME Header Fields This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. mimeheadersiana:message-headers | Current |
| RFC 5064 2007 | The Archived-At Message Header Field This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. headersmailing-listuriiana:message-headers | Current |
| RFC 6758 2012 | Tunneling of SMTP Message Transfer Priorities This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes. headersiana:message-headers | Informational |
| RFC 6854 2013 | Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations. headersiana:message-headers | Current |
| RFC 8255 2017 | Multiple Language Content Type This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email… headersinternationalizationiana:message-headers | Current |
| RFC 9057 2021 | Email Author Header Field Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field. This was not a problem until development of stringent protections on use of the From:… headers | Informational |
| RFC 9110 2022 | HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements,… iana:message-headers | Current |
| RFC 9228 2022 | Delivered-To Email Header Field The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In… headers | Informational |
| RFC 9477 2023 | Complaint Feedback Loop Address Header This document describes a method that allows a Message Originator to specify a Complaint Feedback Loop (CFBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a… headersarffblanti-abuse | Informational |
Transport security & DNS (DANE, MTA-STS, TLS-RPT, DNSSEC)
Encrypting server-to-server mail and anchoring it in DNS.
| RFC | Title | Status |
|---|---|---|
| RFC 1034 1987 | Domain names - concepts and facilities This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. dns | Current |
| RFC 1035 1987 | Domain names - implementation and specification This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. dns | Current |
| RFC 1912 1996 | Common DNS Operational and Configuration Errors This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. dns | Informational |
| RFC 1982 1996 | Serial Number Arithmetic The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. dns | Current |
| RFC 1995 1996 | Incremental Zone Transfer in DNS This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. dns | Current |
| RFC 1996 1996 | A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. dns | Current |
| RFC 2104 1997 | HMAC: Keyed-Hashing for Message Authentication This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information… tls | Informational |
| RFC 2136 1997 | Dynamic Updates in the Domain Name System (DNS UPDATE) Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. dns | Current |
| RFC 2137 1997 | Secure Domain Name System Dynamic Update This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. Obsoleted by RFC 3007. dnsdnssecobsolete | Obsolete |
| RFC 2181 1997 | Clarifications to the DNS Specification This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. dns | Current |
| RFC 2246 1999 | The TLS Protocol Version 1.0 This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Obsoleted by RFC 4346. tlshistoricalobsolete | Obsolete |
| RFC 2308 1998 | Negative Caching of DNS Queries (DNS NCACHE) RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. dns | Current |
| RFC 2782 2000 | A DNS RR for specifying the location of services (DNS SRV) This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. dns | Current |
| RFC 2845 2000 | Secret Key Transaction Authentication for DNS (TSIG) This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. Obsoleted by RFC 8945. dns | Obsolete |
| RFC 2930 2000 | Secret Key Establishment for DNS (TKEY RR) This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. dns | Current |
| RFC 3007 2000 | Secure Domain Name System (DNS) Dynamic Update This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. dnsdnssec | Current |
| RFC 3226 2001 | DNSSEC and IPv6 A6 aware server/resolver message size requirements This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS… dnsdnssec | Current |
| RFC 3596 2003 | DNS Extensions to Support IP Version 6 This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional… dns | Current |
| RFC 3658 2003 | Delegation Signer (DS) Resource Record (RR) The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational… Obsoleted by RFC 4033. dnsdnssecobsolete | Obsolete |
| RFC 4033 2005 | DNS Security Introduction and Requirements The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the… dnsdnssec | Current |
| RFC 4034 2005 | Resource Records for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and… dnsdnssec | Current |
| RFC 4035 2005 | Protocol Modifications for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept… dnsdnssec | Current |
| RFC 4509 2006 | Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. dnsdnssec | Current |
| RFC 4592 2006 | The Role of Wildcards in the Domain Name System This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. dns | Current |
| RFC 4635 2006 | HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation… Obsoleted by RFC 8945. dns | Obsolete |
| RFC 5011 2007 | Automated Updates of DNS Security (DNSSEC) Trust Anchors This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and,… dnsdnssec | Current |
| RFC 5155 2008 | DNS Security (DNSSEC) Hashed Authenticated Denial of Existence The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of… dnsdnssec | Current |
| RFC 5246 2008 | The Transport Layer Security (TLS) Protocol Version 1.2 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Obsoleted by RFC 8446. tls | Obsolete |
| RFC 5280 2008 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate… tlsiana:email-auth | Current |
| RFC 5702 2009 | Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). dnsdnssec | Current |
| RFC 5936 2010 | DNS Zone Transfer Protocol (AXFR) The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be… dns | Current |
| RFC 6125 2011 | Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. Obsoleted by RFC 9525. tls | Obsolete |
| RFC 6186 2011 | Use of SRV Records for Locating Email Submission/Access Services This specification describes how SRV records can be used to locate email services. submissionimappop3dns | Current |
| RFC 6605 2012 | Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. dnsdnssec | Current |
| RFC 6698 2012 | The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change… dnsdnssecdanetls | Current |
| RFC 6781 2012 | DNSSEC Operational Practices, Version 2 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.… dnsdnssec | Informational |
| RFC 6840 2013 | Clarifications and Implementation Notes for DNS Security (DNSSEC) This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC… dnsdnssec | Current |
| RFC 6891 2013 | Extension Mechanisms for DNS (EDNS(0)) The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0))… dns | Current |
| RFC 6960 2013 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. tls | Current |
| RFC 6962 2013 | Certificate Transparency This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is… Obsoleted by RFC 9162. tlsobsolete | Obsolete |
| RFC 6975 2013 | Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC) The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms… dnsdnssec | Current |
| RFC 7344 2014 | Automating DNSSEC Delegation Trust Maintenance This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. dnsdnssec | Current |
| RFC 7477 2015 | Child-to-Parent Synchronization in DNS This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy. dns | Current |
| RFC 7505 2015 | A "Null MX" No Service Resource Record for Domains That Accept No Mail Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes… smtpdns | Current |
| RFC 7525 2015 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This… Obsoleted by RFC 9325. tlsobsolete | Obsolete |
| RFC 7671 2015 | The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. dnsdnssecdanetls | Current |
| RFC 7672 2015 | SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security… smtpdnsdnssecdanetls | Current |
| RFC 7673 2015 | Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers).… dnsdnssecdanetls | Current |
| RFC 7766 2016 | DNS Transport over TCP - Implementation Requirements This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. dns | Current |
| RFC 7871 2016 | Client Subnet in DNS Queries This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. dns | Informational |
| RFC 7929 2016 | DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email… dnsdnssecdaneopenpgp | Informational |
| RFC 8078 2017 | Managing DS Records from the Parent via CDS/CDNSKEY RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated… dnsdnssec | Current |
| RFC 8162 2017 | Using Secure DNS to Associate Certificates with Domain Names for S/MIME This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. dnsdnssecdanesmime | Informational |
| RFC 8198 2017 | Aggressive Use of DNSSEC-Validated Cache The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource… dnsdnssec | Current |
| RFC 8310 2018 | Usage Profiles for DNS over TLS and DNS over DTLS This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several… dnstls | Current |
| RFC 8314 2018 | Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409. smtpsubmissionimappop3tlsiana:mail-parameters | Current |
| RFC 8446 2018 | The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new… tls | Current |
| RFC 8460 2018 | SMTP TLS Reporting A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted… smtpdnstls-rpttlsiana:message-headers | Current |
| RFC 8461 2018 | SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. smtpdnsmta-ststls | Current |
| RFC 8484 2018 | DNS Queries over HTTPS (DoH) This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. dnstls | Current |
| RFC 8499 2019 | DNS Terminology The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This… Obsoleted by RFC 9499. dnsobsolete | Obsolete |
| RFC 8624 2019 | Algorithm Implementation Requirements and Usage Guidance for DNSSEC The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one… Obsoleted by RFC 9904. dnsdnssec | Obsolete |
| RFC 8901 2020 | Multi-Signer DNSSEC Models Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management… dnsdnssec | Informational |
| RFC 8996 2021 | Deprecating TLS 1.0 and TLS 1.1 This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate… tls | Current |
| RFC 9103 2021 | DNS Zone Transfer over TLS DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of… dns | Current |
| RFC 9156 2021 | DNS Query Name Minimisation to Improve Privacy This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. dns | Current |
| RFC 9162 2021 | Certificate Transparency Version 2.0 This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the… tls | Informational |
| RFC 9266 2022 | Channel Bindings for TLS 1.3 This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677. tlssasl | Current |
| RFC 9276 2022 | Guidance for NSEC3 Parameter Settings NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience.… dnsdnssec | Current |
| RFC 9325 2022 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites… tls | Current |
| RFC 9364 2023 | DNS Security Extensions (DNSSEC) This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state… dnsdnssec | Current |
| RFC 9460 2023 | Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol… dns | Current |
| RFC 9499 2024 | DNS Terminology The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document… dns | Current |
TLS, SASL & client authentication
How clients authenticate, and the TLS/OAuth surfaces email relies on.
| RFC | Title | Status |
|---|---|---|
| RFC 2222 1997 | Simple Authentication and Security Layer (SASL) This document describes a method for adding authentication support to connection-based protocols. Obsoleted by RFC 4422. saslobsolete | Obsolete |
| RFC 2831 2000 | Using Digest Authentication as a SASL Mechanism This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. Obsoleted by RFC 6331. saslhistoricalobsolete | Obsolete |
| RFC 4422 2006 | Simple Authentication and Security Layer (SASL) The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to… sasl | Current |
| RFC 4616 2006 | The PLAIN Simple Authentication and Security Layer (SASL) Mechanism This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. sasl | Current |
| RFC 4954 2007 | SMTP Service Extension for Authentication This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple… smtpsubmissionsasliana:mail-parameters | Current |
| RFC 4959 2007 | IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when… imapsasliana:imap-capabilities | Current |
| RFC 5034 2007 | The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this… pop3sasl | Current |
| RFC 5801 2010 | Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more… sasl | Current |
| RFC 5802 2010 | Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism… sasl | Current |
| RFC 6749 2012 | The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and… oauth | Current |
| RFC 6750 2012 | The OAuth 2.0 Authorization Framework: Bearer Token Usage This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in… oauth | Current |
| RFC 7628 2015 | A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple… sasloauth | Current |
| RFC 7636 2015 | Proof Key for Code Exchange by OAuth Public Clients OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). oauth | Current |
| RFC 7677 2015 | SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802. sasl | Current |
| RFC 8628 2019 | OAuth 2.0 Device Authorization Grant The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like… oauth | Current |
| RFC 9700 2025 | Best Current Practice for OAuth 2.0 Security This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of… oauth | Current |
Secure mail (S/MIME, OpenPGP)
End-to-end signing and encryption of message content.
| RFC | Title | Status |
|---|---|---|
| RFC 1847 1995 | Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community.… mimesmimeopenpgp | Current |
| RFC 2015 1996 | MIME Security with Pretty Good Privacy (PGP) This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. mimeopenpgpobsolete | Current |
| RFC 2632 1999 | S/MIME Version 3 Certificate Handling S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure… Obsoleted by RFC 3850. smimeobsolete | Obsolete |
| RFC 2633 1999 | S/MIME Version 3 Message Specification This document describes a protocol for adding cryptographic signature and encryption services to MIME data. Obsoleted by RFC 3851. smimeobsolete | Obsolete |
| RFC 3156 2001 | MIME Security with OpenPGP This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. mimeopenpgp | Current |
| RFC 3850 2004 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key… Obsoleted by RFC 5750. smimeobsolete | Obsolete |
| RFC 3851 2004 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This… Obsoleted by RFC 5751. smimeobsolete | Obsolete |
| RFC 4880 2007 | OpenPGP Message Format This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with… Obsoleted by RFC 9580. openpgpobsolete | Obsolete |
| RFC 5652 2009 | Cryptographic Message Syntax (CMS) This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. smime | Current |
| RFC 5750 2010 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public… Obsoleted by RFC 8550. smimeobsolete | Obsolete |
| RFC 5751 2010 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This… Obsoleted by RFC 8551. smimeobsolete | Obsolete |
| RFC 8550 2019 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280 ("Internet X.509 Public Key… smime | Current |
| RFC 8551 2019 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This… smime | Current |
| RFC 9216 2022 | S/MIME Example Keys and Certificates The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples. smime | Informational |
| RFC 9580 2024 | OpenPGP This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a… openpgp | Current |
| RFC 9788 2025 | Header Protection for Cryptographically Protected Email S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of email message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC 8551) to… headerssmimeopenpgpiana:mail-parametersiana:message-headers | Current |
IMAP (mailbox access)
Reading and managing mail stored on a server.
| RFC | Title | Status |
|---|---|---|
| RFC 1064 1988 | Interactive Mail Access Protocol: Version 2 This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested. Obsoleted by RFC 1176. imaphistoricalobsolete | Obsolete |
| RFC 1176 1990 | Interactive Mail Access Protocol: Version 2 This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol… imaphistoricalobsolete | Informational |
| RFC 1203 1991 | Interactive Mail Access Protocol: Version 3 This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard. imaphistoricalobsolete | Historical |
| RFC 1730 1994 | Internet Message Access Protocol - Version 4 The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server. Obsoleted by RFC 2060. imapobsolete | Obsolete |
| RFC 1731 1994 | IMAP4 Authentication Mechanisms The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. imapsaslobsolete | Current |
| RFC 2060 1996 | Internet Message Access Protocol - Version 4rev1 The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. Obsoleted by RFC 3501. imapobsolete | Obsolete |
| RFC 2061 1996 | IMAP4 Compatibility with IMAP2bis This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of… imapobsolete | Informational |
| RFC 2062 1996 | Internet Message Access Protocol - Obsolete Syntax This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. imap | Informational |
| RFC 2086 1997 | IMAP4 ACL extension The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. Obsoleted by RFC 4314. imapobsolete | Obsolete |
| RFC 2087 1997 | IMAP4 QUOTA extension The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. Obsoleted by RFC 9208. imapobsolete | Obsolete |
| RFC 2088 1997 | IMAP4 non-synchronizing literals The Internet Message Access Protocol Obsoleted by RFC 7888. imapobsolete | Obsolete |
| RFC 2095 1997 | IMAP/POP AUTHorize Extension for Simple Challenge/Response This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Obsoleted by RFC 2195. imappop3saslobsolete | Obsolete |
| RFC 2177 1997 | IMAP4 IDLE command This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. imapiana:imap-capabilities | Current |
| RFC 2192 1997 | IMAP URL Scheme This document defines a URL scheme for referencing objects on an IMAP server. Obsoleted by RFC 5092. imapuriobsolete | Obsolete |
| RFC 2193 1997 | IMAP4 Mailbox Referrals Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. imapiana:imap-capabilities | Current |
| RFC 2195 1997 | IMAP/POP AUTHorize Extension for Simple Challenge/Response This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. imappop3sasl | Current |
| RFC 2221 1997 | IMAP4 Login Referrals When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. imapiana:imap-capabilities | Current |
| RFC 2244 1997 | ACAP -- Application Configuration Access Protocol The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. imap | Current |
| RFC 2342 1998 | IMAP4 Namespace This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. imapiana:imap-capabilities | Current |
| RFC 2595 1999 | Using TLS with IMAP, POP3 and ACAP Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. imappop3tls | Current |
| RFC 2683 1999 | IMAP4 Implementation Recommendations The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This… imap | Informational |
| RFC 2971 2000 | IMAP4 ID extension This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more… imapiana:imap-capabilities | Current |
| RFC 3348 2002 | The Internet Message Action Protocol (IMAP4) Child Mailbox Extension The CHILDREN extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST '' * or a LIST '' % for each mailbox name. imapiana:imap-capabilities | Informational |
| RFC 3501 2003 | INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with… Obsoleted by RFC 9051. imapobsoleteiana:imap-capabilities | Obsolete |
| RFC 3502 2003 | Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND". imapiana:imap-capabilities | Current |
| RFC 3516 2003 | IMAP4 Binary Content Extension This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. imapiana:imap-capabilities | Current |
| RFC 3691 2004 | Internet Message Access Protocol (IMAP) UNSELECT command This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a… imapiana:imap-capabilities | Current |
| RFC 4314 2005 | IMAP4 Access Control List (ACL) Extension The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. imapiana:imap-capabilities | Current |
| RFC 4315 2005 | Internet Message Access Protocol (IMAP) - UIDPLUS extension The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. imapiana:imap-capabilities | Current |
| RFC 4466 2006 | Collected Extensions to IMAP4 ABNF Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place. This document also suggests a set of standard patterns for adding options and… imap | Current |
| RFC 4467 2006 | Internet Message Access Protocol (IMAP) - URLAUTH Extension This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server that supports this extension indicates this with… imapuriiana:imap-capabilities | Current |
| RFC 4469 2006 | Internet Message Access Protocol (IMAP) CATENATE Extension The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new… imapiana:imap-capabilities | Current |
| RFC 4549 2006 | Synchronization Operations for Disconnected IMAP4 Clients This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is… imap | Informational |
| RFC 4550 2006 | Internet Email to Support Diverse Service Environments (Lemonade) Profile This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to… Obsoleted by RFC 5550. imap | Obsolete |
| RFC 4731 2006 | IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. imapiana:imap-capabilities | Current |
| RFC 4978 2007 | The IMAP COMPRESS Extension The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. imapiana:imap-capabilities | Current |
| RFC 5032 2007 | WITHIN Search Extension to the IMAP Protocol This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the… imapiana:imap-capabilities | Current |
| RFC 5092 2007 | IMAP URL Scheme IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. This document obsoletes RFC 2192. It also updates RFC 4467. imapuri | Current |
| RFC 5161 2008 | The IMAP ENABLE Extension Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. imapiana:imap-capabilities | Current |
| RFC 5182 2008 | IMAP Extension for Referencing the Last SEARCH Result Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox. This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the… imapiana:imap-capabilities | Current |
| RFC 5255 2008 | Internet Message Access Protocol Internationalization Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support… imapinternationalizationiana:imap-capabilities | Current |
| RFC 5256 2008 | Internet Message Access Protocol - SORT and THREAD Extensions This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. imapiana:imap-capabilities | Current |
| RFC 5257 2008 | Internet Message Access Protocol - ANNOTATE Extension The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a… imapiana:imap-capabilities | Informational |
| RFC 5258 2008 | Internet Message Access Protocol version 4 - LIST Command Extensions IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the… imapiana:imap-capabilities | Current |
| RFC 5259 2008 | Internet Message Access Protocol - CONVERT Extension CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. imapiana:imap-capabilities | Current |
| RFC 5267 2008 | Contexts for IMAP4 The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. imapiana:imap-capabilities | Current |
| RFC 5464 2009 | The IMAP METADATA Extension The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a… imapiana:imap-capabilities | Current |
| RFC 5465 2009 | The IMAP NOTIFY Extension This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. imapiana:imap-capabilities | Current |
| RFC 5466 2009 | IMAP4 Extension for Named Searches (Filters) The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. imapiana:imap-capabilities | Current |
| RFC 5524 2009 | Extended URLFETCH for Binary and Converted Parts The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. imapuriiana:imap-capabilities | Current |
| RFC 5550 2009 | The Internet Email to Support Diverse Service Environments (Lemonade) Profile This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail.… imapiana:imap-capabilities | Current |
| RFC 5738 2010 | IMAP Support for UTF-8 This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community. Obsoleted by RFC 6855. imapinternationalizationobsoleteiana:imap-capabilities | Obsolete |
| RFC 5788 2010 | IMAP4 Keyword Registry The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. imap | Current |
| RFC 5819 2010 | IMAP4 Extension for Returning STATUS Information in Extended LIST Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client… imapiana:imap-capabilities | Current |
| RFC 5957 2010 | Display-Based Address Sorting for the IMAP4 SORT Extension This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. imapiana:imap-capabilities | Current |
| RFC 6154 2011 | IMAP LIST Extension for Special-Use Mailboxes Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox… imapiana:imap-capabilities | Current |
| RFC 6203 2011 | IMAP4 Extension for Fuzzy Search This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. imapiana:imap-capabilities | Current |
| RFC 6851 2013 | Internet Message Access Protocol (IMAP) - MOVE Extension This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. imapiana:imap-capabilities | Current |
| RFC 7162 2014 | IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, the… imapiana:imap-capabilities | Current |
| RFC 7377 2014 | IMAP4 Multimailbox SEARCH Extension The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command,… imapiana:imap-capabilities | Current |
| RFC 7888 2016 | IMAP4 Non-synchronizing Literals The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal… imapiana:imap-capabilities | Current |
| RFC 7889 2016 | The IMAP APPENDLIMIT Extension This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large. imapiana:imap-capabilities | Current |
| RFC 8437 2018 | IMAP UNAUTHENTICATE Extension for Connection Reuse This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities. imapiana:imap-capabilities | Current |
| RFC 8438 2018 | IMAP Extension for STATUS=SIZE This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox. imapiana:imap-capabilities | Current |
| RFC 8440 2018 | IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. imapiana:imap-capabilities | Current |
| RFC 8474 2018 | IMAP Extension for Object Identifiers This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. imapiana:imap-capabilities | Current |
| RFC 8508 2019 | IMAP REPLACE Extension This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. imapiana:imap-capabilities | Current |
| RFC 8514 2019 | Internet Message Access Protocol (IMAP) - SAVEDATE Extension This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the… imapiana:imap-capabilities | Current |
| RFC 8970 2020 | IMAP4 Extension: Message Preview Generation This document specifies an Internet Message Access Protocol (IMAP) protocol extension that allows a client to request a server-generated abbreviated text representation of message data that is useful as a contextual preview of the entire message. imapiana:imap-capabilities | Current |
| RFC 9051 2021 | Internet Message Access Protocol (IMAP) - Version 4rev2 The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the… imapiana:imap-capabilities | Current |
| RFC 9208 2022 | IMAP QUOTA Extension This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible. imapiana:imap-capabilities | Current |
| RFC 9394 2023 | IMAP PARTIAL Extension for Paged SEARCH and FETCH The PARTIAL extension of the Internet Message Access Protocol (see RFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends the PARTIAL SEARCH return option originally specified… imapiana:imap-capabilities | Current |
| RFC 9585 2024 | IMAP Response Code for Command Progress Notifications This document defines a new IMAP untagged response code, "INPROGRESS", that provides progress notifications regarding the status of long-running commands. imapiana:imap-capabilities | Current |
| RFC 9586 2024 | IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only The UIDONLY extension to the Internet Message Access Protocol (RFCs 3501 and 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses and cannot be used in requests once this extension is enabled. This helps both clients and servers to… imapiana:imap-capabilities | Informational |
| RFC 9590 2024 | IMAP Extension for Returning Mailbox METADATA in Extended LIS This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command. imapiana:imap-capabilities | Current |
| RFC 9738 2025 | IMAP MESSAGELIMIT Extension The MESSAGELIMIT extension of the Internet Message Access Protocol (RFCs 3501 and 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH, SEARCH, STORE, COPY, or MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command. This helps servers to control resource usage when… imapiana:imap-capabilities | Informational |
POP3 (mailbox access)
The simpler download-and-delete access protocol.
| RFC | Title | Status |
|---|---|---|
| RFC 937 1985 | Post Office Protocol: Version 2 This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918. pop3historicalobsolete | Historical |
| RFC 1081 1988 | Post Office Protocol: Version 3 This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Obsoleted by RFC 1225. pop3historicalobsolete | Obsolete |
| RFC 1082 1988 | Post Office Protocol: Version 3: Extended service offerings This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion… pop3historicalobsolete | Informational |
| RFC 1225 1991 | Post Office Protocol: Version 3 This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. Obsoleted by RFC 1460. pop3historicalobsolete | Obsolete |
| RFC 1460 1993 | Post Office Protocol - Version 3 This memo is a revision to RFC 1225, a Draft Standard. Obsoleted by RFC 1725. pop3historicalobsolete | Obsolete |
| RFC 1725 1994 | Post Office Protocol - Version 3 This memo is a revision to RFC 1460, a Draft Standard. Obsoleted by RFC 1939. pop3obsolete | Obsolete |
| RFC 1734 1994 | POP3 AUTHentication command This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. Obsoleted by RFC 5034. pop3saslobsolete | Obsolete |
| RFC 1939 1996 | Post Office Protocol - Version 3 The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. pop3 | Current |
| RFC 1957 1996 | Some Observations on Implementations of the Post Office Protocol (POP3) This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. pop3 | Informational |
| RFC 2384 1998 | POP URL Scheme This memo defines a URL scheme for referencing a POP mailbox. pop3uri | Current |
| RFC 2449 1998 | POP3 Extension Mechanism This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. pop3 | Current |
| RFC 5721 2010 | POP3 Support for UTF-8 This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. This document defines an Experimental Protocol for the Internet community. Obsoleted by RFC 6856. pop3internationalization | Obsolete |
JMAP (modern mailbox API)
The JSON/HTTP successor for mail synchronization.
| RFC | Title | Status |
|---|---|---|
| RFC 8620 2019 | The JSON Meta Application Protocol (JMAP) This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. jmapjsoniana:jmap | Current |
| RFC 8621 2019 | The JSON Meta Application Protocol (JMAP) for Mail This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client. jmapjsoniana:jmap | Current |
| RFC 8887 2020 | A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP. jmapjson | Current |
| RFC 9007 2021 | Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) This document specifies a data model for handling Message Disposition Notifications (MDNs) (see RFC 8098) in the JSON Meta Application Protocol (JMAP) (see RFCs 8620 and 8621). jmapmdnjsoniana:jmap | Current |
| RFC 9219 2022 | S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) This document specifies an extension to "The JSON Meta Application Protocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status. jmapsmimejsoniana:jmap | Current |
| RFC 9404 2023 | JSON Meta Application Protocol (JMAP) Blob Management Extension The JSON Meta Application Protocol (JMAP) base protocol (RFC 8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on a defined endpoint. This binary data is called a "blob". This extension adds additional ways to create and access blobs by making inline method calls within a standard JMAP request. This extension… jmapjsoniana:jmap | Current |
| RFC 9425 2023 | JSON Meta Application Protocol (JMAP) for Quotas This document specifies a data model for handling quotas on accounts with a server using the JSON Meta Application Protocol (JMAP). jmapjsoniana:jmap | Current |
| RFC 9610 2024 | JSON Meta Application Protocol (JMAP) for Contacts This document specifies a data model for synchronising contact data with a server using the JSON Meta Application Protocol (JMAP). jmapcontactsjsoniana:jmap | Current |
| RFC 9661 2024 | The JSON Meta Application Protocol (JMAP) for Sieve Scripts This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). Clients can use this protocol to efficiently search, access, organize, and validate Sieve scripts. jmapsievejsoniana:jmap | Current |
| RFC 9670 2024 | JSON Meta Application Protocol (JMAP) Sharing This document specifies a data model for sharing data between users using the JSON Meta Application Protocol (JMAP). Future documents can reference this document when defining data types to support a consistent model of sharing. jmapjsoniana:jmap | Current |
| RFC 9698 2025 | The JMAPACCESS Extension for IMAP This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via the JSON Meta Application Protocol (JMAP), and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client. imapjmapiana:imap-capabilities | Current |
| RFC 9749 2025 | Use of Voluntary Application Server Identification (VAPID) in JSON Meta Application Protocol (JMAP) Web Push This document defines a method for JSON Meta Application Protocol (JMAP) servers to advertise their capability to authenticate Web Push notifications using the Voluntary Application Server Identification (VAPID) protocol. jmapjsoniana:jmap | Current |
Sieve (server-side filtering)
The standard mail-filtering language.
| RFC | Title | Status |
|---|---|---|
| RFC 3028 2001 | Sieve: A Mail Filtering Language This document describes a language for filtering e-mail messages at time of final delivery. Obsoleted by RFC 5228. sieveobsolete | Obsolete |
| RFC 3685 2004 | SIEVE Email Filtering: Spamtest and VirusTest Extensions The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned… Obsoleted by RFC 5235. sievespamanti-abuseobsolete | Obsolete |
| RFC 3894 2004 | Sieve Extension: Copying Without Side Effects The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior. This document defines a new keyword parameter, ":copy", to be used with the Sieve… sieveiana:sieve-extensions | Current |
| RFC 4790 2007 | Internet Application Protocol Collation Registry Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this… sieveiana:sieve-extensions | Current |
| RFC 5173 2008 | Sieve Email Filtering: Body Extension This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. sieveiana:sieve-extensions | Current |
| RFC 5183 2008 | Sieve Email Filtering: Environment Extension This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. sieveiana:sieve-extensions | Current |
| RFC 5228 2008 | Sieve: An Email Filtering Language This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed… sieveiana:jmapiana:sieve-extensions | Current |
| RFC 5229 2008 | Sieve Email Filtering: Variables Extension In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string… sieveiana:sieve-extensions | Current |
| RFC 5230 2008 | Sieve Email Filtering: Vacation Extension This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. sieveiana:sieve-extensions | Current |
| RFC 5231 2008 | Sieve Email Filtering: Relational Extension This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. This document obsoletes RFC 3431. sieveiana:sieve-extensions | Current |
| RFC 5232 2008 | Sieve Email Filtering: Imap4flags Extension Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP… imapsieveiana:sieve-extensions | Current |
| RFC 5233 2008 | Sieve Email Filtering: Subaddress Extension On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. sieveiana:sieve-extensions | Current |
| RFC 5235 2008 | Sieve Email Filtering: Spamtest and Virustest Extensions The Sieve email filtering language "spamtest", "spamtestplus", and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying Sieve implementation to do the actual checks that result… sievespamanti-abuseiana:sieve-extensions | Current |
| RFC 5260 2008 | Sieve Email Filtering: Date and Index Extensions This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. sieveiana:sieve-extensions | Current |
| RFC 5293 2008 | Sieve Email Filtering: Editheader Extension This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. sieveheadersiana:sieve-extensions | Current |
| RFC 5429 2009 | Sieve Email Filtering: Reject and Extended Reject Extensions This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028. A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original… sieveiana:sieve-extensions | Current |
| RFC 5435 2009 | Sieve Email Filtering: Extension for Notifications Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is… sieveiana:sieve-extensions | Current |
| RFC 5436 2009 | Sieve Notification Mechanism: mailto This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. sieve | Current |
| RFC 5463 2009 | Sieve Email Filtering: Ihave Extension This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations… sieveiana:sieve-extensions | Current |
| RFC 5490 2009 | The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. sieveiana:sieve-extensions | Current |
| RFC 5703 2009 | Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. sievemimeiana:message-headersiana:sieve-extensions | Current |
| RFC 5804 2010 | A Protocol for Remotely Managing Sieve Scripts Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts… sieve | Current |
| RFC 6009 2010 | Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions,… sievedsniana:sieve-extensions | Current |
| RFC 6131 2011 | Sieve Vacation Extension: "Seconds" Parameter This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. sieveiana:sieve-extensions | Current |
| RFC 6134 2011 | Sieve Extension: Externally Stored Lists The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a… sieveiana:sieve-extensions | Current |
| RFC 6558 2012 | Sieve Extension for Converting Messages before Delivery This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. sieveiana:sieve-extensions | Current |
| RFC 6609 2012 | Sieve Email Filtering: Include Extension The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. sieveiana:sieve-extensions | Current |
| RFC 6785 2012 | Support for Internet Message Access Protocol (IMAP) Events in Sieve Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined… imapsieveiana:imap-capabilitiesiana:sieve-extensions | Current |
| RFC 7352 2014 | Sieve Email Filtering: Detecting Duplicate Deliveries This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID… sieveiana:sieve-extensions | Current |
| RFC 8579 2019 | Sieve Email Filtering: Delivering to Special-Use Mailboxes The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a… sieveiana:sieve-extensions | Current |
| RFC 8580 2019 | Sieve Extension: File Carbon Copy (FCC) The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFCs 5230 and 5435 by adding a new tagged argument to the… sieveiana:sieve-extensions | Current |
| RFC 9042 2021 | Sieve Email Filtering: Delivery by MAILBOXID The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming. This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes. sieveiana:sieve-extensions | Current |
| RFC 9122 2023 | IANA Registry for Sieve Actions The Sieve Email Filtering Language (RFC 5228) is a popular email filtering language used upon final mail delivery. This document creates a registry for Sieve actions to help developers and Sieve extension writers track interactions between different extensions. sieveiana:sieve-extensions | Current |
| RFC 9671 2024 | Sieve Email Filtering: Extension for Processing Calendar Attachments This document describes the "processcalendar" extension to the Sieve email filtering language. The "processcalendar" extension gives Sieve the ability to process machine-readable calendar data that is encapsulated in an email message using Multipurpose Internet Mail Extensions (MIME). sievecalendariana:sieve-extensions | Current |
Internationalized email (EAI)
Non-ASCII addresses and headers.
| RFC | Title | Status |
|---|---|---|
| RFC 3492 2003 | Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are… dnsinternationalization | Current |
| RFC 3629 2003 | UTF-8, a transformation format of ISO 10646 ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the… internationalization | Current |
| RFC 4952 2007 | Overview and Framework for Internationalized Email Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These… Obsoleted by RFC 6530. internationalizationobsolete | Obsolete |
| RFC 5335 2008 | Internationalized Email Headers Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document… Obsoleted by RFC 6532. mimeheadersinternationalization | Obsolete |
| RFC 5336 2008 | SMTP Extension for Internationalized Email Addresses This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material… Obsoleted by RFC 6531. smtpinternationalizationiana:mail-parameters | Obsolete |
| RFC 5337 2008 | Internationalized Delivery Status and Disposition Notifications Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient… Obsoleted by RFC 6533. dsninternationalizationiana:message-headers | Obsolete |
| RFC 5504 2009 | Downgrading Mechanism for Email Address Internationalization Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some… Obsoleted by RFC 6530. headersinternationalizationobsoleteiana:message-headers | Obsolete |
| RFC 5890 2010 | Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. dnsinternationalization | Current |
| RFC 5891 2010 | Internationalized Domain Names in Applications (IDNA): Protocol This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and… dnsinternationalization | Current |
| RFC 5892 2010 | The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN). It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). internationalization | Current |
| RFC 5893 2010 | Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. internationalization | Current |
| RFC 5894 2010 | Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend.… dnsinternationalization | Informational |
| RFC 6530 2012 | Overview and Framework for Internationalized Email Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to… internationalization | Current |
| RFC 6531 2012 | SMTP Extension for Internationalized Email This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. smtpsubmissioninternationalizationiana:mail-parameters | Current |
| RFC 6532 2012 | Internationalized Email Headers Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode,… mimeheadersinternationalization | Current |
| RFC 6533 2012 | Internationalized Delivery Status and Disposition Notifications Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient… dsnmdninternationalization | Current |
| RFC 6855 2013 | IMAP Support for UTF-8 This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738. Obsoleted by RFC 9755. imapinternationalizationobsolete | Obsolete |
| RFC 6856 2013 | Post Office Protocol Version 3 (POP3) Support for UTF-8 This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings. pop3internationalization | Current |
| RFC 6857 2013 | Post-Delivery Message Downgrading for Internationalized Email Messages The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver… headersinternationalizationiana:message-headers | Current |
| RFC 6858 2013 | Simplified POP and IMAP Downgrading for Internationalized Email This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results. imappop3headersinternationalization | Current |
| RFC 9755 2025 | IMAP Support for UTF-8 This specification extends the Internet Message Access Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2 (RFC 9051), since that protocol includes everything in this extension. imapinternationalizationiana:imap-capabilities | Current |
Calendaring & contacts over email
iCalendar, scheduling, and address books carried in or alongside mail.
| RFC | Title | Status |
|---|---|---|
| RFC 2425 1998 | A MIME Content-Type for Directory Information This document defines a MIME Content-Type for holding directory information. Obsoleted by RFC 6350. mimecontactsobsolete | Obsolete |
| RFC 2426 1998 | vCard MIME Directory Profile This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. Obsoleted by RFC 6350. contactsobsolete | Obsolete |
| RFC 2445 1998 | Internet Calendaring and Scheduling Core Object Specification (iCalendar) This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. Obsoleted by RFC 5545. calendarobsolete | Obsolete |
| RFC 2446 1998 | iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. Obsoleted by RFC 5546. calendarobsolete | Obsolete |
| RFC 2447 1998 | iCalendar Message-Based Interoperability Protocol (iMIP) This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. Obsoleted by RFC 6047. calendarobsolete | Obsolete |
| RFC 2739 2000 | Calendar Attributes for vCard and LDAP This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. calendarcontacts | Current |
| RFC 4770 2007 | vCard Extensions for Instant Messaging (IM) This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. Obsoleted by RFC 6350. contactsobsolete | Obsolete |
| RFC 4791 2007 | Calendaring Extensions to WebDAV (CalDAV) This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. calendar | Current |
| RFC 5545 2009 | Internet Calendaring and Scheduling Core Object Specification (iCalendar) This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. calendar | Current |
| RFC 5546 2009 | iCalendar Transport-Independent Interoperability Protocol (iTIP) This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use… calendar | Current |
| RFC 6047 2010 | iCalendar Message-Based Interoperability Protocol (iMIP) This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC… calendar | Current |
| RFC 6321 2011 | xCal: The XML Format for iCalendar This specification defines "xCal", an XML format for iCalendar data. calendar | Current |
| RFC 6350 2011 | vCard Format Specification This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. contacts | Current |
| RFC 6351 2011 | xCard: vCard XML Representation This document defines the XML schema of the vCard data format. contacts | Current |
| RFC 6352 2011 | CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. contacts | Current |
| RFC 6473 2011 | vCard KIND:application This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. contacts | Current |
| RFC 6474 2011 | vCard Format Extensions: Place of Birth, Place and Date of Death The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. contacts | Current |
| RFC 6638 2012 | Scheduling Extensions to CalDAV This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. calendar | Current |
| RFC 6715 2012 | vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance (OMA) Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0… contacts | Current |
| RFC 6868 2013 | Parameter Value Encoding in iCalendar and vCard This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications. calendarcontacts | Current |
| RFC 6869 2013 | vCard KIND:device This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). contacts | Current |
| RFC 7095 2014 | jCard: The JSON Format for vCard This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange… contactsjson | Current |
| RFC 7529 2015 | Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules. calendar | Current |
| RFC 7953 2016 | Calendar Availability This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate… calendar | Current |
| RFC 7986 2016 | New Properties for iCalendar This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object. calendar | Current |
| RFC 8605 2019 | vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP) This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are… contacts | Informational |
| RFC 8984 2021 | JSCalendar: A JSON Representation of Calendar Data This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to… calendarjson | Current |
| RFC 9073 2021 | Event Publishing Extensions to iCalendar This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking. This specification also defines a new "STRUCTURED-DATA" property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the… calendar | Current |
| RFC 9074 2021 | "VALARM" Extensions for iCalendar This document defines a set of extensions to the iCalendar "VALARM" component to enhance the use of alarms and improve interoperability between clients and servers. This document updates RFC 5545. calendar | Current |
| RFC 9553 2024 | JSContact: A JSON Representation of Contact Data This specification defines a data model and JavaScript Object Notation (JSON) representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable, and simple to process. In contrast to the JSON-based… contactsjson | Current |
| RFC 9554 2024 | vCard Format Extensions for JSContact This document defines a set of new properties for vCard and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSContact and vCard formats, but the new definitions also aim to be useful within just the vCard format. This document updates RFC 6350 ("vCard Format Specification"). contactsjson | Current |
| RFC 9555 2024 | JSContact: Converting from and to vCard This document defines how to convert contact information between the JSContact and vCard data formats. It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication. It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact… contactsjson | Current |
Specialized & certified mail
EDI, certified email, and military/government message handling.
| RFC | Title | Status |
|---|---|---|
| RFC 1767 1995 | MIME Encapsulation of EDI Objects Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. mimeedi | Current |
| RFC 2156 1998 | MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. mimeheadersiana:message-headers | Current |
| RFC 3335 2002 | MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet This document describes how to exchange structured business data securely using SMTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport), XML or other data used for business to business data … mimesmimeedi | Current |
| RFC 4130 2005 | MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National… edi | Current |
| RFC 5402 2010 | Compressed Data within an Internet Electronic Data Interchange (EDI) Message This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. This document is not an Internet Standards Track specification; it is published for informational purposes. edi | Informational |
| RFC 6017 2010 | Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The… headersedi | Informational |
| RFC 6109 2011 | La Posta Elettronica Certificata - Italian Certified Electronic Mail Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing. The design of the entire… headerscertified-mail | Informational |
| RFC 6477 2012 | Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2… headersiana:message-headers | Informational |
| RFC 7681 2015 | Email Exchange of Secondary School Transcripts A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined… mimeheadersiana:message-headers | Informational |
| RFC 7912 2016 | Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or… headers | Informational |
Netnews (adjacent)
Usenet article formats and NNTP, which share header concepts with email.
| RFC | Title | Status |
|---|---|---|
| RFC 850 1983 | Standard for interchange of USENET messages This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission… Obsoleted by RFC 1036. netnewshistoricalobsoleteiana:message-headers | Obsolete |
| RFC 1036 1987 | Standard for interchange of USENET messages This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard. Obsoleted by RFC 5536. netnewsobsolete | Obsolete |
| RFC 1849 2010 | "Son of 1036": News Article Format and Transmission By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the… Obsoleted by RFC 5536. netnewsiana:message-headers | Obsolete |
| RFC 2980 2000 | Common NNTP Extensions In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. This memo provides information for the… netnewsobsoleteiana:message-headers | Informational |
| RFC 3977 2006 | Network News Transfer Protocol (NNTP) The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific… netnewsiana:message-headers | Current |
| RFC 5536 2009 | Netnews Article Format This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. netnewsiana:message-headers | Current |
| RFC 5537 2009 | Netnews Architecture and Protocols This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. netnewsiana:message-headers | Current |
| RFC 8315 2018 | Cancel-Locks in Netnews Articles This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles. This document updates RFC 5537. headersnetnewsiana:message-headers | Current |
Adjacent standards
URIs, JSON, and other specs email depends on.
| RFC | Title | Status |
|---|---|---|
| RFC 1738 1994 | Uniform Resource Locators (URL) This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. Obsoleted by RFC 4248. uriobsolete | Obsolete |
| RFC 1808 1995 | Relative Uniform Resource Locators In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative Uniform Resource Locators. Obsoleted by RFC 3986. uriobsoleteiana:message-headers | Obsolete |
| RFC 2368 1998 | The mailto URL scheme This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. Obsoleted by RFC 6068. uriobsolete | Obsolete |
| RFC 3986 2005 | Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines… uri | Current |
| RFC 3987 2005 | Internationalized Resource Identifiers (IRIs) This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to… internationalizationuri | Current |
| RFC 6068 2010 | The 'mailto' URI Scheme This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). uriiana:message-headers | Current |
| RFC 6901 2013 | JavaScript Object Notation (JSON) Pointer JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document. json | Current |
| RFC 6902 2013 | JavaScript Object Notation (JSON) Patch JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents. json | Current |
| RFC 7493 2015 | The I-JSON Message Format I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. json | Current |
| RFC 8259 2017 | The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs… json | Current |
| RFC 8288 2017 | Web Linking This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. urijson | Current |
| RFC 8785 2020 | JSON Canonicalization Scheme (JCS) Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed… json | Informational |
| RFC 9116 2022 | A File Format to Aid in Security Vulnerability Disclosure When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities. | Informational |
| RFC 9530 2024 | Digest Fields This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective… | Current |
Historical & superseded
Kept for reference; replaced by current specs.
| RFC | Title | Status |
|---|---|---|
| RFC 733 1977 | Standard for the format of ARPA network text messages ARPANET Mail Message Format (1977): ancestor of email; superseded by RFC 822. Obsoleted by RFC 822. | Obsolete |
| RFC 2822 2001 | Internet Message Format This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. Obsoleted by RFC 5322. | Obsolete |
How to read this
Statuses follow the RFC Editor and IANA registries. "Current" means it is the live specification for its function; "obsolete" means a newer RFC replaces it (we note which); "informational" and "historical" are kept for context. If you only remember one thing: confirm an RFC is current before you build to it. Several widely-cited email RFCs have been superseded.
Egressif's stack tracks the current specs across this whole catalog, which is why our DMARC, SPF, DKIM, and transport handling stay aligned as the standards move. For the deep dives, see the authentication and transport references in Resources.
Plenty of email's most important machinery is not RFC-defined at all: SpamAssassin, Rspamd, DCC, Pyzor, Razor, BIMI, SRS, the blocklists, the provider rules, and the law. Those live in Standards & implementations.