Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Matthias A. <mat...@gm...>]

Am 24.09.24 um 20:07 schrieb Ian! D. Allen:
> On Tue, Sep 24, 2024 at 10:21:06AM -0400, Matthias Andree wrote:
> [...]
>> Sorry if this doesn't fit your bill. Talk to those that change
>> authentication schemes that cost you your freedom, not to providers of
>> free software where you enjoy and retain free choice liberties.
> Yes, it is precisely because I use a GNU/Linux desktop exclusively
> that I need a way to fetch messages sent to my legacy accounts on these
> proprietary services that I don't actually use.

App passwords are the sidestep or workaround while they last. More
towards the very end of this message.

Yes. I am sorry for you. But the authors of free and open source
software cannot fix that. You are talking to the wrong people.
Either you manage to change how big business works (quite unlikely), or
you convince your local members of parliament that you need regulatory
means (meaning legislation) to enforce non-discriminatory access to your
e-mail.

Fetchmail is, as you are, a victim of the policy change of big
corporations that choose or chose to not only change the authentication
scheme (which fetchmail could and can do something about).

Internet has always been about "let's adhere to communication protocols
and then we'll be exchanging data". Now some corporations chose to
depart from that point. That's painful. That change for OAUTH2, on
Microsoft and Google's end, however is a trap, and it *also* comes with
a requirement to have the software reviewed, because they will want to
review the software, its privacy policy, its presentation, and whatnot.
That review costs a lot of effort, in some cases, a lot of money (on the
order of an annual gross salary of a software engineer), and that is a
real road block, and also political change.

We never needed that on the Internet before. We looked at IETF RFCs or
standards, wrote our software such that it adhered sufficiently closely
to those protocols, and were allowed to fetch your mail.
Now with OAUTH2 on Google's and Microsoft's end, that no longer
suffices. Only after going through their review labyrinth, they will
give the author of that software a token that identifies the software
and is part of the OAUTH2 schemes these providers require from client
software. Under whatever arbitrary conditions.

Even if that software or, in newspeak, "app" review, were free of
charge, it can never be free of effort for its author, yours truly.
I need to describe the software, put up privacy policies (of course you
configure or enter your password so it's sent to fetch e-mail), put up
review reports, and what not.

If I make that exception once or twice, that opens the floodgate and I
will be drowned in requests to hand fetchmail in for review here, there,
and everywhere.
And I expect every service to have their own review check-lists and most
will have to be done individually.

Then we also need to discuss with distributors to update fetchmail to
support the "app" tokens we receive to keep things going.  We've seen
the fights distributors and Mozilla have had about the quick Firefox
update schedule.

> In keeping with the robustness principle, to paraphrase Jon Postel, I
> try to be "liberal in what services I fetch email from, and conservative
> in using only free/libre software to send email".
>
> I don't own a cell phone, so using phone "apps" isn't an option.
At some point in time, someone started calling desktop or command-line
application software "apps" irrespective that this continues to run on
your GNU/Linux PC of old. fetchmail is an "app" in that sense. I would
not call it that, but well.

The gist of those specific passwords (however qualified) is: Google and
Microsoft, AFAICT, have been offering and continue to do so, a way that
you - under some conditions - can obtain or configure an
application-specific, "app-specific" or I would usually call it
some-or-our-services specific password, to let you fetch your e-mail.  
Those conditions they impose AFAICT have been "you must switch your
account to two-factor authentication". The idea is that the power of
this specific password is limited to fetching and/or sending e-mail and
does not expose your entire Google or Microsoft account. There is some
sense in that: That same password that gives you e-mail is no longer
good to look at your collaborative documents, at your maps or browsing
history, or whatnot.

I do like the idea of limiting the attack surface or power of an exposed
password, but we did not have to invent another hundreds-of-pages
standard which does not only describe authentication scheme with lots of
half-baked and quarter-implemented use patterns for that purpose.


So bottom line: if your mail service provider permits setting specific
passwords, app-specific, application-specific, service-specific, and you
can abide by the rules you need to obtain or set these, go for them, or
else I am afraid you will have to switch service provider sooner or later.

Hope that helps
Matthias