Document the use with Mutt and other SASL-using IMAP/SMTP clients

[ivucica]

I have managed to get this implementation of the SASL XOAUTH2 method to work with Mutt -- thank you for your work!

It would be nice if it was documented how it can be achieved.

Feel free to assign this to me, and I'll try to come up with some tutorial.

[MarcvdSluys]

@ivucica I'm trying to do the same thing. Have your posted your documentation somewhere, or could you send me your notes (e.g. by email)?

[MarcvdSluys]

Here's my "solution", found by trial and error since I know very little about SASL and OAuth2, for MBsync. I'm sure there are far better ones, but this works for me for now and might help others: https://github.com/MarcvdSluys/SundryNotes/blob/master/mbsync-with-gmail-oauth2.org

[minusdavid]

@MarcvdSluys I was looking through your notes, and I just wanted to confirm that your steps are after installing sasl-xoauth2, right?

So basically, you install this SASL XOAUTH2 plugin, use XOAUTH2 as the SASL mechanism for auth, and supply it with the SMTP Username/email address as username and then a XOAUTH2 access token as the password?

And for on-going usage MBsync has that PassCmd which fires off your custom script to use the refresh token to get a new access token each time it needs to make a XOAUTH2 connection?

If I understand correctly, that sounds great!

[minusdavid]

I'm hoping to figure out how to use sasl-xoauth2 with https://metacpan.org/pod/Authen::SASL and https://metacpan.org/pod/Email::Sender::Transport::SMTP

While I've used Oauth2 heaps, I'm not understanding what sasl-xoauth2 needs outside a Postfix context...

Looking through the code, it looks like it expects the SASL password to be a filepath to a token, so I'm confused how your MBSync implementation is working... unless it's using a different SASL plugin?

[MarcvdSluys]

I must admit I don't recall all details and don't have the time to redo the whole thing. It's still working though.

But yes I installed sasl-xoauth2 so that I can run sasl-xoauth2-tool manually from the shell as shown. This gives me the refresh token. For some reason I do not understand, for two of my GMail accounts the refresh token is permanent (at least valid for more than two years), for a third I need to get a new refresh token once a week. I have no idea where the difference comes from...

The user name is the GMail address as User in .mbsyncrc and the Python script provides the client_id, client_secret and refresh_token to Google, receives the access_token from Google in return and prints it to stdout. MBsync calls the Python script mentioned as PassCmd in .mbsyncrc and uses the return value, i.e. the access token instead of a password. This happens every time I run mbsync.

[minusdavid]

No worries. Thanks for sharing those details.

I must be missing something in sasl-xoauth2 as in the C++ code it seems like the password is supposed to be a path to the OAuth2 token response JSON object rather than the access token value itself.

I thought sasl-xoauth2-tool was just for getting the initial token response, saving that to file, and then you give a the filepath to SASL as the password, so that the plugin can then do all the heavy lifting.

When I looked at https://wiki.archlinux.org/title/Isync it it makes it seem like PassCmd should be a command that provides the access token, but I would think that would just be for the cyrus-sasl-xoauth2 plugin which doesn't seem as sophisticated as sasl-xoauth2?

[minusdavid]

Unfortunately, I've hit a bit of a stumbling point in my investigations.

I'm using stable Debian, but Authen::SASL::XS isn't available in stable Debian, and Email::Sender::Transport::SMTP in stable Debian doesn't allow you to provide your own SASL authenticator (it just seemingly uses SMTP AUTH LOGIN). It looks like the next version of Debian will have the XS library and the newer email library.

I did get the Ubuntu Jammy package from @tarickb 's PPA to install on stable Debian, so that was good. Had to hack sasl-xoauth2-tool to work in a Docker container, but that was trivial.

It looks like Ubuntu 24.04 has the packages I'd need, so might try an experiment using it.

[norbusan]

Just in case it helps, I have written up a document how to use sasl-xoauth2 for mbsync and postfix for both Outlook and Google, see here: https://github.com/norbusan/outlook-gmail-mbsync-postfix-sasl-xoauth

There is also a script for the outlook tokens generation that needs only the client/tenant ids and email.

[norbusan]

@minusdavid

it seem like PassCmd should be a command that provides the access token

I stumbled over that, too, this is wrong. The PassCmd must provide the filename of the token file:

PassCmd "echo ~/.tokens/${your_email}"