Email Security Gateway Deployment: Avoid These Common Mistakes

Don’t declare your primary mail server (MTA) as a secondary MX

When deploying an Email anti-spam or anti-virus solution, administrators commonly make the mistake of placing the gateway as the primary MX for their domain(s), and the backend mail server (protected by this gateway) as the secondary MX, in case the gateway fails.

At face value, this seems like a good idea. In fact, it isn’t.

Why? Spammers habitually target the secondary MX address on the assumption that it is likely to be the main mail server. They may also do this to avoid Nolisting. The end result is that your anti-spam gateway is completely bypassed.

Recommendation: you should only have a single MX for your Email domain(s).

If, for compliance or policy reasons, you need a secondary MX in case the primary gateway fails, you could always deploy a backup spooler or mailbagger, as some admins call them. This is basically an MTA configured to accept mail for the domains that you host, and to hold the messages if it can’t deliver them to the gateway.

Backup Spooler / Mailbagger setup

In this context, it is important that the backup spooler routes all mail it receives back to the primary gateway, not the main MTA, otherwise you’ll be back to square one: spammers will be able to bypass the gateway again and hit the main MTA through your mailbagger.

You COULD configure the mailbagger to route the mail directly to your main MTA only in-extremis, e.g. if the primary gateway will be down for a long period of time. In this case, you should make sure that the mailbagger has some anti-spam/anti-virus capability of its own.

Assuming the mailbagger is set to route mail back to the gateway, you CANNOT add the mailbaggers IP to the trusted IP list on your anti-spam /anti-virus gateway, since the mailbagger may be spooling spam. You WANT to have content filtering working on the AS/AV gateway when receiving traffic from the mailbagger.