[145946] in North American Network Operators' Group
RE: Outgoing SMTP Servers
daemon@ATHENA.MIT.EDU (Brian Johnson)
Thu Oct 27 09:57:12 2011
From: Brian Johnson <bjohnson@drtel.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Date: Thu, 27 Oct 2011 13:53:34 +0000
In-Reply-To: <B8ECE656-6A9F-4EFA-A99E-97E73D997DB7@delong.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I find that large network providers have less issues with this issue.
As a small regional provider, implementing a "sane" port 25 filter has save=
d us a lot of money and customer headaches over the years. Our costs would =
be much higher if we could not save labor hours by implementing this. Possi=
bly making service costs even more prohibitive. Pre implementation of these=
filters we had lower customer satisfaction, and were contemplating hiring =
more people to handle the labor load, due to UCE issues.
It is interesting that some people who fully understand that the Internet i=
s composed of many networks run by people with different interests can say =
what is best for the Internet as a whole. How my organization (or yours or =
anybody else's) runs our network, is between us and our paying users.
But this thread has been interesting to follow. :)
- Brian J.
>-----Original Message-----
>From: Owen DeLong [mailto:owen@delong.com]
>Sent: Wednesday, October 26, 2011 11:42 PM
>To: Scott Howard
>Cc: nanog@nanog.org
>Subject: Re: Outgoing SMTP Servers
>
>
>On Oct 26, 2011, at 8:07 PM, Scott Howard wrote:
>
>> On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong <owen@delong.com>
>wrote:
>> Interesting... Most people I know run the same policy on 25 and 587 thes=
e
>> days...
>>
>> to-local-domain, no auth needed.
>> relay, auth needed.
>>
>> auth required =3D=3D TLS required.
>>
>> Anything else on either port seems not best practice to me.
>>
>> RFC 5068 covers the best practice, and it's not what you've got above.
>>
>> Allowing unauthenticated inbound mail on port 587 defeats the entire
>purpose of blocking port 25 - the front door is now closed to spammers, bu=
t
>you've left the back door open! (Security through obscurity saves you here=
in
>that spammers rarely use port 587 - yet). There isn't a single situations=
where
>you should be expecting an unauthenticated inbound message on the
>'Submission' port (is, 587)
>>
>I still believe that that RFC is not correct. That blocking port 25 has to=
o much
>collateral damage
>and is not a best practice.
>
>As such, you are correct, I am not following RFC 5068. A certain amount of
>spam does hit my
>system, but, the hosts that deliver it are identified and blocked reasonab=
ly
>quickly.
>
>> As much as some ISPs still resist blocking port 25 for residential custo=
mers, it
>does have a major impact on the volume of spam leaving your network. I've
>worked with numerous ISPs as they have gone through the process of
>blocking port 25 outbound. In every case the number of end-user complaints
>has been low enough to be basically considered background noise, but the
>benefits have been significant - including one ISP who removed not only
>themselves but also their entire country from most of the 'Top 10 Spammers=
'
>list when they did it!
>>
>
>Blocking outbound port 25 would not reduce the already infinitesimal volum=
e
>of spam leaving my network in the least. It would, however, block a lot of
>legitimate traffic.
>
>No thanks.
>
>Owen
