[Chapter-delegates] Blocking port tcp/25 outgoing

Wed Nov 11 00:32:32 PST 2009

I beg to respectfully disagree. 

Message submission (as opposed to
message transfer) is defined in rfc4409 as being on port 587. It is true
however that smtp-auth (RFC2554) does not specifically indicate which port
should be used. Hence, you *can* do authentication on port 25, but it is
supposed to be for transfer, not submission. 

There is a good explanation
here
http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Outgoing_mail_SMTP_server

So, I would rather stick to standards and use 587 for submission. This
is what most MUAs will do by default anyway if you define your outgoing
SMTP server as requiring authentication. TLS, as defined in RFC3207, is
essentially port-agnostic, and can be on 25 and/or 587. 

However, we must
realize that ISPs run a service for a population that is, in its vast
majority, clueless regarding how to protect themselves and others of
security threats. In this case, blocking outgoing on port 25 has proved to
be effective. The 0.5% of experts will know how to work around the
limitations.  

Patrick 

On Wed, 11 Nov 2009 09:51:27 +0200, Ed Tric 
wrote:  TLS adds encryption on the standard port 25 , there is no need to
use other port to send securely smtp messages.
 We use TLS with smtp-auth
on our server. The main Adsl provider Romtelecom allows outgoing messages
on 25 , but some cable providers prohibit it.
 >From a user point of view (
having no clue about it ) it's a denial of service to block legitimate
ports.
 Hackers can use other other posrts than 25 to install their
backdors in order to send spam. Security within obscurity is never a good
solution, so i concur with Marcin.
 Let users act as users and experts as
experts. If you want users to act like experts we are going into a wrong
direction:)
 Ed
 Patrick Vande Walle a écrit :  
Marcin,

I concur with
Franck and others. I am actually surprised the main Polish
ISP did not
implement this earlier. 

Over here, ISPs generally accept port 25 traffic
on their main outgoing
SMTP relay from their customers, but block SMTP
traffic going outside their
network for residential customers. Outgoing
e-mail traffic on port 587 or
465 goes through with no problem. 

This is
the good way to block e-mail traffic generated by virus-infected
Windows
boxes. Anyway, most serious e-mail service providers will not
accept any
SMTP connection from dynamic IP blocks, using lists like
Spamhaus PBL
http://www.spamhaus.org/pbl/index.lasso [1]

I am much more concerned with
ISPs blocking *incoming* connections. I know
of one in Belgium which blocks
incoming connections to all ports below
1024. This prevents users from
hosting their blog on a home machine, for
example. It is becoming realistic
to do so on garden variety DSL/cable
connections where the return channel
can be as high as 1 Mbit. 

Patrick

On Wed, 11 Nov 2009 02:42:34 +0000,
Marcin Cieslak  [2]
wrote:

Telekomunikacja Polska - the largest broadband
Internet access provider

in

Poland
(and the incumbent telecom operator)
plans to block traffic outgoing on
the tcp/25
port effective December, 1st
2009. This port is used for the Simple Mail
Transfer
Protocol (SMTP)
traffic.

Mail submission (tcp/587) from RFC 4009 and SMTP over SSL
(tcp/465) are
going
to be the recommended ways for their customers to send
email using
third-party
SMTP relays.

This change will affect their home
(consumer) DSL access customer, 
This will affect I think over 2 million
customers.

1. How many of providers in your region implement such a
measure?

2. If so, do customers have an option to lift the block on
request for
their 
access line? (Assuming customer authentication via
MAC-address or PPP
and variants is used).

3. How does that change
influcence customers? Does that change limit
amount of spam being sent, and
if so, to what extent?

4. To all: Do you think local ISOC chapter should
respond to blocking
of SMTP traffic? If yes,
how?

--Marcin
_______________________________________________
Chapter-delegates
mailing list
Chapter-delegates at elists.isoc.org
[3]
http://elists.isoc.org/mailman/listinfo/chapter-delegates [4]

--

Blog: http://patrick.vande-walle.eu
Twitter:
http://twitter.vande-walle.eu
Identica: http://identica.vande-walle.eu

Links:
------
[1] http://www.spamhaus.org/pbl/index.lasso
[2]
mailto:saper at saper.info
[3] mailto:Chapter-delegates at elists.isoc.org
[4]
http://elists.isoc.org/mailman/listinfo/chapter-delegates
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20091111/194a6a21/attachment.htm>