https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- With the "sasl-xoauth2" plugin, I believe that it handles auto-refreshing of the access token, so while there is a bit of overhead for the backend sysadmin at first, once it's set up, it should be fairly set and forget. (Although if your refresh token expires, then you'll need to set it up again.) -- Now I also mentioned "cyrus-sasl-xoauth2". I don't understand it as well and its documentation is not very good at all. However, my understanding is that you have to pass the access_token value directly as the sasl_password. That means no auto-refreshing of access tokens or anything like that. If we were to support that SASL plugin, then we'd have to handle a lot of the OAuth2 process ourselves, which is not impossible, but it would involve significantly more work. So... at the moment I'm inclined to go with "sasl-xoauth2". -- Additionally, on the "perl-authen-sasl" github by "gbarr", I raised an issue called "Supporting XOAUTH2 authentication?", and there I think the repo maintainer would be open to accepting a patch for a pure Perl XOAUTH2 implementation. I don't know that any of us have the time/expertise to do that, but that's a opportunity open to folks as well. (We could also instantiate our own Authen::SASL plugin and pass that to Email::Sender::Transport::SMTP::Persistent using sasl_authenticator.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Michał <schodkowy.omegi-0r@icloud.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schodkowy.omegi-0r@icloud.c | |om --- Comment #5 from Michał <schodkowy.omegi-0r@icloud.com> --- For auto-refresh, there's also a challenge in that the refreshed credentials will have to be retrieved and saved back to the database (unless you say it's specifically filepath as password, and then the library would just write to that file instead on its own, then that'd be covered already I suppose). There's also the open question about whether Koha should offer some kind of way in the interface to open up login page for some common providers (or a configurable custom one). If yes, then whether it should provide some kind of default community OAuth app client ID to make it easiest (I vote yes, apps like Thunderbird do just that) (of course these app IDs could and should be made configurable to allow flexibility there if need be). I imagine someone could click a button to add server, choose a preconfigured provider like Google Mail or Microsoft, be directed to login page, after login the new server with all data would be populated, easy. Similarly an existing server with oauth login specified should have an option to trigger a login and generation of new access+refresh token data afresh as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- I think for now we just focus on the minimum viable product (MVP), but I opened this bug report, so that we could gather ideas for the longer term. At the moment, for OAuth2, Koha uses Mojolicious::Plugin::OAuth2 which requires a sysadmin to restart Koha for it to take effect. But I like the idea of there being a OAuth2 client in Koha so that people could get that initial OAuth2 token response, which can then be stored and passed to the library. But first we have to see if the SASL plugin works as expected hehe. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- Note that libemail-sender-perl is currently 2.601 in Debian trixie (testing). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #9)

Ahhh... we only have Authen::SASL::Perl available, so it can't make use of the SASL plugin, since it's a pure Perl implementation.

libauthen-sasl-xs-perl is in Debian trixie (testing).

Layers upon layers...

Unfortunately, libauthen-sasl-xs-perl isn't an easy backport. -- At the moment, the barriers appear to be: 1. Installing a sasl-xoauth2 package, which is only available in a Ubuntu PPA 2. Getting the initial access token (I had to hack /usr/bin/sasl-xoauth2-tool to use a particular port which I had my docker forward. For Koha, we'd need to think more about how we'd want to get the token response.) 3. Install libemail-sender-perl 2.601, which isn't available in stable Debian 4. Install libauthen-sasl-xs-perl, which isn't available in stable Debian There's probably other barriers but those are the immediate one jumping out at me. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #12 from Michał <schodkowy.omegi-0r@icloud.com> --- (In reply to David Cook from comment #6)

But first we have to see if the SASL plugin works as expected hehe.

True true

At the moment, for OAuth2, Koha uses Mojolicious::Plugin::OAuth2 which requires a sysadmin to restart Koha for it to take effect.

But I like the idea of there being a OAuth2 client in Koha so that people could get that initial OAuth2 token response, which can then be stored and passed to the library.

Hmm, I don't think a dedicated OAuth2 library should be needed for this at all. I think that for most popular providers out there at least, one should get away with a purely JavaScript solution that'd fill up the field in the UI, that might be the cleanest and most lightweight solution. But if it's impossible, then I think it could be possible to just construct some special redirect URL that'd update the auth data for given SMTP server (or add new one depending on what user does) with the data it gets in response, and just redirect to server list. There should be no need for any kind of OAuth support library there whatsoever I imagine, just copy over the fields, which should just be standard access_token, refresh_token, expires_in etc. in an object. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- Note that tarickb provides a "debian" directory in other branches: https://github.com/tarickb/sasl-xoauth2/tree/packaging/ubuntu So if we wanted to build this ourselves technically we could. Technically, I suppose we could always write a pure Perl Authen::SASL::Perl module for XOAUTH2 as well, although that is more work than I have time for. Of course, we need libemail-sender-perl 2.601 anyway, so a few factors there. -- This is quite low priority, but hopefully I'll find some time at some point to put together a little Ubuntu 24.04 test... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #14)

Technically, I suppose we could always write a pure Perl Authen::SASL::Perl module for XOAUTH2 as well, although that is more work than I have time for.

