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