pop 110/995, imap 143/993 ?

[Robert Wolf]

On Mon, 21 Aug 2017, Sebastian Arcus wrote:

> 
> On 21/08/17 10:37, Gedalya wrote:
> > On 08/21/2017 07:28 AM, voytek at sbt.net.au wrote:
> > > is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
> > > 993 over 143? or?
> > There is no concrete answer. There are various opinions and feelings about
> > this.
> > The opinion againt 993/995 is that these are not standard ports, 
> 
> Out of curiosity, is there a source for this? It's the first time I hear that
> 993/995 are not standard ports - and searching on the Internet, I can't find
> any evidence to back it up? Also, pretty much all email software has been
> using them for the past 20 years or so. It seems like a curiously high rate of
> adoption for a non-standard :-)


Hello,

IMHO the "not standard ports" is meant as "old, useless ports now".

AFAIK at the begining there were only plain-text ports 80, 389, 110, 143, 25,
5222 (XMPP) etc without any encryption. Then SSL was implemented on ports 443,
636, 993, 995, 465, 5223 etc. Later, the STARTTLS feature has been introduced
and servers and clients has implemented STARTTLS sometime. Since STARTTLS is
used in most clients and servers nowdays, there is no need for SSL port. There
is even RFC 2817 for STARTTLS in HTTP. So IMHO all SSL ports are meant to be
old, useless now, some Jabber clients describe SSL encryption on port 5223 as
"legacy".


Pros of STARTTLS is, that you CAN start encryption, if you need it. E.g. for 
SMTP or LDAP you can use plain text connections without expensive encryption for 
normal mail transfer (MX-MX) or for searching (LDAP), and client can start 
encryption, if needed for username+password or cert authentication (SMTP submit 
or LDAP edit with auth).

Of cource for IMAP+POP you have to authenticate everytime, i.e. you need
encryption everytime.


Pros of SSL port is, you now everytime exactly, that your connection is 
encrypted, so your password is never sent over plain-text channel.

Some servers (services) can be configured to fail correct login, if the login
is made through plain-text channel. This is good, because MITM cannot
instantly see, if the password is correct or not, but the password goes
already plain-text and MITM can test it on secure connection later.


Regards,

Robert Wolf.