Why do so few mail providers support Port 587?

Mailman List Mirror (Read Only)
1

Although RFC2476 was published in December 1998, its amazing
how few mail providers support the Message Submission protocol
for e-mail on Port 587. Even odder, some mail providers
use other ports such as 26 or 2525, but not the RFC recommended
Port 587 for remote authenticated mail access for users.

Large mail providers like AOL, GMAIL and Yahoo support authenticated
mail on port 587; and some also support Port 465 for legacy SMTP/SSL.
But a lot of universities and smaller mail providers don't. They
still use SMTP Port 25 for roaming users. With AT&T, Earthlink, COX,
Netzero and other ISPs filtering port 25 for years, I would have thought
most mail providers would have started supporting Port 587 by now.

What can be done to encourage universities and other mail providers
with large roaming user populations to support RFC2476/Port 587?
What can be done to encourage the mail client software programers (i.e.
Outlook, Eudora, etc) to make Port 587 the default (or at least the
first try) and let the user change it back to port 25 (or automatically
fallback) if they are still using a legacy mail server.

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
complicated).

2

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?

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.

Thor

3

because then you can filter port 25 access to anywhere except your
local mailserver, like we do here on campus, and suggest to people
they use a VPN or Authenticated SMTP to port 587 to their ISP or
company when they wish to use an external mail server.

Quite useful when it works (read: the other party has implemented
AUTH-SMTP on port 587).

adrian

4

Thor Lancelot Simon 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
complicated).

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?

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.

In general, I have agreed with your point of view in the past. I will
say, however, that recently I have slightly retraced my position.

The only real benefit I see from it is that running multiple ports
allows the mail server to provide different policies for clients to use.

Ideally, this shouldn't be needed, but given that some mail client
software doesn't allow the configuration options that are needed in some
situations (Apple's Mail.app absolutely infuriates me at times), there
are times that slightly different policies are needed, and the only
really good way to do that is to run them on different ports.

I guess you could think of it as having port 25 available for legacy
support as more and more stuff moves to 587.

authentication for mail submission would be wonderful if it were
ubiquitous...and I'm doing my part (this message, and all others from me
these days submitted to my ISP's system with SMTP AUTH over
TLS...incidentally, they had to configure 587 in order to get the
policies workable for the variety of mail clients that customers
used...sad but true, they had no choice while maintaining any semblance
of varied client support), alas, that day is still fairly far
off...though it is getting closer.

5

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.

If you accept unauthenticated mail on Port 587, don't complain about
the spam you are going to get.

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.

In theory true, you could run a TELNET listener on Port 25 or 135. But
the world works a bit better when most people follow the same practice.
Port 587 is for authenticated mail message submission.

6

And if they's implemented unauthenticated SMTP on port 587, like,
say, Sendmail, you've achieved nothing, or possibly worse, since you
have encouraged people to simply run open relays on a different port
than 25. How long do you think it's going to take for spammers to
take advantage of this? (That's a rhetorical question: I already see
spam engines trying to open port 587 connections in traces).

Slavishly changing ports isn't the solution. Actually using authentication
is the solution. It is silly -- to say the least -- to confuse the benefits
of the two.

Thor

7

I'm sorry, your last message seemed to indicate that you felt that
Sendmail accepting unauthenticated mail on port 587 (if configured to
accept unauthenticated mail at all) was not a problem; that, somehow,
it was a *good* thing that it would happily apply the same policy to
all ports it listened on, so long as one of those ports was 587.

Is that not, in fact, your position?

It is really hard for me to see encouraging people to run additional
unauthenticated mail servers on some other port as a good idea, and it
is really hard for me to read the actual text in your first message
any other way than simply "mail accepted on port 587 good".

Thor

8

Thor,

I don't think anyone is confusing the benefits. Sean's suggestion was quite
clear. Run SMTP-Auth on port 587 and leave port 25 for email from other mail
servers. There are lots of benefits to this approach.

For one thing, it eliminates a lot of the "reasons" for provider email
smarthosting, which needs to go away due to massive abuse. Sender email
authentication will make smarthosting obsolete and users will need a
different way of sending outgoing mail that isn't spam to their own mail
servers for legitimate relay. ISPs filter port 25 outbound, but leave 587
open with the idea that users would have to authenticate against distant
mail servers on that port. Everything works well.

587 running SMTP auth (and relaying for authenticated users) and port 25 for
local (non relay) delivery without authentication should be the default on
all servers.

9

Thor,

587 running SMTP auth (and relaying for authenticated users) and port 25 for
local (non relay) delivery without authentication should be the default on
all servers.

Agreed! At the very least you get the benefit of an electronic trail
to follow if one of your users *is* spamming.. :slight_smile:

If you only relay mail from authenticated users, drop (not bounce) any
mail destined for a non-existant account, and use reasonable spam
blocking and tagging, you should be able to reduce spam to a slow
trickle.. It's working here, thus far... And I don't have
authentication fully implemented yet. :slight_smile:

10

Although RFC2476 was published in December 1998, its amazing
how few mail providers support the Message Submission protocol
for e-mail on Port 587. Even odder, some mail providers
use other ports such as 26 or 2525, but not the RFC recommended
Port 587 for remote authenticated mail access for users.

