send-email issue

> ```
> Net::SMTP>>> Net::SMTP(3.13)
> Net::SMTP>>>   Net::Cmd(3.13)
> Net::SMTP>>>     Exporter(5.76)
> Net::SMTP>>>   IO::Socket::IP(0.41)
> Net::SMTP>>>     IO::Socket(1.46)
> Net::SMTP>>>       IO::Handle(1.46)
> Net::SMTP: Net::Cmd::getline(): unexpected EOF on command channel:  at
> /usr/lib/git-core/git-send-email line 1556.
> Unable to initialize SMTP properly. Check config and use --smtp-debug.
> VALUES: server=smtp.migadu.com encryption=tls hello=localhost.localdomain
> port=465 at /usr/lib/git-core/git-send-email line 1583.
> ```

> 
> You should use:
> 
> port=465
> encryption=ssl
> 
> OR
> 
> port=587
> encryption=tls
> 
> I know that this is confusing terminology, but "tls" stands for "StartTLS",
> which works on port 587, and "ssl" starts for "smtps" on port 465.
> 

> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
> 
> > I know that this is confusing terminology, but "tls" stands for "StartTLS",
> > which works on port 587, and "ssl" starts for "smtps" on port 465.
> 
> This reminds me of an earlier discussion we had that somehow petered
> out before it resuted in usable improvement,
> 
>   https://lore.kernel.org/git/xmqqtuo9kgo0.fsf@gitster.g/
> 
> I do not think it is feasible to immediately rename the two choices
> to SSL/TLS vs StartTLS without transition period, but the first
> patch in the three-patch series there to update the documentation
> alone may have helped this case.
> 
> We may also want to error out when seeing an unknown option other
> than 'ssl' and 'tls', as the necessary first step to make it
> possible to later safely accept StartTLS as a synonym for 'tls' and
> 'ssl/tls' as a synonym for 'ssl'.

> > I do not think it is feasible to immediately rename the two choices
> > to SSL/TLS vs StartTLS without transition period, but the first
> > patch in the three-patch series there to update the documentation
> > alone may have helped this case.
> > 
> > We may also want to error out when seeing an unknown option other
> > than 'ssl' and 'tls', as the necessary first step to make it
> > possible to later safely accept StartTLS as a synonym for 'tls' and
> > 'ssl/tls' as a synonym for 'ssl'.
> 
> Is it easier to just add less ambiguous aliases, eventually phasing out old
> terminology?
> 
> tls -> starttls
> ssl -> smtps
> 
> This way we don't have to change anything, and "smtps" is a valid way to refer
> to smtp over ssl (e.g. see /etc/services for 465/tcp).

> On Mon, Aug 16, 2021 at 09:11:43AM -0400, Konstantin Ryabitsev wrote:
>
>> > I do not think it is feasible to immediately rename the two choices
>> > to SSL/TLS vs StartTLS without transition period, but the first
>> > patch in the three-patch series there to update the documentation
>> > alone may have helped this case.
>> > 
>> > We may also want to error out when seeing an unknown option other
>> > than 'ssl' and 'tls', as the necessary first step to make it
>> > possible to later safely accept StartTLS as a synonym for 'tls' and
>> > 'ssl/tls' as a synonym for 'ssl'.
>> 
>> Is it easier to just add less ambiguous aliases, eventually phasing out old
>> terminology?

>> tls -> starttls
>> ssl -> smtps
>> 
>> This way we don't have to change anything, and "smtps" is a valid way to refer
>> to smtp over ssl (e.g. see /etc/services for 465/tcp).
>
> FWIW, those options make quite a bit of sense to me (and I agree the
> transition to them would be easy).

> >> tls -> starttls
> >> ssl -> smtps
> >> 
> >> This way we don't have to change anything, and "smtps" is a valid way to refer
> >> to smtp over ssl (e.g. see /etc/services for 465/tcp).
> >
> > FWIW, those options make quite a bit of sense to me (and I agree the
> > transition to them would be easy).
> 
> Back when we had the original discussion in April [*], I think we
> found one small glitch that we need to solve before we can start
> introducing aliases---setting the variable to unknown value (imagine
> you set it to 'starttls' and then run a version of Git that does not
> know it yet) does not make Git barf but silently ignore.
> 
> And that needs to be changed to die, and versions of Git with such a
> change, without any alias added, should be allowed to spread to
> eradicate the "silently ignore" version, before we can safely start
> adding aliases.

> This is certainly unfortunate, but IMHO is not a hard requirement for
> adding new values. This is no different than a case where we add a new
> config option, but old versions of Git quietly ignore it.
>
> In other words, I would suggest to tighten this as the values are added,
> but not worry about having a "spreading" period.

> Jeff King <peff@peff.net> writes:
>
>> This is certainly unfortunate, but IMHO is not a hard requirement for
>> adding new values. This is no different than a case where we add a new
>> config option, but old versions of Git quietly ignore it.
>>
>> In other words, I would suggest to tighten this as the values are added,
>> but not worry about having a "spreading" period.
>
> I would have agreed with you even in April if this knob were not
> about security.  Thinking that the user is asking for an encrypted
> connection and silently getting an unencrypted connection is not
> such a good thing, and advertising "we now improved the distinction
> between smtps and starttls easier to express" to users would not
> work well in that context.

> I think per
> https://lore.kernel.org/git/87o8ejej8m.fsf@evledraar.gmail.com/ that
> this may not be much of an issue in practice, i.e. assuming that most
> modern servers only accept auth over the encrypted channel the user will
> get an error anyway.