[Mimedefang] Pre-Acceptance filtering (WAS: Re: recipient filter and RBLs)

[Jan-Pieter Cornet]

On Thu, Dec 06, 2007 at 01:33:16AM -0500, Dirk the Daring wrote:
> On Mon, 3 Dec 2007, "Paul Houselander" <housey at sme-ecom.co.uk> wrote:
> 
> >After a bit of digging around I think ive pretty much decided not to use 
> >the
> >rbl feature in sendmail but to intergrate spamhaus checking into my
> >mime-defang script.

That's a wise decision, I'd say.
 
>    While you can certainly do this, all you're doing is creating a *lot* 
> more work for your mailserver, and encouraging the spammers.

Err, no. You have the wrong idea about mimedefang.

>    The trouble with post-acceptance tools, like SpamAssassin, SpamHaus, 
> DCC, et. al., is that you have to accept the E-Mail. That is, the spammer 
> reached DATA and transmitted the message to you, and you queued it 
> somewhere prior to submitting it to the analysis/tagging tool.

spamhaus is an RBL, the others (spamassassin, DCC) are mail content
analyzers.

It's perfectly OK to put RBL checks like zen.spamhaus at the RCPT
stage, using mimedefang. We're doing that. It enables you to reject
the mail right away, while still allowing mail to recipients who want
to or must receive such mails (eg postmaster).

>    As far as the spammer is concerned, that is "Mission Accomplished". 
> They have successfully wasted your bandwidth and disk space, and you're 
> about to let them waste your CPU and RAM as well.

Not quite, it's "Nuisance Accomplished". For a spammer, it's only
"Mission Accomplished" as soon as someone actually buys something. Or
in practice, this means that as soon as a large enough population of
people see the message.

If people en masse stopped buying crap advertised via spam, it would
go away. Which is never going to happen unless scientists can stop
IQs being distributed by a bell curve (ha! solving the spam problem
through genetic engineering! :)

So all it takes is for enough people to not see the messages, and it
will become less (see Google's anecdotal evidence of this).

>    By the end of HELO, I've stopped fully half of the SPAM sent to my mail 
> relay. By the end of RCPT TO: (before DATA), I've stopped about 75-80%.

Roughly the same here, I suppose. Let's see, the stats for the day:

blocked by HELO pattern: 86 (21%)
pregreeting traffic: 21 (5%)
blocked using blacklists: 258 (64%)
blocked using misc other pre-data checks: 16 (4%) (mainly quota exceeded)
blocked using content analysis: 15 (4%)
valid emails that make it through: 9 (2%)
(total is 405 mails. These numbers are averages, per second, over the
last day).

>    If you want to wait until after DATA to see if you should have even 
> bothered queuing the message, that's fine, but be sure you understand just 
> how much you're increasing the load on your mail server.

MIMEDefang is a milter, allowing you to interact with the SMTP protocol
at practically any level, so it is quite possible to stop mail at 
connect, MAIL From, RCPT... and after DATA, but before ACKing, so you
don't have to generate a bounce and cause backscatter.

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disclamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please !!
!! archive this message indefinitely to allow verification of the logs.  !!