In general it's better to use direct TLS connections. Default to
direct TLS in our example Git config.

Add a hint about STARTTLS, because (1) some old providers may still
not have direct TLS and (2) the Git smtpencryption option is very
confusing.
---
 index.html | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/index.html b/index.html
index 6441a6dc7c5a..e69733f08eac 100644
--- a/index.html
+++ b/index.html
@@ -150,8 +150,8 @@
                 <pre>[sendemail]
 	smtpserver = mail.example.org
 	smtpuser = you@example.org
-	smtpencryption = tls
-	smtpserverport = 587</pre>
+	smtpencryption = ssl
+	smtpserverport = 465</pre>
                 <p>
                   Be sure to fill in the appropriate values for your email
                   provider - you will probably only have to fill in
@@ -162,6 +162,11 @@
                 <pre>git config --global user.email "you@example.org"
 <!--              -->git config --global user.name "Your Name"</pre>
                 <a href="#step-3" class="button">Next</a>
+                <p>
+                  This configuration assumes direct TLS. If your provider only
+                  offers STARTTLS, set <code>smtpencryption = tls</code> and
+                  <code>smtpserverport = 587</code>.
+                </p>
               </div>
             </div>
           </div>

base-commit: 9fb2ece401eced9479ba2f67e2e781a7fba30c4f
-- 
2.34.1

git-send-email.io/patches: FAILED in 36s

[Use direct TLS by default, add hints for STARTTLS][0] from [Simon Ser][1]

[0]: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/27004
[1]: contact@emersion.fr

✓ #639581 SUCCESS git-send-email.io/patches/python.yml https://builds.sr.ht/~sircmpwn/job/639581
✗ #639582 FAILED  git-send-email.io/patches/static.yml https://builds.sr.ht/~sircmpwn/job/639582

Not in love with the "direct" TLS nomenclature, but I don't have any
better ideas at hand. Thanks!

To git@git.sr.ht:~sircmpwn/git-send-email.io
   9fb2ece..2c8927f  master -> master

On 01/12/2021 09.51, Drew DeVault wrote:
> Not in love with the "direct" TLS nomenclature, but I don't have any
> better ideas at hand.
It's usually called implicit TLS