On 13/02/18 16:30, Viktor Dukhovni wrote:
> There's not much gain. If both the client and the server are misconfigured
> on port 587, a client might send passwords and message content in the clear.
> If at least one insists on TLS, and the server does not offer SASL auth prior
> to TLS, there's no compelling reason for port 465. Hence the case for 465 is
> not especially strong, but it now has "official" IETF blessing.
There is one case that I can think of. Older clients (Thunderbird comes
to mind) offered an opportunistic STARTTLS setting, so that if the
server offered TLS it would connect with TLS but if not it would
continue to connect via plain text. Such a client in this setting could
be subject to a MITM attack even if the server is configured to only
allow STARTTLS connections. The MITM would simply connect to the server
via STARTTLS but not offer the client the option.
Note that newer versions of Thunderbird (I believe for several years
now) do not offer this opportunistic STARTTLS setting, so if you set it
to connect via STARTTLS it will simply not work at all if STARTTLS is
not offered, thereby mitigating this attack angle. Also setting an
older client to require encryption would mitigate it as well.
This, I believe would be the strongest reason to prefer SMTPS
connections, but it only applies to older clients that are not well