Outgoing SMTP Servers

Tue Nov 1 19:54:05 UTC 2011

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 at drtel.com> wrote:
>
>
> Sent from my iPad
>
> On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" <bonomi at 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.  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>
>
> This is not plausible. It also has nothing to do with a network owner protecting 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:
>>  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%.
>>
>
> 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 why the filtering is largely effective.
>
> - Brian
>

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================