North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Why do so few mail providers support Port 587?

  • From: Owen DeLong
  • Date: Wed Feb 16 04:40:06 2005

--On Wednesday, February 16, 2005 2:16 +0000 Thor Lancelot Simon <[email protected]> wrote:

On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
Sendmail now includes Port 587, although some people disagree how
its done.  But Exchange and other mail servers are still difficult
for system administrators to configure Port 587 (if it doesn't say
click here for Port 587 during the Windows installer, its too
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?

The whole point of port 587 is that it should _NOT_ allow unauthenticated
submission, where, port 25 generally MUST allow unauthenticated submission
for at least some categories of destination addresses.  If port 25 only
gets used for MTA to MTA communications and port 587 can be used for
CLIENT->MTA submissions on an authenticated only basis, there is some
advantage to it.  Admittedly, port 587 would be unnecessary if ISPs weren't
blocking port 25, but, since they are, it is.  Likely, if people started
requiring SMTP AUTH often enough on port 25 for relay access, the port 25
blocks could be eliminated and port 587 could fade away.  However, in the
meantime, port 687 is a reasonable solution to the real world situation.

Similarly, what harm, exactly, do you see to allowing authenticated
mail submission on port 25?

None.  However, it's very hard to control at the router level whether
your thousands of DSL users are making authenticated submission or
non-authenticated submission to far-end mail servers.  By blocking
port 25 and knowing that almost anyone using 587 is probably recently
enough up on RFCs to know not to allow unauthenticated submission,
this becomes a reasonable compromise.  Everyone requiring auth on
port 25 for relay submission would be a better solution, but, is also
an unrealistic view of the world.

What will actually give us some progress on spam and on usability
issues is requiring authentication for mail submission.  Which TCP
port is used for the service matters basically not at all.

Yep, but, if we block virus->25 and support auth->587, then, we aren't
allowing virus->25 by accident in the current environment.


If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.

Attachment: pgp00007.pgp
Description: PGP signature