Why should I convince developers to use port 587 for all SMTP communication?

Question

There is a growing trend to use port 587 for all client to MTA communications. It's in a standards track RFC: http://www.ietf.org/rfc/rfc2476.txt

My question is "Why?". Why have 2 instances of a SMTP server running on the same server, if they both do the same thing? What security feature does it provide, besides giving me 2 things to troubleshoot as an administrator.

This just seems like unnecessary complication that isn't needed unless the ISP blocks port 25. Even then, if the ISP is blocking port 25 to prevent spam, it just means it will just take a little more time until port 587 is blocked too, and we will have to use a different port altogether.

Just seems like we are creating more work for ourselves rather then solving the problem and authenticating SMTP to begin with

Corinnacorinne

Answer 1

Please see.

http://www.uceprotect.net/downloads/MAAWGPort25English.pdf

I think what you are missing is the port 587 is authenticated only. You shouldn't accept unauthenticated email on port 587, regardless if the recipient is local or not. We (as ISPs), block outbound port 25 to prevent direct-to-mx spam. For example from botted computers. In blocking our residential/dynamic user base from sending outbound on port 25 (we still allow un-authenticated relay from our IP space on port 25), yielded an 85+% percent drop in abuse reports.

ISPS are not going to start blocking 587 (Well they shouldn't since it isn't for MTA to MTA use, only MUA to MTA, since it is the submission port). And it allows for much easier management. Also on the MTA side, forcing all of your local users to authenticate makes it way easier for spam mitigation. When their box gets owned, and poaches their smtp creditionals. All you need to do is disable their account/password. When using relay by ip, you need to block them from connecting to the mail server (we do this by dnyamically applying an ACL to their DSL/Cable connection).

If you are writing either and MUA or an MTA, you need to support both, and in the case of MUA or something the sends email, it should default to 587 attempting TLS, and smtp auth, and only fail back to 465, 25 if that fails.

Contrariwise

What are the expectations around port 465? SMTP Auth as well? – Corinnacorinne

465 is SMTP under SSL. Whereas 25 and 587 start out unencrypted, and the can use starttls (if supported to enable an ssl encrypted connection). Port 465 is SSL from the start. Authentication is optional, server dependent. – Contrariwise

Thanks, it 'clicked' with your explination. It didn't occur to me that all inbound SMTP servers should have an MX, while all port 587 servers are not so linked. This divides the Separation Of Concerns much better with port 25. – Corinnacorinne

we have are inbound MXS and and relay servers on separate boxes, as it allows us to more heavily armor the MXs against spammers. Glad it helped. – Contrariwise

Answer 2

I had a quick reading through the RFC and their thinking is to divide the SMTP world into two areas: transporting mails (that's what SMTP was developed for) and submitting mails.

The authors argue that SMTP was not meant to be used by a mail client (MUA, Message User Agent) but only by mail servers, routing a mail to its destination. They think that if you divide the SMTP world in this way then you could write a SMTP server meant to be accessed only by MUAs that is then able to do things and make assumptions a "normal", forwarding SMTP server should/may not make. A "normal" SMTP server has always been called an MTA, Message Transfer Agent. The authors propose to name the new type of SMTP server MSA, Message Submission Agent.

It seems they think this would make implementing the two server types easier and maybe even more secure. The RFC explains what needs to be different in an MSA when compared to a MTA. For example, the RFC mandates the use of authorization while the original SMTP protocol didn't have that (SMTP AUTH was added later, it seems by the very RFC 2476; however SMTP AUTH itself is the later specified in RFC 2554 which has been replaced by RFC 4954).

An MTA that needs to relay messages from various sources to various destinations cannot use authentication for every message (how should another server authenticate to your server ?). But an MSA, which is the starting point of your message, can and must require authentication from its peer, the mail client. And while an MTA must relay the message unaltered save for adding a Received header, and MSA may "sanitize" an e-mail e.g. by filling in missing headers and things like that.

Ado

rfc5321 says, ""Mail Transfer Agents" (MTAs)". I think this conflicts with your line1/p2 above. – Bigmouth

@Ellipticalview: You mean "that SMTP was not meant to be used by a mail client (MUA, Message User Agent) but only by mail servers"? MUA=client, MTA=server. SMTP was meant to be used to move mail from one server to another, the means by which it was submitted from the user to the server was supposed to be different. But clients started to use it as well and today we've got ports 25 and 465 meant for connections from MTAs and port 587 (called submission) for MUAs which are often handled differently. – Ado

I think you overall point is a fair one. But I also think it's now very confusing that although 'M' originally referred only to 'Mail' for MTA, MUA, and MDA, now it sometimes refers to 'Message', but only for MUA. So I think we need to start over with a new acronym, like perhaps ITA, for input Transport Agent, or MITA, for Message Input Transport Agent, or possibly MSTA for Message Submission Transport Agent, or something other than MTA. – Bigmouth