[146040] in North American Network Operators' Group
Re: Outgoing SMTP Servers
daemon@ATHENA.MIT.EDU (Brian Johnson)
Mon Oct 31 21:20:08 2011
From: Brian Johnson <bjohnson@drtel.com>
To: Robert Bonomi <bonomi@mail.r-bonomi.com>
Date: Tue, 1 Nov 2011 01:17:16 +0000
In-Reply-To: <201110312119.p9VLJEck099196@mail.r-bonomi.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Sent from my iPad
On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com>=20
<snip>
> 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 acceptab=
le
> to the recipients (their users), than the originating MTA operator does. =
An
> originating system cannot accomodate that diversity of opinions _without_=
=20
> getting input from all prospective recipients.
>=20
> And it is, of course, 'not practical' for every email recipient to notify=
=20
> every email 'source' network as to what that recpient considers 'acceptab=
le'.
> <wry grin>
This is not plausible. It also has nothing to do with a network owner prote=
cting his network from his own users.
>=20
> There are only a relative handful of things a _residential_ provider can=
=20
> 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=
=20
> software does not make.
> 3) Check for certain kinds of 'lies' in headers -- things that *cannot*
> occur in legitimate email.=20
> 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.
>=20
> There's no point in checking source addresses against any DNSBL, for reas=
ons
> that should be 'obvious'. <*GRIN*>
>=20
> Further, any sort of "content" filters prevent customers from _discussing=
_=20
> scams in e-mail.
>=20
> There is a 'hard' problem in letting the source 'opt out' of such filteri=
ng,
> because an intentional 'bad guy' will request his outgoing mail not be=20
> monitored, as well as the person who has a 'legitimate' reason for sendin=
g
> messages that might trip mindless content filters.
>=20
> 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,6=
00
> were in character-sets not supported here. Incidentally, spam volume, a=
s
> seen here, is running a bit _under_ 2/3 of all email, down from a peak of=
=20
> over 95%.
>=20
This misses the point of the thread which is not filtering. It is port 25 b=
locking. Statistically all of he problems exist on TCP port 25. This is why=
the filtering is largely effective.
- Brian=
