On Wed, 12 Apr 2006 21:12:44 +0530
"Suresh Ramasubramanian" <[EMAIL PROTECTED]> wrote:
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
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
