OAuth2 support

[drakkan]

Is your feature request related to a problem? Please describe.

First of all thank you for this amazing library. Finally, a well-maintained library for sending emails with Go.
I'm using this library in SFTPGo since version 2.5.0 and it works fine.
I was wondering if there is a plan to add OAuth2 support:

https://developers.google.com/gmail/imap/xoauth2-protocol
https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

Describe the solution you'd like

The Golang oauth2 library could be used to implement the token exchange. Once we have the token the library should be able to implement and use the log in with the XOAUTH2 mechanism.

I'm not sure if this feature should be added here, in a plugin or is outside the scope of this project

Describe alternatives you've considered

No response

Additional context

No response

[wneessen]

Hi @drakkan, thanks for opening this issue and for the nice words. It still baffles me that a packages that started as a mail solution for my small mail service if now used by big projects like SFTPGo, Authelia, uptrace or Vikunja.

I think XOAUTH2 support would be a great addition for the libraby and it should be easy to implement from what I see in the doc you provided. I would leave the token exechange out of it for now, since so far the premise of the lib was to only rely on the Go stdlib. Do you think that would help or would you need the whole token exchange as well?

[drakkan]

Hi @drakkan, thanks for opening this issue and for the nice words. It still baffles me that a packages that started as a mail solution for my small mail service if now used by big projects like SFTPGo, Authelia, uptrace or Vikunja.

I believe it's because the Go libraries for sending emails are not well maintained. All it took was a quick look at the go-mail code to decide to use it 😄

I think XOAUTH2 support would be a great addition for the libraby and it should be easy to implement from what I see in the doc you provided. I would leave the token exechange out of it for now, since so far the premise of the lib was to only rely on the Go stdlib. Do you think that would help or would you need the whole token exchange as well?

I'm not sure, I'll do some testing with my gmail account as soon as I have some free time to see how it might work. I could manage the token exchange directly in SFTPGo. Thank you for considering this feature!

I'm surprised that the other projects you mentioned above don't need this feature

[james-d-elliott]

The reason is precisely the lack of maintenance of many libraries as well as cumbersome API's.

As far as "need" we have not had a lot of interest in the particular feature, however it would be useful to have support all the same, and fairly sure people would use it if the option was available. Specifically for cloud services.

Also somewhat related is the opportunistic auth we use: https://github.com/authelia/authelia/blob/master/internal/notification/smtp_auth.go

[james-d-elliott]

Helpful:

• https://documentation.open-xchange.com/7.10.2/middleware/mail/dovecot/oauth_2.0_with_postfix_and_dovecot.html
• https://github.com/tarickb/sasl-xoauth2

[drakkan]

I have a working proof of concept tested with Gmail

0001-WIP.zip

I still need to understand/fix some things about token exchange (currently I only get an access token, I need a refresh token instead so I can get access tokens in background), as for the SMTP part the only complication is that Gmail and Exchange have a small difference (see the docs linked above):

• After an error Gmail wants an empty response (as done in the above patch)
• Exchange online doesn't want this empty response

I'm not sure if we can auto-detect it somehow (if host is smtp.gmail.com?) or if go-mail needs to know if it's talking to gmail or not.
For now I have no way to test with Exchange online. I will finalize this patch (doc, test cases etc) if I add this feature to SFTPGo.
Thank you!

[james-d-elliott]

Is there a difference in how they advertise the auth extension when you check via telnet? I'd aim to base it on that if possible with the option for implementers to override it. Otherwise make it an implementer choice is probably best, with the default being which ever of the two Dovecot supports (or if there are other known providers of this mechanism make it whatever the theoretical majority use case will be).

[drakkan]

Is there a difference in how they advertise the auth extension when you check via telnet? I'd aim to base it on that if possible with the option for implementers to override it. Otherwise make it an implementer choice is probably best, with the default being which ever of the two Dovecot supports (or if there are other known providers of this mechanism make it whatever the theoretical majority use case will be).

Dovecot seems to support the Google variant. See #130. Thank you!

[drakkan]

Thank you! I'll let you know how the testing goes, the person who asked will be using Exchange Online

[wneessen]

Perfect! Looking forward to your response