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 (extension to the email message format to support attachments and non-ASCII data).
- 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 (protocol used to send emails between computers), previously RFC 821 and RFC 2821.
- RFC 3501 — INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1 (IMAP protocol, used to read emails).
- RFC 4551 — IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization (IMAP extension that adds MODSEQ as a way to quickly find changes to a mailbox)
- RFC 1939 — Post Office Protocol, Version 3 (older POP protocol, used to read emails).
Email security
These RFCs define some security standards for email protocols and formats.
- RFC 2595 — Using TLS with IMAP, POP3 and ACAP (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 (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 (protocol used to encrypt a connection).
- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures (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) (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 that wants to access a user's email account has to know the server(s) to connect to. This used to be manually configured, but nowadays is often done using the user's email address through a service discovery process.
- Thunderbird/Autoconfiguration --- This is Mozillas custom approach that Thunderbird uses to auto-discover servers.
- RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services (a standard that no-one seems to use yet, pity, it looks reasonable).
Note that some software vendors seem to maintain their own database of email domain → server name definitions to support auto-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 (language used to file/filter/forward emails, what our Rules system ultimately generates. More information about Sieve and Sieve extensions. Note that our server doesn't support all the extensions.)