North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Spam filtering bcps [was Re: Open Letter to D-Link abouttheir NTP vandalism]
On Wed, 12 Apr 2006 21:12:44 +0530 "Suresh Ramasubramanian" <[email protected]> wrote:
We already do this.On 4/12/06, Matthew Black <[email protected]> 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
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