Email standards

Email structure

These RFCs define the way emails themselves are structured.

  • RFC 5322 — Internet Message Format (basic format of an email message), previously RFC 822 and RFC 2822.
  • RFC 2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. This is an extension to the email message format to support attachments and non-ASCII data in emails.
  • RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
  • RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text.
  • RFC 2231 — MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations.

Email protocols

These RFCs define how emails are transported between computers, both for sending (SMTP) and receiving (IMAP/POP).

  • RFC 5321 — Simple Mail Transfer Protocol. This is a protocol used to send emails between computers. This was previously RFC 821 and RFC 2821.
  • RFC 3501 — INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1. This is the IMAP protocol, used to read emails.
  • RFC 4551 — IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization. This is an IMAP extension that adds MODSEQ as a way to quickly find changes to a mailbox.
  • RFC 1939 — Post Office Protocol, Version 3. This is the older POP protocol, used to read emails.
  • RFC 8620 — The JSON Meta Application Protocol (JMAP). This is a new protocol for fetching, organizing, and sending messages, to replace older IMAP and SMTP protocols.

Email security

These RFCs define some security standards for email protocols and formats.

  • RFC 2595 — Using TLS with IMAP, POP3 and ACAP. This is a protocol used to upgrade a plaintext IMAP/POP connection to an SSL/TLS encrypted one.
  • RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security. This is a protocol used to upgrade a plaintext SMTP connection to an SSL/TLS encrypted one.
  • RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2. This is a protocol used to encrypt a connection.
  • RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. This allows emails to be signed by a particular domain to ensure they haven't been tampered with, and to say that that domain claims responsibility for the message.
  • RFC 8617 — Authenticated Received Chain (ARC). This is a protocol to provide an authenticated chain of custody for messages that have passed through intermediate mail servers, such as through forwarding.

Service discovery

Email software, including clients like Outlook and Mac Mail, need to know which mail server to contact in order to download the user's messages. This used to be manually configured by the user, but nowadays is often done by putting the user's email address through a service discovery process.

  • Thunderbird/Autoconfiguration — This is Mozilla's custom approach that Thunderbird uses to auto-discover servers.
  • RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services.

Some software vendors maintain their own database of links between email domains and server name definitions to support automatic configuration in their email clients. These seem to be custom databases maintained by each software vendor separately.

Filtering

  • RFC 5228 — Sieve: An Email Filtering Language. Sieve is a language used to file, filter, and forward emails, and is what our Rules system generates on the server. Our server doesn't support all the extensions for Sieve.
Was this article helpful?
6 out of 9 found this helpful