4 ms·

Sadly I believe it will stop working. I'm in the same boat and have been putting off moving to a Google blessed solution because of the effort required to navi

Sadly I believe it will stop working. I'm in the same boat and have been putting off moving to a Google blessed solution because of the effort required to navigate the bewildering array of documentation, client libraries and authentication mechanisms Google offers. Much of the documentation and examples Google makes available are targeted at accessing Gmail on behalf of a human user (who has access to a browser) rather than accessing it on behalf of a machine (which does not). Cutting through the noise is half the battle! I reluctantly spent some time this morning trawling through it and whilst I now have a working solution I couldn't begin to say whether it is the right approach. In the end I decided to ditch SMTP and use the GMail API [1] with a service account [2] setup with domain-wide delegation [3] which is nearly as scary as it sounds. One caveat of this approach is that I choose to use a service account `key` (not to be confused with an `API Key`!) rather than the Google recommended "Workload Identity Federation" [4] so no-doubt this will be depreciated at some point. If you must stick with SMTP then [5] is a good resource for showing how to use SASL XOAUTH with an access token to authenticate with Gmail SMTP. Of course, you need to obtain the access token from Google IAM to use this anyway so there is little benefit of doing this vs using the GMail API directly. [1] https://developers.google.com/gmail/api/guides/sending https://developers.google.com/gmail/api/guides/sending [2] https://developers.google.com/identity/protocols/oauth2#serviceaccount https://developers.google.com/identity/protocols/oauth2#serv... [3] https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority https://developers.google.com/identity/protocols/oauth2/serv... [4] https://cloud.google.com/iam/docs/workload-identity-federation https://cloud.google.com/iam/docs/workload-identity-federati... [5] https://developers.google.com/gmail/imap/xoauth2-protocol#smtp_protocol_exchange https://developers.google.com/gmail/imap/xoauth2-protocol#sm...

jorgesborges 5y ago
Thank you for that comment, very helpful.
- FujiApple 5y ago
  I should add, as many others have pointed out, that moving to use app passwords is a _much_ easier solution in the short term (how long they will be supported I have no idea) so I suggest you try that first. This should have been the first thing I tried but, rather unhelpfully, the Google page where you create app passwords says "You'll only need to enter it once so you don't need to remember it" and later "You won't need to remember it, so don't write it down or share it with anyone.". This suggested to me that these passwords are single use (i.e. a OTP) but testing suggests that this is not the case. Also, whilst using app passwords requires that you enable 2FA on the account, they do _not_ require you to enter the 2nd factor when logging in with the app password (obvious in hindsight, but not made clear by the documentation). I just tested that these work even when "less secure apps" is disabled at the domain admin level (and by extension the individual account). Indeed, after enabling 2FA for the account the option to enable/disable "less secure apps" is removed. So it seems that you can either have no-2FA + (optional) less-secure apps OR 2FA + app passwords.

jorgesborges 5y ago

Thank you for that comment, very helpful.

FujiApple 5y ago
I should add, as many others have pointed out, that moving to use app passwords is a _much_ easier solution in the short term (how long they will be supported I have no idea) so I suggest you try that first. This should have been the first thing I tried but, rather unhelpfully, the Google page where you create app passwords says "You'll only need to enter it once so you don't need to remember it" and later "You won't need to remember it, so don't write it down or share it with anyone.". This suggested to me that these passwords are single use (i.e. a OTP) but testing suggests that this is not the case. Also, whilst using app passwords requires that you enable 2FA on the account, they do _not_ require you to enter the 2nd factor when logging in with the app password (obvious in hindsight, but not made clear by the documentation). I just tested that these work even when "less secure apps" is disabled at the domain admin level (and by extension the individual account). Indeed, after enabling 2FA for the account the option to enable/disable "less secure apps" is removed. So it seems that you can either have no-2FA + (optional) less-secure apps OR 2FA + app passwords.