Re: [SAGE] Secondary MXs and Spam policies.

[Brad Knowles <brad@stop.mail-abuse.org>]

At 1:11 PM -0400 2004-09-16, Adrian Chung wrote:

>  1) Does anyone use secondary MX servers that aren't under their
>  operational/administrative control?  Is there any benefit these days
>  to doing so, or will most MTA's queue mail for an unreachable primary
>  for a reasonable amount of time?

	MTAs should queue for a reasonable period of time, but you've got 
to be careful when selecting secondary MXes to make sure that they 
know who all your valid local addresses are.

	One typical spammer technique is to intentionally connect to 
higher-cost MXes for a domain and dump dictionary-attack addresses on 
them, under the assumption that most people will whitelist their 
secondary MXes, and more of the spam will get through.

>  2) Is it considered best practice or preference to do RBL and
>  extensive filtering during the MTA initial session so that mail deemed
>  as spam is dropped on the floor earlier rather than later, or queue
>  the mail and have something more thorough check it and
>  reject/filter/tag it later?

	It is more scalable to accept the message and filter it after the 
disconnect, but you need to make sure that you don't get into the 
joe-job amplification problem.  My preference is to do all the 
filtering, etc... while holding the sender open, so that I can 
immediately refuse the message.

>  I'm aware that having the mail queued and then rejected means that you
>  may end up sending bounces to non-existent (or purposely crafted)
>  forged envelope sender addresses.

	Right, that's the joe-job amplification attack.

>  In the case of having secondary MXs not under your control which
>  simply queue and forward, you lose the ability to reject mail during
>  the SMTP session unless you check all Received headers against RBLs.

	You need to make sure that your secondaries apply all the same 
anti-spam techniques as you apply, otherwise you (and your 
secondaries) are in for a world of hurt.

	It can also be useful to have tertiary MXes that don't run real 
mail servers.  Instead, they run spamtrap/tar-pit software which is 
designed to catch the spammers who intentionally connect to 
higher-cost MXes, and which shouldn't cause serious problems for real 
mail servers which might accidentally contact them.

>  My personal preference at the moment is to queue mail (even at the
>  expense of higher resource utilization) and do more thorough checks
>  later, than to drop things that came from an RBL-listed server at the
>  front door.  Maybe I don't have enough confidence in RBLs.

	I don't believe in using RBLs to make binary decisions as to 
whether or not to accept or reject the message.  I do believe in 
using them as input to a scoring system (e.g., SpamAssassin), which 
is executed in real-time while the sender is held open.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.