Luckily, someone else on the Internet took it upon themselves to write that code! Authen::SASL 2.18 now contains a Authen::SASL::Perl::XOAUTH2 module. Coupled with Email::Sender::Transport::SMTP 2.601, we'd have a way of authenticating using XOAUTH2 with a OAuth2 access token. -- Now... that being said... that's only part of the solution. Koha would still be responsible for getting the initial access token and refresh token, and then Koha would be responsible for getting new access tokens using refresh tokens. So even if we don't have "Authen::SASL 2.18" and "Email::Sender::Transport::SMTP 2.601" yet, we could work on the other mechanisms required to make this work for real. When we do send_or_die() we'll need to check for a failed auth. Hopefully we'll get an error message flowing through about an expired token, so that we can do a token refresh and then retry. We'll need a way to get the initial token response, store it in Koha, and then use it on an ongoing basis. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Thomas Klausner <domm@plix.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |domm@plix.at --- Comment #18 from Thomas Klausner <domm@plix.at> --- We have a customer that will need XOAUTH support for mailing soon (as they are using MS365, and they will disable basic SMTP). They might go with the external proxy solution (simonrob/email-oauth2-proxy), but they are actually interested in getting proper XOAUTH support into Koha. And are (maybe) willing to sponsor the development (depending on how much it will be). We are currently preparing an offer for the following steps: * First step: Add XOAUTH support to the Koha SMTP sender * all the hard parts are already available on CPAN: LWP::Authen::OAuth2, Authen::SASL::Perl::XOAUTH2 and Email::Sender * we "just" need to add some new config settings to SMTP to allow using an access-token (instead of username/password) * we will also need to set up a cronjob to refresh the access tokens and the refresh token (better via cronjob, because if the mail sending happens infrequently even the refresh token could be invalidated in the interval where nothing happend) * The XOAUTH setup (i.e. the OAuth handshake to login the service account and create a first refresh token) will be done via a command line script * Second step (optional): * Add a GUI to the Staff interface to setup XOAUTH and do the OAuth handshake (so system librarians can do the setup without needing access to the shell) * Probably do this via a plugin The second step will be very likely outside the budget of the client, and even the first step might be too much. In that case we (HKS3) would try to get further funding by other interested libraries. Of course we would very much like to get this changes into the Koha core or at least into a plugin, though AFAIK the Notifications-Area does not support any plugins/hooks as of now. We would need some feedback / discussion on how to actually add this feature to Koha: Just add it to Core, or add a way to Koha core to add this (and later other protocols) via Plugin. Looking forward to some feedback to getting this feature (that will be needed more often in the future, as more and more email providers move away from plain SMTP) into Koha! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #19 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Thomas Klausner from comment #18)

We have a customer that will need XOAUTH support for mailing soon (as they are using MS365, and they will disable basic SMTP).

They might go with the external proxy solution (simonrob/email-oauth2-proxy), but they are actually interested in getting proper XOAUTH support into Koha. And are (maybe) willing to sponsor the development (depending on how much it will be).

We are currently preparing an offer for the following steps:

* First step: Add XOAUTH support to the Koha SMTP sender * all the hard parts are already available on CPAN: LWP::Authen::OAuth2, Authen::SASL::Perl::XOAUTH2 and Email::Sender * we "just" need to add some new config settings to SMTP to allow using an access-token (instead of username/password) * we will also need to set up a cronjob to refresh the access tokens and the refresh token (better via cronjob, because if the mail sending happens infrequently even the refresh token could be invalidated in the interval where nothing happend) * The XOAUTH setup (i.e. the OAuth handshake to login the service account and create a first refresh token) will be done via a command line script * Second step (optional): * Add a GUI to the Staff interface to setup XOAUTH and do the OAuth handshake (so system librarians can do the setup without needing access to the shell) * Probably do this via a plugin

The second step will be very likely outside the budget of the client, and even the first step might be too much. In that case we (HKS3) would try to get further funding by other interested libraries.

Of course we would very much like to get this changes into the Koha core or at least into a plugin, though AFAIK the Notifications-Area does not support any plugins/hooks as of now. We would need some feedback / discussion on how to actually add this feature to Koha: Just add it to Core, or add a way to Koha core to add this (and later other protocols) via Plugin.

Looking forward to some feedback to getting this feature (that will be needed more often in the future, as more and more email providers move away from plain SMTP) into Koha!

The token should be retrieved (if a refresh is needed) when it's going to be used. I don't think we need a cronjob here. Making the API call to retrieve a fresh token, if it has expired or absent, could be done during the sending session. I initially thought of implementing an Email::Sender::Transport class based on the persistent SMTP one. So all the session shares the same token and it gets retrieved in a more generic way. The caveat is you wouldn't have a 'Koha context' in such generic transport, thus not possible to store it on the DB, etc. Excited someone can devote time to accomplish this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- (In reply to Thomas Klausner from comment #18)

* First step: Add XOAUTH support to the Koha SMTP sender * all the hard parts are already available on CPAN: LWP::Authen::OAuth2, Authen::SASL::Perl::XOAUTH2 and Email::Sender * we "just" need to add some new config settings to SMTP to allow using an access-token (instead of username/password) * we will also need to set up a cronjob to refresh the access tokens and the refresh token (better via cronjob, because if the mail sending happens infrequently even the refresh token could be invalidated in the interval where nothing happend) * The XOAUTH setup (i.e. the OAuth handshake to login the service account and create a first refresh token) will be done via a command line script

