<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Fetchmail and Google&#8217;s OAuth 2.0 enforcement</title>
	<atom:link href="http://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/feed/" rel="self" type="application/rss+xml" />
	<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/</link>
	<description>Anything I found worthy to write down.</description>
	<lastBuildDate>Thu, 26 Mar 2026 13:15:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: Dave</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1827</link>
		<dc:creator>Dave</dc:creator>
		<pubDate>Sun, 16 Mar 2025 01:36:57 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1827</guid>
		<description>Other than the requirement to use the Google &#039;random&#039; generated App Password which is only 16 characters and lower-case alpha it has worked great for years in my fetchmail SSL enabled configs.  

So despite all the FUD, I consider it as secure as Google.

But you&#039;d think they would want more security and use mixed case alpha-numerics and extended punctuation symbols...  Go figure.</description>
		<content:encoded><![CDATA[<p>Other than the requirement to use the Google &#8216;random&#8217; generated App Password which is only 16 characters and lower-case alpha it has worked great for years in my fetchmail SSL enabled configs.  </p>
<p>So despite all the FUD, I consider it as secure as Google.</p>
<p>But you&#8217;d think they would want more security and use mixed case alpha-numerics and extended punctuation symbols&#8230;  Go figure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bill</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1770</link>
		<dc:creator>bill</dc:creator>
		<pubDate>Tue, 23 Apr 2024 21:03:09 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1770</guid>
		<description>use &quot;app passwords&quot;. See https://support.google.com/accounts/answer/185833?hl=en for details. Not as secure but works w/o changes to fetchmail.</description>
		<content:encoded><![CDATA[<p>use &#8220;app passwords&#8221;. See <a href="https://support.google.com/accounts/answer/185833?hl=en" rel="nofollow">https://support.google.com/accounts/answer/185833?hl=en</a> for details. Not as secure but works w/o changes to fetchmail.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tired</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1769</link>
		<dc:creator>Tired</dc:creator>
		<pubDate>Fri, 19 Apr 2024 08:22:48 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1769</guid>
		<description>„This is a fight against spammers, scammers and account hijackers, so paranoia is the name of the game.”

It should be completely optional; it could be even switched on by default — but keeping the option to switch it off by „advanced user”.

The password itself is (was?) the protection „against spammers, scammers and account hijackers”. Just keep your password „strong enough” (and don&#039;t show it to anyone) and you&#039;re protected. No need for Google&#039;s „very sophisticated” tools.</description>
		<content:encoded><![CDATA[<p>„This is a fight against spammers, scammers and account hijackers, so paranoia is the name of the game.”</p>
<p>It should be completely optional; it could be even switched on by default — but keeping the option to switch it off by „advanced user”.</p>
<p>The password itself is (was?) the protection „against spammers, scammers and account hijackers”. Just keep your password „strong enough” (and don&#8217;t show it to anyone) and you&#8217;re protected. No need for Google&#8217;s „very sophisticated” tools.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucio C</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1756</link>
		<dc:creator>Lucio C</dc:creator>
		<pubDate>Mon, 22 Jan 2024 13:16:12 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1756</guid>
		<description>I was recently forced to use 2FA with Gsuite, and as expected it broke my fetchmail/procmail arrangement with local storage. Easiest immediate solution (prepared in advance) was to forward all Gsuite to another provider, and fetch from there. However Gsuite does not honour deletion of fetched or forwarded mail (it saves in Bin), so I still need access from my favourite client (Alpine) to cleanup Bin. An app password is the simplest way to do it (and it could work with Alpine *and* fetchmail).</description>
		<content:encoded><![CDATA[<p>I was recently forced to use 2FA with Gsuite, and as expected it broke my fetchmail/procmail arrangement with local storage. Easiest immediate solution (prepared in advance) was to forward all Gsuite to another provider, and fetch from there. However Gsuite does not honour deletion of fetched or forwarded mail (it saves in Bin), so I still need access from my favourite client (Alpine) to cleanup Bin. An app password is the simplest way to do it (and it could work with Alpine *and* fetchmail).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1684</link>
		<dc:creator>Phil</dc:creator>
		<pubDate>Mon, 24 Jul 2023 03:31:21 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1684</guid>
		<description>Thoughtful article. &quot;Worse problems on this planet&quot; indeed. Having been around since web 1.0, and worked with many different access control systems (Netegrity Siteminder, anyone?), I actually think Google could have done worse than settle on OAuth2. I also hope that fetchmail can continue to be the useful tool it has been for so long.</description>
		<content:encoded><![CDATA[<p>Thoughtful article. &#8220;Worse problems on this planet&#8221; indeed. Having been around since web 1.0, and worked with many different access control systems (Netegrity Siteminder, anyone?), I actually think Google could have done worse than settle on OAuth2. I also hope that fetchmail can continue to be the useful tool it has been for so long.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: myl</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1653</link>
		<dc:creator>myl</dc:creator>
		<pubDate>Fri, 17 Feb 2023 16:53:56 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1653</guid>
		<description>Must say I agree with Fetchmail opinion on this. Governments build laws to enforce users rights towards internet services providers, but they should probably take care of other ways to technically set a microscope in their asshole like such over-engineered authentification stuff. 

Just can&#039;t figure-out the added benefit compared to a good password + still allowing mail clients without Oauth2 support to use long/complex application passwords generated by google just indirectly means that highly severing password setup rules could just have been done, with much less user hassle.

As you said, google may someday stop application passwords (+ you can setup just one &amp; use it for several clients, I did so and nothing looks really verified there). But if they do this, they&#039;ll screw almost all home automation software, IP cameras, home written stuff working since years, etc... There&#039;s IMO a benefit/risk balance here to avoid loosing users!

Issue is I tried several alternative free mail providers between the warning message and the planned end for good old login+passwd auth: All caused issues (reliability, various usage quotas...) after a few days to a few weeks. So I gave my phone nb to google to allow 2 factor setup &amp; being able to setup app passwd. Really tried to avoid this, but in the end that&#039;s what I did.

We all know providing free services that are (almost) always connected was a way for google to identify who &amp; when is using a networked device and not only the device: You can get rid of your locally stored data (cookies etc), but you can&#039;t erase user behavior data google stores under your account (so carefully verified)!

Let&#039;s hope politics will soon put another stop in their gallop.</description>
		<content:encoded><![CDATA[<p>Must say I agree with Fetchmail opinion on this. Governments build laws to enforce users rights towards internet services providers, but they should probably take care of other ways to technically set a microscope in their asshole like such over-engineered authentification stuff. </p>
<p>Just can&#8217;t figure-out the added benefit compared to a good password + still allowing mail clients without Oauth2 support to use long/complex application passwords generated by google just indirectly means that highly severing password setup rules could just have been done, with much less user hassle.</p>
<p>As you said, google may someday stop application passwords (+ you can setup just one &amp; use it for several clients, I did so and nothing looks really verified there). But if they do this, they&#8217;ll screw almost all home automation software, IP cameras, home written stuff working since years, etc&#8230; There&#8217;s IMO a benefit/risk balance here to avoid loosing users!</p>
<p>Issue is I tried several alternative free mail providers between the warning message and the planned end for good old login+passwd auth: All caused issues (reliability, various usage quotas&#8230;) after a few days to a few weeks. So I gave my phone nb to google to allow 2 factor setup &amp; being able to setup app passwd. Really tried to avoid this, but in the end that&#8217;s what I did.</p>
<p>We all know providing free services that are (almost) always connected was a way for google to identify who &amp; when is using a networked device and not only the device: You can get rid of your locally stored data (cookies etc), but you can&#8217;t erase user behavior data google stores under your account (so carefully verified)!</p>
<p>Let&#8217;s hope politics will soon put another stop in their gallop.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1610</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Tue, 12 Jul 2022 01:29:56 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1610</guid>
		<description>The spammers, scammers, and hackers are usually humans too.  I am curious how you expect to stop them without effecting the rest of us.  I have done extensive firewall work and I have run into too many false-positives and false-negatives.  The gray area can be difficult to judge if you donot have the experience.</description>
		<content:encoded><![CDATA[<p>The spammers, scammers, and hackers are usually humans too.  I am curious how you expect to stop them without effecting the rest of us.  I have done extensive firewall work and I have run into too many false-positives and false-negatives.  The gray area can be difficult to judge if you donot have the experience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ghengis M.</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1609</link>
		<dc:creator>Ghengis M.</dc:creator>
		<pubDate>Thu, 07 Jul 2022 19:24:51 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1609</guid>
		<description>Thanks Eli, I came looking for a resource on fixing my GMail issues with fetchmail, and as well as that, had an easier solution, I&#039;m just gonna setup some forwards, Google is no longer worth the aggravation.</description>
		<content:encoded><![CDATA[<p>Thanks Eli, I came looking for a resource on fixing my GMail issues with fetchmail, and as well as that, had an easier solution, I&#8217;m just gonna setup some forwards, Google is no longer worth the aggravation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Uplawski</title>
		<link>https://billauer.se/blog/2022/06/fetchmail-gmail-lsa-oauth2/comment-page-1/#comment-1602</link>
		<dc:creator>Michael Uplawski</dc:creator>
		<pubDate>Tue, 14 Jun 2022 08:22:45 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=6627#comment-1602</guid>
		<description>It is oftentimes a good idea to wait a few weeks after the uproar and *then* read some concise summary of facts and conclusions.

Thank you Eli, I bookmark this page.

Although I am myself not affected by OAuth2, I do use fetchmail. Your text is very clear as well as a good starting point, should I need to dig deeper into some specific aspects.  “There are worse problems on this planet”, but I have underestimated the scope of the problem ... 

Cheers from France.

Michael</description>
		<content:encoded><![CDATA[<p>It is oftentimes a good idea to wait a few weeks after the uproar and *then* read some concise summary of facts and conclusions.</p>
<p>Thank you Eli, I bookmark this page.</p>
<p>Although I am myself not affected by OAuth2, I do use fetchmail. Your text is very clear as well as a good starting point, should I need to dig deeper into some specific aspects.  “There are worse problems on this planet”, but I have underestimated the scope of the problem &#8230; </p>
<p>Cheers from France.</p>
<p>Michael</p>
]]></content:encoded>
	</item>
</channel>
</rss>
