On 2025-05-23 02:49, Peter Corlett via mailop wrote:
On Fri, May 23, 2025 at 01:11:52AM -0700, Chris via mailop wrote:On 2025-05-22 20:56, Marco Moock via mailop wrote:[...]587 does not use implicit TLS, it can use STARTTLS optional.Correct.Umm. That *may/can* be true. But as a rule it's chosen specifically for use with TLS. I just performed a check to see if we've overlooked anything using 587 and it's appears others have the same understanding. Cloudflare, for example: ---QUOTE Originally, the Simple Mail Transfer Protocol (SMTP) used port 25. Today, SMTP should instead use port 587 — this is the port for encrypted email transmissions using SMTP Secure (SMTPS). Port 465 is also used sometimes for SMTPS. However, this is an outdated implementation and port 587 should be used if possible. Finally, some email service providers also support SMTP on port 2525 as a backup in case these other ports are blocked by a network provider or a firewall. QUOTE---Cloudflare is not the relevant standards body, IETF is. Whoever wrote that is technically wrong, which is not entirely surprised as this is quite a confusing state of affairs. However, this also looks like user-level rather than implementor-level documentation and the important takeaway is that mail submissions should be encrypted, and that port 587 is the best choice. The use of port 587 is described in RFC 6409 and "Updated by:" RFC 8314. In particular from RFC 6409: Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA], with additional restrictions or allowances as specified here. ESMTP, i.e. regular port 25 traffic, does not use implicit TLS, but can optionally use STARTTLS. And so does traffic on port 587. Anything using implicit TLS on port 587 is standards-violating and broken. The "restrictions or allowances" concern themselves with authn/authz, fixing up submitted messages etc. The RFC doesn't have much to say about TLS apart from saying that submission servers "MAY" -- not even "SHOULD"! -- support the STARTTLS extension, and also that it is "especially useful for message submission". RFC 8314 is that it reassigns port 465 from regular SMTP with implicit TLS (which basically nobody used for that purpose except perhaps spammers and other miscreants) to submission with implicit TLS. There is a corresponding rename of the service (see /etc/services) from "smtps" to "submissions". The authors of RFC 8314 clearly want to eventually completely replace STARTTLS on 587 with implicit TLS on 465, but GLWT given the plethora of MUAs and general resistance to change, so 587 isn't going away any time soon. There are still plain HTTP sites on port 80, after all. But it also has this to say: [...] As a result, clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period. Which is pretty clear.I think 587 is always assumed to be encrypted. :)Assumption is the mother of all cock-ups.
You said it, brother! I stand (rightfully) corrected. :)IMHD It was 2 am. my time, and I was too tired to grok the appropriate RFC's. :{
I'll know better next time. ;) Thanks for taking the time to produce the appropriate info.
The initial stages of the protocol negotiation are not encrypted, and unless the server admin actually bothers to test it periodically, it's merely an unverified aspiration that their users' passwords and emails are properly end-to-end encrypted. _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
0xE512722F.asc
Description: application/pgp-keys
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