* Second step (optional): * Add a GUI to the Staff interface to setup XOAUTH and do the OAuth handshake (so system librarians can do the setup without needing access to the shell) * Probably do this via a plugin

In theory, I think that this all sounds good to me. That said, I haven't tried the XOAUTH setup before, so that's the thing that I still need to wrap my head around. Still just looking around on Google at how to get the initial access token. I find the run throughs like https://github.com/google/gmail-oauth2-tools/wiki/OAuth2DotPyRunThrough to be interesting because they use the "Installed application" type and not the "service account" type, but surely we'd want to use service accounts. Anyway, it's just this process that I still need to spend some time on... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40153 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Jesse Maseto <jesse@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jesse@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #25 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #24)

It's a good question. Necessity is usually the mother of invention. I can talk to some people about this. They might be able to authorise me to work on it.

I've done some talking and at the moment, it looks like that people prefer the "email-oauth2-proxy" proxy or "sasl-xoauth2" Postfix plugin over working on Koha. -- If someone did want to work on it for Koha, the first step to getting the ball rolling would be to get "Authen::SASL 2.18" and "Email::Sender::Transport::SMTP 2.601" into Koha usage. At the moment, Koha's supported OSes don't have the required versions for these modules, so the Koha community would need to package them. If we move forward, this will probably be necessary anyway for support for older Koha releases on older OSes. -- libauthen-sasl-perl bullseye (oldoldstable) (perl): Authen::SASL - SASL Authentication framework 2.1600-1.1: all bookworm (oldstable) (perl): Authen::SASL - SASL Authentication framework 2.1600-3: all trixie (stable) (perl): Authen::SASL - SASL Authentication framework 2.1700-1: all forky (testing) (perl): Authen::SASL - SASL Authentication framework 2.1900-1: all sid (unstable) (perl): Authen::SASL - SASL Authentication framework 2.1900-1: all Package libemail-sender-perl bullseye (oldoldstable) (perl): Perl module for sending email 1.300035-1: all bookworm (oldstable) (perl): Perl module for sending email 2.600-1: all trixie (stable) (perl): Perl module for sending email 2.601-1: all forky (testing) (perl): Perl module for sending email 2.601-1: all sid (unstable) (perl): Perl module for sending email 2.601-1: all -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #27 from David Cook <dcook@prosentient.com.au> --- Does that help? I'm not sure how many resources I myself can dedicate to this, especially as I think we only have 1 library that uses Microsoft email services, but I've done heaps of research on this topic, so I'm happy to do things like testing and advising. And like I said... ultimately no one can do anything unless Koha has the necessary versions of Authen::SASL and Email::Sender::Transport::SMTP, so that's really the first step to get the ball rolling. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #29 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #28)

Ok, so I did a little sort of standalone proof-of-concept within koha-testing-docker...

The test.pl script is simple enough. Here are the key parts: my $sasl = Authen::SASL->new( mechanism => 'XOAUTH2', callback => { user => $gmail_user, pass => $access_token, }, ); my $transport = Email::Sender::Transport::SMTP->new({ host => 'smtp.gmail.com', port => 587, ssl => 'starttls', sasl_authenticator => $sasl, timeout => 60, debug => 1, }); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #31 from David Cook <dcook@prosentient.com.au> --- Also, if this information is stored in the database (and I suspect it would) we need to keep in mind that the SQL Reports will be able to retrieve this information. that said, we could update Koha/Report.pm to hide certain columns. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #32 from David Cook <dcook@prosentient.com.au> --- Ok dokie... so I have tried out the sasl-xoauth2 plugin which is developed at https://github.com/tarickb/sasl-xoauth2 I followed the instructions on the README.md in the Github repo. I am using Ubuntu and I installed from the sasl-xoauth2 PPA. I tested using a Gmail account and a pre-existing Google project that I had from previous XOAUTH2 efforts. It took a lot of trial and error because the instructions weren't perfect for when a chroot is used in postfix, but that's OK. I figured it out, and I'm going to send a PR to update the documentation. Oh... another thing. I didn't want to run sasl-xoauth2 on my workstation, so sasl-xoauth2-tool didn't work for me. Instead, I used the google_oauth_bootstrap.pl script I had in KTD. So maybe I should polish that script up a bit and add it as a patch here to help people a bit... -- I don't think the sasl-xoauth2 has any functionality for periodically refreshing tokens. I think it just relies on refreshing expired access tokens at send time, and banking that you send email regularly before the refresh token expires... but I'm not 100% certain. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #34 from David Cook <dcook@prosentient.com.au> --- Created attachment 191851 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191851&action=edit Bug 38338: Add script to help bootstrap xoauth2 email tokens This change adds a CLI script which can be used to get an initial access token and refresh token for an OAuth2 account to use for XOAUTH2. Test plan: 0. Apply the patch 1. Create an "oauth2.json" file containing a client_id, client_secret, scope, redirect_uri, auth_endpoint, and token_endpoint 2. Run the script using "--conf oauth2.json" and follow the prompts to get an access token and refresh token -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #36 from David Cook <dcook@prosentient.com.au> --- I'm not saying that we should include this bootstrap script in Koha as is. Rather, it's just a useful script that people might want to use while they're experimenting. Maybe I should've included my test.pl script too although it needs some other stuff too... Maybe I could add the whole poc as a patch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Saiful Amin <saiful@semanticconsulting.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |saiful@semanticconsulting.c | |om -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #39 from David Cook <dcook@prosentient.com.au> --- I'm planning on implementing sasl-xoauth2 using Microsoft on a live site in the near future. I think it will work well because it's a whole of server solution. By the way, Microsoft have updated their timelines again: https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-sm... So now there are no changes for existing Microsoft tenants in 2026. New tenants at the end of December 2026 will have basic auth disabled by default, and admins will be able to re-enable it. New tenants created after December 2026 won't have basic auth available, and second half of 2027 will see total removal of SMTP basic auth. So... there's a lot more breathing room now. I'm hoping to prove the sasl-xoauth2 Postfix based solution in a real world context soon. And I'm happy to help people with a Perl based solution, although I probably won't be coding it myself at this stage. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #41 from Olivier Hubert <olivier.hubert@inlibro.com> --- (In reply to David Cook from comment #37)

