Menu
▾
▴
fetchmail-users — User questions and discussion
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(21) |
Sep
(17) |
Oct
(35) |
Nov
(39) |
Dec
(55) |
| 2006 |
Jan
(70) |
Feb
(11) |
Mar
(55) |
Apr
(27) |
May
(73) |
Jun
(47) |
Jul
(63) |
Aug
(27) |
Sep
(52) |
Oct
(39) |
Nov
(87) |
Dec
(15) |
| 2007 |
Jan
(23) |
Feb
(46) |
Mar
(108) |
Apr
(63) |
May
(54) |
Jun
(34) |
Jul
(29) |
Aug
(103) |
Sep
(46) |
Oct
(69) |
Nov
(29) |
Dec
(17) |
| 2008 |
Jan
(45) |
Feb
(32) |
Mar
(25) |
Apr
(17) |
May
(39) |
Jun
(20) |
Jul
(64) |
Aug
(31) |
Sep
(38) |
Oct
(20) |
Nov
(42) |
Dec
(50) |
| 2009 |
Jan
(10) |
Feb
(38) |
Mar
(3) |
Apr
(29) |
May
(41) |
Jun
(31) |
Jul
(21) |
Aug
(53) |
Sep
(49) |
Oct
(26) |
Nov
(28) |
Dec
(15) |
| 2010 |
Jan
(83) |
Feb
(38) |
Mar
(33) |
Apr
(44) |
May
(9) |
Jun
(16) |
Jul
(35) |
Aug
(38) |
Sep
(11) |
Oct
(35) |
Nov
(68) |
Dec
(19) |
| 2011 |
Jan
(16) |
Feb
(69) |
Mar
(42) |
Apr
(54) |
May
(56) |
Jun
(29) |
Jul
|
Aug
(65) |
Sep
(3) |
Oct
(39) |
Nov
(33) |
Dec
(4) |
| 2012 |
Jan
(31) |
Feb
(21) |
Mar
(26) |
Apr
(13) |
May
(38) |
Jun
(39) |
Jul
(14) |
Aug
(31) |
Sep
(8) |
Oct
(32) |
Nov
(12) |
Dec
(16) |
| 2013 |
Jan
(40) |
Feb
(22) |
Mar
(21) |
Apr
(15) |
May
(13) |
Jun
(9) |
Jul
(34) |
Aug
(10) |
Sep
(10) |
Oct
|
Nov
(7) |
Dec
(1) |
| 2014 |
Jan
(25) |
Feb
(9) |
Mar
(8) |
Apr
(12) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(4) |
Sep
(27) |
Oct
(25) |
Nov
(18) |
Dec
(3) |
| 2015 |
Jan
(18) |
Feb
(13) |
Mar
(4) |
Apr
(19) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(4) |
Nov
(19) |
Dec
(6) |
| 2016 |
Jan
|
Feb
(8) |
Mar
(14) |
Apr
|
May
(11) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(11) |
Dec
(17) |
| 2017 |
Jan
(17) |
Feb
(35) |
Mar
|
Apr
(4) |
May
(8) |
Jun
(2) |
Jul
(16) |
Aug
|
Sep
(5) |
Oct
(11) |
Nov
(15) |
Dec
(10) |
| 2018 |
Jan
|
Feb
(3) |
Mar
|
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(10) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(10) |
| 2019 |
Jan
(4) |
Feb
(14) |
Mar
(33) |
Apr
(17) |
May
(7) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
(22) |
Oct
(13) |
Nov
|
Dec
|
| 2020 |
Jan
(36) |
Feb
(19) |
Mar
(31) |
Apr
(2) |
May
(22) |
Jun
(7) |
Jul
(25) |
Aug
(9) |
Sep
(17) |
Oct
(52) |
Nov
(13) |
Dec
(9) |
| 2021 |
Jan
(23) |
Feb
(13) |
Mar
(9) |
Apr
(15) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(23) |
Sep
(3) |
Oct
(8) |
Nov
(28) |
Dec
(9) |
| 2022 |
Jan
(38) |
Feb
(2) |
Mar
(56) |
Apr
(24) |
May
(29) |
Jun
(22) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(2) |
Dec
|
| 2023 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2024 |
Jan
(15) |
Feb
(4) |
Mar
|
Apr
(4) |
May
(11) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
(7) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(10) |
Jul
|
Aug
(1) |
Sep
(12) |
Oct
|
Nov
|
Dec
|
|
From: Héctor A. <hab...@gm...> - 2022-03-21 15:24:22
|
> > > 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 > |
|
From: Matthias A. <mat...@gm...> - 2022-03-20 11:27:57
|
The 6.4.29 release of fetchmail is now available at <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. It updates the Vietnamese-language translations. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.29.tar.xz/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.29.tar.lz/download> The detached GnuPG signature is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.29.tar.xz.asc/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.29.tar.lz.asc/download> The SHA256 hashes for the tarballs are: SHA256(fetchmail-6.4.29.tar.xz)= 397df984082abae51edec6831700d68636f0e117cfaffcbdd3eed66d04b97321 SHA256(fetchmail-6.4.29.tar.lz)= 7f465b1959197f0510309986da02ba5fa813b6e2fd863bbb5994798b83a1ff85 Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.4.29 (released 2022-03-20, 31661 LoC): # TRANSLATIONS: language translations were updated by this fine person: * vi: Trần Ngọc Quân [Vietnamese] -------------------------------------------------------------------------------- Happy fetches, Matthias |
|
From: L A W. <fet...@tl...> - 2022-03-17 09:31:57
|
Someone was saying fetchmail would need to do a client request. Presumably that sends back a response asking the oauth provider if the client should have access. Then that sends back a 'blob' (cookie) that is used for future access? Also was something about the need for a json parser. Is that it? The display of the response seems to be 1 sticking point -- wouldn't sending the response to a local system or user defined browser? to handle the Q+A, then the stub stores the response for future authorizations? Or how much more complex is oauth than I'm thinking...? Something that parses limited HTML isn't real hard in perl. I have a few local apps that do such parsing, like to pull down rss_rdr, or one to check for the latest linux kernel version, etc. The part that might get hairy is invoking a local client to display the web-auth page and get the blob back from that transaction (?) But isn't the rest mostly straight forward? It may be beyond my capabilities, but I wouldn't know w/o a better idea of the problem. All of that code is mostly for setup. It seems once you have the token, no more interactive browser access is needed, is that about right? Sorry if this has been designed in detail for fetchmail already ...if so, is there a pointer to the design? Thanks, -linda |
|
From: Matthias A. <mat...@gm...> - 2022-03-13 07:45:03
|
Am 13.03.22 um 05:41 schrieb Martin E. Main: > > Hi, > > I am hoping for some advice on errors I am seeing with my fetchmail > configuration. Until recently I had been using fetchmail under the > Centos 7 distro with no problem whatsoever, but with RH decision to > abandon Centos, I moved to Ubuntu 20.04 and started experiencing > periodic errors. These errors are almost random and affect only one of > the servers I download from, Google has not shown the same problems. > From reading some online advice, I added /no sslcertck/ and /sslproto > 'SSL3+'/ which did appear to improve the frequency and I almost > thought it had eliminated the problem after a few days of no errors in > daily logfile, but this is not the case. Any advice or direction very > welcome. > > Thanks, > [I am replying to the moderator's copy, so this reply may hit the list before Martin's original post does.] Hello Martin, * it is a bit unfortunate that in the verbose logs, there is no event with failing connection. * your Ubuntu fetchmail and OpenSSL packages are out of date. it is unfortunate that Ubuntu are so bad about maintaining software. They freeze their stuff and abandon it. fetchmail 6.4.2 is two years old... two years of missed fixes, including SSL fixes. HOWEVER, * It seems that accountservergroup.com do support TLSv1.2, so sslproto with SSLv3, TLSv1 or TLSv1.1 the respective "+" variants should not be used. * Chances are that some of their load balancing experiences trouble and some servers are not responding properly. Take this up with their support. * You may want to recompile openssl 1.1.1[latest version you find] and fetchmail 6.4.28 into a separate prefix and run them and see if that improves the situation. I am truncating some logs in my quote. > Martin > > Log File > > ------------------------------------------------------------------------------------------- > > Mar 11 12:54:02 mmsys fetchmail[1667]: Unknown login or authentication > error on hm...@ma...@shared103.accountservergroup.com > > Mar 11 12:54:02 mmsys fetchmail[1667]: socket error while fetching > from hm...@ma...@mail.martinmain.net > > Mar 11 13:54:01 mmsys fetchmail[1667]: shared103.accountservergroup.com: > > Mar 11 13:54:01 mmsys fetchmail[1667]: System error during > SSL_connect(): handshake failed at protocol or connection level. > > Mar 11 13:54:01 mmsys fetchmail[1667]: > shared103.accountservergroup.com: SSL connection failed. > > Mar 11 13:54:01 mmsys fetchmail[1667]: socket error while fetching > from ad...@ma...@mail.martinmain.net > > [...] > > fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun > Mar 13 08:05:39 2022: poll started > > Trying to connect to 162.215.249.52/993...connected. > > fetchmail: Loaded OpenSSL library 0x1010106f newer than headers > 0x1010104f, trying to continue. > > fetchmail: Server certificate: > > fetchmail: Issuer Organization: Sectigo Limited > > fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure > Server CA > > fetchmail: Subject CommonName: *.accountservergroup.com > > fetchmail: Subject Alternative Name: *.accountservergroup.com > > fetchmail: Subject Alternative Name: accountservergroup.com > > fetchmail: mail.martinmain.net key fingerprint: > 68:19:3D:CF:B5:DB:82:E7:1A:F0:CC:58:D4:23:16:86 > > fetchmail: SSL/TLS: using protocol TLSv1.2, cipher > ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits > > fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR > LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN] > Dovecot ready. > [...] |
|
From: Martin E. M. <mm...@ma...> - 2022-03-13 05:01:53
|
Hi, I am hoping for some advice on errors I am seeing with my fetchmail configuration. Until recently I had been using fetchmail under the Centos 7 distro with no problem whatsoever, but with RH decision to abandon Centos, I moved to Ubuntu 20.04 and started experiencing periodic errors. These errors are almost random and affect only one of the servers I download from, Google has not shown the same problems. From reading some online advice, I added no sslcertck and sslproto 'SSL3+' which did appear to improve the frequency and I almost thought it had eliminated the problem after a few days of no errors in daily logfile, but this is not the case. Any advice or direction very welcome. Thanks, Martin Log File ------------------------------------------------------------------------------------------- Mar 11 12:54:02 mmsys fetchmail[1667]: Unknown login or authentication error on hm...@ma...@shared103.accountservergroup.com Mar 11 12:54:02 mmsys fetchmail[1667]: socket error while fetching from hm...@ma...@mail.martinmain.net Mar 11 13:54:01 mmsys fetchmail[1667]: shared103.accountservergroup.com: Mar 11 13:54:01 mmsys fetchmail[1667]: System error during SSL_connect(): handshake failed at protocol or connection level. Mar 11 13:54:01 mmsys fetchmail[1667]: shared103.accountservergroup.com: SSL connection failed. Mar 11 13:54:01 mmsys fetchmail[1667]: socket error while fetching from ad...@ma...@mail.martinmain.net Mar 12 00:54:01 mmsys fetchmail[1667]: shared103.accountservergroup.com: Mar 12 00:54:01 mmsys fetchmail[1667]: System error during SSL_connect(): handshake failed at protocol or connection level. Mar 12 00:54:01 mmsys fetchmail[1667]: shared103.accountservergroup.com: SSL connection failed. Mar 12 00:54:01 mmsys fetchmail[1667]: socket error while fetching from mm...@ma...@mail.martinmain.net /etc/fetchmailrc ------------------------------------------------------------------------------------------- set postmaster ad...@ma... set no bouncemail poll mail.martinmain.net proto imap via shared103.accountservergroup.com user "ad...@ma..." pass "<secret>" is ad...@ma... ssl antispam 554 sslproto 'SSL3+' no sslcertck user "hm...@ma..." pass ""<secret>" is hm...@ma... ssl antispam 554 sslproto 'SSL3+' no sslcertck user "mm...@ma..." pass ""<secret>" is mm...@ma... ssl antispam 554 sslproto 'SSL3+' no sslcertck poll imap.gmail.com proto imap port 993 user "mma...@gm..." pass "<secret>" is mm...@ma... ssl antispam 554 Send bugs to fetchmail-users <mailto:fet...@li...> . When sending bugs or asking for help, please do not make up information except your password and please report the following: 1. Your operating system. Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-104-generic x86_64) 2. Your compiler version, if you built from source; otherwise, the name and origin of the RPM or other binary package you installed. This is fetchmail release 6.4.2+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5 3. The name and version of the SMTP listener or MDA you are forwarding to. Postfix version 3.4.13 4. Any command-line options you used. fetchmail -d 60 -f /etc/fetchmailrc --pidfile /var/run/fetchmail/fetchmail.pid --syslog 5. The output of env LC_ALL=C fetchmail -V called with whatever other command-line options you used. env LC_ALL=C fetchmail -v -f /etc/fetchmailrc fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:05:39 2022: poll started Trying to connect to 162.215.249.52/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: Server certificate: fetchmail: Issuer Organization: Sectigo Limited fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: Subject CommonName: *.accountservergroup.com fetchmail: Subject Alternative Name: *.accountservergroup.com fetchmail: Subject Alternative Name: accountservergroup.com fetchmail: mail.martinmain.net key fingerprint: 68:19:3D:CF:B5:DB:82:E7:1A:F0:CC:58:D4:23:16:86 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN] Dovecot ready. fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN fetchmail: IMAP< A0001 OK Pre-login capabilities listed, post-login capabilities have more. fetchmail: IMAP> A0002 LOGIN "ad...@ma..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY NAMESPACE NOTIFY SPECIAL-USE COMPRESS=DEFLATE QUOTA fetchmail: IMAP< A0002 OK Logged in fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDVALIDITY 1526871272] UIDs valid fetchmail: IMAP< * OK [UIDNEXT 3057] Predicted next UID fetchmail: IMAP< * OK [HIGHESTMODSEQ 140] Highest fetchmail: IMAP< A0003 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). fetchmail: No mail for ad...@ma... at mail.martinmain.net fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE Logging out fetchmail: IMAP< A0004 OK Logout completed (0.001 + 0.000 secs). fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:05:41 2022: poll completed fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:05:41 2022: poll started Trying to connect to 162.215.249.52/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: Server certificate: fetchmail: Issuer Organization: Sectigo Limited fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: Subject CommonName: *.accountservergroup.com fetchmail: Subject Alternative Name: *.accountservergroup.com fetchmail: Subject Alternative Name: accountservergroup.com fetchmail: mail.martinmain.net key fingerprint: 68:19:3D:CF:B5:DB:82:E7:1A:F0:CC:58:D4:23:16:86 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN] Dovecot ready. fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN fetchmail: IMAP< A0001 OK Pre-login capabilities listed, post-login capabilities have more. fetchmail: IMAP> A0002 LOGIN "hm...@ma..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY NAMESPACE NOTIFY SPECIAL-USE COMPRESS=DEFLATE QUOTA fetchmail: IMAP< A0002 OK Logged in fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDVALIDITY 1526719397] UIDs valid fetchmail: IMAP< * OK [UIDNEXT 3046] Predicted next UID fetchmail: IMAP< * OK [HIGHESTMODSEQ 6235] Highest fetchmail: IMAP< A0003 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). fetchmail: No mail for hm...@ma... at mail.martinmain.net fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE Logging out fetchmail: IMAP< A0004 OK Logout completed (0.001 + 0.000 secs). fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:05:43 2022: poll completed fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:05:43 2022: poll started Trying to connect to 162.215.249.52/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: Server certificate: fetchmail: Issuer Organization: Sectigo Limited fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: Subject CommonName: *.accountservergroup.com fetchmail: Subject Alternative Name: *.accountservergroup.com fetchmail: Subject Alternative Name: accountservergroup.com fetchmail: mail.martinmain.net key fingerprint: 68:19:3D:CF:B5:DB:82:E7:1A:F0:CC:58:D4:23:16:86 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN] Dovecot ready. fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN fetchmail: IMAP< A0001 OK Pre-login capabilities listed, post-login capabilities have more. fetchmail: IMAP> A0002 LOGIN "mm...@ma..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY NAMESPACE NOTIFY SPECIAL-USE COMPRESS=DEFLATE QUOTA fetchmail: IMAP< A0002 OK Logged in fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $forwarded) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $forwarded \*)] Flags permitted. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDVALIDITY 1526716986] UIDs valid fetchmail: IMAP< * OK [UIDNEXT 34698] Predicted next UID fetchmail: IMAP< * OK [HIGHESTMODSEQ 68940] Highest fetchmail: IMAP< A0003 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). fetchmail: No mail for mm...@ma... at mail.martinmain.net fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE Logging out fetchmail: IMAP< A0004 OK Logout completed (0.001 + 0.000 secs). fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:05:45 2022: poll completed fetchmail: 6.4.2 querying imap.gmail.com (protocol IMAP) at Sun Mar 13 08:05:45 2022: poll started Trying to connect to 108.177.15.109/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: Server certificate: fetchmail: Issuer Organization: Google Trust Services LLC fetchmail: Issuer CommonName: GTS CA 1C3 fetchmail: Subject CommonName: imap.gmail.com fetchmail: Subject Alternative Name: imap.gmail.com fetchmail: imap.gmail.com key fingerprint: 7B:9E:F8:D2:3B:5D:E0:D7:75:ED:AA:84:3A:61:17:E3 fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK Gimap ready for requests from 94.201.121.136 b18mb538896304wrj fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH fetchmail: IMAP< A0001 OK Thats all she wrote! b18mb538896304wrj fetchmail: IMAP> A0002 LOGIN "mma...@gm..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584 fetchmail: IMAP< A0002 OK mma...@gm... authenticated (Success) fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotPhishing $Phishing) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotPhishing $Phishing \*)] Flags permitted. fetchmail: IMAP< * OK [UIDVALIDITY 1] UIDs valid. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDNEXT 1800] Predicted next UID. fetchmail: IMAP< * OK [HIGHESTMODSEQ 357153] fetchmail: IMAP< A0003 OK [READ-WRITE] INBOX selected. (Success) fetchmail: No mail for mma...@gm... at imap.gmail.com fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE LOGOUT Requested fetchmail: IMAP< A0004 OK 73 good day (Success) fetchmail: 6.4.2 querying imap.gmail.com (protocol IMAP) at Sun Mar 13 08:05:47 2022: poll completed fetchmail: normal termination, status 1 1. The output of env LC_ALL=C fetchmail --nodetach -vvv --nosyslog with whatever other command-line options you use routinely. env LC_ALL=C fetchmail --nodetach -vvv --nosyslog -f /etc/fetchmailrc It is very important that the transcript include your POP/IMAP server's greeting line, so I can identify it in case of server problems. This transcript will not reveal your passwords, which are specially masked out precisely so transcripts can be passed around. Old UID list from mail.martinmain.net: <empty> Old UID list from mail.martinmain.net: <empty> Old UID list from mail.martinmain.net: <empty> Old UID list from imap.gmail.com: <empty> Scratch list of UIDs: <empty> fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:15:17 2022: poll started Trying to connect to 162.215.249.52/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: The USERTRUST Network fetchmail: Issuer CommonName: USERTrust RSA Certification Authority fetchmail: Subject CommonName: USERTrust RSA Certification Authority fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: The USERTRUST Network fetchmail: Issuer CommonName: USERTrust RSA Certification Authority fetchmail: Subject CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok fetchmail: Server certificate: fetchmail: Issuer Organization: Sectigo Limited fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: Subject CommonName: *.accountservergroup.com fetchmail: Subject Alternative Name: *.accountservergroup.com fetchmail: Subject Alternative Name: accountservergroup.com fetchmail: mail.martinmain.net key fingerprint: 68:19:3D:CF:B5:DB:82:E7:1A:F0:CC:58:D4:23:16:86 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN] Dovecot ready. fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN fetchmail: IMAP< A0001 OK Pre-login capabilities listed, post-login capabilities have more. fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: GSSAPI error gss_inquire_cred: Unspecified GSS failure. Minor code may provide more information fetchmail: GSSAPI error gss_inquire_cred: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0) fetchmail: No suitable GSSAPI credentials found. Skipping GSSAPI authentication. fetchmail: If you want to use GSSAPI, you need credentials first, possibly from kinit. fetchmail: IMAP> A0002 LOGIN "ad...@ma..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY NAMESPACE NOTIFY SPECIAL-USE COMPRESS=DEFLATE QUOTA fetchmail: IMAP< A0002 OK Logged in fetchmail: selecting or re-polling default folder fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDVALIDITY 1526871272] UIDs valid fetchmail: IMAP< * OK [UIDNEXT 3057] Predicted next UID fetchmail: IMAP< * OK [HIGHESTMODSEQ 140] Highest fetchmail: IMAP< A0003 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). fetchmail: 0 messages waiting after first poll fetchmail: No mail for ad...@ma... at mail.martinmain.net fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE Logging out fetchmail: IMAP< A0004 OK Logout completed (0.001 + 0.000 secs). fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:15:19 2022: poll completed New UID list from mail.martinmain.net: <empty> fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: Query status=1 (NOMAIL) fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:15:19 2022: poll started Trying to connect to 162.215.249.52/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: The USERTRUST Network fetchmail: Issuer CommonName: USERTrust RSA Certification Authority fetchmail: Subject CommonName: USERTrust RSA Certification Authority fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: The USERTRUST Network fetchmail: Issuer CommonName: USERTrust RSA Certification Authority fetchmail: Subject CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok fetchmail: Server certificate: fetchmail: Issuer Organization: Sectigo Limited fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: Subject CommonName: *.accountservergroup.com fetchmail: Subject Alternative Name: *.accountservergroup.com fetchmail: Subject Alternative Name: accountservergroup.com fetchmail: mail.martinmain.net key fingerprint: 68:19:3D:CF:B5:DB:82:E7:1A:F0:CC:58:D4:23:16:86 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN] Dovecot ready. fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN fetchmail: IMAP< A0001 OK Pre-login capabilities listed, post-login capabilities have more. fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: GSSAPI error gss_inquire_cred: Unspecified GSS failure. Minor code may provide more information fetchmail: GSSAPI error gss_inquire_cred: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0) fetchmail: No suitable GSSAPI credentials found. Skipping GSSAPI authentication. fetchmail: If you want to use GSSAPI, you need credentials first, possibly from kinit. fetchmail: IMAP> A0002 LOGIN "hm...@ma..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY NAMESPACE NOTIFY SPECIAL-USE COMPRESS=DEFLATE QUOTA fetchmail: IMAP< A0002 OK Logged in fetchmail: selecting or re-polling default folder fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDVALIDITY 1526719397] UIDs valid fetchmail: IMAP< * OK [UIDNEXT 3046] Predicted next UID fetchmail: IMAP< * OK [HIGHESTMODSEQ 6235] Highest fetchmail: IMAP< A0003 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). fetchmail: 0 messages waiting after first poll fetchmail: No mail for hm...@ma... at mail.martinmain.net fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE Logging out fetchmail: IMAP< A0004 OK Logout completed (0.001 + 0.000 secs). fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:15:21 2022: poll completed New UID list from mail.martinmain.net: <empty> fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: Query status=1 (NOMAIL) fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:15:21 2022: poll started Trying to connect to 162.215.249.52/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: The USERTRUST Network fetchmail: Issuer CommonName: USERTrust RSA Certification Authority fetchmail: Subject CommonName: USERTrust RSA Certification Authority fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: The USERTRUST Network fetchmail: Issuer CommonName: USERTrust RSA Certification Authority fetchmail: Subject CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok fetchmail: Server certificate: fetchmail: Issuer Organization: Sectigo Limited fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure Server CA fetchmail: Subject CommonName: *.accountservergroup.com fetchmail: Subject Alternative Name: *.accountservergroup.com fetchmail: Subject Alternative Name: accountservergroup.com fetchmail: mail.martinmain.net key fingerprint: 68:19:3D:CF:B5:DB:82:E7:1A:F0:CC:58:D4:23:16:86 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN] Dovecot ready. fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE AUTH=PLAIN AUTH=LOGIN fetchmail: IMAP< A0001 OK Pre-login capabilities listed, post-login capabilities have more. fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: GSSAPI error gss_inquire_cred: Unspecified GSS failure. Minor code may provide more information fetchmail: GSSAPI error gss_inquire_cred: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0) fetchmail: No suitable GSSAPI credentials found. Skipping GSSAPI authentication. fetchmail: If you want to use GSSAPI, you need credentials first, possibly from kinit. fetchmail: IMAP> A0002 LOGIN "mm...@ma..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY NAMESPACE NOTIFY SPECIAL-USE COMPRESS=DEFLATE QUOTA fetchmail: IMAP< A0002 OK Logged in fetchmail: selecting or re-polling default folder fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $forwarded) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $forwarded \*)] Flags permitted. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDVALIDITY 1526716986] UIDs valid fetchmail: IMAP< * OK [UIDNEXT 34698] Predicted next UID fetchmail: IMAP< * OK [HIGHESTMODSEQ 68940] Highest fetchmail: IMAP< A0003 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). fetchmail: 0 messages waiting after first poll fetchmail: No mail for mm...@ma... at mail.martinmain.net fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE Logging out fetchmail: IMAP< A0004 OK Logout completed (0.001 + 0.000 secs). fetchmail: 6.4.2 querying mail.martinmain.net (protocol IMAP) at Sun Mar 13 08:15:23 2022: poll completed New UID list from mail.martinmain.net: <empty> fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: Query status=1 (NOMAIL) fetchmail: 6.4.2 querying imap.gmail.com (protocol IMAP) at Sun Mar 13 08:15:23 2022: poll started Trying to connect to 108.177.15.109/993...connected. fetchmail: Loaded OpenSSL library 0x1010106f newer than headers 0x1010104f, trying to continue. fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: Google Trust Services LLC fetchmail: Issuer CommonName: GTS Root R1 fetchmail: Subject CommonName: GTS Root R1 fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: Google Trust Services LLC fetchmail: Issuer CommonName: GTS Root R1 fetchmail: Subject CommonName: GTS CA 1C3 fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok fetchmail: Server certificate: fetchmail: Issuer Organization: Google Trust Services LLC fetchmail: Issuer CommonName: GTS CA 1C3 fetchmail: Subject CommonName: imap.gmail.com fetchmail: Subject Alternative Name: imap.gmail.com fetchmail: imap.gmail.com key fingerprint: 7B:9E:F8:D2:3B:5D:E0:D7:75:ED:AA:84:3A:61:17:E3 fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits fetchmail: IMAP< * OK Gimap ready for requests from 94.201.121.136 t16mb58749193wrr fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH fetchmail: IMAP< A0001 OK Thats all she wrote! t16mb58749193wrr fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: GSSAPI error gss_inquire_cred: Unspecified GSS failure. Minor code may provide more information fetchmail: GSSAPI error gss_inquire_cred: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0) fetchmail: No suitable GSSAPI credentials found. Skipping GSSAPI authentication. fetchmail: If you want to use GSSAPI, you need credentials first, possibly from kinit. fetchmail: IMAP> A0002 LOGIN "mma...@gm..." * fetchmail: IMAP< * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584 fetchmail: IMAP< A0002 OK mma...@gm... authenticated (Success) fetchmail: selecting or re-polling default folder fetchmail: IMAP> A0003 SELECT "INBOX" fetchmail: IMAP< * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotPhishing $Phishing) fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotPhishing $Phishing \*)] Flags permitted. fetchmail: IMAP< * OK [UIDVALIDITY 1] UIDs valid. fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< * OK [UIDNEXT 1800] Predicted next UID. fetchmail: IMAP< * OK [HIGHESTMODSEQ 357153] fetchmail: IMAP< A0003 OK [READ-WRITE] INBOX selected. (Success) fetchmail: 0 messages waiting after first poll fetchmail: No mail for mma...@gm... at imap.gmail.com fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE LOGOUT Requested fetchmail: IMAP< A0004 OK 73 good day (Success) fetchmail: 6.4.2 querying imap.gmail.com (protocol IMAP) at Sun Mar 13 08:15:24 2022: poll completed New UID list from imap.gmail.com: <empty> fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: Query status=1 (NOMAIL) fetchmail: normal termination, status 1 |
|
From: Matthias A. <mat...@gm...> - 2022-03-12 20:41:15
|
Am 12.03.22 um 08:47 schrieb Jon Brinkmann: > Without the certificates extracted from the output of the command: > > openssl s_client -connect imap.mail.me.com:993 -showcerts > > or with the Mozilla root certificates, available from > > https://curl.se/[...] > > fetchmail says: > > fetchmail: Server certificate verification error: self signed certificate in certificate chain > fetchmail: Missing trust anchor certificate: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services > fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. See README.SSL for details. Jon, stop random trying - it wastes everybody's time - and go systematically. Disregard random stuff you find on the Internet. It is not usually written for your distribution or distribution's version or file layout and may not be complete - see above. Forget -showcerts. It is a debugging tool for knowledgeable developers, not for end users. Read and understand the error message and the referenced information. Look for and install Mozilla's root certificates PER YOUR DISTRIBUTION'S PACKAGE. Find out how it's called if it is not ca-certificates nor ca-certificates-mozilla nor ca_root_nss. Also see: > https://... No. I don't care for even more distraction, because there is no need. imap.mail.me.com validates properly for me, out of the box, on Fedora Linux 35, on Ubuntu 20.04.4, on Alpine Linux 3.15, and on FreeBSD 13.0. I have tried all four just now. > $ fetchmail -vcNd0 -f/dev/null imap.mail.me.com -pimap --ssl --user joe > Enter password for jo...@im...: > fetchmail: --check mode enabled, not fetching mail > fetchmail: 6.4.28 querying imap.mail.me.com (protocol IMAP) at Sat, 12 > Mar 2022 20:34:10 +0000 (UTC): poll started > Trying to connect to 17.42.251.32/993...connected. > fetchmail: Server certificate: > fetchmail: Issuer Organization: Apple Inc. > fetchmail: Issuer CommonName: Apple Public Server RSA CA 12 - G1 > fetchmail: Subject CommonName: imap.mail.me.com > fetchmail: Subject Alternative Name: p41-imap.mail.me.com > [...] > fetchmail: Subject Alternative Name: p28-imap.mail.me.com > fetchmail: Subject Alternative Name: imap.mail.me.com > fetchmail: Subject Alternative Name: p80-imap.mail.me.com > fetchmail: Subject Alternative Name: p33-imap.mail.me.com > fetchmail: Subject Alternative Name: p59-imap.mail.me.com > fetchmail: Subject Alternative Name: p72-imap.mail.me.com > fetchmail: Subject Alternative Name: mail.mac.com > fetchmail: imap.mail.me.com key fingerprint: > D8:37:66:9C:66:58:51:20:BB:0F:28:B1:68:F3:0A:F9 > fetchmail: SSL/TLS: using protocol TLSv1.3, cipher > TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits > fetchmail: IMAP< * OK [CAPABILITY XAPPLEPUSHSERVICE IMAP4 IMAP4rev1 > SASL-IR AUTH=ATOKEN AUTH=PLAIN] (2210B49-fcb7e75610a7) > st43p00im-tygg09060401.me.com > fetchmail: will idle after poll > [...] |
|
From: Jon B. <bri...@nm...> - 2022-03-12 07:51:12
|
Without the certificates extracted from the output of the command: openssl s_client -connect imap.mail.me.com:993 -showcerts or with the Mozilla root certificates, available from https://curl.se/docs/caextract.html fetchmail says: fetchmail: Server certificate verification error: self signed certificate in certificate chain fetchmail: Missing trust anchor certificate: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. See README.SSL for details. fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed fetchmail: imap.mail.me.com: SSL connection failed. fetchmail: socket error while fetching from <name>@imap.mail.me.com fetchmail: Query status=2 (SOCKET) The certificate chain is: depth=2 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services verify error:num=19:self signed certificate in certificate chain verify return:1 depth=2 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services verify return:1 depth=1 CN = Apple Public Server RSA CA 12 - G1, O = Apple Inc., ST = California, C = US verify return:1 depth=0 CN = imap.mail.me.com, OU = management:idms.group.859635, O = Apple Inc., ST = California, C = US verify return:1 Also see: https://support.plesk.com/hc/en-us/articles/213961665-How-to-verify-that-SSL-for-IMAP-POP3-SMTP-works-and-a-proper-SSL-certificate-is-in-use for example: https://www.sslshopper.com/ssl-checker.html#hostname=imap.mail.me.com:993 On Sat, Mar 12, 2022 at 01:06:32AM +0100, Matthias Andree wrote: > > Am 11.03.22 um 22:59 schrieb Jon Brinkmann: > > Thanks! > > > > I got it working, with one additional step. The depth=2 SSL certificate for > > icloud.com is self-signed, so fetchmail refuses the SSL connection. I found > > the solution at: > > > > https://geekmush.wordpress.com/2007/06/29/how-to-make-fetchmail-happy-with-the-servers-ssl-cert/ > > Congratulations, you have just installed some attacker's CA > certificates. That is not a solution, but unsafe garbage. > > Please everyone remove the certificates you have installed that way. > > Instead, install your distribution's default Mozilla certificate > package. Depending on your distribution, it might be called > ca-certificates or ca_root_nss or similar. > > Explanation: > > The root CA certificate (Equifax's in that example on the website) MUST > be obtained via a SECURE separate channel and NOT from the connection. > There are SSL tools (for instance, SSLsplit) that will generate such CA > certificates on the fly to crack the encrypted connection and you could > not tell from the name that this is happening. This is typical for > anti-virus/web security gateways/firewalls and of course also in > malicious attacks. > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users |
|
From: Matthias A. <mat...@gm...> - 2022-03-12 00:06:44
|
Am 11.03.22 um 22:59 schrieb Jon Brinkmann: > Thanks! > > I got it working, with one additional step. The depth=2 SSL certificate for > icloud.com is self-signed, so fetchmail refuses the SSL connection. I found > the solution at: > > https://geekmush.wordpress.com/2007/06/29/how-to-make-fetchmail-happy-with-the-servers-ssl-cert/ Congratulations, you have just installed some attacker's CA certificates. That is not a solution, but unsafe garbage. Please everyone remove the certificates you have installed that way. Instead, install your distribution's default Mozilla certificate package. Depending on your distribution, it might be called ca-certificates or ca_root_nss or similar. Explanation: The root CA certificate (Equifax's in that example on the website) MUST be obtained via a SECURE separate channel and NOT from the connection. There are SSL tools (for instance, SSLsplit) that will generate such CA certificates on the fly to crack the encrypted connection and you could not tell from the name that this is happening. This is typical for anti-virus/web security gateways/firewalls and of course also in malicious attacks. |
|
From: Jon B. <bri...@nm...> - 2022-03-11 21:59:17
|
Thanks! I got it working, with one additional step. The depth=2 SSL certificate for icloud.com is self-signed, so fetchmail refuses the SSL connection. I found the solution at: https://geekmush.wordpress.com/2007/06/29/how-to-make-fetchmail-happy-with-the-servers-ssl-cert/ I couldn't use "forceidle" with the latest stable version of fetchmail, 6.4.28. It's only in the 6.5 beta versions. On Sat, Mar 05, 2022 at 11:06:53AM -0800, Eric Durand wrote: > > This is what I have. I am using IDLE and multiple fechmails processes to gather > emails from a bunch of places (also see https://github.com/rand0mdud3/ > multifetchmail) > > > set no bouncemail > > poll imap.mail.me.com protocol imap idletimeout 540 > username icloud-username there is local-username here, has password > xxx-xxx-xxx-xxx and wants nokeep, fetchall, ssl, idle and forceidle > > > iCloud does support IDLE but doesn't advertise it AFAIK, so it you want idle, > you'll have to use the forceidle thingy (and it's only supported by recent > versions of fetchmail) > You will also have to generate an app specific password on appleid.apple.com. > > > On Sat, Mar 5, 2022 at 9:58 AM Jon Brinkmann <bri...@nm...> wrote: > > I'd like to use fetchmail with iCloud via IMAP. The Apple support page > https://support.apple.com/en-us/HT202304 gives relevant information. > I found nothing specific to this on the web or our forum. > > Does anyone have a working configuration file to share? > > Jon > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users > |
|
From: Matthias A. <mat...@gm...> - 2022-03-06 09:38:13
|
Am 06.03.22 um 09:43 schrieb Andrew C Aitchison: > >> 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? > > Sadly, I think *their systems* are more secure if they turn off IMAP/TLS > and rely on just one authentication system. > There may also be merit in device- and app-specific authentication > tokens. That would even be grosser if they were shifting their own blame to somebody else. We have some SASL and GSSAPI (Kerberos)... > > Plus TLS doesn't save passwords from the boot-strap problem. This > fancy new stuff may help to get a new password agreed between both > ends securely. ...in place for authentication, why did we have to reinvent Kerberos if not by the Big Tech to exert control where it does not belong? I am happy to add new SASL mechanisms if they don't require registering the application or reading through hundreds of pages of specs that then still leave many questions open as to some service's particular implementation quirks and idiosyncrasies. > Frankly, I am as worried about losing an account through a disk crash > as having it hacked. If I really care about the information being secure > I don't want it on the internet in the first place. Well, true enough, and then there is client-side encryption to make sure you need not trust some storage provider to keep your data safe. And there are encrypted backup systems to avert data loss in case of disk crashes. There seems to be a decent choice of incremental or deduplicating or history-preserving backups, some built on keeping file history with hardlinks and forward or reverse diffs (rsync based backups, or rsnapshot - these usually without encryption last time I'd checked), some encrypting and block deduplicating (such as borg backup or restic, borg with optional compression which, however, seems to be less effective than deduplication in my personal practice), and others (for instance duplicity and its wrappers). Some systems (for instance, borg backup and restic) permit mounting of backups through FUSE. Regards, Matthias |
|
From: Andrew C A. <fet...@ai...> - 2022-03-06 08:43:50
|
On Fri, 4 Mar 2022, Matthias Andree wrote:
> Am 04.03.22 um 17:36 schrieb Andrew C Aitchison:
> > 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.
Thanks.
6.5 before 7 is sufficient.
I have gone to 6.5 for the logging timestamps; I was wondering if
I should copy Gentoo and go to 7 even though it is in alpha.
> 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?
Sadly, I think *their systems* are more secure if they turn off IMAP/TLS
and rely on just one authentication system.
There may also be merit in device- and app-specific authentication tokens.
Plus TLS doesn't save passwords from the boot-strap problem. This
fancy new stuff may help to get a new password agreed between both ends
securely.
Frankly, I am as worried about losing an account through a disk crash
as having it hacked. If I really care about the information being secure
I don't want it on the internet in the first place.
--
Andrew C. Aitchison Kendal, UK
an...@ai...
On Fri, 4 Mar 2022, Matthias Andree wrote:
> 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
>
--
Andrew C. Aitchison Kendal, UK
an...@ai...
|
|
From: Eric D. <ran...@gm...> - 2022-03-05 19:07:11
|
This is what I have. I am using IDLE and multiple fechmails processes to gather emails from a bunch of places (also see https://github.com/rand0mdud3/multifetchmail) set no bouncemail > > poll imap.mail.me.com protocol imap idletimeout 540 > username icloud-username there is local-username here, has password > xxx-xxx-xxx-xxx and wants nokeep, fetchall, ssl, idle and forceidle > iCloud does support IDLE but doesn't advertise it AFAIK, so it you want idle, you'll have to use the forceidle thingy (and it's only supported by recent versions of fetchmail) You will also have to generate an app specific password on appleid.apple.com . On Sat, Mar 5, 2022 at 9:58 AM Jon Brinkmann <bri...@nm...> wrote: > I'd like to use fetchmail with iCloud via IMAP. The Apple support page > https://support.apple.com/en-us/HT202304 gives relevant information. > I found nothing specific to this on the web or our forum. > > Does anyone have a working configuration file to share? > > Jon > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users > |
|
From: Jon B. <bri...@nm...> - 2022-03-05 17:57:11
|
I'd like to use fetchmail with iCloud via IMAP. The Apple support page https://support.apple.com/en-us/HT202304 gives relevant information. I found nothing specific to this on the web or our forum. Does anyone have a working configuration file to share? Jon |
|
From: Matthias A. <mat...@gm...> - 2022-03-05 16:26:47
|
The 6.4.28 release of fetchmail is now available from <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. It updates the Spanish translation, courtesy of Cristian Othón Martínez Vera. DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3, and you may want to review COPYING. NOTE that LibreSSL licensing is incompatible with fetchmail's, as there is no GPL clause 2(b) exception for LibreSSL, so LibreSSL can only be used where it is part of the operating system (one of the very few examples is OpenBSD). The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.28.tar.xz/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.28.tar.lz/download> The detached GnuPG signature is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.28.tar.xz.asc/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.28.tar.lz.asc/download> The SHA256 hashes for the tarballs are: SHA256(fetchmail-6.4.28.tar.xz)= a003f9ac88bf083a232c9451ef5f3f88473fad2c7f2822d3f7455a6d32bc3a97 SHA256(fetchmail-6.4.28.tar.lz)= 5ba7ea053772b8eafa65cd410656225ec5ced8b51e47296fb11c31a7940ad423 Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.4.28 (released 2022-03-05, 31661 LoC): # TRANSLATIONS: language translations were updated by this fine person: * es: Cristian Othón Martínez Vera [Spanish] -------------------------------------------------------------------------------- Happy fetches, Matthias |
|
From: Matthias A. <mat...@gm...> - 2022-03-04 20:15:47
|
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. |
|
From: joe a <joe...@j4...> - 2022-03-04 17:08:02
|
Pardon the formatting of this reply. For some reason I did not get a copy of my post and the reply and has to find them in the archives.
I do get the announcements, however.
It seems simplest for me to just try forwarding my gmail, rather than struggle with the alternatives.
Thanks for the information.
joe a.
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.
> 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?
X(O)Auth 2.0 authentication *is* more complex than traditional methods
and documentation could be better.
I actually get gmail to forward my email to my real account.
--
Andrew C. Aitchison Kendal, UK
an...@ai...
|
|
From: Andrew C A. <fet...@ai...> - 2022-03-04 16:36:19
|
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. > 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? X(O)Auth 2.0 authentication *is* more complex than traditional methods and documentation could be better. I actually get gmail to forward my email to my real account. -- Andrew C. Aitchison Kendal, UK an...@ai... |
|
From: joe a <joe...@j4...> - 2022-03-04 15:56:35
|
Received the email below from Google (links deleted). What does this mean for Fetchmail? A quick search turned up "not much". 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? ********************************** On May 30, you may lose access to apps that are using less secure sign-in technology aa...@gm... To help keep your account secure, Google will no longer support the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password. Instead, you’ll need to sign in using Sign in with Google . . or other more secure technologies, like OAuth 2.0. . . . ------------------------------ *What do you need to do?* *Email software, like Outlook 2016 or earlier,* has less secure access to your Gmail. Switch to Office 365, Outlook 2019 or newer, or any other email software where you can sign in using *Sign in with Google*. Learn more. . . You received this email to let you know about important changes to your Google Account and services. ********************************** joe a |
|
From: Matthias A. <mat...@gm...> - 2022-02-28 01:50:59
|
The 6.4.27 release of fetchmail has been available for a month <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. I seem not to have mailed out the announcement... ...and upgrading is not really essential from 6.4.26. Do note that when using with wolfSSL that you pull in its security fix, and unless you've linked wolfSSL dynamically, rebuild fetchmail. DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3, and you may want to review COPYING. NOTE that LibreSSL licensing is incompatible with fetchmail's, as there is no GPL clause 2(b) exception for LibreSSL, so LibreSSL can only be used where it is part of the operating system (one of the very few examples is OpenBSD). The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.27.tar.xz/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.27.tar.lz/download> The detached GnuPG signature is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.27.tar.xz.asc/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.27.tar.lz.asc/download> The SHA256 hashes for the tarballs are: SHA256(fetchmail-6.4.27.tar.xz)= 9e64f9e71f798cf1fe2278b84e2f5880b806527c0c0206925c086ccd179113dc SHA256(fetchmail-6.4.27.tar.lz)= 09e3818043c40d0eeb53565ff0d9aca657ff3de3950a378f699aec984f28a335 Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.4.27 (released 2022-01-26, 31661 LoC): # BREAKING CHANGES: * Bump wolfSSL minimum required version to 5.1.1 to pull in security fix. # TRANSLATIONS: language translations were updated by this fine person: * ro: Remus-Gabriel Chelu [Romanian] -------------------------------------------------------------------------------- Happy fetches, Matthias |
|
From: Matthias A. <mat...@gm...> - 2022-02-28 01:44:54
|
Greetings, The 6.5.0.beta7 release of fetchmail is now available at <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.beta7.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.beta7.tar.xz.asc/download> The SHA256 hash for the tarball is: SHA256(fetchmail-6.5.0.beta7.tar.xz)= ec7c7b1af74e6cf8b4011bbe4f270796775e9db672a731bc68980124b91d0133 Here are the release notes: =------------------------------------------------------------------------------- fetchmail-6.5.0.beta7: (since .beta6): # ADDITIONS: * There is now a --forceidle feature to force idle mode even if not advertised in the server capabilities. This is a dangerous option, use it carefully. Courtesy of Eric Durand, GitLab merge request !39. * rcfile parsing errors are now reported in more detail, and with -vv mode, also lead to a non-importable Python dump of what was obtained, for debugging. =------------------------------------------------------------------------------- fetchmail-6.4.22...27 were merged into .beta7, highlights: # BREAKING CHANGES: * Since distributions continue patching for LibreSSL use, which cannot be linked legally, block out LibreSSL in configure.ac and socket.c, and refer to COPYING, unless on OpenBSD (which ships it in the base system). OpenSSL and wolfSSL 5 can be used. SSL-related documentation was updated, do re-read COPYING, INSTALL, README, README.packaging, README.SSL. Note that distribution of packages linked with LibreSSL is not feasible due to a missing GPLv2 clause 2(b) exception. fetchmail can now be used with wolfSSL 5.1.1's OpenSSL compatibility layer, see INSTALL and README.SSL. This is considered experimental. Feedback solicited. # OPENSSL AND LICENSING NOTE: * fetchmail 6.5.0 is compatible with OpenSSL 1.1.1 and 3.0.0. OpenSSL's licensing changed between these releases from dual OpenSSL/SSLeay license to Apache License v2.0, which is considered incompatible with GPL v2 by the FSF. For implications and details, see the file COPYING. # ADDITIONS: * Added an example systemd unit file and instructions to contrib/systemd/ which runs fetchmail as a daemon with 5-minute poll intervals. Courteously contributed by Barak A. Pearlmutter, Debian Bug#981464. # CHANGES: * ./configure --with-ssl now supports pkg-config module names, too. See INSTALL. * IMAP: When fetchmail is in not-authenticated state and the server volunteers CAPABILITY information, use it and do not re-probe. (After STARTTLS, fetchmail must and will re-probe explicitly.) * fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997 recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer, placing --sslproto tls1.2+ more prominently. # SECURITY FIXES: * CVE-2021-39272: fetchmail-SA-2021-02: On IMAP connections, without --ssl and with nonempty --sslproto, meaning that fetchmail is to enforce TLS, and when the server or an attacker sends a PREAUTH greeting, fetchmail used to continue an unencrypted connection. Now, log the error and abort the connection. --Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on a dedicated port (default 993): use --ssl, or the ssl user option in an rcfile. --Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. The paper did not mention fetchmail. * This allows STARTTLS in more scenarios, but also hardens against bypassing. # BUG FIXES: * Fetchmail no longer crashes when attempting a connection with --plugin "" or --plugout "". * Fetchmail no longer leaks memory when processing the arguments of --plugin or --plugout on connections. * On POP3 connections, the CAPAbilities parser is now caseblind. * Fix segfault on configurations with "defaults ... no envelope". Reported by Bjørn Mork. Fixes Debian Bug#992400. This is a regression in fetchmail 6.4.3 and happened when plugging memory leaks, which did not account for that the envelope parameter is special when set as "no envelope". The segfault happens in a constant strlen(-1), triggered by trusted local input => no vulnerability. * Fix program abort (SIGABRT) with "internal error" when invalid sslproto is given with OpenSSL 1.1.0 API compatible SSL implementations. ================================================================================ |
|
From: Matthias A. <mat...@gm...> - 2022-01-30 20:28:06
|
Am 30.01.22 um 04:52 schrieb grarpamp: > > Existance of 8601 allows apps to advertise they are > using a standard format, that the world has agreed > through ISO process, by default for any timestamps > that may be present in the apps logs. But since there > are no such shipped LC_TIME, and locale does not split > between GUI and log, the apps have to do the log, > letting user override via some app config. > "Locales" are meant for use in equivalent of > human interface / display / GUI, but are pain > in the ass trying to make them serve for log > since they require reversing tools to do anything > programmatic with, if they are even parseable > at all due to other log problems in the apps. It's as simple as "if your log is in a locale I do not understand, I am not supporting you". Review https://www.fetchmail.info/fetchmail-FAQ.html#G3 again and find it enforces LC_ALL=C to stomp over everything with the master switch and get me the ANSI-C locale. Available everywhere since 30+ years. And while the C standard %a %b %e %H:%M:%S %Y is neither ISO8601 nor logical, it is usable. I am the programmer you know... > People who never had to look at, digest, parse, > filter, sort, merge, store, extract, etc all sorts > of logs, unfortunately often may not yet appreciate > the wisdom of using 8601 for logs. 8601 serves > both the programming and reading purposes in logs. ...and there is something called "compatibility" on the other side of the scales. It will likely happen, but not before fetchmail 7. Please file a *short* reminder (don't write an epic) on the Gitlab project site, milestone 7.0, with just "consider switching date-and-time formats to ISO8601" and reference the mailing list archive for this thread, and possibly two or three bullet points with the key items, that's enough. |
|
From: joea- l. <joe...@j4...> - 2022-01-30 16:37:28
|
Thanks for the reply. The latter part of your post was difficult for me to comprehend. However, I believe the issue is related to how fetchmail deals with the date/time as by altering the environment the daemon "runs in", the time stamp was altered. But, in line below, I will attempt to address your questions: > What platform? Opensuse 15.2 (Carlos mentioned 15.3, but that was a test VM I spun up to compare the vendor supplied rendition of fetchmail "as installed" to my own setup. That bought up some other questions I may address in the appropriate forum. > $ uname -a Linux AAAAAA 5.3.18-lp152.87-default #1 SMP Sun Aug 8 21:53:57 UTC 2021 (44d702a) x86_64 x86_64 x86_64 GNU/Linux (AAAAAA replaces what I took to be the host name) > > What are the defaults? > > $ env - locale > $ env - locale -k d_t_fmt > $ locale > $ locale -k d_t_fmt locale LANG=POSIX LC_CTYPE=en_US.UTF-8 LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= locale -k d_t_fmt d_t_fmt="%a %b %e %H:%M:%S %Y" > The leading zero "03 PM" seems unusual at first sight, > perhaps check if it is platform specific... > %0* GNU libc extension. Explicitly specify zero for padding. As mentioned changing the fetchmail running environment as shown below in a snippet of my systemd fetchmail unit file gives me a 24 hr format. There may be other ways to address the format without changing the "language" but I am currently not aware of them. [Service] Type=simple . . . Environment=LC_TIME=en_GB.UTF-8 User=fetchmail Group=fetchmail . . . joe a. |
|
From: Carlos E. R. <rob...@te...> - 2022-01-30 12:39:06
|
On 2022-01-30 04:52, grarpamp wrote: > What platform? He was using openSUSE Leap 15.3 the other day. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) |
|
From: grarpamp <gra...@gm...> - 2022-01-30 03:52:19
|
What platform?
$ uname -a
What are the defaults?
$ env - locale
$ env - locale -k d_t_fmt
$ locale
$ locale -k d_t_fmt
The leading zero "03 PM" seems unusual at first sight,
perhaps check if it is platform specific...
%0* GNU libc extension. Explicitly specify zero for padding.
https://pubs.opengroup.org/onlinepubs/9699919799/
>> https://wiki.archlinux.org/title/Locale#LC_TIME:_date_and_time_format
>> locale(7)
> No change.
LC_TIME can only pick from locales predefined in
the system, which may not contain what is sought.
And randomly picking different locales outside the
users locale, to get 24h or 8601, such as Arch
webpage suggests, can change other things along
with it, compare the definitions to see.
To get standard iso8601, or 24h, both of which are
nominally independent from language and country,
users may need to customize or create a locale.
Locale's honored only if the app calls the libraries.
See: sleeping at timestamp()
https://www.freebsd.org/cgi/man.cgi?query=localedef
https://www.freebsd.org/cgi/man.cgi?query=locale
https://www.freebsd.org/cgi/man.cgi?query=setlocale
https://www.freebsd.org/cgi/man.cgi?query=strftime
https://www.freebsd.org/cgi/man.cgi?query=environ
On that platform...
env - LC_ALL=C TZ=UTC locale -k d_t_fmt
d_t_fmt="%a %b %e %H:%M:%S %Y"
env - LC_ALL=C TZ=UTC ./fetchmail -v 127.0.0.1
fetchmail: 6.4.27 querying 127.0.0.1 (protocol auto) at Sun Jan 30
xx:xx:xx 2022: poll started
env - LC_ALL=en_GB.UTF-8 TZ=UTC locale -k d_t_fmt
d_t_fmt="%a %e %b %X %Y"
env - LC_ALL=en_GB.UTF-8 TZ=UTC ./fetchmail -v 127.0.0.1
fetchmail: 6.4.27 querying 127.0.0.1 (protocol auto) at Sun 30 Jan
xx:xx:xx 2022: poll started
env - LC_ALL=ru_RU.UTF-8 TZ=UTC locale -k d_t_fmt
d_t_fmt="%A, %e %B %Y г. %X"
env - LC_ALL=ru_RU.UTF-8 TZ=UTC ./fetchmail -v 127.0.0.1
fetchmail: 6.4.27 запрашивает 127.0.0.1 (протокол auto) на
воскресенье, 30 января 2022 г. xx:xx:xx: опрос начат
env - LC_ALL=iso8601 TZ=UTC locale -k d_t_fmt
d_t_fmt="%Y%m%dT%H%M%S%z"
env - LC_ALL=iso8601 TZ=UTC ./fetchmail -v 127.0.0.1
fetchmail: 6.4.27 querying 127.0.0.1 (protocol auto) at
20220130Txxxxxx+0000: poll started
8601 uses 24h per standard.
Existance of 8601 allows apps to advertise they are
using a standard format, that the world has agreed
through ISO process, by default for any timestamps
that may be present in the apps logs. But since there
are no such shipped LC_TIME, and locale does not split
between GUI and log, the apps have to do the log,
letting user override via some app config.
"Locales" are meant for use in equivalent of
human interface / display / GUI, but are pain
in the ass trying to make them serve for log
since they require reversing tools to do anything
programmatic with, if they are even parseable
at all due to other log problems in the apps.
People who never had to look at, digest, parse,
filter, sort, merge, store, extract, etc all sorts
of logs, unfortunately often may not yet appreciate
the wisdom of using 8601 for logs. 8601 serves
both the programming and reading purposes in logs.
YMMV...
cat */LC_TIME | sort | uniq -c | sort -nr
131 %a %e %b %X %Y
20 %a %b %e %X %Y
8 %a %b/%e %T %Y
4 %d %b %Y %X
3 %x %A %X
3 %b %d %Y %X
3 %a %_m/%e %T %Y
3 %Y - %b - %e %a %X
2 %e. %b, %Y. gads %X
2 %a %e %b %Y %X
2 %a %d %b %Y %X
2 %A, %e %B %Y �. %X
1 %Y%m%dT%H%M%S%z
1 %Y оны %B сарын %e, %A гараг, %X
1 %A, %e %B %Y �. %X
1 %A, %e %B %Y ի. %X
1 %A, %e %B %Y �. %X
1 %A, %e %B %Y ж. %X
1 %A, %e %B %Y г. %X
1 %A, %e %B %Y �. %X
1 %A %e %B %Y %H:%M:%S
1 %A %e %B %Y %H:%M.%S
|
|
From: Carlos E. R. <rob...@te...> - 2022-01-29 19:27:52
|
On 2022-01-29 17:17, joea- lists wrote: > Other logs and terminal display all show 24hr format.with no > alterations > to environment settings. Most other logs in openSUSE are written by syslog, which uses a different system. Journal aside. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) |
18 messages has been excluded from this view by a project administrator.
