WARNING: CIVIL DISAGREEMENT AHEAD!
TL;DR version: Read RFC8314 at https://tools.ietf.org/html/rfc8314
On 23 Jan 2020, at 5:18, Benny Kjær Nielsen wrote:
On 23 Jan 2020, at 10:35, Marc ARC wrote:
At first we thought we’ll use port 993 since this is secure. But
then we realised that port 143 can also be secure with StartTLS.
Or is 993 better since it secures before communicating and is it
future proof ?
Port 993 mainly exists for historical reasons.
I understand that point of view, and might have totally agreed a decade
ago, but I think it has been overtaken by events, experience, and
RFC8314.
Port 993 (and 995 for POP3: everything I say in this message about
143/993 for IMAP4 also applies to 110/995 for POP3 if you support it.)
were nearly the last cases of SSL/TLS 'wrapper' ports established in
IETF standards, and they generated concern about the proliferation of
such port reservations exhausting the supply of ports traditionally
reserved for binding by "root" processes and deemed more trustworthy. In
the same "SSL 3" draft specification which proposed those ports, port
465 for SMTP was proposed but by the time that became the TLS 1.0
specification, 465 was dropped as unjustifiable. HOWEVER, 465 as
TLS-wrapped mail submission (NOT transport) has more recently been
revived as a best practice: see below.
The reason that 993 remained is that unlike SMTP transport, which
largely occurs between servers with no relationship more enduring than a
single message handoff and without live human interaction, IMAP has a
clear fixed client/server model with a presumption that the client
software is being tended by a human customer of the server operator.
Both sides of IMAP maintain confidential persistent state about their
partner by necessity, so it is reasonable for a client to require an
explicit port and session encryption configuration for each of the small
number of servers it needs to communicate with.
Personally, I would keep both ports open and make sure that the use of
STARTTLS is required for port 143. If you close one of these ports
then it'll likely affect users at some point when configuring an email
client which either defaults to 143 or 993 (or it might even not
support both).
This is reasonable advice for server operators who have a diverse set of
legacy customers who use whatever client software they personally
prefer. For more controlled environments (e.g. workplace mail systems)
it is reasonable to abandon port 143 and STARTTLS and only support 993,
because there are marginal security risks with making initial
connections unencrypted and using STARTTLS. Whether to close port 143
when you've been supporting it for existing users is a question that can
only be answered by understanding your users and your support capacity.
FWIW, there are no IMAP clients that support STARTTLS over port 143 but
don't support TLS wrapper mode on port 993. However, If you have allowed
a broad range of encryption & authentication options in the past,
existing client configs may need radical change to work with a 993-only
server.
And with SMTP we are confronted with a choice 25 or 465 or 587 ? We
prefer 587 since it requires AUTH . . . but what about the security
Port 587 is the standard for email submission (email client sending an
email) and is equivalent to 143 for IMAP (it uses STARTTLS). Port 465
is a mess (Microsoft), but some email clients might still expect it to
work (Microsoft).
The best practices for initial mail submission have changed. Port 465
has been a mess but the way in which it remained a mess for 2 decades
made RFC8314 a reasonable solution for making submission more
Port 465 is kind of equivalent to port 993, but in practice I've seen
servers using port 465 with STARTTLS making it behave like port 587.
Yeah... That's bad and wrong to the point where nothing should
accommodate a server doing it. Clients detecting that behavior should
fail and alert with a message mocking the dubious competence and lineage
of the server admins involved. (Your mother was a hamster, and your
father smelt of elderberries!)
You'll also need port 25 because this is the standard port used when
SMTP servers talk to eachother.
Correct.
Port 25 is for SMTP *transport* not *submission*. Any mail server
handling outbound transport might need to connect to any other mail
server handling inbound transport anywhere on the Internet. SMTP has to
start in cleartext because it always has and because it is hard to make
sure that random SMTP servers on the Internet can always negotiate
encryption that works. Similarly, while it is wise to prefer strong
encryption protocols and ciphers for SMTP/STARTTLS, it is actually
counter-productive to disallow all weaker encryption modes because SMTP
servers will ultimately fall back to clear text transport if they can't
make any encryption work. In simple terms: any encryption that can't be
easily decrypted in real time by anyone who can capture it is safer than
cleartext.
A common historical error has been to offer SMTP AUTH on port 25 to
support submission. In the modern world this should never be needed and
supporting submission and transport on the same channel make securing
each function more error-prone.
In a perfect world, only ports 25, 143 and 587 would exist.
I dissent!
In a perfect world, we'd have 25 (SMTP with lenient STARTTLS and no
AUTH,) 465 (SMTP-like submission wrapped in TLS with mandatory AUTH,)
and 993 (IMAP4 wrapped in TLS with mandatory AUTH.)
In the real world, the only things preventing that are widespread legacy
configurations of capable clients and servers, a tiny population of
legacy clients that can't do any encryption and/or any authentication,
and a surprisingly large population of horrible firewalls (primarily
Cisco PIX & ASA) which sit in front of clients or servers and break
every extension to email since ~1990.
We have been googling but can’t seem to find the mail between the
ports
I'm unclear on the meaning of this sentence...
You'll probably get other opinions, but the important part is to
ensure that it's not possible to communicate on any port without
encryption enabled (with or without STARTTLS).
As stated, that is infeasible. See above my discussion of SMTP on port
25. Obsolete mail servers and stupid firewalls will always be with us.
Fully disabling cleartext as the last resort on port 25 will cause the
loss of email until everyone gets working mail systems deployed in this
century...
Demanding TLS (i.e. ports 465 and 993) is ideal. Requiring it via
STARTTLS (ports 143 and 587) if you can't force the use of wrapped ports
is essential.
Security-wise, it is more important that you look into which TLS
protocols you allow on the server, but I'm not qualified to make any
recommendations on that:
https://en.wikipedia.org/wiki/Transport_Layer_Security
That's ONLY important for submission and IMAP4. For SMTP, it is safe and
reasonable to disallow SSLv2 and SSLv3 but there are still sending
machines out there which can't do anything better than TLSv1.0, which is
still better than cleartext. Worse yet, many of those will attempt
STARTTLS on servers that support it, but if they can't negotiate TLSv1.0
they simply fail and never even try cleartext.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate
