Re: After Gmail, Microsoft too...
Matthias Andree <[email protected]> Sat, 22 Oct 2022 13:50:45 +0200
| Newsgroups | gmane.mail.getmail.user |
|---|---|
| Message-ID | <[email protected]> |
Am 22.10.22 um 02:39 schrieb Charles Cazabon: > Marc Lobelle <[email protected]> wrote: >> I understand what to do with Gmail. However , my institutional mail >> (University of Louvain, Belgium) has been outsourced to Microsoft, and >> Microsoft too changed its authentification rules: from yesterday mornin= g on, >> my getmail cannot any more fetch my mail @uclouvain.be. > Okay, that's a pain. They've turned off app passwords, too - is that > Microsoft doing so for all users/clients, or is it just a policy set by = your > university? > >> If you used to fetch your mail programmatically from your own app, >> this remains possible but the app will have to support OAuth and to >> be registered on the Azure portal. UCL admin consent may then be >> required and may take up to 1-2 weeks for approval. > It's possible to integrate getmail with a service that uses OAUTH2; see = the > Gmail integration as an example. > > But this "register your app with the Azure portal" is trickier. The doc= page > I found is here: > https://learn.microsoft.com/en-us/azure/active-directory/develop/quickst= art-register-app > > ... and that makes it sound like *I* have to get an Azure account and re= gister > getmail as an application? That doesn't make sense to me. Maybe it mea= ns the > more obvious thing, which is that someone in your AD domain needs to reg= ister > it as an allowed app, not sure. > > Because if it requires me to get an Azure account, you're unfortunately = out of > luck. Not gonna happen. Yes, and write privacy/data protection policies down beforehand and whatnot (which is viable, but not sufficient) and jumping more hoops. We all have Internet protocols and standards, including standards that avoid clear-text passwords for authentication, or deferring authentication to third parties---and for a standard-compliant mail server the exact maker and type of (well-behaved) client must not matter, and in Marc's case it *STILL* appears to be at the mercy of UCL admins from the cited reply above. (And please nobody think they were better off with fetchmail: same situation. Same hoops. Same decision about registration and similar slippery slopes. I would be happy to add OAuth2 code if *THAT* were the actual obstacle, but it is not, the providers' policy decisions and other con- and restrictions are. To me it makes no sense to invest into technical means that leave the policy issues unsolved, such as registration or app-based permissions.)