SMTP TLS SSL 25 465 587
#1 Notes about SSL/TLS :
(SSL)-SSL V1.0 (never released by Netscape)
|-(1995)-> SSL V2.0
|-(1996)-> SSL V3.0
|-(1999)-> SSL changes name to->TLS
|-(1999)-> TLS V1.0
|-(2006)-> TLS V1.1
|-(2008)-> TLS V1.2
V
(TLS)
Library OpenSSL supports SSL V2.0, SSL V3.0, TLS V1.0, TLS V1.1 and TLS V1.2
#1.2 SSL is deprecated
SSL 3.0 has been deprecated in June 2015 (RFC 7568) (*).
So TLS is to prefer.
#2 SMTP Ports
PORT | PURPOSE | Encrypted | Clear mode |
25 |
Relay (Server2Server)for smtp relaying (in order to transmit emails between two servers).
|
YES (starts with STARTTLS)
|
YES |
587 |
Submission (Client2Server) for client messages submission in clear or enrcypted (submit emails from client/user to server)
|
YES (starts with STARTTLS)
|
YES |
465 | Submission (Client2Server) commonly known as SSL PORT of SMTP but not endorsed by IANA nor IETF as standard port. |
YES (starts as soon as connection is established)
|
NO |
#2.1 Ports -> 25 Vs. 587 :
Generally are used different ports in order to separate users submission traffic (587) and relay traffic (25).
#2.2 Ports -> 465 Vs. 587 :
- The 465 is the dedicate port for SSL (SSMTP) :
communication starts immediately encrypted (when connection is established). - The 587 is clear/encrypted :
connection starts in clear and encryption can start later when the channel is promoted to secure ( with STARTTLS ). After STARTTLS the port remains 587 and os encrypted (on the same TCP connection without reconnection) .
STARTTLS is a way to promote an existing insecure connection ( I mean upgrade it ) to a secure connection.
Note that despite in name is present TLS, STARTTLS doesn’t mean you have to use TLS but you can use SSL.
#2.3 Historically
http://lists.w3.org/Archives/Public/ietf-tls/1997JanMar/0079.html)
... ssmtp 465/tcp ssmtp ...
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
... 465 TCP URL Rendezvous Directory for SSM (Cisco protocol) Official465 TCP Simple Mail Transfer Protocol over TLS/SSL (SMTPS)1997 - Unofficial... 587 TCP UDP Message Submission
So 465 is now reserved to SSM protocols.
#3 Conclusion
- a) Official submission port (for email client) is 587 and not 465
( RFC 6409 – https://tools.ietf.org/html/rfc6409) - b) Starting from 1998 the port 465 isn’t standard of SMTP :
465 is now dedicated to SSM protocol( http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt ) - c) SSLv3 is deprecated and the advice is to use TLS
( RFC 7568 – https://tools.ietf.org/html/rfc7568 ) - d) the propper way to use TLS with SMTP is using 587 (with STARTTLS)
( RFC 3207 – http://tools.ietf.org/html/rfc3207 http://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-9 )
From “academic” point of view counclusion shoud be : server must use only 587/TLS (and STARTTLS) in order to provide email client submission.
However on internet there are several ISPs that show 465 as submission port (for example gmail).
Btw there are some security concerns about use of STARTTLS : since the connection starts insecure (plaintext) and only If both “client and server” support TLS then the client sends a “STARTTLS” request to turn on encryption. An attacker can detect and inject requests/answers (that are in plaintext) in order to force client to use insecure (plaintext) connection (http://www.postfix.org/CVE-2011-0411.html)
From “pragmatic“ point of view could exist clients that don’t support 587/TLS (STARTTLS). Indeed for legacy reasons may be required 465/SSL. However about email clients seems that all recently versions of email clients support TLS: https://en.wikipedia.org/wiki/Comparison_of_email_clients#SSL_and_TLS_support
From: Paul Hoffman
Subject: Revoking the smtps TCP port
Newsgroups: gmane.ietf.apps-tls
Date: 1998-11-13 01:18:20 GMT (17 years, 7 weeks, 6 days, 8 hours and 38 minutes ago)
Greetings again. Some of you noticed that the revocation of the smtps port
was removed at the last minute from draft-hoffman-smtp-ssl (which, for
those of you who missed it, has been sent on to the RFC editor as a
Proposed Standard). I took it out during the last steps at the request of
Jeff Schiller, who was concerned that it might cause delay with the IESG.
After the draft was sent to the RFC Editor, I sent a request to IANA,
including the text that had been in the earlier version of the draft and a
note that this had been widely discussed. They removed the port from the
official list.
--Paul Hoffman, Director
--Internet Mail Consortium