On: Mon, 31 Oct 2011 09:48:21 -0700, Michael Thomas <mike@mtcc.com> opined:
Dave CROCKER wrote:
On 10/30/2011 8:36 PM, Brian Johnson wrote:
So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct?
If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection?
As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency.
I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities:
1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse
Given the cost of incoming filtering, I'd think that outbound filtering would be down in the noise. On the other hand, getting support blowback for false positives seems plausible, but probably no worse than blowback from false positives incoming. So, #3 -- assuming my list is exhaustive which it probably isn't -- seems like a real possibility. Especially when you consider that it opens a can of worms of "now that > we know we have a likely bot, what do we with it, and how much will that cost?"
There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients. And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. <wry grin> There are only a relative handful of things a _residential_ provider can use to "reliably" filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins. There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. <*GRIN*> Further, any sort of "content" filters prevent customers from _discussing_ scams in e-mail. There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters. Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%.