Jumping back to Perl... it looks like Email::Sender::Transport::SMTP and Email::Sender::Transport::SMTP::Persistent connect to the SMTP server only at the time they're sending the email... so you can't test the authentication until sending time...

If there is an auth error, we'd have to create a new transport and re-try with the new transport...

I'm not sure what you mean by having to recreate the transport, but I'm not the most familiar with the way Koha sends email. I thought that having the token created (and refreshed) separately would ensure that the token we have is always valid. Given that we should be reasonably sure that the token is good, why would a transport error necessitate the creation of a new transport? By the way, I was able to get a working version of a test script sending, but as mentioned on Mattermost, the configuration of the instance required that we use the URL https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/token along with the "https://outlook.office365.com/.default" scope (instead of something like "https://outlook.office365.com/SMTP.Send"). I think the different configuration in Azure instances will increase the variability of scenarios. Certainly compared to using Gmail anyway. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #43 from David Cook <dcook@prosentient.com.au> --- Also... I just realised that Microsoft have a client credentials grant flow: https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols... That would make things much much easier... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #45 from Olivier Hubert <olivier.hubert@inlibro.com> --- As stated by the RFC (https://www.rfc-editor.org/rfc/rfc6749#section-1.3.4): "Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) [...]" I think this is one of those cases so we should be able to use client credentials. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #47 from David Cook <dcook@prosentient.com.au> --- Unfortunately, while the client credentials grant is available for Microsoft, I don't think it's available for Google/Gmail. For those, they seem to use the authorization grant, which makes it more painful. So when setting up a XOAUTH2 client in Koha, I think we'd need to specify the grant type so that the code can do different things for different setups? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #49 from Olivier Hubert <olivier.hubert@inlibro.com> --- Created attachment 195697 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195697&action=edit Bug 38338: this patch lays the groundwork for native XOAUTH2 authentication support in Koha. It also implements the CCG XOAUTH2 flow. Important: it currently only supports the CCG flow. The other flows need to be implemented and tested. Test plan 0. Determine which email address will be receiving the test email. 1. Install the required dependencies if they are not already installed: 1.1. sudo cpanm Authen::SASL@2.1800 1.2. sudo cpanm Email::Sender@2.601 2. Apply the patch. 3. Update the database, by running the following command in the Koha git directory: 3.1. perl installer/data/mysql/updatedatabase.pl 4. Restart Plack, if Plack is running. 5. In the Intranet, navigate to the SMTP Servers page. For example, the link is available in the Administration page, under the "Additional parameters" section. 6. Create or update an SMTP server to use XOAUTH2 authentication. Specifically fill the following fields: 6.1. User name: use the email address that will be used to generate the OAUTH token. 6.2. Authentication type: OAUTH 6.3. OAUTH server type: Client Credentials Grant 6.4. Token URL: the complete URL (with Tenant ID if needed) to the /token endpoint for the server. 6.5. Scope: the complete scope that will be used to obtain the token. 6.6. Client ID: the client ID that will be used to obtain the token. 6.7. Client secret: the client secret that will be used to obtain the token. 6.8. Adapt the other parameters according to your SMTP server's specifications. 7. Update system preferences to send from the email specified in step 6.1. 7.1. In particular, KohaAdminEmailAddress should be using that email. 7.2. Ensure that SendAllEmailsTo is configured to the email address that is used for the test (step 0). 8. Open the profile of any patron, for example: Henry Acevedo (23529000035676). 9. Edit and save the profile to add any email address as a primary email, if there isn't one already. 10. From the "Plus" menu, select the option to "Send welcome notice". 11. From the command line, run the following command in the Koha git directory: 11.1. perl ./misc/cronjobs/process_message_queue.pl 12. Check the email account used at step 0 to confirm that the email was received correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com --- Comment #53 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- It seems Keycloak 26.2 you can simulate SMTP with XOAUTH2? https://www.keycloak.org/2025/05/send-mails-xoauth-26-2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #55 from Thomas Klausner <domm@plix.at> --- (In reply to Caroline Cyr La Rose from comment #53)

