Ports allocation for SMTP, POP and IMAP

Protocol	Port	Allow Encryption?	Allow Plain?	STATUS	NOTE
SMTP	25	YES – explicit encryption:  after connection is opened … using  (command) STARTTLS	YES	RG	relay server2server
SMTP	587	YES – explicit encryption:  after connection is opened … using  (command) STARTTLS	YES	RG	submission client2server rfc2487
SMTP	465	YES – implicit: as soon as connection is opened	NO	WK + CF	Read here more information
IMAP4	143	YES – explicit encryption:  after connection is opened … using  (command) STARTTLS	YES	RG	rfc2595
IMAPS	993	YES – implicit: as soon as connection is opened	NO	RG
POP3	110	YES – explicit encryption:  after connection is opened … using  (command) STARTTLS	YES	RG	rfc2595
POP3S	995	YES – implicit: as soon as connection is opened	NO	RG

Note Table RG: registered (Internet Assigned Numbers Authority has assigned this port and reported here)
WK: well-know (is not registered but is de facto used and well-know)
CF: conflict between RG e WK using this port (there different protocols that use the same port)
Implicit encryption:
  use of this port requires use of encryption when connection is established (so there isn’t any in clear traffic)
Explicit encryption:
  connection starts in clear and after, at some point, is upgraded to encrypted (with command STARTTLS)

Note about the meaning of : STARTTLS/143&110 :
  I mean  protocols (IMAP/POP) over 143 and 110 using STARTTLS
SSL/993&995:
  I mean  protocols (IMAP/POP)  IMAP/POP over port 993 and 995 (encryption as soon as connection is established)

 

Considerations :

SSL TLS (Vs.)

SSL is frequently used as synonym for SSLV2, SSLV3 and TLSV1.x (read here) : SSL and TLS are versions of the same protocol (read here and wiki).  The version of encryption protocols (TLS or SSL) is decided in HELLO handshake between client and server.
Example :

[Server] ssl-srv-supports:SSLV2,SSLV3,TLSV1.0,TLSV1.1,TLSV1.2->MAX(ssl-srv-supports) is TLSV1.2
(Client) ssl-cli-supports:SSLV2,SSLV3->MAX(ssl-cli-support) is SSLV3

(Client) — HELO MAX(ssl-cli-supports) —>[Server]
                                         >[Server] MIN(SSLV3 ,MAX(ssl-srv-supports))=SSLV3
(Client) <—---HELO OK for SSLV3 --------[Server]

So connection is established in SSLV3 despite its depreciation and the server supports TLSV1.2

Are SSLV2/SSLV3  and  993/995 deprecated?

Do I have to use STARTTLS since SSL is deprecated?
SSLV2/SSLV3 -> YES this versions are deprecated for security issues
SSL/993&995 -> NO are not deprecated (*1) you can use, if you want,  TLS on this ports.
(*1) Really ports 993 and 995 should be abandoned in advantage of STARTTLS/143&110 btw this is not happening.

So deprecation of SSL doesn’t mean that SSL/993&995&465  are deprecated too: from point of view of security 993/995  and 143/110  (after STARTTLS) are the same.
Ports 993 and 995 are not limited to use with version SSLV2/SSLV3 : if client and server agree they can use TLS version/

STARTTLS

STARTTLS is not related to the cryptographic protocols so it is not part of SSL/TLS specifications but is related to IMAP, POP, SMTP (and HTTP…) protocols:
https://tools.ietf.org/html/rfc2487
https://tools.ietf.org/html/rfc2595

STARTTLS is a command over an in clear () connection that asks to sever to upgrade the connection to encrypted () .

STARTTLS is not necessarily related to version TLS (cryptographic protocols)  but connection after STARTTLS could be upgraded to SSLVx (and not necessarily to TLSVx.y)

Implicit Vs. Explicit

 Explicit: the client issues STARTTLS command but, from users side can’t be verified if the connection continues in clear or encrypted.
Generally the 143&110 ports are associated (by the users) to in clear connection (so not secure )
Configuration could confuse the user: do 143&110 ports require or not  encryptions?

Implicit : the connection starts encrypted so there isn’t any in clear communication between client&server.
Generally the 993&995 ports are associated (by the users) to the encrypted connections (secure ).
Configuration could be simpler : 993&995 requires for sure encryption.

 

STARTTLS isn’t protocol agnostic

Filtering

some issues if you want to close in clear traffic. There are ways in order to prevent use 143&110 in clear on server side. If you want to block, on user/company side, in clear traffic on 143&110 then this it is quite tricky: ports STARTTLS/143&110 can be used for both in clear and encrypted.

Proxying

Connection proxying (Stunel , proxy, nginx …): proxy  of the connections can’t be protocol agnostic. STARTTLS has to be detected by the proxy in order to upgrade the connection to encrypted.

Termination of encryption

Termination of encryption on Balancer (with STARTTLS)… you might want to terminate the encrypted connection on the balancer… for example for load/performance reasons.

With use of implicit ports (e.g. 993,995 and 465) the Balancer is sure that connection is encrypted as soon as connection is established.
With use of explicit  ports (e.g 143, 110…) the Balancer can’t figure out if connection has to be encrypted or not (only on the ports that are used).

With explicit encryption connection can be promoted to encrypted after that the connection is opened.
Balancer can’t be, in this case,  protocol agnostic: it has to inspect the traffic and upgrade to encrypted connection when STARTTLS is issued by the client  (only when STARTTLS is related to a SMTP/IMAP/POP command and not email data)

Authenticate

Authentication (login/password) should take its place only after the upgrade of the channel to secure (so after STARTTLS in case of explicit port).

Deployment

You might want to split, for some legacy matters, traffic to FrontEnds (FE): deploy dedicated accelerated instances of SMTP/IMAP/POP FrontEnd isn’t so easy.

Example split of traffic in order to:
– reserve some new (SSL accelerate) instances of FronEnd dedicated to the encrypted traffic
– some others FronEnd (old legacy and slow FronEnd)  dedicated to in clear traffic

If there are requirements about the split of traffic based on use of encryptions: using of STARTTLS/143&110  can run in troubles .

Users adoption and growth curve

If you are switching to encryption for million of users  then you would like to grow bit by bit for encryption adoption.
If you are adding new ports (implicit ports) dedicated to encryption (SSL/993&995) then “old” users have to proactively configure their email client in order to use new ports:
probably only new users and few old users will adopt encryption.

If you are switching to STARTTLS on (existing) 143 and 110 then “old” users could unawares switch to adopt encryption.

Therefore the SSL adoption using STARTTLS/143&110 could be potentially higher than using SSL/993&995

Security STARTTLS/143&110

There are security concerns related to use STARTTLS.
The first part of connection is in clear and a Man-in-the-Middle attack could force to continue the connection in clear (rejecting STARTTLS). Is not possible discover if server support STARTTLS without ask… and you are not sure if the the answer (“NO please continue in clear”) is from the right server.
http://www.postfix.org/CVE-2011-0411.html

How much emails & who encrypts

Source of data : https://www.google.com/transparencyreport/saferemail/

Compatibility email clients