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).
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.)
