Outgoing SMTP Servers
bonomi at mail.r-bonomi.com
Mon Oct 31 16:19:14 CDT 2011
On: Mon, 31 Oct 2011 09:48:21 -0700, Michael Thomas <mike at 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'.
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
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
More information about the NANOG