Good morning,
I have a stable low-volume Postfix setup on a 10-year-history IP address. In mid-2025 we need to relocate interstate. The mail MX is going to be offline for a few days for the relocation and have possible further outage time through new location setup. The new location will also likely end up with a different static IP. There is nothing business critical coming through the server, but I would prefer to not totally lose inbound email during relocation downtime. In (early) anticipation of this I am aiming to setup a VPS secondary MX for the domains served by the primary MX to store and relay-fwd to primary MX when it is back online in case the downtime extends over several days. This can be a relatively simple config I believe from looking at https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup <https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup> I have some questions and would appreciate advice from the list. I'd prefer to keep the secondary MX as simple as possible - is there a set of sensible anti-spam configs on the secondary? The primary MX has extensive anti-spam and auth config, with DNSBLs, local DNS server, amavis, spamassassin, milters, etc. in the mail flow, before locally delivering to Cyrus IMAP. It is far from simple… What is sensible for a basic store and forward MX? The domains are also setup with DNSSEC, I don't want to break anything. And I assume I'll need a cert for TLS… I'd value general advice on recommendations for an approach. Finally, is it worth using the secondary MX as a sending SMTP server also, to build sending IP reputation over time? Or should we just continue to run the existing primary MX as sending SMTP, then just change its IP on relocation, and only ever use the secondary for store and forward inbound?
Some general considerations. I have several backup MXs for several domains, where the MX sometimes is the primary for a specific set of domains, sometimes another of this set of MX for a different set of domains. I exchange the list of valid recipients between these servers to block non recipient email reception on the "backup" MXs. That is the relay_recipient_maps directive. I sync those files via ssh/rsync between these MX servers, the "master" being the driver for its specific list. I have no relay as per se, only via the preference in the MX DNS entries. In all cases, you should increase the maximal_queue_lifetime sufficiently, so the email on the backup MX doesn't expire in case it takes longer to setup the primary MX again. DNSsec is not the issue, just keep the dns zone file updated once you have the static IPs and have the reverse dns mapping fixed as well. Regarding the cert, that just doesn't matter for the backup MX. self-signed, letsencrypt, whatever suits the purpose to have encrypted transport between backup MX and delivering servers. And similarly later for backup MX to master MX (unless you REQUIRE a "valid" non-self-signed,non-letsencrypt cert in master MX - which is, as far as I understand - not advisable anyway). Building sender credibility is an issue you have on the relocated master again as well, so the earlier you start with the backup mx does not impact the master credibility and sending then constantly thru the backup isn't really an option, right? Regarding anti spam measures, maybe a plain out of the box postgrey amavis spamassassin clamav is sufficient for this purpose. Maybe these considerations help already? Florian _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
