Re: Oauth support

On Tue, Nov 29, 2022 at 03:06:41PM -0500, John P. Rouillard wrote:
> 
> Ralf, this only handles IMAP (well IMAPS) right? It doesn't make a
> change to mailer.py to send email using SMTP authentication with
> OAuth2 on a server.

Yes, only IMAP, the outgoing side is currently not handled.

But I *think* that you can get away by installing a local mailer (my
choice would be postfix), there seems to be a SASL OAuth plugin for
postfix:
https://mmogilvi.users.sourceforge.net/software/oauthbearer.html#setupPostfix

Note that most of the cloud email accounts I know of allow sending from
a single sender-address only. So you cannot distinguish mails sent by
the roundup mailer (which, when replied to are sent to roundup-mailgw)
and mails sent by roundup-admin (which come from an administrative
account and do not end up in the tracker when replied to). So most users
I know of who are retrieving mail from the cloud are using a different
mechanism for sending.

> I had patches to call an external mailer for mailer.py a few years
> ago. As I remember they had an issue that I never fixed. Maybe these
> external interfaces would be better handled by calling an external
> application?

Yes, see above.

I don't know about the other applications you mention.

> >I also have a script (currently not in the roundup repo) for requesting
> >the initial tokens from a MS cloud.
> 
> Might https://github.com/pdobsan/mailctl work?  I know nothing about
> it other than a reference from the msmtp page for arch linux
> https://wiki.archlinux.org/title/Msmtp.

I have no idea and no time to look. I've committed the script that works
for me -- you only need that once, all subsequent token renewals are
done using the refresh token you obtain with that script. The
roundup-mailgw does support renewing the access token using the refresh
token (and also handles the case this yields a new refresh token).

> If we do start adding suport for native handling of smtp oauth2,
> config.ini can support:
> 
>   [oauth2]
>   # the client id(required)
>   client_id = xyzzy

I'd rather put the secrets into an oauth directory where it can be used
by both, smtp and imap. For imap you might use *several different*
directories with secrets if you have several inboxes.

>   # url, msmail default 
>   token_endpoint = https://xyszzy.com/authv2/xyzzy
> 
>   # default oauth
>   oauth_directory = oauth2

Yep, this currently contains the client_id and the client_secret for
imap.

>   # saved in an external file or placed inline
>   client_secret = file://oauth/secret
See above.

> the [mail] section could have use_oauth2 = true/false in
> adddition to the password key to enable oauth2 and use the [oauth2]
> link to the settings here. mailgw would just use these settings if the
> oauth method was used.

OK.

> Handing multiple providers (if/when needed) would be pretty straight
> forward. Add an additional config.ini file similar to
> extensions/config.ini and detectors/config.ini in the oauth_directory.
> It could have sections:
> 
>   [gmail-in]
> 
>   [msmail-out]
> 
>   [fredsmail-in]

At least the access_token and the refresh_token need a writeable file
(they are renewed). So putting the client id and secret into the same
directory would have everything in one place. The sections above would
just contain oauth directory and token endpoint.

> with the same keys as [oauth2] except for oauth_directory.
I'd put the directory in there, too.

The other things look fine to me.

Are you aware if the python smtp implementation can use OAuth?
There is code for Google OAuth on the net for IMAP that I've used to
implement OAuth with the IMAP lib. Maybe there is something similar for
smtp?


> Token files would be prefixed with the config name. E.G.
> gmail-in_access_token, msmail-out_refresh_token
> fredsmail-in_access_token. The [oauth2] settings would use
> oauth2_token_file.

No, they all live in the respective oauth directory for that endpoint.
So I wouldn't give the files different names, just the directory.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]