Re: [Fetchmail-users] Planned Google authentication changes

[Héctor A. <hab...@gm...>]

>
> > IIRC I had to enable "use less secure" in gmail for it to work with
> > fetchmail.  Perhaps  I was just in a hurry then and lazy now?
> >
> Yes, that switch used to be there. Not sure how long it will last.


 I just read in my Google Settings (Security section) that the "Less secure
app access" will no longer be available starting on May 30th, 2022. Does
this mean that my only option to continue using Fetchmail to read emails
sent to my GMail Inbox is to forward them to another email service?

Or just go find a service that does not scan all your email and forces
> YOU to change.
>

Is there any Fetchmail friendly email service that you or anyone in this
list can recommend? I think I'm having 2 different problems now: One is
Oath2 (which to me it looks like an inconvenient trend, but I read it can
be fixed through patches) and the other problem is that soon no "Less
secure app access" will be allowed in Google anymore.

Thank you in advance for any orientation.

Regards,

Hector.

El vie, 4 mar 2022 a las 15:16, Matthias Andree (<mat...@gm...>)
escribió:

> Am 04.03.22 um 17:36 schrieb Andrew C Aitchison:
> > On Fri, 4 Mar 2022, joe a wrote:
> >
> >> Received the email below from Google (links deleted).   What does
> >> this mean for Fetchmail?  A quick search turned up "not much".
> >
> > Fetchmail 7, which is still in alpha (but, I believe, distributed with
> > Gentoo Linux) has OAuth 2.0 support built in.
> >
> > Fetchmail 6 has third party patches which add (X)OAuth 2.0 support
> >   http://mmogilvi.users.sourceforge.net/software/oauthbearer.html
> > - patches for the latest releases are also available on my website:
> >   https://www.aitchison.me.uk/fetchmail/
> > (I am about to improve the landing page).
> >
> > With fetchmail 7 in alpha and fetchmail 6.5 in beta,
> > it would be useful to see a roadmap of future fetchmail development.
>
> There is no such thing as a roadmap if you are looking for planned
> release dates.
> This is currently a volunteer spare-time project, not a
> commercially-organized one, and apparently some big tech are trying to
> squeeze out the small ones. More below.
>
> Fetchmail 6.5 should arrive on a scope of months though, albeit without
> OAuth2. It will cut off support for systems not compliant to C99 and/or
> the Single Unix Specification v3.
>
> For fetchmail 7 the release date "depends" on circumstances I have not
> planned yet. After 6.5.
>
>
> I am quite unhappy to put it politely that the Big Tech badmouth (not to
> say libel) apps using established password logins through TLS and that
> offer TLS certificates and others means as "less secure apps". What do
> they think they are doing with asking browser-like client feature sets
> to obtaining a ticket for logging into another system? How many security
> fixes are needed in browsers for each and every release again, to be
> sure nobody steals that token through some phishing or cracking?
>
> How many hoops do open source application users or maintainers need to
> jump through to possibly or then again not register their app for OAuth?
> And then again for the next service? What are the policies, check
> Android's FairEmail.
> https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-content-faq147
> -- It's not a hard obstacle, but still the process would be at Google or
> some other Big Tech's discretion and however else believes they need to
> exert control over what client is permitted to get OAuth for their
> flavor of the service as well.
>
> How many services would I, or we counting users in, have to register
> fetchmail with? This just does not scale to do centrally. As maintainer,
> you cannot guarantee a quality of service if aiming at a moving target.
>
> Next day they change their login or come up with another revision of the
> hundreds-of-pages OAuth2 framework and implementation sepcifications
> scattered thorugh many IETF docs, or change whatever detail they forgot
> to document but that Thunderbird just did ever so slightly differently
> that it did not trip up their tester. And this is just for
> authentication. How crazy is that.
>
>
> Please, someone using fetchmail with Google or Microsoft or other
> services that want to shove OAuth down your throats, please volunteer to
> search the documentation for your service and see if it is possible to
> set *app-specific passwords* instead.
>
> Once upon a time, this used to work for some service I did use at that
> time.
> The Big Techs will likely run stats to see when is a safe time to flip
> switches (and which ones) in order not to drive too many users away.
>
> > IIRC I had to enable "use less secure" in gmail for it to work with
> > fetchmail.  Perhaps  I was just in a hurry then and lazy now?
> >
> Yes, that switch used to be there. Not sure how long it will last.
>
> Or just go find a service that does not scan all your email and forces
> YOU to change.
>
>
> > X(O)Auth 2.0 authentication *is* more complex than traditional methods
> > and documentation could be better.
>
> And that is the crucial point. If you want a security sensitive
> component designed securely, you don't overengineer it with a dozen of
> specs dozens of pages each, but something simple, reproducible,
> auditable that is self-contained in one central spec, possibly relying
> on another set of well-established building blocks for elementary
> functions such as crypto. And then you don't offer half of the
> interfaces you've documented. If you fail to document that properly,
> that entire cardhouse will collapse.
>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>