Email structure

These RFCs define the way emails themselves are structured.

•  — Internet Message Format (basic format of an email message), previously RFC 822 and RFC 2822.
•  — 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).
•  — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
•  — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text.
•  — 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).

•  — Simple Mail Transfer Protocol (protocol used to send emails between computers), previously RFC 821 and RFC 2821.
•  — INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1 (IMAP protocol, used to read emails).
•  — 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)
•  — 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.

•  — Using TLS with IMAP, POP3 and ACAP (protocol used to upgrade a plaintext IMAP/POP connection to an SSL/TLS encrypted one).
•  — SMTP Service Extension for Secure SMTP over Transport Layer Security (protocol used to upgrade a plaintext SMTP connection to an SSL/TLS encrypted one).
•  — The Transport Layer Security (TLS) Protocol Version 1.2 (protocol used to encrypt a connection).
•  — 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.

•  --- This is Mozillas custom approach that Thunderbird uses to auto-discover servers.
•  — 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

•  — Sieve: An Email Filtering Language (language used to file/filter/forward emails, what our Rules system ultimately generates. More information about . Note that our server doesn't support all the extensions.)