[146071] in North American Network Operators' Group
Re: Outgoing SMTP Servers
daemon@ATHENA.MIT.EDU (Carlos Martinez-Cagnazzo)
Tue Nov 1 15:55:08 2011
In-Reply-To: <5F2E5817-06E1-4822-9405-431098D7902A@drtel.com>
Date: Tue, 1 Nov 2011 17:54:05 -0200
From: Carlos Martinez-Cagnazzo <carlosm3011@gmail.com>
To: NANOG <nanog@nanog.org>
Reply-To: carlos@lacnic.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
The point to make here is:
- if an ISP takes the path of blocking tcp/25, then they MUST
communicate this appropiately to customers and other users
- they also MUST provide alternatives: SMTP over SSL should be allowed
(tcp/465), authenticated relay, but *something*.
IMO blocking 25/tcp is a side-effect of the failure of the whole ISP
system to decisively deal with spammers. It's easier to blind-block
25/tcp than to do proper investigations and to collaborate with law
enforcement. I have tried to hand reports with *static* IP addresses,
contract identifiers and even home, mobile and work phone numbers of
known spammers in Uruguay (I happen to have my personal feud with one
that sells dog food), only to be shelved by management on the fears of
legal action.
I have also trouble swallowing the argument of "blocking 25/tcp is
great because it avoids us getting into black lists and reduces spam".
Yes, sure, but that doesn't prove it's the right approach in the long
run, as you are dealing with symptoms and not causes/sources.
It's the same thing as having tons of aspirines each time you have a
headache. Even if the pain subsides, you might still have other
underlying conditions that in fact are being masqueraded by your
"solution".
So, as it is often the case in society, we all pay the price.
On Mon, Oct 31, 2011 at 11:17 PM, Brian Johnson <bjohnson@drtel.com> wrote:
>
>
> Sent from my iPad
>
> On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com>
>
> <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. =A0They have a better idea of what is accep=
table
>> 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 notif=
y
>> every email 'source' network as to what that recpient considers 'accepta=
ble'.
>> <wry grin>
>
> This is not plausible. It also has nothing to do with a network owner pro=
tecting his network from his own users.
>
>>
>> There are only a relative handful of things a _residential_ provider can
>> use to "reliably" filter outgoing mail. A non-comprehensive list:
>> =A01) 'Greylisting' at the origin is as effective at stopping spam as it=
is
>> =A0 =A0 at the destination.
>> =A02) Checks for certain kinds of standards violations that legitimate m=
ail
>> =A0 =A0 software does not make.
>> =A03) Check for certain kinds of 'lies' in headers -- things that *canno=
t*
>> =A0 =A0 occur in legitimate email.
>> =A04) 'Rate-limiting' to detect/quarrantine abnormal traffic levels.
>> =A05) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if
>> =A0 =A0 present), and quarrantining on abnormal numbers of different put=
ative
>> =A0 =A0 origins.
>>
>> There's no point in checking source addresses against any DNSBL, for rea=
sons
>> that should be 'obvious'. =A0<*GRIN*>
>>
>> Further, any sort of "content" filters prevent customers from _discussin=
g_
>> scams in e-mail.
>>
>> There is a 'hard' problem in letting the source 'opt out' of such filter=
ing,
>> because an intentional 'bad guy' will request his outgoing mail not be
>> monitored, as well as the person who has a 'legitimate' reason for sendi=
ng
>> messages that might trip mindless content filters.
>>
>> Statistical note: =A0Out of the last roughly 6,000 pieces of spam seen h=
ere,
>> circa 2,700 were caught by checks 2), and 3) above, and another circa 2,=
600
>> were in character-sets not supported here. =A0 Incidentally, spam volume=
, as
>> seen here, is running a bit _under_ 2/3 of all email, down from a peak o=
f
>> over 95%.
>>
>
> This misses the point of the thread which is not filtering. It is port 25=
blocking. Statistically all of he problems exist on TCP port 25. This is w=
hy the filtering is largely effective.
>
> - Brian
>
--=20
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
