On 24 Jul 2016, at 18:24, Peter wrote:
Outlook misnames STARTTLS as "TLS". TLS wrappermode is what outlook
calls "SSL".
Minor bit of pedantry:
Short form:
A MUA that supports any version of TLS or STARTTLS has no excuse for not
supporting both. A server offering port 465 "wrappermode" is
implementing a service not described in any formal spec except for
proprietary 1996 SSLv3 drafts, i.e. NEVER mentioned in any TLS
specification. So, if a MUA offers SSL and TLS as distinct encryption
choices, it should be clear how those map to the concrete technical
options: SSL=wrappermode, TLS=STARTTLS.
Longer form:
The only specification for SMTP wrapped in transport encryption of the
TLS/SSL heritage was in a series of 1996 Netscape SSLv3 drafts, the last
of which got published in abridged form 15 years after the fact as the
explicitly historical RFC6101, with all references to a reserved port
for "SMTPS" (wrappermode) removed. It is not unreasonable for "SSL" to
refer to wrappermode, since there's no spec for TLS wrapping SMTP in
that way and no description in any version SSL of any mechanism for a
STARTTLS-like upgrade from an initially unencrypted session. It's
trivial to support TLS in a "wrappermode" deployment and probably harder
to avoid than the principle could be worth, but what formal spec exists
for SMTP wrapped in encryption from the initial connect is only for
SSLv3 and NOT any version of TLS. Similarly, there's no formal reason
for a STARTTLS implementation to support any version of SSL, although
many unfortunately do. It pains me to say it, but Outlook is right in
this case.
Rant:
There are blatantly obvious "Best Practices" in this area now and have
been for at least a decade, but software including most MUAs and most
MTAs including Postfix haven't adopted them as default, well-documented
config & behavior yet. Port 25 for inbound and authenticated transit
(relay) SMTP with opportunistic encryption. Port 587 for submission
requiring encryption with authentication inside the encryption, nothing
less than TLSv1.0. Port 465 wrappermode only where absolutely necessary
on a temporary provisional basis for clients that can't do TLS (and
hence STARTTLS.) This model is not hard to deploy: it's documented for
and supported by most if not all major MTAs, it's just not generally the
model that documentation and default configs focus on. We need to adjust
our thinking in Postfix terms to the idea that smtpd and submission are
distinct services that incidentally share a similar set of options,
somewhat like smtp and lmtp. In 2016, a need to use "permit_mynetworks"
or deploy port 465 wrappermode or allow SSLv3 for STARTTLS clients
should be treated as technical debt that demands retirement. Sure, many
sites need such crutches now and will for many years, but we should
recognize that reliance on authentication by IP and obsolete and/or
weakly-specified security mechanisms are bad things that we should work
to eliminate, rather than norms we should be cargo-culting into eternity
because some antique docs describe them.
