On Wed, 12 Apr 2006 21:12:44 +0530 "Suresh Ramasubramanian" <ops.lists@gmail.com> wrote:
On 4/12/06, Matthew Black <black@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