[TriLUG] OT: Backup MX providers?

[Michael Hrivnak]

Ditto what Alan said.  If you're going to have multiple MXs, they
should really be identical to each other.  Avoid scanning twice, for
example if a message gets scanned and queued on a secondary MX, then
forwarded to a primary MX.  More about that in a moment.

If you must do your own email filtering, you might consider deploying
a couple of VMs in a service like Amazon EC2 and make those your MXs.
Do all scanning at these border MTAs, and give them a secure way to
forward to the final destination.

Another interesting pitfall to consider is SPF(1) checks.  They must
be performed only on the first MX-listed host the message arrives at,
or the check will likely fail.  If you have a primary MX A and a
backup MX B, if A receives a message that was queued on B, A will
check to see if the sending domain designates B as a valid origin
host!  Some have tried to improve this logic by looking at Received
headers, but that can be problematic and is not often attempted.

A key point here is that when you allow one of your MXs to accept a
message, you are taking responsibility for it.  It's like adopting
children- those messages are yours now!  If your MTA accepts it but
the final destination bounces it, your MTA could now be used for
backscatter(2) and will likely end up on RBLs.  You should also be
very confident in the reliability of your MXs- you don't want messages
queuing up on a machine that doesn't have rock-solid storage.  From a
blame perspective, it's better to let the originating service queue a
message and reattempt delivery than to accept that message onto a
less-than-stellar backup MX.

Fighting spam and viruses in email has become very challenging for a
small or even medium size operation.  You may want to look at services
like Postini.  This will let you keep the email itself in-house (if
that's a desirable thing) while letting someone else deal with all the
issues faced at the MX border.

Think about how much time it will take you to get everything setup
just right.  Postfix/Exim/Sendmail/etc, spamassassin, clamav, SPF,
DKIM, RBLs, graylisting, etc- there are a lot of pieces to the puzzle.
 Which messages are safe to reject or drop?  Which should you flag but
make available to the user in case it was a false positive?  How do
you implement that?  Filtering can be resource-intensive; how will it
scale?  Think about the idiot exec who will say "The email system is
broken" because a spam message slipped through and then demand that
you look into it.  What happens when a trigger-happy blacklister like
Barracuda blacklists one of your MTAs for no good reason?

Many look use spamassassin.  What happens when someone writes a stupid
rule (https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269)
which breaks every installation in the world at once (on a holiday
none the less), then it gets replaced by an equally stupid stopgap
rule (https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269#c3),
and 2 years later that is still in place and waiting to cause the same
problem all over again
(https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6271)?

These are just some of the many problems that can arise.  Looking at
the cost of the labor involved in setting up and maintaining a good
solution, you may find that using a service like Postini makes much
more sense.

Michael

P.S. I used to be in favor of running multiple MTAs for redundancy.  I
thought it was better to accept and queue the message onto a machine
that I control and trust than to let it sit in the queue on some
who-knows-what rickety MTA run by some incompetent buffoon.  That may
have been true 5 years ago, but as expressed above, it's just become
too labor-intensive.

(1) http://en.wikipedia.org/wiki/Sender_Policy_Framework
(2) http://en.wikipedia.org/wiki/Backscatter_(email)


On Mon, Feb 6, 2012 at 8:30 PM, Alan Porter <porter at trilug.org> wrote:
>
> A lot of folks will tell you that a secondary MX is more
> trouble than it is worth.
>
> If you don't set the secondary up to accept/reject using
> the same rules as the primary, then it just becomes a
> spam magnet.
>
> For example, if your secondary just receives and forwards
> ALL email for your domain, then spammers will send lots of
> stuff to addresses that don't exist (like bogus at example.com)
> through the secondary.  It will blindly accept it, queueing
> it up for transfer to the primary.  When the primary receives
> the message, it will know that the user does not exist, but
> by that time, it's too late to do the proper thing, which is
> to reject the email and close the connection.  The sender
> will show that email as "delivered", the spammer will mark
> that address as "OK", and they move on.
>
> With a secondary MX, you end up having "special" rules to
> handle secondary-to-primary email.  You want to discard the
> messages, not reject them as they're being presented by the
> secondary.  Otherwise, they will sit in a queue on the
> secondary forever.
>
> The "proper" way to set up a secondary is to have it use the
> same rules and the same database of users or mailboxes.  Some
> people implement this using a periodic report or rsync that
> copies a list of valid users from the primary to the secondary.
>
> Since LEGITIMATE email senders will resend after a little
> while, the benefit of the secondary MX is pretty low.
>
> This is why TriLUG has a single MX.
>
>
> Alan (who set up postfix on pilot in 2009)
>
>
>
> --
> This message was sent to: Michael Hrivnak <mhrivnak at hrivnak.org>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  : http://www.trilug.org/mailman/options/trilug/mhrivnak%40hrivnak.org
> TriLUG FAQ          : http://www.trilug.org/wiki/Frequently_Asked_Questions