Why do so few mail providers support Port 587?

Wed Feb 16 09:42:06 UTC 2005


--On Tuesday, February 15, 2005 21:30 -0500 Sean Donelan <sean at donelan.com> 
wrote:

>
> On Wed, 16 Feb 2005, Thor Lancelot Simon wrote:
>> This is utterly silly.  Running another full-access copy of the MTA
>> on a different port than 25 achieves precisely nothing -- and this
>> "support" has always been included in sendmail, with a 1-line change
>> either to the source code (long ago) or the default configuration or
>> simply by running sendmail from inetd.
>>
>> What benefit, exactly, do you see to allowing unauthenticated mail
>> submission on a different port than the default SMTP port?
>>
>> Similarly, what harm, exactly, do you see to allowing authenticated
>> mail submission on port 25?
>
> How do you tell the difference.  Yes, you can run any protocol on any
> port.  But Well-known ports have a better chance of working across today's
> Internet full of NAT and firewalls.  By keeping authenticated and
> unauthenticated protocols on different ports, its easier to control
> the use of unauthenticated protocols at various middle-points in the
> network without affecting people using authenticated protocols.
>
> Port 25 accepts unauthenticated e-mail for various legacy reasons, which
> are not going to go away soon.
>
> Port 587 is supposed to be authenticated, although some programmers and
> system administrators think its too hard to ask for authentication.
>
I would argue that in today's environment, a well implemented mailserver
supports authenticated submission on ports 25 and 587, and, unauthenticated
delivery on port 25.  It may also support some level of unauthenticated
submission by local users on port 25, if necessary.

> If you accept unauthenticated mail on Port 587, don't complain about
> the spam you are going to get.
>
If you accept unauthenticated mail on port 587, the problem isn't the
spam you will receive, it is the spam you will forward.


Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050216/95ea5fae/attachment.sig>