[gtaSAGE-members] Secondary MXs and Spam policies.

[Thamer Al-Harbash]

On Thu, 16 Sep 2004, Adrian Chung wrote:

> 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?

If you have a handful of accounts you can probably get away with
queueing and relying on SpamAssassin to do the RBL check. If you
have 100,000+ accounts I can tell you from experience you should
do an RBL check first, queue it, and then run it through a spam
filter if the system load is low enough.

Incidently, lots of spammers will connect, spam 100+ accounts,
and disconnect. Dropping the connection before you even process
the messages can save you a lot of cpu time.

> 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.

It depends on why you're rejecting it. You don't always generate
bounces. Ultimately you only generate a bounce if the mail cannot
be delivered locally.

Right now my personal mail servers will accept mail as long as
its destined to my local domain. If you try to send an email to a
non existant account I write it to /dev/null. It's useless to do
anything else as you'll just generate bounces to non existant
addresses 99% of the time.

On a large user base you should verify if the account is local or
not and deny the SMTP DATA command if the user is not
local. Unfortunately this allows spammers to harvest your users,
but it does lower your processing load and free up your
queue. It's cheap to do a local user lookup (or it should be if
you did your job right). It's expensive to bounce.

I don't believe in writing to /dev/null on such a system because
customers with cancelled accounts should generate an error on the
other end. This policy is important or people "lose" mail.

> 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.

That's too bad. See if you can get a friend to act as
secondary. Honestly, for a personal system I wouldn't bother with
secondary. I only set one up because I had the resources
available. If I didn't I wouldn't bother.

On the other hand you're forced to have a secondary NS which
usually means you can setup a secondary MX.

> 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.

Works fine with 5 users. Good luck doing it with 100k users.

Have you looked at DCC? Spamassassin will use it if it can. It's
a decent system for rejecting bulk mail based on white lists and
fuzzy checksums. It's very lightweight too.


-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F