Large mail providers like AOL, GMAIL and Yahoo support authenticated
mail on port 587; and some also support Port 465 for legacy SMTP/SSL.
But a lot of universities and smaller mail providers don't.

Lots of small companies support these as well, including hosting companies and smaller ISPs, and have done so for 5 or 6 years.

  They
still use SMTP Port 25 for roaming users. With AT&T, Earthlink, COX,
Netzero and other ISPs filtering port 25 for years, I would have thought
most mail providers would have started supporting Port 587 by now.

What can be done to encourage universities and other mail providers
with large roaming user populations to support RFC2476/Port 587?

Get the software developers to do some useful programming.

What can be done to encourage the mail client software programers (i.e.
Outlook, Eudora, etc) to make Port 587 the default (or at least the
first try) and let the user change it back to port 25 (or automatically
fallback) if they are still using a legacy mail server.

Don't forget enabling SMTP AUTH by default. Microsoft seems to only support SMTPS and POPS (alternate ports).

Eudora finally supports TLS reasonably well now that they switched to using OpenSSL. While Eudora can be configured for port 587, it takes some doing, since users have to install the esoteric settings menu plugin or edit a config file.

It'd be nice if the new account wizards actually got this stuff right. We give customers a document that walks them through the wizard, then walks them through fixing the things the wizard didn't do.

Sendmail now includes Port 587, although some people disagree how
its done.

The configs for sendmail that come with RedHat have it listening only to 127.0.0.1 by default. The config file (.mc) has a good config line for port 587 documented and commented out. They also have a port 465 example, which has encryption required, but not AUTH.

Is the proper configuration or proper examples the responsibility of sendmail developers, those packaging sendmail with systems, or those who deploy the software?

11

Thor Lancelot Simon wrote:

What benefit, exactly, do you see to allowing unauthenticated mail
submission on a different port than the default SMTP port?

The relevant RFC says that port 587 must be used for authenticated connections ONLY.

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

I think the idea was that Port 25 must also allow unauthenticated connections from foreign MTAs. Port 587 is designed to be used only to relay mail for authenticated users of the server in question, because outgoing Port 25 connections are so widely blocked by large ISPs.

What will actually give us some progress on spam and on usability
issues is requiring authentication for mail submission.

That's the way it's *supposed* to work now. What actually will give us progress on spam is a complete rewriting of the SMTP protocol, but quite frankly, I'm not holding my breath.

12

Daniel Senie wrote:

Is the proper configuration or proper examples the responsibility of sendmail developers, those packaging sendmail with systems, or those who deploy the software?

The correct answer is "those who deploy the software," regardless of whether it's a mail server, firewall, IP router,* or any other type of software.

*I had to say that; this *is* NANOG.

13

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
complicated).

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.

Owen

14

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

15

Um, you actually have to work somewhat to get sendmail to support
unauthenticated submission on port 587. The default configuration
is that port 25 is unauthenticated (albeit with some restrictions
on relaying (only for local clients)) and port 587 is authenticated.

As such, I'm not sure why you seem to think that sendmail on port 587
is unauthenticated.

Sure, spammers will try anything that might work. However, for the moment,
587 is a reasonable pragma. Unauthenticated relays on 587 should definitely
be blocked no questions asked. It's not that clear cut for 25.

Owen

16

Thor Lancelot Simon 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
complicated).
   
This is utterly silly. Running another full-access copy of the MTA
on a different port than 25 achieves precisely nothing

I think we have ignored/trivialized the obvious.

Port 587 gives you the ability to class your connections as either MTA<->MTA, Legacy User->MTA, MSP User ->MTA.

This is quite valuable as you now have the theoretical ability treat them differently. Whether that means different access/authentication/encryption/firewall/relay policies or whatever.

If all one does is run a full copy on that port then *THEY* have gained almost nothing in practice, aside from further un-exploited capabilities. However we all gain from ever increasing, even if it is only incremental, support of well known RFC's.

Specific MTA discussions aside, port 587 is a good thing, and the more of it the merrier.

17

ONLY if that unauthenticated sender is also permitted to RELAY.

That is not a given. The decision to relay or not is separate from whether the user is authenticated with SMTP AUTH or some other method (IP address range, smtp-after-pop), just as it is on port 25.

I'm not arguing for leaving port 587 wide open, but there are uses to allowing potr 587 and 25 to have the same rules, and not permit relay on either. This is necessary where SMTP-after-POP is still in use, for example, but does NOT imply open relay. Yes, authorized users (authorized by AUTH, smtp-after-pop, or IP address ranges) can still send mail (including spam, subject to enforcement) but that does NOT constitute open relay.

18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thor Lancelot Simon wrote:

19

Umm.. because the Sendmail 8.13.3 tree has this:

(from cf/README):

20

Yet another reason for supporting port 587 on your servers for remote
authenticated mail submission from your users. If you don't support
port 587, and use SPF, it may break when AOL or other providers re-direct
port 25.

http://www.heise.de/english/newsticker/news/56437