Sysadmin

Mail terminology

Client and server components

There are different components involved in an email transmission from sender to recipient.

How does email work? MTA, MUA, MSA, MDA, SMTP

MUA (Mail User Agent)

Client application that allows receiving and sending emails. It can be a desktop application such as Microsoft Outlook/Thunderbird/… or web-based such as Gmail/Hotmail/… (the latter is also called Webmail).

MSA (Mail Submission Agent)

A server program that receives mail from an MUA, checks for any errors, and transfers it (with SMTP) to the MTA hosted on the same server.

MTA (Mail Transfer Agent)

A server application that receives mail from the MSA, or from another MTA. It will find (through name servers and the DNS) the MX record from the recipient domain's DNS zone in order to know how to transfer the mail. It then transfers the mail (with SMTP) to another MTA (which is known as SMTP relaying) or, if the recipient’s server has been reached, to the MDA.

Examples of MTAs are Postfix, Exim, Sendmail, qmail, ...

MDA (Mail Delivery Agent)

A server program that receives mail from the server’s MTA, and stores it into the mailbox. MDA is also known as LDA (Local Delivery Agent).

An example is Dovecot, which is mainly a POP3 and IMAP server allowing an MUA to retrieve mail, but also includes an MDA which takes mail from an MTA and delivers it to the server’s mailbox.

Mailbox: maildir/mbox

The server’s mail storage. Maildir is a way of storing email messages. It is usually preferable over mbox.

SMTP

Protocol used by MUAs to send emails to an MSA. The recommended SMTP port for sending mail (from an MUA to an MSA) is the port 587, which uses TLS encryption.

IMAP/POP3

Protocols used by MUAs to retrieve emails from a server mailbox. POP3 deletes the email messages from the server after they have been downloaded. IMAP is usually preferable as it maintains all email messages on the server, permitting management of a mailbox by multiple email clients.

MX (Mail Exchanger) record

A Mail Exchanger (MX) record in the DNS specifies which server is responsible for accepting email addresses on behalf of a domain. The host name from the MX record must map to one or more address record (A or AAAA) in the DNS, and must not point to any CNAME records.

Email authentification

Email authentication is a technique used to improve email deliverability (reduce the risk of emails ending up in the recipients’ spam folders). It allows antispam filters to better verify the identity of the sender, and prevent spoofing and phishing scams.

Terms to know

MAIL FROM address

The email address to which bounce messages are delivered. This address is included in the SMTP envelope (data part of the SMTP protocol).

It is also known as RFC5321.MailFrom, Envelope sender address, Envelope from address, Return Path address, Bounce address, ...

Display From address

The email address that is displayed to the end user within their email client (MUA). This address is contained in the header (meta data) of the email. The email client (MUA) doesn’t have access to the SMTP envelope (and thus can’t see the aforementioned MAIL FROM address). The Display From address can be different than the MAIL FROM address.

The MAIL FROM address is used by the SMTP. The Display From address is used by the MUA to display the address in the Form field.

It is also known as RFC5322.From, header From address, ...

There are 3 main protocols allowing email authentication:

DKIM – DomainKeys Identified Mail

The sender creates an MD5 hash value of some elements of the email (e.g. the email header). The sender then uses a private key (only known by him) to encrypt that MD5 hash. The encrypted string is inserted into the mail, known as the DKIM signature. The sender stores a public key in a DNS record.

The receiver finds the public key from the DNS for that domain. The receiver then uses this public key to decrypt the DKIM signature from the email back to the original MD5 hash. The receiver generates a new MD5 hash from the elements of the email signed by DKIM, and compares it with the original MD5 hash. If they match the receiver knows that:

The shortcoming of DKIM is that it can only protect mail that has been signed, but it doesn't provide a mechanism to prove that an unsigned message should have been signed.

SPF – Sender Policy Framework

SPF enables the sender domain to publicly state which MTA servers (IPs) may send emails on its behalf.

The receiver server checks if SPF exists in the DNS for the domain in the MAIL FROM address (also called envelope sender address). If SPF exists, the receiver checks if the IP address of the sending server matches in the list of IPs in the SPF.

The shortcoming of SPF is that it validates the originating server only looking at the domain in the MAIL FROM address, not the mail header From address. The MAIL FROM address is the email address that receiving servers use to notify the sending server of delivery problems; it is also called envelope sender, envelope from, bounce address or Return Path address. The problem with this limitation is that the From address is what recipients see in their email clients.

DMARC – Domain-based Message Authentication, Reporting & Conformance

DMARC is built on top of SPF and DKIM to address the shortcomings of these two authentication standards. DMARC allows to enforce DKIM or SPF validation, and confirm that the Display From address is authentic.

The sender adds a DMARC policy in the DNS.

The receiver

Domain alignment consists of verifying that the From address (address displayed to the final recipient) matches with:

Comments

Comments including links will not be approved.