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