SMTP port 465
Jun. 20th, 2020 07:26 amI am frustrated. Either I'm confused, or people stop reading new updated RFCs as soon as they think they understand something.
I'm trying to set up Postfix on a server to handle outgoing mail using SMTP. For now, at least, I am trying to send mail from one user, for one purpose, using one MUA, via code that I'm writing myself. I don't need lots of compatibility with all the various whatevers out there. My priorities are 1) maximum security and 2) minimum sysadmin dicking around required by me. Simplicity furthers both these goals.
The how-to says to punch holes in the firewall for 3 different ports: 25, 587, and 465. Why so many ports? For outgoing mail, it appears that the options are 587 and 465. Why both? If I can get one working for my one little purpose and leave the other one closed, that's simpler, and therefore better. So which port to enable, 587 or 465?
As I understand it, here's what these two ports do:
* port 587 has the client connect via cleartext. The user-authentication conversation happens in cleartext. The server may indicate that STARTTLS is an option. At some point the client may issue the STARTTLS command, and then the TLS handshake happens, and then everything is encrypted from then on out. There's a couple of criticisms of this: one, that the user-authentication conversation happens in cleartext, and thus can be spied on— ok, sure the credentials are somehow obfuscated, but still, you're leaking more info than is totally necessary— and secondly, a man-in-the-middle attack could suppress the STARTTLS command.
* on port 465 the TLS handshake happens immediately upon connection and thus everything is encrypted.
It sounds to me like port 465 would be better, ideally, but one has to go along with whatever is standard, and everyone thinks that port 587 is standard?— However, I've read RFC 8314. RFC seems to be saying, the port 465 approach is better, y'all are encouraged to do things that way going forward; but systems should have port 587 available for the next several years so that clients have some way to do encrypted SMTP just in case they don't yet do the port 465 thing.
In response to a Stack Overflow question about choosing between 465 and 587, this guy's interpretation of what RFC 8314 seems to agree with mine. He describes the recommendation to use port 587 as "outdated". He refers to port 465 as one of the "recommended secure ports". He says that "[a]lthough RFC 8314 certainly allows the continued use of explicit TLS with port 587 and the STARTTLS command" (emphasis mine; note allows not requires or recommends) he then points out a problem with the port 587 and STARTTLS approach.
However, this answer, which seems clear and sensible and in agreement with the RFC, is generally ignored (only one up-vote) and criticized. The one comment on this answer basically says "you're wrong" and claims that the use of port 465 for SMTPS "is not a practice that follows the RFCs". No, in fact, RFC 8314, section 3.3, if you read it, says "It is desirable to migrate core protocols used by MUA software to Implicit TLS over time" and does say "...servers SHOULD implement... Implicit TLS on port 465". But all over the Internet, lots and lots of "experts" say "port 587 is the right port for STMP, including secure SMTP, and port 465 is just this crazy non-standard thing that ISPs do for backward compatibility".
This seems to be because in the past, port 465 was assigned for some other reason, and then deprecated. Since knowing that such-and-such has been deprecated is a way to show off that one is an expert, the message "465 has been deprecated!" gets amplified over and over, drowning out the "let's go in this direction now!" message of RFC 8314.
So why wasn't a different port chosen for SMTPS, once port 465 had acquired that taint of being deprecated? There are a lot of numbers.
I'm trying to set up Postfix on a server to handle outgoing mail using SMTP. For now, at least, I am trying to send mail from one user, for one purpose, using one MUA, via code that I'm writing myself. I don't need lots of compatibility with all the various whatevers out there. My priorities are 1) maximum security and 2) minimum sysadmin dicking around required by me. Simplicity furthers both these goals.
The how-to says to punch holes in the firewall for 3 different ports: 25, 587, and 465. Why so many ports? For outgoing mail, it appears that the options are 587 and 465. Why both? If I can get one working for my one little purpose and leave the other one closed, that's simpler, and therefore better. So which port to enable, 587 or 465?
As I understand it, here's what these two ports do:
* port 587 has the client connect via cleartext. The user-authentication conversation happens in cleartext. The server may indicate that STARTTLS is an option. At some point the client may issue the STARTTLS command, and then the TLS handshake happens, and then everything is encrypted from then on out. There's a couple of criticisms of this: one, that the user-authentication conversation happens in cleartext, and thus can be spied on— ok, sure the credentials are somehow obfuscated, but still, you're leaking more info than is totally necessary— and secondly, a man-in-the-middle attack could suppress the STARTTLS command.
* on port 465 the TLS handshake happens immediately upon connection and thus everything is encrypted.
It sounds to me like port 465 would be better, ideally, but one has to go along with whatever is standard, and everyone thinks that port 587 is standard?— However, I've read RFC 8314. RFC seems to be saying, the port 465 approach is better, y'all are encouraged to do things that way going forward; but systems should have port 587 available for the next several years so that clients have some way to do encrypted SMTP just in case they don't yet do the port 465 thing.
In response to a Stack Overflow question about choosing between 465 and 587, this guy's interpretation of what RFC 8314 seems to agree with mine. He describes the recommendation to use port 587 as "outdated". He refers to port 465 as one of the "recommended secure ports". He says that "[a]lthough RFC 8314 certainly allows the continued use of explicit TLS with port 587 and the STARTTLS command" (emphasis mine; note allows not requires or recommends) he then points out a problem with the port 587 and STARTTLS approach.
However, this answer, which seems clear and sensible and in agreement with the RFC, is generally ignored (only one up-vote) and criticized. The one comment on this answer basically says "you're wrong" and claims that the use of port 465 for SMTPS "is not a practice that follows the RFCs". No, in fact, RFC 8314, section 3.3, if you read it, says "It is desirable to migrate core protocols used by MUA software to Implicit TLS over time" and does say "...servers SHOULD implement... Implicit TLS on port 465". But all over the Internet, lots and lots of "experts" say "port 587 is the right port for STMP, including secure SMTP, and port 465 is just this crazy non-standard thing that ISPs do for backward compatibility".
This seems to be because in the past, port 465 was assigned for some other reason, and then deprecated. Since knowing that such-and-such has been deprecated is a way to show off that one is an expert, the message "465 has been deprecated!" gets amplified over and over, drowning out the "let's go in this direction now!" message of RFC 8314.
So why wasn't a different port chosen for SMTPS, once port 465 had acquired that taint of being deprecated? There are a lot of numbers.