{"thread":{"id":"56279","subject":"send-email issue","startedAt":"2021-08-13T17:50:29Z","lastAt":"2021-08-24T21:45:13Z","messageCount":13,"participants":["Ben Goldberg","Konstantin Ryabitsev","Junio C Hamano","Jeff King","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"432693","messageId":"24a88faf-5339-8449-80c4-f6085bd1e098@benaaron.dev","threadId":"56279","inReplyTo":null,"subject":"send-email issue","fromName":"Ben Goldberg","fromEmail":"ben@benaaron.dev","sentAt":"2021-08-13T17:50:20Z","receivedAt":"2021-08-13T17:50:29Z","isPatch":false,"sender":{"key":"ben@benaaron.dev","avatar":null},"body":"Hello,\n\nI hope this is right place to ask this kind of question.\nWhen I try to use get send-email I get:\n```\nUnable to initialize SMTP properly. Check config and use --smtp-debug. \nVALUES: server=smtp.migadu.com encryption=tls \nhello=localhost.localdomain port=465 at /usr/lib/git-core/git-send-email \nline 1583.\n```\nI used to be able to use send-email on this machine so I'm not sure why \nit's not wokring now. I'm able to send email using that account using \nThunderbird on this machine, so I don't think it's a network issue. And \nI double checked my smtp config.\n\nThx,\nBen\n"},{"id":"432694","messageId":"b4b1dda4-6bf7-f4b1-88c5-9d579a7c56d3@benaaron.dev","threadId":"56279","inReplyTo":"24a88faf-5339-8449-80c4-f6085bd1e098@benaaron.dev","subject":"Re: send-email issue","fromName":"Ben Goldberg","fromEmail":"ben@benaaron.dev","sentAt":"2021-08-13T17:57:13Z","receivedAt":"2021-08-13T17:57:20Z","isPatch":false,"sender":{"key":"ben@benaaron.dev","avatar":null},"body":"A little additional info. When I run send-email with --smtp-debug=1 I \nget this.\n```\nNet::SMTP>>> Net::SMTP(3.13)\nNet::SMTP>>> Net::Cmd(3.13)\nNet::SMTP>>> Exporter(5.76)\nNet::SMTP>>> IO::Socket::IP(0.41)\nNet::SMTP>>> IO::Socket(1.46)\nNet::SMTP>>> IO::Handle(1.46)\nNet::SMTP: Net::Cmd::getline(): unexpected EOF on command channel: at \n/usr/lib/git-core/git-send-email line 1556.\nUnable to initialize SMTP properly. Check config and use --smtp-debug. \nVALUES: server=smtp.migadu.com encryption=tls \nhello=localhost.localdomain port=465 at /usr/lib/git-core/git-send-email \nline 1583.\n```\n\nHope that helps.\n"},{"id":"432695","messageId":"9207c356-6c5f-d5d8-4862-a6131b4db8dc@benaaron.dev","threadId":"56279","inReplyTo":"b4b1dda4-6bf7-f4b1-88c5-9d579a7c56d3@benaaron.dev","subject":"Re: send-email issue","fromName":"Ben Goldberg","fromEmail":"ben@benaaron.dev","sentAt":"2021-08-13T18:00:18Z","receivedAt":"2021-08-13T18:00:21Z","isPatch":false,"sender":{"key":"ben@benaaron.dev","avatar":null},"body":"Oh, and I'm running git version 2.32.0\n"},{"id":"432696","messageId":"20210813180056.ctzivmakj4bj5apa@nitro.local","threadId":"56279","inReplyTo":"b4b1dda4-6bf7-f4b1-88c5-9d579a7c56d3@benaaron.dev","subject":"Re: send-email issue","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-08-13T18:00:56Z","receivedAt":"2021-08-13T18:01:02Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Fri, Aug 13, 2021 at 01:57:13PM -0400, Ben Goldberg wrote:\n> ```\n> Net::SMTP>>> Net::SMTP(3.13)\n> Net::SMTP>>> Net::Cmd(3.13)\n> Net::SMTP>>> Exporter(5.76)\n> Net::SMTP>>> IO::Socket::IP(0.41)\n> Net::SMTP>>> IO::Socket(1.46)\n> Net::SMTP>>> IO::Handle(1.46)\n> Net::SMTP: Net::Cmd::getline(): unexpected EOF on command channel: at\n> /usr/lib/git-core/git-send-email line 1556.\n> Unable to initialize SMTP properly. Check config and use --smtp-debug.\n> VALUES: server=smtp.migadu.com encryption=tls hello=localhost.localdomain\n> port=465 at /usr/lib/git-core/git-send-email line 1583.\n> ```\n\nYou should use:\n\nport=465\nencryption=ssl\n\nOR\n\nport=587\nencryption=tls\n\nI know that this is confusing terminology, but \"tls\" stands for \"StartTLS\",\nwhich works on port 587, and \"ssl\" starts for \"smtps\" on port 465.\n\n-K\n"},{"id":"432697","messageId":"f7ee6a03-74f2-152e-5158-4103c744595a@benaaron.dev","threadId":"56279","inReplyTo":"20210813180056.ctzivmakj4bj5apa@nitro.local","subject":"Re: send-email issue","fromName":"Ben Goldberg","fromEmail":"ben@benaaron.dev","sentAt":"2021-08-13T18:03:13Z","receivedAt":"2021-08-13T18:03:17Z","isPatch":false,"sender":{"key":"ben@benaaron.dev","avatar":null},"body":"> \n> You should use:\n> \n> port=465\n> encryption=ssl\n> \n> OR\n> \n> port=587\n> encryption=tls\n> \n> I know that this is confusing terminology, but \"tls\" stands for \"StartTLS\",\n> which works on port 587, and \"ssl\" starts for \"smtps\" on port 465.\n> \n\nThat worked! Thanks so much for your help!\n\n"},{"id":"432756","messageId":"xmqq35rbtx84.fsf@gitster.g","threadId":"56279","inReplyTo":"20210813180056.ctzivmakj4bj5apa@nitro.local","subject":"Re: send-email issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-14T23:36:43Z","receivedAt":"2021-08-14T23:36:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Ryabitsev writes:\n\n> I know that this is confusing terminology, but \"tls\" stands for \"StartTLS\",\n> which works on port 587, and \"ssl\" starts for \"smtps\" on port 465.\n\nThis reminds me of an earlier discussion we had that somehow petered\nout before it resuted in usable improvement,\n\n https://lore.kernel.org/git/xmqqtuo9kgo0.fsf@gitster.g/\n\nI do not think it is feasible to immediately rename the two choices\nto SSL/TLS vs StartTLS without transition period, but the first\npatch in the three-patch series there to update the documentation\nalone may have helped this case.\n\nWe may also want to error out when seeing an unknown option other\nthan 'ssl' and 'tls', as the necessary first step to make it\npossible to later safely accept StartTLS as a synonym for 'tls' and\n'ssl/tls' as a synonym for 'ssl'.\n\n"},{"id":"432800","messageId":"20210816131143.6ifcbpxp6ilo2nv5@nitro.local","threadId":"56279","inReplyTo":"xmqq35rbtx84.fsf@gitster.g","subject":"Re: send-email issue","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-08-16T13:11:43Z","receivedAt":"2021-08-16T13:30:28Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Sat, Aug 14, 2021 at 04:36:43PM -0700, Junio C Hamano wrote:\n> Konstantin Ryabitsev writes:\n> \n> > I know that this is confusing terminology, but \"tls\" stands for \"StartTLS\",\n> > which works on port 587, and \"ssl\" starts for \"smtps\" on port 465.\n> \n> This reminds me of an earlier discussion we had that somehow petered\n> out before it resuted in usable improvement,\n> \n> https://lore.kernel.org/git/xmqqtuo9kgo0.fsf@gitster.g/\n> \n> I do not think it is feasible to immediately rename the two choices\n> to SSL/TLS vs StartTLS without transition period, but the first\n> patch in the three-patch series there to update the documentation\n> alone may have helped this case.\n> \n> We may also want to error out when seeing an unknown option other\n> than 'ssl' and 'tls', as the necessary first step to make it\n> possible to later safely accept StartTLS as a synonym for 'tls' and\n> 'ssl/tls' as a synonym for 'ssl'.\n\nIs it easier to just add less ambiguous aliases, eventually phasing out old\nterminology?\n\ntls -> starttls\nssl -> smtps\n\nThis way we don't have to change anything, and \"smtps\" is a valid way to refer\nto smtp over ssl (e.g. see /etc/services for 465/tcp).\n\n-K\n"},{"id":"432809","messageId":"YRqQJTyBW6j6b2pW@coredump.intra.peff.net","threadId":"56279","inReplyTo":"20210816131143.6ifcbpxp6ilo2nv5@nitro.local","subject":"Re: send-email issue","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-16T16:19:49Z","receivedAt":"2021-08-16T16:19:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 16, 2021 at 09:11:43AM -0400, Konstantin Ryabitsev wrote:\n\n> > I do not think it is feasible to immediately rename the two choices\n> > to SSL/TLS vs StartTLS without transition period, but the first\n> > patch in the three-patch series there to update the documentation\n> > alone may have helped this case.\n> > \n> > We may also want to error out when seeing an unknown option other\n> > than 'ssl' and 'tls', as the necessary first step to make it\n> > possible to later safely accept StartTLS as a synonym for 'tls' and\n> > 'ssl/tls' as a synonym for 'ssl'.\n> \n> Is it easier to just add less ambiguous aliases, eventually phasing out old\n> terminology?\n> \n> tls -> starttls\n> ssl -> smtps\n> \n> This way we don't have to change anything, and \"smtps\" is a valid way to refer\n> to smtp over ssl (e.g. see /etc/services for 465/tcp).\n\nFWIW, those options make quite a bit of sense to me (and I agree the\ntransition to them would be easy).\n\n-Peff\n"},{"id":"432813","messageId":"xmqq4kbps58l.fsf@gitster.g","threadId":"56279","inReplyTo":"YRqQJTyBW6j6b2pW@coredump.intra.peff.net","subject":"Re: send-email issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-16T16:51:06Z","receivedAt":"2021-08-16T16:51:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Aug 16, 2021 at 09:11:43AM -0400, Konstantin Ryabitsev wrote:\n>\n>> > I do not think it is feasible to immediately rename the two choices\n>> > to SSL/TLS vs StartTLS without transition period, but the first\n>> > patch in the three-patch series there to update the documentation\n>> > alone may have helped this case.\n>> > \n>> > We may also want to error out when seeing an unknown option other\n>> > than 'ssl' and 'tls', as the necessary first step to make it\n>> > possible to later safely accept StartTLS as a synonym for 'tls' and\n>> > 'ssl/tls' as a synonym for 'ssl'.\n>> \n>> Is it easier to just add less ambiguous aliases, eventually phasing out old\n>> terminology?\n\nThere is no issue around ambiguity. The problem is that the code\ndoes not complain a bogus value in $smtp_encryption---when it is\n'ssl', ssmtp gets used, when it is 'tls', StartTLS gets used,\notherwise we do not see any errors.\n\n>> tls -> starttls\n>> ssl -> smtps\n>> \n>> This way we don't have to change anything, and \"smtps\" is a valid way to refer\n>> to smtp over ssl (e.g. see /etc/services for 465/tcp).\n>\n> FWIW, those options make quite a bit of sense to me (and I agree the\n> transition to them would be easy).\n\nBack when we had the original discussion in April [*], I think we\nfound one small glitch that we need to solve before we can start\nintroducing aliases---setting the variable to unknown value (imagine\nyou set it to 'starttls' and then run a version of Git that does not\nknow it yet) does not make Git barf but silently ignore. \n\nAnd that needs to be changed to die, and versions of Git with such a\nchange, without any alias added, should be allowed to spread to\neradicate the \"silently ignore\" version, before we can safely start\nadding aliases.\n\nOther than that, the transition is not harder than any other\ntransition we've done in the past.\n\n\n[Reference]\n\n* https://lore.kernel.org/git/xmqqtuo9kgo0.fsf@gitster.g/\n"},{"id":"432815","messageId":"YRqY4Tw4YxbepuFg@coredump.intra.peff.net","threadId":"56279","inReplyTo":"xmqq4kbps58l.fsf@gitster.g","subject":"Re: send-email issue","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-16T16:57:05Z","receivedAt":"2021-08-16T16:57:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 16, 2021 at 09:51:06AM -0700, Junio C Hamano wrote:\n\n> >> tls -> starttls\n> >> ssl -> smtps\n> >> \n> >> This way we don't have to change anything, and \"smtps\" is a valid way to refer\n> >> to smtp over ssl (e.g. see /etc/services for 465/tcp).\n> >\n> > FWIW, those options make quite a bit of sense to me (and I agree the\n> > transition to them would be easy).\n> \n> Back when we had the original discussion in April [*], I think we\n> found one small glitch that we need to solve before we can start\n> introducing aliases---setting the variable to unknown value (imagine\n> you set it to 'starttls' and then run a version of Git that does not\n> know it yet) does not make Git barf but silently ignore.\n> \n> And that needs to be changed to die, and versions of Git with such a\n> change, without any alias added, should be allowed to spread to\n> eradicate the \"silently ignore\" version, before we can safely start\n> adding aliases.\n\nThis is certainly unfortunate, but IMHO is not a hard requirement for\nadding new values. This is no different than a case where we add a new\nconfig option, but old versions of Git quietly ignore it.\n\nIn other words, I would suggest to tighten this as the values are added,\nbut not worry about having a \"spreading\" period.\n\n-Peff\n"},{"id":"432830","messageId":"xmqqzgthql1h.fsf@gitster.g","threadId":"56279","inReplyTo":"YRqY4Tw4YxbepuFg@coredump.intra.peff.net","subject":"Re: send-email issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-16T18:52:42Z","receivedAt":"2021-08-16T18:52:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> This is certainly unfortunate, but IMHO is not a hard requirement for\n> adding new values. This is no different than a case where we add a new\n> config option, but old versions of Git quietly ignore it.\n>\n> In other words, I would suggest to tighten this as the values are added,\n> but not worry about having a \"spreading\" period.\n\nI would have agreed with you even in April if this knob were not\nabout security. Thinking that the user is asking for an encrypted\nconnection and silently getting an unencrypted connection is not\nsuch a good thing, and advertising \"we now improved the distinction\nbetween smtps and starttls easier to express\" to users would not\nwork well in that context.\n\n"},{"id":"433448","messageId":"87eeakfc6b.fsf@evledraar.gmail.com","threadId":"56279","inReplyTo":"xmqqzgthql1h.fsf@gitster.g","subject":"Re: send-email issue","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-08-23T14:49:08Z","receivedAt":"2021-08-23T14:50:09Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Aug 16 2021, Junio C Hamano wrote:\n\n> Jeff King writes:\n>\n>> This is certainly unfortunate, but IMHO is not a hard requirement for\n>> adding new values. This is no different than a case where we add a new\n>> config option, but old versions of Git quietly ignore it.\n>>\n>> In other words, I would suggest to tighten this as the values are added,\n>> but not worry about having a \"spreading\" period.\n>\n> I would have agreed with you even in April if this knob were not\n> about security. Thinking that the user is asking for an encrypted\n> connection and silently getting an unencrypted connection is not\n> such a good thing, and advertising \"we now improved the distinction\n> between smtps and starttls easier to express\" to users would not\n> work well in that context.\n\nI think per\nhttps://lore.kernel.org/git/87o8ejej8m.fsf@evledraar.gmail.com/ that\nthis may not be much of an issue in practice, i.e. assuming that most\nmodern servers only accept auth over the encrypted channel the user will\nget an error anyway.\n\nBut how true that is in the wild beyond just the GMail example, I don't\nknow...\n"},{"id":"433629","messageId":"xmqq8s0qms9p.fsf@gitster.g","threadId":"56279","inReplyTo":"87eeakfc6b.fsf@evledraar.gmail.com","subject":"Re: send-email issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-24T21:45:06Z","receivedAt":"2021-08-24T21:45:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> I think per\n> https://lore.kernel.org/git/87o8ejej8m.fsf@evledraar.gmail.com/ that\n> this may not be much of an issue in practice, i.e. assuming that most\n> modern servers only accept auth over the encrypted channel the user will\n> get an error anyway.\n\nLet's see how it goes. It may be wishful thinking but it would lead\nto the easiest/simplest solution.\n\n\n"}]}