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.)