Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]

Wed Apr 12 15:53:07 UTC 2006

On Wed, 12 Apr 2006 21:12:44 +0530
  "Suresh Ramasubramanian" <ops.lists at gmail.com> wrote:
> On 4/12/06, Matthew Black <black at csulb.edu> wrote:
> 
>> Where is the bandwidth savings once we've accepted an entire message,
>> scanned it, determined it was spam, then provided a 550 rejection
>> versus silently droping?
> 
> If you can scan it inline, you can stop, issue a 550 and drop the SMTP
> connection any time you want.  Like for example, midstream when you
> discover a fake header pattern.
> 
> You'd start with whatever can be rejected in session - fake HELOs,
> blocklist listed IPs, random faked headers,  dodgy attachment types
> that are more likely to be viruses than not
> 
> Then apply the heavier and more cpu intensive filters later, on a much
> smaller volume of spam

We already do this.

> Maybe not all that much of a bandwidth / cpu saving, but saving remote
> postmasters the hassle of troubleshooting lost email is always a good
> idea.

After all said methods have been performed and the message gets
through reputation filtering; blacklists; forged/munged headers,
e-mail addresses, domain names the message comes in and then
there's that final dot. Up to this point, the message hasn't
proven to be spam until it can be scanned using BrightMail,
SpamAssassin, Baysian filters, DCC lists, or other methods.
All I'm saying is that once the full DATA submission has completed,
there's no bandwidth savings from silently dropping the message
versus providing a 550 rejection. In the best of all worlds,
it would be nice to give feedback. No system is perfect and a
false-positive rate of less than one in a million "220" accepted
messages seems pretty small.

matthew black
california state university, long beach