|
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 about their NTP vandalism]
On 4/12/06, Matthew Black <[email protected]> wrote: > Agreed, but we're willing to live with an error rate of less > than one in a million. This isn't a space shuttle. I don't think > the USPS can claim 99.9999% delivery accuracy. Nonetheless, to I'm not even saying five nines. Spam filtering - even with heuristics etc - is less than perfect, and per user spam filtering, however idiot proof, sometimes turns out to be like giving Acme Inc gadgets to Wile E Coyote. [users having fun with procmail and .forwards should already be a familiar story I guess?] > We already reject most connections with a 550 or TCP REFUSE > based on reputation filtering and blacklists, et al. That works just fine. I dont have any argument with it > 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. -- Suresh Ramasubramanian ([email protected])
|