1

Let's suppose we have an SMTP server called alpha.example.com, which is the only MX server listed for example.com.

Like most modern email SMTP servers, rejects emails not bound for its group of virtual users, rejects incoming email from spamhaus listed domains, runs mail through SpamAssassin, checks SPF records, all of that good stuff.

However, being the only MX record listed for example.com, there's a concern that if the machine is taken down for maintenance, email may be delayed. Well behaved other SMTP servers will obviously queue, and retry later, but that could introduce some tens of minutes or hours of delay, even if the primary is brought down for a small amount of time if it coincides with an attempted delivery.

We want to start a secondary SMTP server, which let's call beta.example.com, which will be listed as the lower priority MX record. But alpha.example.com is still where all the mail is stored, it's still where all the users connect their MUAs to. So beta.example.com will just store-and-forward email to alpha.example.com, since it's not the "endpoint".

My question is: Does beta need to also run its email through the same checks as alpha? ie. checking for virtual users, spamhaus, SPF lookups, DKIM checks, or is the fact that those things are checked on alpha when the email is delivered is sufficient

Also, will beta relaying the emails to alpha fall afoul of those emails SPF lookups, given that beta.example.com is unlikely to be listed as a valid sender of arbitary.org's emails.

Technically I'm using Postfix for SMTP (and Dovecot for the authentication/IMAP side), in case that informs the answers.

2 Answers 2

5

Having the secondary server run the same type of checks doesn't cost anything, so why not just do it?

Some other reasons:

  • You would have to adapt your primary server to correctly handle mails from the secondary server like they come from one hop before. Your SPF concern is valid and by default would be a problem. Assuming filtering has already happened is much simpler.
  • Most antispam solutions will reject some mails before they are completely transmitted (e.g. right after the EHLO message or after the TO header). Without these filters, you now first have to accept those and fully deal with them on the primary server. In some jurisdictions, this can even become a legal problem (e.g. in certain constellations, it is acceptable to outright reject a mail, with the sender knowing this, but it's not OK to first accept the mail and then delete it anyway in further filtering steps, without the sender knowing this).
1

Parsing Authentication-Results of your backup MX is not the real problem here. RFC 7601 describes solid mechanisms for dealing with potential abuse - you remove obviously spoofed headers during header cleanup and tell your validation software to trust the results determined by your backup mx (TrustedAuthServIDs beta.example.com in opendmarc.conf).

Yet No, running a secondary MX with the same configuration as the primary MX defeats much of the original purpose for deploying it:

  1. There is a non-zero probability that your primary mail server outage is caused by one of your mail filtering programs - if you just duplicate the setup, one bad spamassassin update breaks both, one bad SPF validator update breaks both, .. A backup MX that likely fails from a shared root cause is not worth much.

  2. You primary mail server probably already filters mail based on statistical data (e.g. Bayesian Filtering) which is hard to keep in sync between primary and backup mx. If you really setup mail screening on backup mx the way it is on primary mx - and that data is different, you will either degrade your spam filtering quality - or send more bounces (eww).

  3. If your task is to ensure some service level like "98% of yearly non-spam mail must show up in IMAP within 60 seconds" you have already got tons of room for unscheduled maintenance. It is entirely possible that potential service level improvement versus the recurring administrative cost for running the backup MX end up making any remotely complex backup MX setup "not worth it".

4
  • What if the outage is just caused by routine system reboots, restarting, that sort of thing?
    – coiax
    Mar 15, 2019 at 10:56
  • @coiax Sure that is downtime.. but these days, it is going to be about 23 seconds at 3:10 in the morning, about once a month. You can probably find another single point of failure with worse service quality properties than that.
    – anx
    Mar 15, 2019 at 13:50
  • So, following this logic, when would you ever actually want a secondary MX server?
    – coiax
    Mar 15, 2019 at 14:41
  • @coiax when the primary is no longer "where all the mail is stored"
    – anx
    Mar 16, 2019 at 0:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .