{"thread":{"id":"55467","subject":"[PATCH] send-email: clarify SMTP encryption settings","startedAt":"2021-04-09T21:18:23Z","lastAt":"2021-04-11T05:51:08Z","messageCount":11,"participants":["Drew DeVault","Eric Sunshine","Georgios Kontaxis","Junio C Hamano","brian m. carlson","Bagas Sanjaya"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"421477","messageId":"20210409211812.3869-1-sir@cmpwn.com","threadId":"55467","inReplyTo":null,"subject":"[PATCH] send-email: clarify SMTP encryption settings","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2021-04-09T21:18:12Z","receivedAt":"2021-04-09T21:18:23Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"The present options are misleading; \"ssl\" enables generic, \"modern\" SSL\nsupport, which could use either SSL or TLS; and \"tls\" enables the\nSMTP-specific (and deprecated) STARTTLS protocol.\n\nThis changes the canonical config options to \"ssl/tls\" and \"starttls\",\nupdates the docs to explain the options in more detail, and updates\ngit-send-email to accept either form.\n---\n Documentation/git-send-email.txt | 11 ++++++++---\n git-send-email.perl              |  4 ++--\n 2 files changed, 10 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 93708aefea..3597935e41 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -168,9 +168,14 @@ Sending\n \tunspecified, choosing the envelope sender is left to your MTA.\n \n --smtp-encryption=<encryption>::\n-\tSpecify the encryption to use, either 'ssl' or 'tls'.  Any other\n-\tvalue reverts to plain SMTP.  Default is the value of\n-\t`sendemail.smtpEncryption`.\n+\tSpecify the encryption to use, either 'ssl/tls' or 'starttls', whichever\n+\tis recommended by your email service provider.  SSL/TLS is typically\n+\tused on port 465 and is preferred if available.  STARTTLS is typically\n+\tused on port 25 or 587. Any other value reverts to plain SMTP.  The\n+\tdefault is the value of `sendemail.smtpEncryption`.\n++\n+For legacy reasons, 'ssl' is accepted for 'ssl/tls' and 'tls' is accepted for\n+'starttls'.\n \n --smtp-domain=<FQDN>::\n \tSpecifies the Fully Qualified Domain Name (FQDN) used in the\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex f5bbf1647e..34fdf587bd 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1503,7 +1503,7 @@ sub send_message {\n \t\tmy $use_net_smtp_ssl = version->parse($Net::SMTP::VERSION) < version->parse(\"2.34\");\n \t\t$smtp_domain ||= maildomain();\n \n-\t\tif ($smtp_encryption eq 'ssl') {\n+\t\tif ($smtp_encryption eq 'ssl' || $smtp_encryption eq 'ssl/tls') {\n \t\t\t$smtp_server_port ||= 465; # ssmtp\n \t\t\trequire IO::Socket::SSL;\n \n@@ -1538,7 +1538,7 @@ sub send_message {\n \t\t\t\t\t\t Hello => $smtp_domain,\n \t\t\t\t\t\t Debug => $debug_net_smtp,\n \t\t\t\t\t\t Port => $smtp_server_port);\n-\t\t\tif ($smtp_encryption eq 'tls' && $smtp) {\n+\t\t\tif (($smtp_encryption eq 'tls' || $smtp_encryption eq 'starttls') && $smtp) {\n \t\t\t\tif ($use_net_smtp_ssl) {\n \t\t\t\t\t$smtp->command('STARTTLS');\n \t\t\t\t\t$smtp->response();\n-- \n2.31.1\n\n"},{"id":"421481","messageId":"CAPig+cTnd23pk9GyH2p-6AjW0cvPD6nqK62moTfRA3FXgROkRw@mail.gmail.com","threadId":"55467","inReplyTo":"20210409211812.3869-1-sir@cmpwn.com","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-04-09T22:04:55Z","receivedAt":"2021-04-09T22:05:09Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Apr 9, 2021 at 5:18 PM Drew DeVault <sir@cmpwn.com> wrote:\n> The present options are misleading; \"ssl\" enables generic, \"modern\" SSL\n> support, which could use either SSL or TLS; and \"tls\" enables the\n> SMTP-specific (and deprecated) STARTTLS protocol.\n>\n> This changes the canonical config options to \"ssl/tls\" and \"starttls\",\n> updates the docs to explain the options in more detail, and updates\n> git-send-email to accept either form.\n> ---\n\nMissing sign-off.\n"},{"id":"421495","messageId":"07869D2B-1962-4602-915E-78AE931B34C2@99rst.org","threadId":"55467","inReplyTo":"20210409211812.3869-1-sir@cmpwn.com","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Georgios Kontaxis","fromEmail":"geko1702+firehose@99rst.org","sentAt":"2021-04-09T23:14:54Z","receivedAt":"2021-04-09T23:15:00Z","isPatch":true,"sender":{"key":"geko1702+firehose@99rst.org","avatar":null},"body":"\n\n> On Apr 9, 2021, at 14:18, Drew DeVault <sir@cmpwn.com> wrote:\n> \n> The present options are misleading; \"ssl\" enables generic, \"modern\" SSL\n> support, which could use either SSL or TLS; and \"tls\" enables the\n> SMTP-specific (and deprecated) STARTTLS protocol.\n> \n> This changes the canonical config options to \"ssl/tls\" and \"starttls\",\n> updates the docs to explain the options in more detail, and updates\n> git-send-email to accept either form.\n> ---\n> Documentation/git-send-email.txt | 11 ++++++++---\n> git-send-email.perl              |  4 ++--\n> 2 files changed, 10 insertions(+), 5 deletions(-)\n> \n> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\n> index 93708aefea..3597935e41 100644\n> --- a/Documentation/git-send-email.txt\n> +++ b/Documentation/git-send-email.txt\n> @@ -168,9 +168,14 @@ Sending\n>    unspecified, choosing the envelope sender is left to your MTA.\n> \n> --smtp-encryption=<encryption>::\n> -    Specify the encryption to use, either 'ssl' or 'tls'.  Any other\n> -    value reverts to plain SMTP.  Default is the value of\n> -    `sendemail.smtpEncryption`.\n> +    Specify the encryption to use, either 'ssl/tls' or 'starttls', whichever\n> +    is recommended by your email service provider.  SSL/TLS is typically\n> +    used on port 465 and is preferred if available.  STARTTLS is typically\n> +    used on port 25 or 587. Any other value reverts to plain SMTP.  The\nWeird that we fail open (no encryption) on typos.\nAny chance we can fix that in this patch?\n\n> +    default is the value of `sendemail.smtpEncryption`.\n> ++\n> +For legacy reasons, 'ssl' is accepted for 'ssl/tls' and 'tls' is accepted for\n> +'starttls'.\n> \n> --smtp-domain=<FQDN>::\n>    Specifies the Fully Qualified Domain Name (FQDN) used in the\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index f5bbf1647e..34fdf587bd 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -1503,7 +1503,7 @@ sub send_message {\n>        my $use_net_smtp_ssl = version->parse($Net::SMTP::VERSION) < version->parse(\"2.34\");\n>        $smtp_domain ||= maildomain();\n> \n> -        if ($smtp_encryption eq 'ssl') {\n> +        if ($smtp_encryption eq 'ssl' || $smtp_encryption eq 'ssl/tls') {\n>            $smtp_server_port ||= 465; # ssmtp\n>            require IO::Socket::SSL;\n> \n> @@ -1538,7 +1538,7 @@ sub send_message {\n>                         Hello => $smtp_domain,\n>                         Debug => $debug_net_smtp,\n>                         Port => $smtp_server_port);\n> -            if ($smtp_encryption eq 'tls' && $smtp) {\n> +            if (($smtp_encryption eq 'tls' || $smtp_encryption eq 'starttls') && $smtp) {\n>                if ($use_net_smtp_ssl) {\n>                    $smtp->command('STARTTLS');\n>                    $smtp->response();\n> -- \n> 2.31.1\n> \n\n"},{"id":"421496","messageId":"CAJL8038F7T0.8RC0YRP0G9ZQ@taiga","threadId":"55467","inReplyTo":"07869D2B-1962-4602-915E-78AE931B34C2@99rst.org","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2021-04-09T23:39:00Z","receivedAt":"2021-04-09T23:39:07Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Fri Apr 9, 2021 at 7:14 PM EDT, Georgios Kontaxis wrote:\n> Weird that we fail open (no encryption) on typos.\n> Any chance we can fix that in this patch?\n\nThat would technically be a breaking change.\n"},{"id":"421497","messageId":"xmqqlf9rklkb.fsf@gitster.g","threadId":"55467","inReplyTo":"20210409211812.3869-1-sir@cmpwn.com","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-10T00:52:36Z","receivedAt":"2021-04-10T00:52:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Drew DeVault <sir@cmpwn.com> writes:\n\n> The present options are misleading; \"ssl\" enables generic, \"modern\" SSL\n> support, which could use either SSL or TLS; and \"tls\" enables the\n> SMTP-specific (and deprecated) STARTTLS protocol.\n\nHmph.\n\nIsn't SMTPS (running SMTP over SSL encrypted connection) the one\nthat was once deprecated until it got resurrected)?\n\nSTARTTLS is not all that SMTP specific---POP and IMAP can also start\nin cleartext and upgrade with STARTTLS the same way, no?\n\nI couldn't find a justification for our log message to call\nSTARTTLS-style explicit TLS \"deprecated\".  When you send an updated\nversion, please give a reference.\n\n> This changes the canonical config options to \"ssl/tls\" and \"starttls\",\n> updates the docs to explain the options in more detail, and updates\n> git-send-email to accept either form.\n> ---\n\nMissing Sign-off, ...\n\n>  Documentation/git-send-email.txt | 11 ++++++++---\n>  git-send-email.perl              |  4 ++--\n>  2 files changed, 10 insertions(+), 5 deletions(-)\n>\n> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\n> index 93708aefea..3597935e41 100644\n> --- a/Documentation/git-send-email.txt\n> +++ b/Documentation/git-send-email.txt\n> @@ -168,9 +168,14 @@ Sending\n>  \tunspecified, choosing the envelope sender is left to your MTA.\n>  \n>  --smtp-encryption=<encryption>::\n> -\tSpecify the encryption to use, either 'ssl' or 'tls'.  Any other\n> -\tvalue reverts to plain SMTP.  Default is the value of\n> -\t`sendemail.smtpEncryption`.\n> +\tSpecify the encryption to use, either 'ssl/tls' or 'starttls', whichever\n> +\tis recommended by your email service provider.  SSL/TLS is typically\n> +\tused on port 465 and is preferred if available.  STARTTLS is typically\n> +\tused on port 25 or 587. Any other value reverts to plain SMTP.  The\n> +\tdefault is the value of `sendemail.smtpEncryption`.\n\nI think it is a vast improvement to describe what existing 'ssl' and\n'tls' does, like the above does.  It is a documentation update that\ndeserves its own commit (i.e. [PATCH 1/3]), and it should be done\nbefore adding the new ssl/tls and starttls synonyms.\n\nMaking it an error to give unrecognised string (i.e. other than\n'ssl' and 'tls'), or at least warning, would be a good follow-up\nchange (i.e. [PATCH 2/3]), but that is optional.\n\nAnd then, it may make sense to introduce the synonyms, but please\nmake it a separate patch that builds on top of the other two steps\n(i.e. [PATCH 3/3]).\n\nHonestly I am ambivalent about these two synonyms this patch added.\n\nIn the ideal world, it would have been nice if we could make 'tls'\nas the name of the choice that has been known as 'ssl' (i.e. the\nunderlying transport protocol to run SMTP or any other higher layer\nprotocol on top, there used to be SSL but these days TLS is used as\nan improved alternative---SSL 2.0/3.0 have been deprecated for some\ntime), but because we used 'tls' to mean the STARTTLS-style \"start\nSMTP as plain and then upgrade to encrypted channel\", we can't reuse\nthe 'tls' for that purpose.\n\nI do not have any qualm about the fully spelled out \"starttls\"\nsynonym for the latter.  In fact, if we can go back in time and redo\nthe history with hindsight, that is the name we should have used\nfrom the beginning.  But I find it unfortunate that we need to say\n'ssl/tls', i.e. prefixing the name of the choice with the name of a\ndeprecated thing, for the former.  Another reason I am hesitant\nabout 'ssl/tls' is because the description of it in documentation\nnaturally invites errors.  I.e. \"You can set it to 'ssl/tls'...\"\nsounds as if the manual is telling me to use one of 'ssl' or 'tls',\nwhich is not what it is sayng---it literally wants me to say\n'ssl/tls' with a slash in it.\n\nThanks.\n"},{"id":"421500","messageId":"CAJMW3X0O81L.8TNFDEFUNML1@taiga","threadId":"55467","inReplyTo":"xmqqlf9rklkb.fsf@gitster.g","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2021-04-10T00:57:30Z","receivedAt":"2021-04-10T00:57:35Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Fri Apr 9, 2021 at 8:52 PM EDT, Junio C Hamano wrote:\n> Hmph.\n>\n> Isn't SMTPS (running SMTP over SSL encrypted connection) the one\n> that was once deprecated until it got resurrected)?\n\nKind of, back in the 90's, but that's water under the bridge now. SMTP\nover SSL/TLS is the de-facto standard.\n\n> STARTTLS is not all that SMTP specific---POP and IMAP can also start\n> in cleartext and upgrade with STARTTLS the same way, no?\n\nWell, email-specific, at least. Sorry for the confusion.\n\n> I couldn't find a justification for our log message to call\n> STARTTLS-style explicit TLS \"deprecated\". When you send an updated\n> version, please give a reference.\n\nThe main concern with STARTTLS is downgrade attacks. I'll note this in\nthe commit message for v2.\n\n> I think it is a vast improvement to describe what existing 'ssl' and\n> 'tls' does, like the above does. It is a documentation update that\n> deserves its own commit (i.e. [PATCH 1/3]), and it should be done\n> before adding the new ssl/tls and starttls synonyms.\n>\n> Making it an error to give unrecognised string (i.e. other than\n> 'ssl' and 'tls'), or at least warning, would be a good follow-up\n> change (i.e. [PATCH 2/3]), but that is optional.\n>\n> And then, it may make sense to introduce the synonyms, but please\n> make it a separate patch that builds on top of the other two steps\n> (i.e. [PATCH 3/3]).\n\nAck, can do.\n\n> In the ideal world, it would have been nice if we could make 'tls'\n> as the name of the choice that has been known as 'ssl' (i.e. the\n> underlying transport protocol to run SMTP or any other higher layer\n> protocol on top, there used to be SSL but these days TLS is used as\n> an improved alternative---SSL 2.0/3.0 have been deprecated for some\n> time), but because we used 'tls' to mean the STARTTLS-style \"start\n> SMTP as plain and then upgrade to encrypted channel\", we can't reuse\n> the 'tls' for that purpose.\n>\n> I do not have any qualm about the fully spelled out \"starttls\"\n> synonym for the latter. In fact, if we can go back in time and redo\n> the history with hindsight, that is the name we should have used\n> from the beginning. But I find it unfortunate that we need to say\n> 'ssl/tls', i.e. prefixing the name of the choice with the name of a\n> deprecated thing, for the former. Another reason I am hesitant\n> about 'ssl/tls' is because the description of it in documentation\n> naturally invites errors. I.e. \"You can set it to 'ssl/tls'...\"\n> sounds as if the manual is telling me to use one of 'ssl' or 'tls',\n> which is not what it is sayng---it literally wants me to say\n> 'ssl/tls' with a slash in it.\n\nIf I may propose a bold alternative: what I added as \"ssl/tls\", i.e.\n\"modern\" SSL, should be \"yes\", no encryption should be \"no\", and if you\nspecifically need starttls: \"starttls\".\n"},{"id":"421502","messageId":"xmqqczv3kks4.fsf@gitster.g","threadId":"55467","inReplyTo":"CAJMW3X0O81L.8TNFDEFUNML1@taiga","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-10T01:09:31Z","receivedAt":"2021-04-10T01:09:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n>> I couldn't find a justification for our log message to call\n>> STARTTLS-style explicit TLS \"deprecated\". When you send an updated\n>> version, please give a reference.\n>\n> The main concern with STARTTLS is downgrade attacks. I'll note this in\n> the commit message for v2.\n> ...\n> If I may propose a bold alternative: what I added as \"ssl/tls\", i.e.\n> \"modern\" SSL, should be \"yes\", no encryption should be \"no\", and if you\n> specifically need starttls: \"starttls\".\n\nWell, \"is starttls deprecated\" given to search engine gives me\n\n    SMTPS (implicit SSL) has been deprecated/obsolete since\n    SMTP+STARTTLS (explicit SSL) was defined in RFC2487.\n\nas the \"featured snippet\", and there are debates like \"SMTPS has\nbeen deprecated since forever (late 90's or thereabouts)\"\nhttps://news.ycombinator.com/item?id=10556797\n\nI strongly prefer to keep our documentation out of that mess by not\ntaking sides.  To me, both are valid options to make the world safer\nover cleartext, and we won't have to make recommendations when both\nare available.\n\nThanks.\n"},{"id":"421508","messageId":"YHEB1ClofnD6nQWA@camp.crustytoothpaste.net","threadId":"55467","inReplyTo":"20210409211812.3869-1-sir@cmpwn.com","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-10T01:39:32Z","receivedAt":"2021-04-10T01:39:40Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-09 at 21:18:12, Drew DeVault wrote:\n> The present options are misleading; \"ssl\" enables generic, \"modern\" SSL\n> support, which could use either SSL or TLS; and \"tls\" enables the\n> SMTP-specific (and deprecated) STARTTLS protocol.\n> \n> This changes the canonical config options to \"ssl/tls\" and \"starttls\",\n> updates the docs to explain the options in more detail, and updates\n> git-send-email to accept either form.\n> ---\n>  Documentation/git-send-email.txt | 11 ++++++++---\n>  git-send-email.perl              |  4 ++--\n>  2 files changed, 10 insertions(+), 5 deletions(-)\n> \n> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\n> index 93708aefea..3597935e41 100644\n> --- a/Documentation/git-send-email.txt\n> +++ b/Documentation/git-send-email.txt\n> @@ -168,9 +168,14 @@ Sending\n>  \tunspecified, choosing the envelope sender is left to your MTA.\n>  \n>  --smtp-encryption=<encryption>::\n> -\tSpecify the encryption to use, either 'ssl' or 'tls'.  Any other\n> -\tvalue reverts to plain SMTP.  Default is the value of\n> -\t`sendemail.smtpEncryption`.\n> +\tSpecify the encryption to use, either 'ssl/tls' or 'starttls', whichever\n> +\tis recommended by your email service provider.  SSL/TLS is typically\n> +\tused on port 465 and is preferred if available.  STARTTLS is typically\n> +\tused on port 25 or 587. Any other value reverts to plain SMTP.  The\n> +\tdefault is the value of `sendemail.smtpEncryption`.\n> ++\n> +For legacy reasons, 'ssl' is accepted for 'ssl/tls' and 'tls' is accepted for\n> +'starttls'.\n\nI definitely approve of describing the two options.  Even just saying\nthat one option is tunneled and one is actually STARTTLS would be an\nimprovement here without the additional options.  Apparently I managed\nto figure it out, but I'm not sure if that's because I use STARTTLS or\nbecause I would logically prefer the more modern TLS over SSL just by\nlooking at the names.\n\nSince I agree that \"ssl/tls\" may be a bit confusing, maybe we could call\nthat option \"wrapped\" or \"tunneled\"?  Other names are possible, of\ncourse.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"421509","messageId":"CAJNUBUZNAXE.283NJ968IDN2X@taiga","threadId":"55467","inReplyTo":"YHEB1ClofnD6nQWA@camp.crustytoothpaste.net","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2021-04-10T01:42:11Z","receivedAt":"2021-04-10T01:42:15Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Fri Apr 9, 2021 at 9:39 PM EDT, brian m. carlson wrote:\n> Since I agree that \"ssl/tls\" may be a bit confusing, maybe we could call\n> that option \"wrapped\" or \"tunneled\"? Other names are possible, of\n> course.\n\nI would prefer to name the options after the terms we can expect the\nuser to find in their mail service provider's documentation, hence\nSSL/TLS and STARTTLS. Though I can see the confusion in including the\nslash, I'll figure something else out.\n"},{"id":"421551","messageId":"xmqqczv2jdk6.fsf@gitster.g","threadId":"55467","inReplyTo":"CAJNUBUZNAXE.283NJ968IDN2X@taiga","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-10T16:43:05Z","receivedAt":"2021-04-10T16:43:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n> On Fri Apr 9, 2021 at 9:39 PM EDT, brian m. carlson wrote:\n>> Since I agree that \"ssl/tls\" may be a bit confusing, maybe we could call\n>> that option \"wrapped\" or \"tunneled\"? Other names are possible, of\n>> course.\n>\n> I would prefer to name the options after the terms we can expect the\n> user to find in their mail service provider's documentation, hence\n> SSL/TLS and STARTTLS. Though I can see the confusion in including the\n> slash, I'll figure something else out.\n\nOK.  \n\n * My e-mail provider [*] seems to label these two as SSL/TLS\n   (sometimes just TLS) and STARTTLS, but that is aligning how the\n   popular client programs call these two methods, so it may not be\n   a good datapoint.\n\n * GMail help page [*] seems to use 'SSL' vs 'STARTTLS' (they seem\n   to support both).\n\n * Outlook.live.com/ help page [*] says they want you to use\n   'STARTTLS' for SMTP, but they use 'SSL/TLS' to describe their\n   IMAP and POP offerings.\n\nWith the above limited samples, I agree that the choices between\n'SSL/TLS' and 'STARTTLS' would appear familiar to our end-users.\n\n\n\n[Reference]\n\n* https://helpspot.pobox.com/index.php?pg=kb.page&id=118\n  https://helpspot.pobox.com/index.php?pg=kb.page&id=125\n  https://helpspot.pobox.com/index.php?pg=kb.page&id=399\n\n* https://support.google.com/mail/answer/7126229?hl=en\n\n* https://support.microsoft.com/en-us/office/pop-imap-and-stmp-settings-8361e398-8af4-4e97-b147-6c6c4ac95353\n"},{"id":"421565","messageId":"f347c0bf-b08e-34d7-e1ae-796a3e619b8c@gmail.com","threadId":"55467","inReplyTo":"xmqqlf9rklkb.fsf@gitster.g","subject":"Re: [PATCH] send-email: clarify SMTP encryption settings","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-04-11T05:48:40Z","receivedAt":"2021-04-11T05:51:08Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 10/04/21 07.52, Junio C Hamano wrote:\n> Isn't SMTPS (running SMTP over SSL encrypted connection) the one\n> that was once deprecated until it got resurrected)?\n> \n> STARTTLS is not all that SMTP specific---POP and IMAP can also start\n> in cleartext and upgrade with STARTTLS the same way, no?\n\nWikipedia entry on Opportunistic TLS [1] said that STARTTLS is not specific\nto SMTP, but also to various protocols:\n> The STARTTLS command for IMAP and POP3 is defined in RFC 2595, for SMTP in RFC 3207, for XMPP in RFC 6120 and for NNTP in RFC 4642. For IRC, the IRCv3 Working Group has defined the STARTTLS extension. FTP uses the command \"AUTH TLS\" defined in RFC 4217 and LDAP defines a protocol extension OID in RFC 2830. HTTP uses upgrade header. \n\n[1]: https://en.wikipedia.org/wiki/Opportunistic_TLS\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"}]}