Hacker News Reader

Comment by severus_snape | Hacker News Reader

  # do your code change
  git commit
  git send-email --to=<some mailing list> -1

  # amend your change
  git commit --amend
  git send-email -v2 --to=<some mailing list> -1

I'm not sure what is needlessly annoying and absurd.

Edit with minimal configuration:

  cat ~/.gitconfig

  [user]
   email = your@mail.address
   name = Your Name
  
  [sendemail]
   smtpuser = your@mail.address
   smtpserver = smtp.whatever.com
   smtpserverport = 587
   smtpencryption = tls

View on HN

You left out the entire configure SMTP step. Honestly I’m not even sure how to do that if your SMTP server requires 2FA and does not allow legacy app specific passwords.

There are instructions provided for Gmail and some others:

https://git-send-email.io/#step-2

A tool from Google is mentioned and linked to:

https://github.com/google/gmail-oauth2-tools/tree/master/go/...

That uses app specific passwords, and with Google Workspace, the administrator can completely turn off these “less secure apps”. Pretty sure Office 365 has the same.

Sadly you’re right. Microsoft has brainwashed many IT departments into forcing oauth on everything, no app specific passwords, no regular passwords, nothing else. Thankfully they do support this on imap and smtp, but you have to have something that can handle it. I use a modified version of isync with the sasl plugin to fetch mail, and a python smtp sender that supports the oauth flow along with a set of scripts for generating a new refresh token every few months. It’s a heck of a lot of stuff to maintain, but at least it works. If anyone’s interested I could provide links or upload the modified versions to fix o365 quirks.

Multiple enterprise customers use my software (https://emailengine.app) because it can proxy OAuth2-enabled IMAP/SMTP connections as regular password-based sessions. Turns out there are a lot of legacy, like all kinds of cron scripts, that want to connect to some IMAP account to check and do something. It all breaks down once the organisation enforces OAuth for their email. So, personally, I don't like it at all, but as a software developer, I'm really happy about it. Helps with my sales effort :P

Oh that’s pretty cool, thanks for the link. I’ve used davmail as a proxy like this, just for the oauth support, but it doesn’t scale to large mailboxes or high traffic well at all. May forward this along for some of our internal services people.

You can also use this (locally-hosted) proxy of mine which transparently adds OAuth 2.0 support to any IMAP/POP/SMTP client: https://github.com/simonrob/email-oauth2-proxy.

There’s another method that doesn’t use app specific passwords but I’m not entirely sure how it DOES work - it opens a connection and then gives you a web address to go to in your browser to authenticate with 2fa. And then somehow it magically works until it decides it doesn’t like you anymore.

I never studied the protocol of Gmail/Exchange/etc. 2FA, but I suppose the SMTP auth token expires after a while, and the client somehow hasn't implemented token refresh? Anyway, glad to know there is a way (?) to get git-send-email working with stricter 2FA.

I've always assumed that the server side stores as much information about the client as it can, so not just "username/password" but source IP, client headers, etc and somehow uses that as a "session token".

The tool from Google that is linked to appears to use oauth2.

Every mail server/provider that provides 2FA that I used allows for configuring "tokens" (called a bit different everywhere) which are a high entropy random string, and some of them require TFA only for IMAP or POP, i.e., getting mail, not SMTP, i.e., sending mail.

If you use this proxy of mine then any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.

They said they found it difficult to configure, not that they found it difficult to use afterwards.

If your system cannot relay mail correctly already, as most office setups are easy to configure to be able to provide that without extra config, at least for Linux setups, then the set up means having something like the following in their gitconfig:

    cat .gitconfig
    # snip
    [sendemail]
     to = default@list.example.com
     annotate = yes
     suppresscc = self
     smtpencryption=tls
     smtpserver=imap.example.com
     smtpserverport=587
     smtpuser=foo.bar@example.com

(only the ones starting with "smtp" are relevant for mail, the other ones are just there for convenience)

And that has to be done once, iow., in essence it's as hard a setting up an email fat client like thunderbird.

FWIW, I haven't done that kind of setup for years because modern iOS/macOS does email server discovery, where you enter "bob@example.com" and then it does discovery and figures out the right imap.example.com:587 etc for you by looking at DNS.

Yes, such things are nice. The well-known URI [0] system is also sometimes used for this, at least there's one entry for Thunderbird under the "autoconfig/mail" subdirectory. Having some of those auto-config methods available for git send-mail could be nice, as it would lower the barrier a bit further, even if most devs are probably able to check their SMTP endpoint and port.

[0]: https://en.wikipedia.org/wiki/Well-known_URI

Reply on news.ycombinator.com