It seems Keycloak 26.2 you can simulate SMTP with XOAUTH2?

https://www.keycloak.org/2025/05/send-mails-xoauth-26-2

No, this describes how to XOAUTH when sending mails with keycloak. So in that case keycloak is in the same position as koha: the need to send mails via MS/Google and XOAUTH. (and it seems they had quite some problems...) This post does NOT describe how to use keycloak to test XOAUTH2 :-( -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #57 from David Cook <dcook@prosentient.com.au> --- (In reply to Caroline Cyr La Rose from comment #54)

So we have a bit of time. But anyone who can get their hands on a tenant ID is welcome to test!

Well tenant ID and client credentials. I have someone interested but it's taking a long time for their IT to get the client credentials to us. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #59 from David Cook <dcook@prosentient.com.au> --- (In reply to Olivier Hubert from comment #58)

(In reply to Tomás Cohen Arazi (tcohen) from comment #52)

...

I always felt we should implement an `Email::Sender::Transport::XOAUTH` module, maybe based on https://metacpan.org/dist/Amazon-SES/view/lib/Email/Sender/Transport/SES.pm

Do you mean that we should put all XOAUTH-related code in its own transport, and simply alternate between the Permanent transport and XOAUTH transport at send time, depending on the SMTP::Server configuration?

The transport is already stored on a per library basis, so it's not so much swapping between Persistent and XOAUTH, as just using the right transport for the right library.

The problem with this is that some XOAUTH flows require a web-based authentication. This needs to be done while configuring the SMTP server, as it cannot be done when sending emails. It's why I decided to integrate everything into SMTP::Server. If you have an idea on how to allow that authentication to work when setting up the server yet decouple XOAUTH from SMTP::Server, I am willing to try it.

So you could have an auth type in the Koha::SMTP::Server, and then in Koha::SMTP::Server->transport() you could choose the appropriate transport, and in the transport constructor you could check if the access token is expired. If it is, get a new one. With authorization_code grant, you'd have access to a refresh token, so you'd just use that for fetching a new access token. And if that fails, then you just have to fail overall anyway. The web-based authentication is a bit of a pain, but it shouldn't be a big drama. In practice, refresh tokens should last long enough on an active server, but we could put together a cronjob to fetch a new access token every night. So the initial setup of authentication_code grant is annoying but once it's set up then it should work fairly similarly to the client credentials grant at send time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #61 from David Cook <dcook@prosentient.com.au> --- (In reply to Olivier Hubert from comment #60)

Yes, I agree that all this is possible and the way to go. The problem I see is that the SMTP server configuration, and so eventually the web authentication, is / will be done through smtp_server.pl. If we allow that page to configure the Transport and not the SMTP::Server instance, then we are forever coupling Transport::OAUTH and SMTP::Server. In that case, I don't really see the need to have a separate entity for Transport::OAUTH if it needs to always work in conjunction with SMTP::Server.

I think you have summed up pretty well how will work, with a cronjob for the refresh token, etc. I'm just curious as to why we need two separate classes if we're linking them so deeply. I might be trying to solve a non-issue. I'm not sure how the relationship between different classes is managed.

Honestly, I think it's "six of one and half a dozen of another". Since it's all backend, I don't think it really matters, as we can always change things if necessary. I think Tomas's transport idea would be cleaner, but it's not critical I think. For now, I think the most important thing is just getting something that works. The perfect is the enemy of the good. I don't know why I'm so full of English idioms today. I'm going to query one of my libraries to see how they're going getting some credentials, so I can test this out. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #63 from Olivier Hubert <olivier.hubert@inlibro.com> --- (In reply to David Cook from comment #62)

Olivier: Do you have any thoughts about where to store the refresh_token when adding the authorization code grant?

Yes. I have updated the structure of the oauth_access_tokens table, and added a field called `type`. So now a stored OAUTH token can be either for the auth process, for SMTP OAUTH or a refresh token. I went with this approach because it seemed redundant to create another table while we have one named oauth_access_tokens. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #65 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #52)

I always felt we should implement an `Email::Sender::Transport::XOAUTH` module, maybe based on https://metacpan.org/dist/Amazon-SES/view/lib/Email/Sender/Transport/SES.pm

Actually that model would work well especially if we did want to support SES or Microsoft Graph as per bug 42179 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #67 from David Liddle <david_liddle@sil.org> --- (In reply to David Cook from comment #66)

Maybe we should actually look at rebranding "SMTP servers" as "Email transports"? Of course, SMTP with basic (ie plain/login) auth would be the most popular transport at the moment, but we could have SMTP with XOAUTH2, Microsoft Graph (which uses OAuth2 for auth), AWS SES, etc.

On bug 42179, Owen suggested making it pluggable, which is also a very feasible option.

Just a comment: While "transports" is technically accurate, it will not convey meaning to the majority of people using it. Something along the lines of "Outgoing email" may be more readily understood. It could be appended with "settings" or "services", but it should be clear. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Blou <philippe.blouin@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philippe.blouin@inlibro.com --- Comment #69 from Blou <philippe.blouin@inlibro.com> --- Hello David, (In reply to David Cook from comment #61)

For now, I think the most important thing is just getting something that works. The perfect is the enemy of the good. I

(then)

we should actually look at rebranding "SMTP servers" as "Email transports"?

It's not a contradiction, but to me it lacks some urgency. This patch needs to go into 26.05. 26.11 will be too late for MS's deadline. Terminology and presentation are very much secundary and can be improved on later. Not that cosmetic changes cannot be done right now, but the conversation should be about getting this through QA and release asap. The fact that it's listed as Low and Enhancement is wrong, and it should be changed to High priority. And Blocker. Unless someone can change MS's mind again and again? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Olivier Hubert <olivier.hubert@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #71 from Olivier Hubert <olivier.hubert@inlibro.com> --- Important: currently only the CCG flow is supported. The other flows need to be implemented and tested. Test plan 0. Determine which email address will be receiving the test email. 1. Install the required dependencies if they are not already installed: 1.1. sudo cpanm Authen::SASL@2.1800 1.2. sudo cpanm Email::Sender@2.601 2. Apply the patch. 3. Update the database, by running the following command in the Koha git directory: 3.1. perl installer/data/mysql/updatedatabase.pl 3.2. perl build-resources.PL 4. Restart Plack, if Plack is running. 5. In the Intranet, navigate to the SMTP Servers page. For example, the link is available in the Administration page, under the "Additional parameters" section. 6. Create or update an SMTP server to use XOAUTH2 authentication. Specifically fill the following fields: 6.1. User name: use the email address that will be used to generate the OAUTH token. 6.2. Authentication type: OAUTH 6.3. OAUTH server type: Client Credentials Grant 6.4. Token URL: the complete URL (with Tenant ID if needed) to the /token endpoint for the server. 6.5. Scope: the complete scope that will be used to obtain the token. 6.6. Client ID: the client ID that will be used to obtain the token. 6.7. Client secret: the client secret that will be used to obtain the token. 6.8. Adapt the other parameters according to your SMTP server's specifications. 7. Update system preferences to send from the email specified in step 6.1. 7.1. In particular, KohaAdminEmailAddress should be using that email. 7.2. Ensure that SendAllEmailsTo is configured to the email address that is used for the test (step 0). 8. Open the profile of any patron, for example: Henry Acevedo (23529000035676). 9. Edit and save the profile to add any email address as a primary email, if there isn't one already. 10. From the "Plus" menu, select the option to "Send welcome notice". 11. From the command line, run the following command in the Koha git directory: 11.1. perl ./misc/cronjobs/process_message_queue.pl 12. Check the email account used at step 0 to confirm that the email was received correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #73 from David Cook <dcook@prosentient.com.au> --- (In reply to Blou from comment #69)

This patch needs to go into 26.05. 26.11 will be too late for MS's deadline. Terminology and presentation are very much secundary and can be improved on later. Not that cosmetic changes cannot be done right now, but the conversation should be about getting this through QA and release asap.

It's getting pretty late in the process, but I've been talking about this issue for over a year so I get wanting to get it into Koha ;).

The fact that it's listed as Low and Enhancement is wrong, and it should be changed to High priority. And Blocker. Unless someone can change MS's mind again and again?

Feel free to update those. I wouldn't be surprised if Microsoft changes their mind again haha. -- But in any case... yes I would like to get this functionality into Koha. We just need to make sure that we're doing it in a way that works for everyone. To that end... I still haven't received any credentials for testing this, unfortunately. If InLibro were able to provide some test credentials, it would go a very long way to moving this along. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #75 from David Cook <dcook@prosentient.com.au> --- (In reply to Thomas Klausner from comment #70)

While I agree that this patch should be in Koha ASAP (and I volunteer to QA it, I might even have access to a MS Entra Test env from another project), there exists a workaround: You can use a tool like https://github.com/simonrob/email-oauth2-proxy which provides a local SMTP server (which Koha can talk to) and forwards the mails via XOAUTH to the actual mail provider.

I think we're set to miss the window for 26.05, and it is unfortunate, but I think it's because there are alternatives available, there are barriers to testing with Microsoft, and it's just not a priority for enough people yet. I know for me security bugs take a higher priority than other bugs, especially enhancements/new features. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #77 from David Cook <dcook@prosentient.com.au> --- (Note one little bug: when you're editing a OAUTH server, the OAUTH server type will say "Not implemented yet" next to it even for "Client Credentials Grant". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #79 from David Cook <dcook@prosentient.com.au> --- Turns out it pays to read the instructions... https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols... The final step was to create a service principal and give it mailbox permissions for the particular account in question. I'd hunted and hunted for the UI to do this, but couldn't find it. The only way I could get it done was using "Exchange Online PowerShell" which is an extension module for regular Powershell that sits on your desktop. It's not great, especially if you work with multiple different systems I think. But... it worked. Just took a lot of effort. I am starting to come around to the idea of using the Microsoft Graph API (as Brian does on bug 42179) to be a much more user-friendly of setting up email integration with Microsoft. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #81 from David Cook <dcook@prosentient.com.au> --- Testing Olivier's work (with Brian Pichman's help) also gave me the confidence to write a patch for the Postfix plugin sasl-xoauth2: https://github.com/tarickb/sasl-xoauth2/pull/123 So that's cool :D -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #83 from David Cook <dcook@prosentient.com.au> --- So I started thinking... SASL is a framework that is supposed to decouple authentication mechanisms from application protocols... so really... surely we should be able to leverage it more. Starting in Debian 13 Trixie libauthen-sasl-xs-perl is available. Older versions of Debian have libauthen-sasl-cyrus-perl. Both of these should be able to interface with the libsasl2.so shared library, which would allow them to hook into sasl-xoauth2. So that would be another option, which would require far fewer changes to Koha. The only downside of sasl-xoauth2 so far has been the lack of responsiveness from its author. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42179 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #85 from David Cook <dcook@prosentient.com.au> --- After learning a lot about Microsoft and XOAUTH2, I think that these patches might be more complex than we need. I don't have much time available at the moment, but I could have a crack at this again at some point. Brian Pichman is also doing interesting things on Bug 42179. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #87 from David Cook <dcook@prosentient.com.au> --- I've actually created a simple SASL plugin for the XOAUTH2 mechanism in C: https://github.com/minusdavid/simple-sasl-xoauth2 I still need to improve the documentation, and I've got a bit more polishing I want to do, but it's a functional C equivalent of Authen::SASL::Perl::XOAUTH2, and I've tested it in Perl using Authen::SASL::XS as well, which was good fun. In the past, I've tested C SASL plugins using Postfix, but now I can just use Authen::SASL::XS and Net::SMTP. I don't even have to send the email. I can just check that the authentication succeeds and then end the connection. Of course, that leads to the same issue we have here in Koha. While we have SASL plugins that can perform the SASL authentication, we need a provider for the plugins. -- For Postfix, my plan is to write a daemon that Postfix will call using a socketmap lookup, so a Perl or Golang daemon will create a Unix socket, Postfix will connect to that and send some query information, and the daemon will return the authentication credentials (including username and OAuth2 token). For Koha, we could build it in. Koha::SASL::Helpers or something. I've got an idea for this one... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #89 from David Cook <dcook@prosentient.com.au> --- So one of the problems with this work has been an inability for people to test it... But I've come up with a solution for that. The "dovecot/dovecot" Docker image provides a SMTP submission service which can be protected with XOAUTH2 authentication. Using https://github.com/minusdavid/simple-sasl-xoauth2 with Authen::SASL::XS, I have a little Perl script using Net::SMTP to send an SMTP auth request to that Dovecot submission service. I use Keycloak to generate the access token and Dovecot verifies the token against Keycloak. Net::SMTP>>> Net::SMTP(3.15) Net::SMTP>>> Net::Cmd(3.15) Net::SMTP>>> Exporter(5.77) Net::SMTP>>> IO::Socket::IP(0.4101) Net::SMTP>>> IO::Socket(1.52) Net::SMTP>>> IO::Handle(1.52) Net::SMTP=GLOB(0x55d97900e218)<<< 220 9e027f6ee005 Dovecot ready. Net::SMTP=GLOB(0x55d97900e218)>>> EHLO localhost.localdomain Net::SMTP=GLOB(0x55d97900e218)<<< 250-9e027f6ee005 Net::SMTP=GLOB(0x55d97900e218)<<< 250-8BITMIME Net::SMTP=GLOB(0x55d97900e218)<<< 250-AUTH OAUTHBEARER XOAUTH2 Net::SMTP=GLOB(0x55d97900e218)<<< 250-SMTPUTF8 Net::SMTP=GLOB(0x55d97900e218)<<< 250-BURL imap Net::SMTP=GLOB(0x55d97900e218)<<< 250-CHUNKING Net::SMTP=GLOB(0x55d97900e218)<<< 250-ENHANCEDSTATUSCODES Net::SMTP=GLOB(0x55d97900e218)<<< 250-SIZE Net::SMTP=GLOB(0x55d97900e218)<<< 250 PIPELINING Net::SMTP=GLOB(0x55d97900e218)>>> AUTH XOAUTH2 dXNlcj10ZXN0AWF1dGg9QmVhcmVyIGV5SmhiR2NpT2lKRlV6STFOaUlzSW5SNWNDSWdPaUFpU2xkVUlpd2lhMmxrSWlBNklDSXRZMHc1WWxGcllUWmxNWHB6VkRobWNERkRkblZ3WDJ4WVRuRk5kekpoTlhWcE5XNVdabXRUVjBjMEluMC5leUpsZUhBaU9qRTNPREUwTXpVek16Z3NJbWxoZENJNk1UYzRNVFF6TlRBek9Dd2lhblJwSWpvaWIyNXlkR0ZqT2prek5ETTVPVFkyTFRkaU1XSXRNREl5TlMxak1XRTJMVEV6TXpVME56RTROR0kyTkNJc0ltbHpjeUk2SW1oMGRIQTZMeTlyWlhsamJHOWhhem80TURnd0wzSmxZV3h0Y3k5MFpYTjBJaXdpZEhsd0lqb2lRbVZoY21WeUlpd2lZWHB3SWpvaVpHOTJaV052ZENJc0luTnBaQ0k2SWtSVk1Hc3plbTVXYkhCWFJHMTBUakZHZG5oRVVUQkhMU0lzSW1Gc2JHOTNaV1F0YjNKcFoybHVjeUk2V3lJaVhTd2ljMk52Y0dVaU9pSnZjR1Z1YVdRZ2NISnZabWxzWlNCbGJXRnBiQ0lzSW1WdFlXbHNYM1psY21sbWFXVmtJanAwY25WbExDSnVZVzFsSWpvaVJtbHljM1FnVEdGemRDSXNJbkJ5WldabGNuSmxaRjkxYzJWeWJtRnRaU0k2SW5SbGMzUWlMQ0puYVhabGJsOXVZVzFsSWpvaVJtbHljM1FpTENKbVlXMXBiSGxmYm1GdFpTSTZJa3hoYzNRaUxDSmxiV0ZwYkNJNkluUmxjM1JBZEdWemRDNTBaWE4wSW4wLnRSSDkxeXF0YnZvdU1RVlpNbzI0QXBrWFdJdjhpTFJOX25wNEV3YXBQRlRNNlJTT2RiYi1UVkFPNWFwRkhyR1VjbDFkMU40Qzd5OGdYUWRTd25aUk1BAQE= Net::SMTP=GLOB(0x55d97900e218)<<< 235 2.7.0 Logged in. Net::SMTP=GLOB(0x55d97900e218)>>> QUIT Net::SMTP=GLOB(0x55d97900e218)<<< 221 2.0.0 Bye Technically, we don't actually have to send the email. We can just send the AUTH header and then quit, but we can prove that the authentication was successful. -- I'll look at streamlining and polishing things up further, but I think this is a good way of testing XOAUTH2 work without requiring a Google or Microsoft account. -- One word of warning. Net::SMTP doesn't seem to handle sending long SMTP AUTH messages, and Dovecot will refuse AUTH lines longer than 1000 characters. I had to remove some claims from the JWT and use a shorter signing algorithm to get Dovecot and NET::SMTP to play nice. But that's a Net::SMTP issue I reckon. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #91 from David Cook <dcook@prosentient.com.au> --- When it comes to adding a XOAUTH2 SASL plugin to Postfix, the idea of using a socketmap to connect to a token service seems logical. But when it comes to Koha... we already have so many daemons. Plus, we might want to offer interactive logins for things like Google that don't have client credential grants like Microsoft. But then that's where handling this with plugins seems quite interesting. The "pass" callback in Authen::SASL can be a coderef. Calling plugins makes sense. That said, you could argue that this should be core functionality, so it doesn't make sense to use plugins. But because of the variable options for how to get the token from different providers... plugins also make a lot of sense. You just choose the plugin you want to go with. Since this is still fairly new territory... maybe plugins do make the most sense. Once there are tried and true plugins, then we could bring them into Koha proper. I think that's the way I'm leaning the most... And it would mean the initial changes needed would be minimal. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #93 from David Cook <dcook@prosentient.com.au> --- I'm pretty content with the simple-sasl-xoauth2 plugin now, so I've posted that on Github and added some extensive documentation on how to test it using Net::SMTP (with Dovecot and Keycloak) or Postfix (with Microsoft). https://github.com/minusdavid/simple-sasl-xoauth2/wiki -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=29587 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 Chris Slone <cslone@camdencountylibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cslone@camdencountylibrary. | |org --- Comment #96 from Chris Slone <cslone@camdencountylibrary.org> --- Thanks for the work on this. We were affected by the change in MS's SMTP requirements and are sending via AWS and having way more delivery issues. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42870 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #99 from David Cook <dcook@prosentient.com.au> --- I think that this bug report (bug 38338) is still valid, but for now I'm going to focus on bug 42870 and creating a Koha Plugin which handles the XOAUTH2 SMTP authentication. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #100 from Chris Slone <cslone@camdencountylibrary.org> --- I'll try to get this going on my test box, but won't be able to do so until after next week. Thanks again for all the work! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 --- Comment #102 from David Cook <dcook@prosentient.com.au> --- I've submitted a pull request for koha-testing-docker to add a Dovecot container integrated with Keycloak for testing XOAUTH2. Instructions are on the PR: https://gitlab.com/koha-community/koha-testing-docker/-/merge_requests/606 They're based off the work I did testing the C SASL plugin "simple-sasl-xoauth2" https://github.com/minusdavid/simple-sasl-xoauth2/wiki#dovecot-smtp-submissi... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #104 from David Cook <dcook@prosentient.com.au> --- Looking back on the comments and history... I'm not sure why I marked this as "Failed QA". I think maybe I was going to provide an alternate option but then decided it would be better to open a different ticket, so that InLibro's work could continue here. I don't think the posted patches are the right way to go. I think that they try to do too much and in a suboptimal way. But I don't want to be a blocker either if others thought this was an optimal way to go. I think bug 42870 is going to be a better route overall because it expands the possibilities with a very minimal change to the status quo. So there's really no risk with it as far as changes go. There's also no reason why the 2 bugs can't go together. As Tomas suggested earlier, bug 38338 could be implemented as a Email::Sender::Transport::SMTP module, and it could stack on top of bug 42870. -- You are receiving this mail because: You are watching all bug changes.