20th September 2011

Best Current Practice for MTAs

This is my attempt at writing down wisdom accumulated in many years of operating real-world Internet mail servers while trying hard to keep the Internet mail system as a whole usable and stable.

This document is still very much work in progress, any feedback is appreciated.

Valid Reverse DNS

  • The sender IP address must have a reverse DNS entry (PTR record).
  • The reverse hostname must have a forward DNS entry (A, AAAA records).
  • One of these address records must match the sender IP address.

References: RFC 1912, RFC 1033

Common Mailbox Names

  • Accept mail for the postmaster mailbox without domain.
  • Accept mail for the postmaster, abuse and security mailboxes on all domains the MTA accepts mail for.
  • Messages to these addresses must actually reach clueful people able to act on e.g. abuse notifications.

Reference: RFC 2142, RFC 2821

Random Notes

These have to be cleaned up, extended, and all relevant references added.

  • Valid HELO/EHLO argument:
    • The HELO/EHLO argument must be an FQDN.
    • The FQDN must have a forward DNS entry (A, AAAA records).
    • One of these address records must match the sender IP address.
  • Refuse to accept mail for inexisting addresses at SMTP time using a permanent error (i.e. do not accept, then generate a DSN later).
  • Refuse spam/malware at SMTP time using a permanent error. Already accepted mail which is later flagged as spam, malware or otherwise unacceptable must not generate a DSN; options include flagged delivery to let the recipient decide what to do with unwanted mail, or rerouting to spam mailbox(es).
  • Accept DSN (MAIL FROM:<>).
  • Support active and passive STARTTLS on port 25.
  • Support SMTPS on port 465, otherwise equal to port 25, except for the SSL from the start, without STARTTLS command.
  • Correct handling of Submission on port 587:
    • Mandatory authentication (AUTH): Only accept mail from authenticated peers.
    • Mandatory TLS (STARTTLS): Only accept SMTP AUTH after TLS has been enabled (STARTTLS).
    • Do not accept unauthenticated mail whatsoever. Submission is only for MUA mail submission, not for MTA to MTA mail delivery. This distinction allows to block spam from DSL/Cable zombies on port 25 and 465, while still allowing mail submission from clients on port 587.
  • Include the (envelope-from: <...>) extension in generated Received: headers to help with debugging problems related to the envelope sender (e.g. SPF).
  • Use SRS when sending mail with source addresses for which the MTA is not responsible in the SPF sense. In other words, use SRS when forwarding mail (/etc/aliases or virtusertable style forwarding and pseudo-mailinglists).
  • Use real mailing list software like Mailman instead of deprecated /etc/aliases style group forwards.
  • When retrying a delivery after a temporary failure, use the same envelope sender as the first delivery attempt for the same message. Otherwise greylisting will be broken.
  • When using greylisting, make sure that you:
    • Whitelist known real mailservers, e.g. using DNSWL.
    • Immediately give a permanent failure for inexisting users in order not to break callout verification.
  • Excempt the postmaster and abuse mailboxes from overly aggressive anti-spam measures, especially from DNS heuristics (like pattern-matching the DNS reverse name to disallow DUL/DSL/Cable type of addresses). To resolve problems and educate those who operate a badly configured MTA, you will need and want to be able to receive mail to postmaster and/or abuse.
    Alternative: Point to (captcha-enabled) abuse contact web form when refusing mail for postmaster and abuse.

References

  • Standards Track:
    • RFC 2821 — Simple Mail Transfer Protocol (obsoletes RFC 1869, RFC 974, RFC 821)
    • RFC 4409 — Message Submission for Mail (obsoletes RFC 2476)
    • RFC 2142 — Mailbox Names for Common Services, Roles and Functions
  • Best Current Practice / Informational:
    • RFC 1033 — Domain Administrators Operations Guide
    • RFC 1912 — Common DNS Operational and Configuration Errors
    • RFC 2505 — Anti-Spam Recommendations for SMTP MTAs
    • RFC 3013 — Recommended Internet Service Provider Security Services and Procedures
    • RFC 5068 — Email Submission Operations: Access and Accountability Requirements
0d1c446
Ƿ