Menu
▾
▴
fetchmail-users
|
From: Ian! D. A. <id...@id...> - 2024-09-20 06:25:34
|
Is fetchmail version 7 with XOAUTH2 stable enough to release? >From Microsoft "POP, IMAP, and SMTP settings for Outlook.com": Outlook.com requires the use of Modern Auth / OAuth2. Basic auth is in the process of being deprecated from the Outlook.com service. >From Microsoft on September 12, 2024: Update your sign-in technology before September 16th, 2024 to maintain email access. The safety and security of your information is top priority for Microsoft. To help keep your account secure, Microsoft will no longer support the use of third-party email and calendar apps which ask you to sign in with only your Microsoft Account username and password. To keep you safe you will need to use a mail or calendar app which supports Microsoft’s modern authentication methods. If you do not act, your third-party email apps will no longer be able to access your Outlook.com, Hotmail or Live.com email address on September 16th. Failing excerpt from my "fetchmail -v hotmail" after September 16: fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [...] fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< SASL PLAIN XOAUTH2 fetchmail: POP3< USER fetchmail: POP3< . fetchmail: POP3> USER us...@ho... fetchmail: POP3< +OK fetchmail: POP3> PASS * fetchmail: POP3< -ERR Logon failure: unknown user name or bad password. fetchmail: Logon failure: unknown user name or bad password. fetchmail: Authorization failure [...] Google is still letting us use USER/PASS authentication. -- | Ian! D. Allen, BA-Psych, MMath-CompSci id...@id... Ottawa CANADA | Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca | Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com | Improve democracy www.fairvote.ca and defend digital freedom www.eff.org |
|
From: gene h. <ghe...@sh...> - 2024-09-20 09:25:28
|
On 9/20/24 02:26, Ian! D. Allen wrote: > Is fetchmail version 7 with XOAUTH2 stable enough to release? > > From Microsoft "POP, IMAP, and SMTP settings for Outlook.com": > > Outlook.com requires the use of Modern Auth / OAuth2. Basic auth > is in the process of being deprecated from the Outlook.com service. > > From Microsoft on September 12, 2024: > > Update your sign-in technology before September 16th, 2024 to maintain > email access. > > The safety and security of your information is top priority for > Microsoft. To help keep your account secure, Microsoft will no longer > support the use of third-party email and calendar apps which ask you > to sign in with only your Microsoft Account username and password. To > keep you safe you will need to use a mail or calendar app which > supports Microsoft’s modern authentication methods. If you do not > act, your third-party email apps will no longer be able to access > your Outlook.com, Hotmail or Live.com email address on September 16th. > > Failing excerpt from my "fetchmail -v hotmail" after September 16: > > fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [...] > fetchmail: POP3> CAPA > fetchmail: POP3< +OK > fetchmail: POP3< TOP > fetchmail: POP3< UIDL > fetchmail: POP3< SASL PLAIN XOAUTH2 > fetchmail: POP3< USER > fetchmail: POP3< . > fetchmail: POP3> USER us...@ho... > fetchmail: POP3< +OK > fetchmail: POP3> PASS * > fetchmail: POP3< -ERR Logon failure: unknown user name or bad password. > fetchmail: Logon failure: unknown user name or bad password. > fetchmail: Authorization failure [...] > > Google is still letting us use USER/PASS authentication. Good, but will it reduce the spam and phishing from the first two of those sites? For 2 or 3 days maybe... Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis |
|
From: Andrew C A. <fet...@ai...> - 2024-09-20 20:56:11
|
On Fri, 20 Sep 2024, Ian! D. Allen wrote: > Google is still letting us use USER/PASS authentication. Google's magic date is the end of this month: Google discontinuing "Less Secure App" authentication. https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html App Passwords will continue to be available. -- Andrew C. Aitchison Kendal, UK an...@ai... |
|
From: Matthias A. <mat...@gm...> - 2024-09-24 14:21:20
|
Am 20.09.24 um 08:08 schrieb Ian! D. Allen: > Is fetchmail version 7 with XOAUTH2 stable enough to release? No it's not. 6.5 is neither, but very close. > From Microsoft "POP, IMAP, and SMTP settings for Outlook.com": > > Outlook.com requires the use of Modern Auth / OAuth2. Basic auth > is in the process of being deprecated from the Outlook.com service. Yeah. Their choice to take away user freedom of choice, and imply to have software reviewed if they deem it good enough to talk to them. > From Microsoft on September 12, 2024: > > Update your sign-in technology before September 16th, 2024 to maintain > email access. > > The safety and security of your information is top priority for > Microsoft. To help keep your account secure, Microsoft will no longer > support the use of third-party email and calendar apps which ask you > to sign in with only your Microsoft Account username and password. To > keep you safe you will need to use a mail or calendar app which > supports Microsoft’s modern authentication methods. If you do not > act, your third-party email apps will no longer be able to access > your Outlook.com, Hotmail or Live.com email address on September 16th. Yeah. Their choice to take away user freedom of choice, and imply to have software reviewed if they deem it good enough to talk to them. See which of the service permit you to configure app-specific passwords, and use those, or else choose a different service. Fetchmail is free and open source software, and free means free choice. When have we had to fix security issues in fetchmail for the last time? How many over the decades? How many weeks ago has your favorite browser that you do need for OAUTH2 schemes fixed security bugs, and how many were they? 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. |
|
From: Ian! D. A. <id...@id...> - 2024-09-24 19:26:01
|
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. 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. -- | Ian! D. Allen, BA-Psych, MMath-CompSci id...@id... Ottawa CANADA | Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca | Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com | Improve democracy www.fairvote.ca and defend digital freedom www.eff.org |
|
From: Lucio C. <lu...@la...> - 2024-09-24 20:17:49
|
Not an outlook user but forced to be a gsuite user at work, so I passed through this already. On Tue, 24 Sep 2024, Ian! D. Allen wrote: > 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. Can you instruct your "legacy proprietaruy service" to FORWARD all mail to another fetchmail-firendly provider ? This is one of the solutions I used. > I don't own a cell phone, so using phone "apps" isn't an option. I don't have a smartphone as well, but the reference to "app password" does not imply phone apps. An "app password" (at least as defined by google) is just a dedicated password for the e-mail account different from the personal one, whjich csn be used by a generic Mail User Agent (e.g. alpine or fetchmail). They call "app" what we oldtimers call binary, program, executable, piece of software. I have defined an "app password" for my gsuite account. This is an alternative to forwarding. Actually I use app password for occasional IMAP access. I could use it with fetchmail as well, but I fetch the bulk from the fetchmail-firendly provider where I forward all stuff. It's a PITA, but it's viable (so far) to overcome the b**y OAUTH. -- Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ A middle rank researcher at end career is not rich but is in the top 5% of the Italian income tax taxpayers. Does it not sound strange ? |
|
From: Matthias A. <mat...@gm...> - 2024-09-25 10:27:36
|
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 |
|
From: Ian! D. A. <id...@id...> - 2024-10-03 05:08:05
|
On Wed, Sep 25, 2024 at 06:27:27AM -0400, Matthias Andree wrote: > App passwords are the sidestep or workaround while they last. Yes, app passwords are still working with gmail (October 2 2024): - https://support.google.com/accounts/answer/185833 As of September 16, app passwords don't work with hotmail: - https://support.microsoft.com/en-us/office/modern-authentication-methods-now-needed-to-continue-syncing-outlook-email-in-non-microsoft-email-apps-c5d65390-9676-4763-b41f-d7986499a90d - https://techcommunity.microsoft.com/t5/outlook-blog/keeping-our-outlook-personal-email-users-safe-reinforcing-our/ba-p/4164184 "App passwords or Application passwords will be deprecated as part of the Basic Auth deprecation. You will need to use Modern Auth for all cases." I can generate an "app password" for my Microsoft account, but using that password in my .fetchmailrc does not work: fetchmail: POP3< -ERR Logon failure: unknown user name or bad password. fetchmail: Logon failure: unknown user name or bad password. --- On Tue, Sep 24, 2024 at 03:43:06PM -0400, Lucio Chiappetti wrote: > Can you instruct your "legacy proprietaruy service" to FORWARD all mail to > another fetchmail-firendly provider? Yes, but forwarding from hotmail has Spamassassin SPF problems: 4.0 SPF_FAIL SPF: sender does not match SPF record (fail) Also, fetching email via POP kept my hotmail account alive without me having to access it in a browser, because POP was treated as a "login". I've set up hotmail forwarding and have a cron job to remind me to use a web browser to log in to hotmail every now and then to keep the account alive. -- | Ian! D. Allen, BA-Psych, MMath-CompSci id...@id... Ottawa CANADA | Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca | Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com | Improve democracy www.fairvote.ca and defend digital freedom www.eff.org |
|
From: Matthias A. <mat...@gm...> - 2024-10-16 19:43:30
|
Am 03.10.24 um 06:30 schrieb Ian! D. Allen: > On Wed, Sep 25, 2024 at 06:27:27AM -0400, Matthias Andree wrote: >> App passwords are the sidestep or workaround while they last. > Yes, app passwords are still working with gmail (October 2 2024): > -https://support.google.com/accounts/answer/185833 > > As of September 16, app passwords don't work with hotmail: > -https://support.microsoft.com/en-us/office/modern-authentication-methods-now-needed-to-continue-syncing-outlook-email-in-non-microsoft-email-apps-c5d65390-9676-4763-b41f-d7986499a90d > -https://techcommunity.microsoft.com/t5/outlook-blog/keeping-our-outlook-personal-email-users-safe-reinforcing-our/ba-p/4164184 > "App passwords or Application passwords will be deprecated as part of the Basic Auth deprecation. You will need to use Modern Auth for all cases." Hm. App-specific passwords still seem to be advertised under the condition that 2-factor authentication is enabled and it references "mail apps on some smartphones" or devices ("f.i., xbox 360") that seem unable to use "regular security codes" (this is all translated back from German from the page about 2FA for the account). I haven't tested this but unless they stop requiring application reviews for OAuth2 application tokens, if they really turned off application passwords, then we're done with Microsoft. fetchmail 7 (currently in development) has rudimentary support for OAUTH2 but has no application token so that's of limited use. > I can generate an "app password" for my Microsoft account, but using > that password in my .fetchmailrc does not work: > > fetchmail: POP3< -ERR Logon failure: unknown user name or bad password. > fetchmail: Logon failure: unknown user name or bad password. Does it have to be a specific application-specific password *for mail*? I presume these passwords would be limited to one particular service. > On Tue, Sep 24, 2024 at 03:43:06PM -0400, Lucio Chiappetti wrote: >> Can you instruct your "legacy proprietaruy service" to FORWARD all mail to >> another fetchmail-firendly provider? > Yes, but forwarding from hotmail has Spamassassin SPF problems: > > 4.0 SPF_FAIL SPF: sender does not match SPF record (fail) That's self-inflicted by how SpamAssassin is configured. It doesn't have to punish SPF forwardings like that. I know SPF is being promoted for spam defense, but it's broken by design and for many people causes more trouble than it's worth. > Also, fetching email via POP kept my hotmail account alive without me > having to access it in a browser, because POP was treated as a "login". > > I've set up hotmail forwarding and have a cron job to remind me to > use a web browser to log in to hotmail every now and then to keep the > account alive. > |
|
From: Carlos E. R. <rob...@te...> - 2024-10-16 20:53:19
Attachments:
OpenPGP_signature.asc
|
On 2024-10-03 06:30, Ian! D. Allen wrote: > Yes, but forwarding from hotmail has Spamassassin SPF problems: > > 4.0 SPF_FAIL SPF: sender does not match SPF record (fail) Perhaps you can add your own rule to add 4 good points to emails coming from the hotmail account, to nullify that SPF rule. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X