Skip to content

Mail (SMTP)

A few topics around mail and mail servers.

Todo

Topics not covered yet

Todo

postfix configuration examples

Sender, recipients, and headers

An email consists of a list of headers and a body (separated by an empty line). Standard headers include From: and To: (and CC:), which mail clients show as sender and recipients (usually listing name and email address). See RFC 5322 §3.6.2 for more details about the headers.

In SMTP there are (possibly) different “envelope” sender (also known as return path, passed in the SMTP command MAIL FROM) and recipients (SMTP command RCPT TO). Envelope sender and receivers only use email addresses, no names.

Delivery errors are reported to the sender, and recipients are the current list a mail server wants to deliver an email to.

When a new mail is created by a mail client, usually sender and the email address in From: are the same; the initial recipients are created from the email addresses from To:, CC: and possibly BCC: headers (BCC: headers are not actually sent in outgoing emails, but should be kept in emails stored in the senders Sent folder).

When a mail gets routed to different servers, each server only gets the recipient list for the destinations on its server (sometimes mails are event sent as single entities for each recipient). During mail forwarding and alias handling a recipient might get rewritten or expanded to multiple recipients.

SPF (RFC 7208) - Sender Policy Framework

SPF tells mail servers which servers to expect mails for senders from a given domain from (only senders are checked, not the header From:).

The policy is stored in a single TXT record starting with v=spf1 for the domain. (In the past there was also an SPF record type with the same format as TXT, but isn’t used anymore.)

The IANA “Underscored and Globally Scoped DNS Node Names” registry lists _spf, but the scope is only used in examples to store nested or related TXT records - the main entry point into the policy doesn’t use _spf.

Software and examples

Most spam filter software should be able to evaluate SPF in its scoring system:

DNS lookup

$ dig +noall +answer TXT stbuehler.de @ns1.stbuehler.de
...
stbuehler.de.       3600    IN  TXT "v=spf1 +mx ?all"

DKIM (RFC 6376) - DomainKeys Identified Mail Signatures

DKIM adds a signature to mails (as DKIM-Signature header). It is created by the sending mail server for a domain and can be verified by receiving mail servers.

DKIM signatures are supposed to survive mail forwarding of various kinds, an area where SPF fails completely.

Keys are stored as TXT records under a “selector” under the _domainkey zone for a sending domain (or some parent domain); the signature includes the selector and the domain it is from. Keys can’t be listed directly from DNS as you need to know the selector.

Signature cover certain headers (as configured on the signing server); they can allow for more headers of a given name getting appendend or not. A signature can also allow appending to the body (like mailing lists often do) without breaking the signature by signing a fixed length prefix of the body.

Some recommend to roll over DKIM keys very quickly (and even publish the old private keys), so they can’t be used longterm to verify if some mail was sent through your servers; mails should be received within a few days, and after that there is no real value in verifying DKIM again.

Todo

As far as I can tell DKIM doesn’t specify which domains DKIM signatures should be verified against. So a server could sign mails with keys from domains completely unrelated to sender or header From:.

DMARC is more useful for that; without that it probably makes sense to only consider DKIM signatures matching the header From: (or a parent domain) a good influence on a “spam” score.

Software

Most spam filter software should be able to evaluate DKIM signatures in its scoring system; some may also be able to create them.

Checking DKIM signatures:

Creating DKIM signatures:

DMARC (RFC 7489)

A DMARC policy is configured for the domain of the header From:; if it is present it asks for SPF and DKIM to be checked against the header From:.

A policy can also request that receiving servers report failures or aggregated feedback.

The policy is stored as TXT record under the _dmarc zone for a source domain.

Warning

A DMARC policy on a domain quite likely breaks all later forwarding and mailing list handling that doesn’t completely rewrite both envelope sender and header From:.

MTA-STS (RFC 8461)

MTA-STS signals that senders should use TLS to connect to the mail servers of a domain, and to verify the certificate (against the MX target name).

It starts with an TXT records under the _mta-sts zone for the receiving domain to signal the presence of a policy; the policy itself must be fetched via HTTPS from the policy domain (mta-sts. added as prefix to the receiving domain) at /.well-known/mta-sts.txt, again using a verified TLS connection.

The MTA-STS policy also includes a list of valid MX target names (possibly using wildcards).

TLSRPT (RFC 8460)

If a sender couldn’t send a mail to you because of TLS issues, TLSRPT allows defining a feedback channel to report those errors to.