Setting up a secure Postfix server in 2019

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:

abuse@ and postmaster@ really should exist and be checked or alias to your account
Sign up for feedback loops operated by the big providers
double- and triple-check that your MTA isn't an open relay!
Offer every possible method of verification you possibly can; TLS, SPF, DKIM & DMARC ... and keep an eye on the reports.
Don't run weak ciphers and don't accept horribly obsolete protocol handshakes -- but equally, don't block legitimate traffic from large providers who aren't running the latest TLS versions yet. Receive generously, send conservatively.
You REALLY need to become very comfortable with the inner workings of Postfix and TLS, and understand what constitutes a decent level of encryption with modern cipher suites
Further reading on TLS:
PTRs and declared hostnames should always agree!
Autodiscover records in DNS, autoconfiguration and service discovery can be convenient for users and support bodies
Add proactive monitoring (fail2ban, etc); monitor access to inboxes, establish patterns of normal IP traffic if you can and keep an eye on outbound volumes and bounces
Run verbose logging and rotate/archive, instead of encounter an issue and realise you have no useful historical data to analyse
Support as many modern protocols on as many ports as you can
Validate inbound mail as much as you can afford to - RBL, SBL, postscreen
Consider miltering not just for AV and spam but also greylisting - greypost configured with a light touch has massively reduced the volume of inbound junk
Be as strict as possible with how your customers' clients can connect (RFC compliance, HELOs required, etc)

I recommend you also read my recent post about Postfix, SSLv3 and TLS.

How about managing traffic?

Some notes:

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
  - Best lists are Spamhaus ZEN, cbl.abuseat.org, dul.dnsbl.sorbs.net, sbl-xbl.spamhaus.org, uceprotect.net and and barracudacentral RBLs
- sender_restrictions_bad_tlds.regexp (in the format "/\.date$/ REJECT All mail from .date domains is rejected by this system")
  - smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/sender_restrictions_bad_tlds.regexp
  - I've built a list of TLDs I deny emails from based on observed traffic; there's plenty of resources to get started:
  - https://www.spamhaus.org/statistics/tlds/
  - https://www.symantec.com/blogs/feature-stories/top-20-shady-top-level-domains
  - http://www.surbl.org/tld
- 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 #Spotify spotify.com

Adding your own whitelisted clients is best done using a postgrey_whitelist_clients.local file in the same directory so you won't lose your additions should anything overwrite the default file.

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.

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

For newcomers, important areas to cover are:

How about managing traffic?

Some other useful resources...

Greylisting's great!

Leave a Reply Cancel reply