https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42179
David Cook <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from David Cook <[email protected]> --- (In reply to Brian Pichman from comment #4) > I think, ultimately, this would need to be put within the SMTP space -- > since Microsoft is no longer allowing SMTP connections to send email. I'm > open to other ideas, but the recommended path is using Microsoft Graph or > OAuth -- both of which require a decent lift on IT teams to set up and use > to work with Koha. I think that you mean SMTP Plain/Login auth. When using XOAuth2 for auth, it's still SMTP. Microsoft is definitely still using SMTP connections to send email. > The method I proposed provides a one-click button for library staff to > email. I'm curious to hear more on this one. It seems to me that both the API and SMTP XOAUTH2 would need the same app registration in Microsoft Entra ID in order to work. Indeed in the Koha::SMTP::Server change, using the Microsoft Graph API is also using the OAuth client credentials grant for the authentication step (just like Olivier's code in bug 38338). > In other words, SMTP is dying from providers like Microsoft for sending, and > they want to force people to use APIs (Microsoft Graph) or OAuth. I > wouldn't be surprised if AWS follows the same path. Sending from the AWS > SES API is much faster and more reliable than via the SMTP Route. > https://stackoverflow.com/questions/30721611/amazon-simple-email-service-ses- > should-i-use-smtp-interface-or-ses-api. There's a decent discussion here I'd say this is a mischaracterisation of the situation. SMTP isn't going anywhere. But... I think using APIs to send emails is another good option for sure. > In talking with others, this may be a larger discussion too -- as calling > this SMTP Delivery is a bit incorrect and probably needs to be renamed as > Message Delivery or something more standard ... Yeah, I think definitely more thought and discussion required. At the moment, we link libraries to SMTP servers, but yeah it would probably need a rebrand. I like the overall idea though. I think Owen makes a good point about making it pluggable as well. When it comes to APIs, different providers (like Microsoft, AWS, others) are likely to have different APIs. Note also that someone with report permissions could easily lookup the Microsoft365GraphClientId and Microsoft365GraphClientSecret. I don't think we have a good way of storing secrets in system preferences at the moment. (While we do store secrets in them, I think moving forward we always want to be striving to do better.) Another note on that... I notice a new "svc/api_delivery/callback" file, but we're not adding any new files to the "svc" API. -- Going back to the AWS SES API... take a look at https://metacpan.org/pod/Email::Sender::Transport::SES. Tomas actually thought about doing the same thing with XOAUTH2: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38338#c52 Perhaps smtp_servers should be "email_transports". Hmm... -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
