Re: [PATCH] send-email: clarify SMTP encryption settings

["Drew DeVault" <sir@cmpwn.com>]

On Fri Apr 9, 2021 at 8:52 PM EDT, Junio C Hamano wrote:
> Hmph.
>
> Isn't SMTPS (running SMTP over SSL encrypted connection) the one
> that was once deprecated until it got resurrected)?

Kind of, back in the 90's, but that's water under the bridge now. SMTP
over SSL/TLS is the de-facto standard.

> STARTTLS is not all that SMTP specific---POP and IMAP can also start
> in cleartext and upgrade with STARTTLS the same way, no?

Well, email-specific, at least. Sorry for the confusion.

> I couldn't find a justification for our log message to call
> STARTTLS-style explicit TLS "deprecated". When you send an updated
> version, please give a reference.

The main concern with STARTTLS is downgrade attacks. I'll note this in
the commit message for v2.

> I think it is a vast improvement to describe what existing 'ssl' and
> 'tls' does, like the above does. It is a documentation update that
> deserves its own commit (i.e. [PATCH 1/3]), and it should be done
> before adding the new ssl/tls and starttls synonyms.
>
> Making it an error to give unrecognised string (i.e. other than
> 'ssl' and 'tls'), or at least warning, would be a good follow-up
> change (i.e. [PATCH 2/3]), but that is optional.
>
> And then, it may make sense to introduce the synonyms, but please
> make it a separate patch that builds on top of the other two steps
> (i.e. [PATCH 3/3]).

Ack, can do.

> In the ideal world, it would have been nice if we could make 'tls'
> as the name of the choice that has been known as 'ssl' (i.e. the
> underlying transport protocol to run SMTP or any other higher layer
> protocol on top, there used to be SSL but these days TLS is used as
> an improved alternative---SSL 2.0/3.0 have been deprecated for some
> time), but because we used 'tls' to mean the STARTTLS-style "start
> SMTP as plain and then upgrade to encrypted channel", we can't reuse
> the 'tls' for that purpose.
>
> I do not have any qualm about the fully spelled out "starttls"
> synonym for the latter. In fact, if we can go back in time and redo
> the history with hindsight, that is the name we should have used
> from the beginning. But I find it unfortunate that we need to say
> 'ssl/tls', i.e. prefixing the name of the choice with the name of a
> deprecated thing, for the former. Another reason I am hesitant
> about 'ssl/tls' is because the description of it in documentation
> naturally invites errors. I.e. "You can set it to 'ssl/tls'..."
> sounds as if the manual is telling me to use one of 'ssl' or 'tls',
> which is not what it is sayng---it literally wants me to say
> 'ssl/tls' with a slash in it.

If I may propose a bold alternative: what I added as "ssl/tls", i.e.
"modern" SSL, should be "yes", no encryption should be "no", and if you
specifically need starttls: "starttls".