[TriLUG] OT: Backup MX providers?

[Matt Pusateri]

All very valid points so far,  a good discussion.  I want to caution one thing, I volunteer for FOSS project running their mailing lists, they moved to a EC2 instance.  Long story short EC2 subnet blocks are on a lot of blacklists b/c of how easy it is to provision and setup a spam server.  Not that it's harder anywhere else, but a lot of spammers jumped on the EC2 bandwagon.  This apparently is a known problem hosting mail via a EC2 instance, and will most likely cause you problems.  Yahoo in particular is almost impossible to get off their block list. 

As a side note, I've never had issues with TW Telecom being a backup MX, doing a store and forward to our primary.  The primary still ends up filtering the mail, I haven't had to setup a secondary, and I'm not sure how TW Telecom has their's setup, but we've never had the problem of them abusing our secondary MX.  And while I've lost my circuit before, TW Telecom whole network has never gone down, so using them for a backup MX has never been an issue.

Matt P.

On Feb 6, 2012, at 9:59 PM, Michael Hrivnak wrote:

> 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
> -- 
> This message was sent to: M. Pusateri <mpusateri at wickedtrails.com>
> 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/mpusateri%40wickedtrails.com
> TriLUG FAQ          : http://www.trilug.org/wiki/Frequently_Asked_Questions