Christopher's Broom Cupboard header image

Setting up a secure Postfix server in 2019 - what to consider?

Postfix is great, and widely used, but freshly installed it's like a newborn child. Nowadays there's a lot of work required to get it to an acceptable level to face the wild west of the Internet.

NB: This is a living document and will probably change over time as I revise my own methods for managing my servers.

Running an MTA to an 'acceptable' standard now requires lots of additional config and tuning, but it's satisfying once done. Be prepared to learn lots about DNS, TLS, certificate structure, mail filtering (miltering), regular expression and monitoring - crucial once your system is operational.

Once you've had your fill of the RFCs (https://www.fastmail.com/help/technical/standards.html), there's plenty other stuff to learn. http://www.emailarchivestaskforce.org/documents/guide-to-email-standards/ is worth a read, and are you sure you know how to validate an email address? https://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx/

For newcomers, important areas to cover are:

  • understanding quirks of different email clients, some of the odd scenarios with specific email services
  • familiarising oneself with the certificate process
  • how TLS is employed with email
  • Hands-on experience is crucial!
  • Doing dry runs with a dev system is invaluable - you must be able to make and break things without taking down customers' email 🙂

I administer shared Postfix servers for numerous clients. Some are newest releases of Postfix, and some, due to legacy requirements, are older. Nothing necessarily wrong with that, but some configuration options aren't always available.

If I was setting up a new Postfix server today, I'd go through these steps:

How about managing traffic?

  • Banning and blocking unwanted traffic isn't a bad thing... it'll also make your logs a lot saner.
  • I've found this combination of add-on checks brings benefits:
    • Judicious use of reject_rbl_client, reject_rhsbl_helo, reject_rhsbl_reverse_client and reject_rhsbl_sender = often significant reductions in unwanted traffic
    • sender_restrictions_bad_tlds.regexp (in the format "/\.date$/ REJECT All mail from .date domains is rejected by this system")
    • postgrey_whitelist_recipients & _clients (and postgrey_whitelist_clients.local, in the format <domain/regular expression>) - https://linux.die.net/man/8/postgrey
    • header_checks.regexp
      • header_checks = pcre:/etc/postfix/header_checks.regexp
    • client_checks.cidr (in the format "103.110.211.0/24        REJECT No mail from this IP range accepted", can also do single IPs)
    • client_checks_rbl_whitelist (to explicitly permit SMTP connections from certain senders,  in the format "IP/address/hostname OK, e.g. "sender1@ OK", "sendermtadomain.com OK"
      • smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/client_checks.cidr, check_client_access hash:/etc/postfix/client_checks_rbl_whitelist, ...(etc)

Probably enough for a starter system! And once everything is running satisfactorily,

  • Check, test and periodically recheck. Deliverability is a moving target more than ever - some large providers are taking a rather bizarre approach to it (accepting mail then silently dropping, wtf?) which will cause you big headaches if you don't spot it quickly.
  • Set up accounts on various freemail services and periodically email from test accounts on customer domains (if you manage them and have permission), or set up domains purely for this purpose. Automate this if possible as you can periodically pseudo-randomly run two-way tests to check deliverability; I still do this manually.

Some other useful resources...

Header checks:

Greylisting's great!

I use greypost with PostfixI initially whitelisted various clients including a base list from https://github.com/schweikert/postgrey/blob/master/postgrey_whitelist_clients
And I add to it, for example (and be descriptive):

# Google-hosted newsletter sender...
dripemail2.com
#Marks & Spencer
mta.news.marksandspencer.com
# Companies House
companieshouse.gov.uk
# Web Co-op SMTP
mailforward.mailhostbox.com
# Ryanair
ryanairemail.com
# Dreamhost - tries from a relay MX then doesn't try a third time
dreamhost.com
mailchannels.net
# MandrillApp (various things)
mandrillapp.com
# Booking.com's weird MTAs
sg.booking.com
booking.com
# LinkedIn
linkedin.com
# Various email testing tools
mail.unlocktheinbox.com
verifier.port25.com
# 20i
stackmail.com

And for a quieter life, drop all traffic from DigitalOcean AS14061: 2604:a880:800::/56 !
SO many unwanted bruteforce attempts and spam from their IPv6 ranges, and they've failed to act on numerous reports of abusive traffic from me and numerous other mail operators over the years. Ban their ASes. Ban them now.

I'm always happy to discuss all aspects of configuration and accept corrections - tweet @christopherw, email or comment on this article.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via email. You can also subscribe without commenting.

I footnotes