OK, I've been using Postfix for, um, years. In fact, the current server
has been running -- and is *still* running -- on CentOS 4 for more than
a decade -- a distribution that's been moribound since early 2012.
Still on PostFix 2.2.10, which is WAYYYYY past the sell-by date.
I'm so far into the past, frankly, that I'm thinking it would be smarter
to start from scratch than trying to perform some magical update. This
coincides with the installation of fiber service, so the old setup can
run in parallel while I update everything.
My plan: put together a CentOS 7 server on a tower with a laptop
motherboard and SSD, to limit power consumption, running with the latest
Postfix from that distribution, and copy over only those things that are
unique to my mailserver. Like, just the existing mail, not much else.
(I use IMAP extensively).
So, a question: is there a best-practices guide, manual, or book that
describes how to set up all the modern goodies like DKIM and TLS? What
I found thus far:
1. https://linux-audit.com/postfix-hardening-guide-for-security-and-privacy/
2.
https://security.stackexchange.com/questions/81944/perfectly-secure-postfix-mta-smtp-configuration
3. https://mecsa.jrc.ec.europa.eu/en/postfix
4. https://www.linuxtechi.com/configure-domainkeys-with-postfix-on-centos-7/
I'm open to buying an up-to-date book; my PostFix library has books with
publish dates of 2001, 2004, and 2005. Recommendations from Wietse and
Viktor in particular are welcome, but others feel free to chime in.
===
TL;DR: reduce the size of the attack surfaces exposed to the public by
the mail server, including "sneak" channels
Other hardening: I'm putting the mail server in a separate DMZ channel,
using VLAN tagging, with VLAN-unaware devices running through a port on
a HP ProCurve gigaswitch port. For the mail server, these are the only
ports being forwarded from a single public IP address, terminating in
the edge router, via DNAT to the mail server: 25, 465, and 587. The
Dovecot ports are *not* being forwarded from the public IP address, but
only from "inside" or by VPN or SSH tunnel: 118, 995, 143, and 993.
SSH (22) is also restricted likewise -- no direct public access.
N.B.: the VLAN channels are
local LAN
NTP appliance TM1000A
Mail server
Web servers
(future) WiFi Access Point
all on separate VLANs and with all packet forwarding curated by the edge
router's custom IPTABLES configuration. Adding a VLAN is easy if I add
other servers.
The intent is (1) to reduce the size of the broadcast domain and control
packet volume on each channel, (2) in particular protect the TM1000A
appliance which shares the tendency of most embedded TCP/IP stacks to be
a little fragile in the face of heavy packet traffic, and (3) erect high
walls between VLANs in case of a breech of a server or appliance in an
otherwise public-facing device.
