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
|
Oct
|
Nov
|
Dec
|
From: Matthias A. <mat...@gm...> - 2024-07-20 09:42:16
|
The 6.4.39 release of fetchmail is now available at the usual locations, including <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.xz/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.lz/download> The detached GnuPG signature is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.xz.asc/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.lz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.4.39.tar.xz)= 75109a1f307b538155fa05f5ef298e8298cb4deae95aed24c16b38d36ff0a186 SHA2-256(fetchmail-6.4.39.tar.lz)= 657ff8655860e649c0863eb942eda1668d4f20f72263129622829e60c018854b Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.4.39 (released 2024-07-20, 31729 LoC): # BUG FIXES: * When a server offers STARTTLS although the connection is already wrapped in TLS, fetchmail would issue a bogus "WARNING: server offered STARTTLS but sslproto '' given." (or STLS for POP3). In situations where we wrap the connection in TLS, suppress the warning. Reported by Mike Pope. * If fetchmail was running localized, generate an error e-mail message locally, and if the selected translation would require the Subject: line to wrap inside an RFC-2047 encoded word (=?UTF-8?Q?...?=), the wrapped encoded-word was not indented, thus not marked as a continuation line. -------------------------------------------------------------------------------- |
From: Matthias A. <mat...@gm...> - 2024-06-25 17:05:17
|
Am 25.06.24 um 19:01 schrieb Matthias Andree via Fetchmail-users: > Am 25.06.24 um 03:53 schrieb Michael Pope: >>> 1- a genuine issue with authentication (did the service change login >> policies? >> >> I fear there may have been a "quiet change" at the provider. My >> credentials are correct/unchanged for their webmail. > > Yep. I find it most confusing though that the server would offer > STARTTLS in spite of having already negotiated TLS. This seems to be a > first to be seen in the wild and reported - and this is what confused > fetchmail, which simply does not expect to see STARTTLS offered on a TLS > connection, and also would not use it, nor would that make sense. It > might be a configuration issue on your provider's servers. None of the > servers I've read conversations of would offer STARTTLS on a TLS-wrapped > connection. > >>> 2- fetchmail misreporting the authentication failure with that WARNING >> OK, sslproto is (probably) correct, and that warning is incorrect. Is >> there any other logging/warning/error configuration I can try to get >> better >> debugging of why authentication is failing? Does fetchmail only see a >> success/fail, or is the next step to fire up wireshark:-)? > > There isn't anything you can do but checking the provider's help and > news pages or contacting them. > > The very first communication is the successful negotiation of TLS v1.2, > and after receiving the initial prompt, the first command that fetchmail > tries is A0001 LOGIN with your user and password, and that fails. > This is the *entire* conversation after the SSL negotiation, and > WireShark is not going to give you anything useful because fetchmail has > the cleartext conversation, but Wireshark only has the encrypted stuff, > and decoding that would be quite a bit of a hassle and a distraction > because you already have it... > https://wiki.wireshark.org/TLS#tls-decryption > Oh - and one more thing, since OpenSSL negotiated > fetchmail: SSL/TLS: using protocol TLSv1.2, cipher > ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits Wireshark cannot even decrypt that conversation according to the wiki page I've linked above. >> fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID >> ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] imap >> ready - cma-tmc >> fetchmail: IMAP> A0001 LOGIN "mpope" * >> fetchmail: IMAP< A0001 NO [AUTHENTICATIONFAILED] Authentication failed. > So... your provider will need to support you. > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users |
From: Matthias A. <mat...@gm...> - 2024-06-25 17:02:06
|
Am 25.06.24 um 03:53 schrieb Michael Pope: >> 1- a genuine issue with authentication (did the service change login > policies? > > I fear there may have been a "quiet change" at the provider. My > credentials are correct/unchanged for their webmail. Yep. I find it most confusing though that the server would offer STARTTLS in spite of having already negotiated TLS. This seems to be a first to be seen in the wild and reported - and this is what confused fetchmail, which simply does not expect to see STARTTLS offered on a TLS connection, and also would not use it, nor would that make sense. It might be a configuration issue on your provider's servers. None of the servers I've read conversations of would offer STARTTLS on a TLS-wrapped connection. >> 2- fetchmail misreporting the authentication failure with that WARNING > OK, sslproto is (probably) correct, and that warning is incorrect. Is > there any other logging/warning/error configuration I can try to get better > debugging of why authentication is failing? Does fetchmail only see a > success/fail, or is the next step to fire up wireshark:-)? There isn't anything you can do but checking the provider's help and news pages or contacting them. The very first communication is the successful negotiation of TLS v1.2, and after receiving the initial prompt, the first command that fetchmail tries is A0001 LOGIN with your user and password, and that fails. This is the *entire* conversation after the SSL negotiation, and WireShark is not going to give you anything useful because fetchmail has the cleartext conversation, but Wireshark only has the encrypted stuff, and decoding that would be quite a bit of a hassle and a distraction because you already have it... https://wiki.wireshark.org/TLS#tls-decryption > fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID > ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] imap > ready - cma-tmc > fetchmail: IMAP> A0001 LOGIN "mpope" * > fetchmail: IMAP< A0001 NO [AUTHENTICATIONFAILED] Authentication failed. So... your provider will need to support you. |
From: Peter P. <ro...@ri...> - 2024-06-25 09:55:11
|
On Tue, Jun 25, 2024 at 11:10:31AM +0200, Carlos E. R. wrote: > On 2024-06-25 03:55, q17nsisr--- via Fetchmail-users wrote: > > Greetings fetchmail-users mailing list!! > > > > My mail fetching setup currently looks like this: > > remote mail server <-> fetch <-> local maildir <-> local mail server <-> local e-mail client > > > > Where email on the remote mail server is pgp/mime encrypted with the subject header hidden or replaced as supported by several of the email services listed below: > > https://www.privacyguides.org/en/email/ - Encrypted Private Email Recommendations - Privacy Guides > > https://www.privacyguides.org/en/email-aliasing/ - Email Aliasing - Privacy Guides > > > > I would like to alter the "... <-> fetch <-> local maildir <-> ..." part of my mail fetching setup so that the fetched email is automatically decrypted during or after the fetching process and before this mail is seen by the local mail server or email client. > > Does anyone on this mailing list have any advice or tips for doing this? > > Probably adding procmail and maybe formail. SCNR, but I would really, really, really strongly recommend against using procmail in the year 2024. Maildrop has a clear, easy to learn syntax, and it makes it much harder to make a mistake writing a rule or to forget about any kind of unspecified default behavior. Also, I think the real issue here would be the fact that unattended decryption would mean that there is a copy of the OpenPGP key that is either stored somewhere unprotected (no passphrase), or is loaded into some kind of agent, again, unprotected in memory. In either case this opens an avenue of attack for Somebody(tm) to use that unprotected copy of the key, either for decrypting other encrypted material they have obtained, or, if the key has multiple capabilities, even for signing things. Once that is dealt with (and "I don't care" is a way to deal with it, albeit one that I would very strong discourage), there is also the interesting aspect of making sure that the decrypted messages do NOT go into the same maildir or IMAP folder or whatever as any unencrypted messages received, because then there would be no way to tell if a certain message was encrypted and decrypted or just looks like one. There is also an additional interesting aspect that OpenPGP messages have more data in the OpenPGP structure, such as integrity hashes, possibly a signature from the sender, etc, and some of that data may be lost if only the decrypted copy is saved. G'luck, Peter -- Peter Pentchev ro...@ri... ro...@de... pe...@mo... PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 |
From: Carlos E. R. <rob...@te...> - 2024-06-25 09:10:46
|
On 2024-06-25 03:55, q17nsisr--- via Fetchmail-users wrote: > Greetings fetchmail-users mailing list!! > > My mail fetching setup currently looks like this: > remote mail server <-> fetch <-> local maildir <-> local mail server <-> local e-mail client > > Where email on the remote mail server is pgp/mime encrypted with the subject header hidden or replaced as supported by several of the email services listed below: > https://www.privacyguides.org/en/email/ - Encrypted Private Email Recommendations - Privacy Guides > https://www.privacyguides.org/en/email-aliasing/ - Email Aliasing - Privacy Guides > > I would like to alter the "... <-> fetch <-> local maildir <-> ..." part of my mail fetching setup so that the fetched email is automatically decrypted during or after the fetching process and before this mail is seen by the local mail server or email client. > Does anyone on this mailing list have any advice or tips for doing this? Probably adding procmail and maybe formail. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar) |
From: <q17...@du...> - 2024-06-25 01:55:35
|
Greetings fetchmail-users mailing list!! My mail fetching setup currently looks like this: remote mail server <-> fetch <-> local maildir <-> local mail server <-> local e-mail client Where email on the remote mail server is pgp/mime encrypted with the subject header hidden or replaced as supported by several of the email services listed below: https://www.privacyguides.org/en/email/ - Encrypted Private Email Recommendations - Privacy Guides https://www.privacyguides.org/en/email-aliasing/ - Email Aliasing - Privacy Guides I would like to alter the "... <-> fetch <-> local maildir <-> ..." part of my mail fetching setup so that the fetched email is automatically decrypted during or after the fetching process and before this mail is seen by the local mail server or email client. Does anyone on this mailing list have any advice or tips for doing this? |
From: Michael P. <mpo...@gm...> - 2024-06-25 01:54:13
|
> 1- a genuine issue with authentication (did the service change login policies? I fear there may have been a "quiet change" at the provider. My credentials are correct/unchanged for their webmail. > 2- fetchmail misreporting the authentication failure with that WARNING OK, sslproto is (probably) correct, and that warning is incorrect. Is there any other logging/warning/error configuration I can try to get better debugging of why authentication is failing? Does fetchmail only see a success/fail, or is the next step to fire up wireshark:-)? Cheers, Mike Pope |
From: Matthias A. <mat...@gm...> - 2024-06-24 21:33:10
|
Am 23.06.24 um 08:56 schrieb Michael Pope: > I am currently unable to collect mail from a mail provider. This has > worked in the past. The line in the logs: > fetchmail: imap.themessagingco.com.au: WARNING: server offered STARTTLS > but sslproto '' given. > looks pretty suspicious. > > OS: Fedora 40 Linux > Package: fetchmail-6.4.38-1.fc40.x86_64 > MDA: procmail, though it never gets called > Command line: just "fetchmail", however .fetchmailrc is: > > poll imap.themessagingco.com.au protocol IMAP port 993 > auth password > user "mpope" password "*********" > ssl sslproto tls1.2+ sslcertck > mda "/usr/bin/procmail -o -d mpope" > > LC_ALL=C fetchmail -V: attached as fet1.log > LC_ALL=C fetchmail --nodetach -vvv --nosyslog: attached as fet2.log I have received the logs off-list, and the crucial part is: > fetchmail: SSL/TLS: using protocol TLSv1.2, cipher > ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits > fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID > ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] imap > ready - cma-tmc > fetchmail: Protocol identified as IMAP4 rev 1 > fetchmail: will idle after poll > fetchmail: found updated capabilities list > fetchmail: imap.themessagingco.com.au: WARNING: server offered > STARTTLS but sslproto '' given. > fetchmail: IMAP> A0001 LOGIN "mpope" * > fetchmail: IMAP< A0001 NO [AUTHENTICATIONFAILED] Authentication failed. > fetchmail: IMAP> A0002 LOGOUT > fetchmail: IMAP< * BYE Logging out > fetchmail: IMAP< A0002 OK Logout completed. > fetchmail: 6.4.38 querying imap.themessagingco.com.au (protocol IMAP) > at Sun Jun 23 16:16:45 2024: poll completed Meaning there is 1- a genuine issue with authentication (did the service change login policies? Did someone or something change your password without your knowing? Opt in to two-factor authentication or app passwords? In such a case, you should create that app password for your IMAP clients and use the app password in fetchmail), this is something you need to actively sort out. It seems the starting point for your mail service provider would be https://support.themessaging.co/hc/en-au/categories/21520592100633-How-do-I and then read through the pages linked underneath "Password and Security Management". This is unrelated to the warning you are seeing. 2- fetchmail misreporting the authentication failure with that WARNING and confusing you. The program behaves correctly and aborts the poll after authentication failure, but the warning you've seen clearly is a bug. I need to fix that for a future release. That's not just a five-minute thing though because the authentication driver is a touch nontrivial for a code - with a few more ifs and thens. Thanks for taking the time to report this, I've made a Gitlab issue from it: https://gitlab.com/fetchmail/fetchmail/-/issues/64 Best regards, Matthias |
From: Matthias A. <mat...@gm...> - 2024-06-23 11:04:17
|
Am 23.06.24 um 08:56 schrieb Michael Pope: > I am currently unable to collect mail from a mail provider. This has > worked in the past. The line in the logs: > fetchmail: imap.themessagingco.com.au: WARNING: server offered STARTTLS > but sslproto '' given. > looks pretty suspicious. > > OS: Fedora 40 Linux > Package: fetchmail-6.4.38-1.fc40.x86_64 > MDA: procmail, though it never gets called > Command line: just "fetchmail", however .fetchmailrc is: > > poll imap.themessagingco.com.au protocol IMAP port 993 > auth password > user "mpope" password "*********" > ssl sslproto tls1.2+ sslcertck > mda "/usr/bin/procmail -o -d mpope" > > LC_ALL=C fetchmail -V: attached as fet1.log > LC_ALL=C fetchmail --nodetach -vvv --nosyslog: attached as fet2.log Mike, the list appears to strip off binary attachments, and many mailers declare attachments as binary regardless of the content. Sorry for the inconvenience - but please send the logs to me off-list/directly and I'll have a look and see if I can do something (at least fixing the error message to match the situation, which it clearly does not in your case). Seems there is one corner case in the imap.c code that might be a logic bug. A log would help identifying this. Sorry again. Best regards, Matthias -- Matthias Andree |
From: Michael P. <mpo...@gm...> - 2024-06-23 06:56:37
|
I am currently unable to collect mail from a mail provider. This has worked in the past. The line in the logs: fetchmail: imap.themessagingco.com.au: WARNING: server offered STARTTLS but sslproto '' given. looks pretty suspicious. OS: Fedora 40 Linux Package: fetchmail-6.4.38-1.fc40.x86_64 MDA: procmail, though it never gets called Command line: just "fetchmail", however .fetchmailrc is: poll imap.themessagingco.com.au protocol IMAP port 993 auth password user "mpope" password "*********" ssl sslproto tls1.2+ sslcertck mda "/usr/bin/procmail -o -d mpope" LC_ALL=C fetchmail -V: attached as fet1.log LC_ALL=C fetchmail --nodetach -vvv --nosyslog: attached as fet2.log Cheers, Mike Pope |
From: Carlos E. R. <rob...@te...> - 2024-05-18 16:13:57
|
On 2024-05-18 17:11, Matthias Andree via Fetchmail-users wrote: > Am 18.05.24 um 14:42 schrieb Carlos E. R. >> On 2024-05-13 23:31, Matthias Andree via Fetchmail-users wrote: >>> Am 11.05.24 um 15:40 schrieb Andrew C Aitchison: ... >>> Yep. And all the while they are doing that, EC is considering if they >>> want to ban calling apps "less secure" if whatever. >> >> Sorry, what or who is "EC"? > > European Commission, the executive body of the European Union. Ah! That move would be nice of them :-) -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar) |
From: Matthias A. <mat...@gm...> - 2024-05-18 15:11:12
|
Am 18.05.24 um 14:42 schrieb Carlos E. R. > On 2024-05-13 23:31, Matthias Andree via Fetchmail-users wrote: >> Am 11.05.24 um 15:40 schrieb Andrew C Aitchison: >>> >>> Executive Summary: >>> >>> Google Less Secure Apps (LSA) will be turned off in two stages: >>> Beginning June 15, 2024: >>> No new accounts >>> Beginning September 30, 2024: >>> Access to LSAs will be turned off for all Google Workspace >>> accounts. >>> >>> OAuth and App Password access to smtp/imap/pop etc. will continue. >>> >>> https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-le$ >>> >>> >>> >> Yep. And all the while they are doing that, EC is considering if they >> want to ban calling apps "less secure" if whatever. > > Sorry, what or who is "EC"? European Commission, the executive body of the European Union. |
From: Carlos E. R. <rob...@te...> - 2024-05-18 12:58:17
|
On 2024-05-13 23:31, Matthias Andree via Fetchmail-users wrote: > Am 11.05.24 um 15:40 schrieb Andrew C Aitchison: >> >> Executive Summary: >> >> Google Less Secure Apps (LSA) will be turned off in two stages: >> Beginning June 15, 2024: >> No new accounts >> Beginning September 30, 2024: >> Access to LSAs will be turned off for all Google Workspace >> accounts. >> >> OAuth and App Password access to smtp/imap/pop etc. will continue. >> >> https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-le$ >> >> > Yep. And all the while they are doing that, EC is considering if they > want to ban calling apps "less secure" if whatever. Sorry, what or who is "EC"? > I don't really > care. Fetchmail isn't "less secure" because it doesn't bring the web > browser that requires 100 security fixes every month, quite the > contrary. We've had Kerberos/GSSAPI for ages. > > So then, app password access it will be. > > https://support.google.com/mail/answer/185833?hl=en&sjid=3175199933505007620-EU#app-passwords -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar) |
From: Matthias A. <mat...@gm...> - 2024-05-18 09:16:12
|
Am 15.05.24 um 21:01 schrieb Lucio Chiappetti: > On Mon, 13 May 2024, Matthias Andree wrote: > >> So then, app password access it will be. > > Yes, insofar it works. > > I do not really understand in what an app password is different from > any other password (though I never dared trying it with webmail > access, which I do extremely seldom). Lucio, The idea behind "app passwords" is that * they give only limited access for *one* particular service or sub-area of the entire suite of services of some larger offering. Like, you cannot log into your Google account, or Google Meet, or use this app password to change your global account password, etc. (That is assuming you keep your recovery e-mail address separate from a service you can access with this app password for email.) * they are not subject to two-factor authentication (2FA), so easier to set up for an application that cannot do 2FA or where trusted. > > I feel inclined IMVHO to thin[k] G*** itself is a PITA. Just yesterday > I added a cousin's address to a series of crontab for birthday wishes > (used since years), and it bounced because of an SPF error. Apparently > this was due to the fact mailx (the MUA used by crontab) issued a From > of the form us...@ma...main (while alpine uses user@domain which > passes SPF on the SMTP for the domain). A mailx -r cured it. For my own convenience, on my computers, I have added SPF workarounds such that I usually set up source-address-based routing to the SMTP submission server [mail.gmx.net]:submission, and authentication to my Postfix ages ago to overcome this SPF madness. |
From: Lucio C. <lu...@la...> - 2024-05-15 19:21:36
|
On Mon, 13 May 2024, Matthias Andree wrote: > So then, app password access it will be. Yes, insofar it works. I do not really understand in what an app password is different from any other password (though I never dared trying it with webmail access, which I do extremely seldom). Currently I use app password for *occasional* Gsuite checks from my alpine MUA (for spam folder once per day, or for mail "in transit" before it is fetchmailed). I could use the same app password with fetchmail, but I preferred to forward Gsuite mail to a third party and fetch it from there. I feel inclined IMVHO to thing G*** itself is a PITA. Just yesterday I added a cousin's address to a series of crontab for birthday wishes (used since years), and it bounced because of an SPF error. Apparently this was due to the fact mailx (the MUA used by crontab) issued a From of the form us...@ma...main (while alpine uses user@domain which passes SPF on the SMTP for the domain). A mailx -r cured it. -- Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "All that is google does not glitter Nor all who use alpine/procmail are lost" |
From: Matthias A. <mat...@gm...> - 2024-05-14 23:12:04
|
The 6.5.0.beta10 release of fetchmail is now available at the usual location, <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta10.tar.xz/download> The detached GnuPG signature is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta10.tar.xz.asc/download> The SHA256 hash for the tarball is: SHA2-256(fetchmail-6.5.0.beta10.tar.xz)= 1c818b87ccd6cde10b18e55bb30e2ce9dca9c4cc28be699fd436c4eab87ac636 ============================================================================ |
From: <rb...@al...> - 2024-05-14 17:14:37
|
FWIW I got an app password from Google years ago and had no trouble since. I still haven't figured out how to fetchmail from an Outlook server, which may be my incompetence. russell bell |
From: Matthias A. <mat...@gm...> - 2024-05-13 21:31:26
|
Am 11.05.24 um 15:40 schrieb Andrew C Aitchison: > > Executive Summary: > > Google Less Secure Apps (LSA) will be turned off in two stages: > Beginning June 15, 2024: > No new accounts > Beginning September 30, 2024: > Access to LSAs will be turned off for all Google Workspace > accounts. > > OAuth and App Password access to smtp/imap/pop etc. will continue. > > https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-le$ > > Yep. And all the while they are doing that, EC is considering if they want to ban calling apps "less secure" if whatever. I don't really care. Fetchmail isn't "less secure" because it doesn't bring the web browser that requires 100 security fixes every month, quite the contrary. We've had Kerberos/GSSAPI for ages. So then, app password access it will be. https://support.google.com/mail/answer/185833?hl=en&sjid=3175199933505007620-EU#app-passwords |
From: graeme v. <gra...@ve...> - 2024-05-12 21:23:48
|
>> >> It would be helpful in in verbose mode at least it indicated that the >> error was being ignored. Because I my case >> >> it failed right after that error and it was not immediately obvious >> that it had been ignored. Lost of time chasing the wrong error message. > > Sorry for that, yes, we can do that. Pushed to the Git branch that will > spawn a 6.5 release in the future in commit db0fd264, example output: > Thanks for that. Obviously I'm now "in the know" about that message but hopefully it will help the next guy in this situation. >>> If that persists with any version since and including 6.4.34, let me >>> know. The trace as posted looks as though the server had not replied to >>> UIDL at all (which I find strange because fetchmail should wait for a >>> reply before sending TOP 1 1 to get the header of the first message), >>> but I am not going to look into bugs of older versions. >>> >> OK, I was not seeing this as a "bug" ... I took it to mean "you need >> to use UIDL if you're using pop3+keep" > > > This is the standing recommendation and best current practice, yes, but > the log looks strange. Anyways, we're not going to dig this up. > > >> >> FYI Have a Trixie system which offers 6.4.38-1 ... the mailbox is >> one I'm using for testing ...so it has nothing sensitive (even the >> password) >> >> if you would like me to run a test? > > It's just that I lack time to dig up if that would be a bug in 6.4.16 > that I've fixed since. Or whoever compiled your version had compiler > bugs. My policy is to update. So if 6.4.38 shows similar client/server > synchronization errors, let me know, and please provide those logs with > -vv options to fetchmail. > > From memory I did not think there was a "bug" here, simply that e.g. the man page could point out if you have pop3+keep you MUST use uidl (or something like that). I believe what you are saying is, you may well see a bug, but this is an old version so you're , understandably, not willing to dig back that far. I was pointing out, that one of my systems runs 6.4.38-1 (which is new enough to be worth looking at?) . If it would be useful I can run a test on that ? 1: Would it be useful 2: what test would you like me to run? (is it pop3+keep and no uidl? ..with -vv , or something more specific) |
From: Andrew C A. <fet...@ai...> - 2024-05-11 14:00:19
|
On Sat, 11 May 2024, Andrew C Aitchison wrote: > Executive Summary: > > Google Less Secure Apps (LSA) will be turned off in two stages: > Beginning June 15, 2024: > No new accounts > Beginning September 30, 2024: > Access to LSAs will be turned off for all Google Workspace accounts. > > OAuth and App Password access to smtp/imap/pop etc. will continue. Oops. Cut and paste failure. The correct address is: https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html?m=1 -- Andrew C. Aitchison Kendal, UK an...@ai... |
From: Andrew C A. <fet...@ai...> - 2024-05-11 13:53:04
|
Executive Summary: Google Less Secure Apps (LSA) will be turned off in two stages: Beginning June 15, 2024: No new accounts Beginning September 30, 2024: Access to LSAs will be turned off for all Google Workspace accounts. OAuth and App Password access to smtp/imap/pop etc. will continue. https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-le$ -- Andrew C. Aitchison Kendal, UK an...@ai... |
From: Matthias A. <mat...@gm...> - 2024-04-27 08:12:49
|
Am 23.04.24 um 22:30 schrieb Matthias Andree via Fetchmail-users: >> Apr 23 22:13:29 fetchmail: POP3< +OK send PASS >> Apr 23 22:13:29 fetchmail: POP3> PASS * >> Apr 23 22:13:29 fetchmail: POP3< +OK Welcome. >> Apr 23 22:13:29 fetchmail: POP3> STAT >> Apr 23 22:13:29 fetchmail: POP3< +OK 29 650667 >> Apr 23 22:13:29 fetchmail: POP3> LAST >> Apr 23 22:13:29 fetchmail: POP3< -ERR Not supported >> Apr 23 22:13:29 fetchmail: Not supported >> Apr 23 22:13:29 fetchmail: LAST is an obsolete command that many >> servers will not support. We will try modern means to find what >> messages are new. >> Apr 23 22:13:29 fetchmail: POP3> UIDL >> Apr 23 22:13:29 fetchmail: POP3< +OK >> Apr 23 22:13:29 fetchmail: POP3< 1 Id1516a57b9a0d4280 >> Apr 23 22:13:29 fetchmail: POP3< 2 Id1516a57ba7a71933 >> Apr 23 22:13:29 fetchmail: POP3< 3 Id1516a57bb8920733 > > I couldn't push this to sourceforge.net though (*), so only Gitlab > currently has it, see > https://gitlab.com/fetchmail/fetchmail/-/commit/db0fd264a85d11565b4abd20b0d7b6bbd4d77c23 I have now been able to push this to the Git repo on sourceforge.net, too. |
From: Matthias A. <mat...@gm...> - 2024-04-23 20:34:35
|
Am 09.04.24 um 16:18 schrieb Info: > Greeting all, > > How do I download Selected Remote Folder to Specific Local Folder > > For example: > Remote folder= INBOX.Sent > Local folder = INBOX/Sent > > > #========= fetchmail release =========# > > This is fetchmail release 6.4.37+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. > Compiled with SSL library 0x30000080 "OpenSSL 3.0.8 7 Feb 2023" > Run-time uses SSL library 0x300000b0 "OpenSSL 3.0.11 19 Sep 2023" > OpenSSL: OPENSSLDIR: "/usr/lib/ssl" > Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3" > > > groups fetchmail > fetchmail : nogroup vmail postfix > > > cat /etc/default/fetchmail > START_DAEMON=yes > > > cat /etc/fetchmailrc > # /etc/fetchmailrc for system-wide daemon mode > # This file must be chmod 0600, owner fetchmail > # > set daemon 300 > set postmaster root > set no bouncemail > set no spambounce > set no syslog > set logfile "/var/log/fetchmail.log" > # > ########## mail.domain.com ########## > poll mail.domain.com protocol imap > user us...@do... there with password XXyyXXyy > is us...@do...n here This has set up fetchmail to forward via SMTP, totally ignoring LMTP servers. > keep ssl > norewrite > preconnect "date >> /var/log/fetchmail.log" > > > > #========= my lmtp sockets =========# > > In order do deliver emails from a selected remote folder to a specific > local folder one has to use the MDA parameter. > > How and which MDA? This is outside fetchmail's scope and a mail filtering thing on the receiving end. You may want to consult Dovecot's documentation, dovecot-lda in particular. |
From: Matthias A. <mat...@gm...> - 2024-04-23 20:30:56
|
Am 16.02.24 um 17:58 schrieb graeme vetterlein: > > On 14/02/2024 21:10, Matthias Andree via Fetchmail-users wrote: >> Am 13.02.24 um 22:34 schrieb graeme vetterlein: >>> The last "other person" email I saw was 29 Jan .. >>> >>> I saw my own mail come back to me on 7th feb ... but no response. >> >> >> That can happen without your dropping off the list. >> >> People get distracted, go on business trips, have week-end plans, >> whatever. Else show your support contract to claim service :-) >> >> > I wasn't complaining ...it just looked a little odd (and I have > dropped off other lists) ...I sent a email, I immediately > > got a response (an echo of my mail) what I expected next was it would > appear again in a "summary" (I don't' recall my "sign up" options, > but usually I opt to get a weekly summary email not "live" every email > as soon as it' sent) ... is this not how this mailing list works? There was a lot of churn in my mail logs quite a while ago and I have added a greylisting feature to it. I won't tell too much about the details, but the bottom line is if you haven't mailed the list in a long time (nobody has), the delivering mail server gets temporarily refused initially and has to come back for a retry, which all properly functioning mail relays do, but spammers sometimes do not, and there is some time for them to appear on real-time blacklist. This causes a delay of several minutes, which will not occur on subsequent messages using the same sender:destination relation in a certain time frame. Also, the list driver software is mailman 2, and it won't just boot you from the list, but only if your messages and certain subsequent probe messages keep causing undeliverable notices on several distinct days afterwards. > > It would be helpful in in verbose mode at least it indicated that the > error was being ignored. Because I my case > > it failed right after that error and it was not immediately obvious > that it had been ignored. Lost of time chasing the wrong error message. Sorry for that, yes, we can do that. Pushed to the Git branch that will spawn a 6.5 release in the future in commit db0fd264, example output: > Apr 23 22:13:29 fetchmail: POP3< +OK send PASS > Apr 23 22:13:29 fetchmail: POP3> PASS * > Apr 23 22:13:29 fetchmail: POP3< +OK Welcome. > Apr 23 22:13:29 fetchmail: POP3> STAT > Apr 23 22:13:29 fetchmail: POP3< +OK 29 650667 > Apr 23 22:13:29 fetchmail: POP3> LAST > Apr 23 22:13:29 fetchmail: POP3< -ERR Not supported > Apr 23 22:13:29 fetchmail: Not supported > Apr 23 22:13:29 fetchmail: LAST is an obsolete command that many > servers will not support. We will try modern means to find what > messages are new. > Apr 23 22:13:29 fetchmail: POP3> UIDL > Apr 23 22:13:29 fetchmail: POP3< +OK > Apr 23 22:13:29 fetchmail: POP3< 1 Id1516a57b9a0d4280 > Apr 23 22:13:29 fetchmail: POP3< 2 Id1516a57ba7a71933 > Apr 23 22:13:29 fetchmail: POP3< 3 Id1516a57bb8920733 I couldn't push this to sourceforge.net though (*), so only Gitlab currently has it, see https://gitlab.com/fetchmail/fetchmail/-/commit/db0fd264a85d11565b4abd20b0d7b6bbd4d77c23 > (*) ssh: connect to host git.code.sourceforge.net port 22: Connection > timed out >>> >>> The full set of messages I originally got: >>> >>> >>> fetchmail: POP3> STAT >>> fetchmail: POP3< +OK 2 12792 >>> fetchmail: POP3> LAST >>> fetchmail: POP3< -ERR bad command >>> fetchmail: bad command >>> fetchmail: POP3> UIDL >>> fetchmail: POP3> TOP 1 1 >>> fetchmail: protocol error while fetching UIDLs >>> fetchmail: POP3> QUIT >>> fetchmail: client/server synchronization error while fetching from >>> gr...@ma...@pop3.my.provider.net >>> fetchmail: 6.4.16 querying pop3.my.provider.net (protocol POP3) at Tue >>> 13 Feb 2024 16:59:19 GMT: poll completed >> >> If that persists with any version since and including 6.4.34, let me >> know. The trace as posted looks as though the server had not replied to >> UIDL at all (which I find strange because fetchmail should wait for a >> reply before sending TOP 1 1 to get the header of the first message), >> but I am not going to look into bugs of older versions. >> > OK, I was not seeing this as a "bug" ... I took it to mean "you need > to use UIDL if you're using pop3+keep" This is the standing recommendation and best current practice, yes, but the log looks strange. Anyways, we're not going to dig this up. > > FYI Have a Trixie system which offers 6.4.38-1 ... the mailbox is > one I'm using for testing ...so it has nothing sensitive (even the > password) > > if you would like me to run a test? It's just that I lack time to dig up if that would be a bug in 6.4.16 that I've fixed since. Or whoever compiled your version had compiler bugs. My policy is to update. So if 6.4.38 shows similar client/server synchronization errors, let me know, and please provide those logs with -vv options to fetchmail. |
From: Info <in...@wc...> - 2024-04-09 14:43:07
|
Greeting all, How do I download Selected Remote Folder to Specific Local Folder For example: Remote folder= INBOX.Sent Local folder = INBOX/Sent #========= fetchmail release =========# This is fetchmail release 6.4.37+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. Compiled with SSL library 0x30000080 "OpenSSL 3.0.8 7 Feb 2023" Run-time uses SSL library 0x300000b0 "OpenSSL 3.0.11 19 Sep 2023" OpenSSL: OPENSSLDIR: "/usr/lib/ssl" Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3" groups fetchmail fetchmail : nogroup vmail postfix cat /etc/default/fetchmail START_DAEMON=yes cat /etc/fetchmailrc # /etc/fetchmailrc for system-wide daemon mode # This file must be chmod 0600, owner fetchmail # set daemon 300 set postmaster root set no bouncemail set no spambounce set no syslog set logfile "/var/log/fetchmail.log" # ########## mail.domain.com ########## poll mail.domain.com protocol imap user us...@do... there with password XXyyXXyy is us...@do...n here keep ssl norewrite preconnect "date >> /var/log/fetchmail.log" #========= my lmtp sockets =========# unix 2 [ ACC ] STREAM LISTENING 377089 private/lmtp unix 2 [ ACC ] STREAM LISTENING 377202 /var/spool/postfix/private/dovecot-lmtp unix 2 [ ACC ] STREAM LISTENING 377199 /run/dovecot/lmtp #========= my Dovecot lmtp service =========# service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } inet_listener lmtp { address = 127.0.0.1 port = 24 } #========= my ISP IMAP =========# A001 OK You are so in n namespace * NAMESPACE (("INBOX." ".")) NIL NIL n OK Namespace completed (0.001 + 0.000 secs). A002 list "INBOX." "*" * LIST (\HasNoChildren \Trash) "." INBOX.Trash * LIST (\HasNoChildren \Junk) "." INBOX.spambucket * LIST (\HasNoChildren \Sent) "." INBOX.Sent * LIST (\HasNoChildren \Drafts) "." INBOX.Drafts * LIST (\HasNoChildren) "." INBOX.Templates A002 OK List completed (0.001 + 0.000 secs). #========= my local IMAP =========# * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot (Debian) ready. a01 OK [CAPABILITY IMAP4rev1 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 PREVIEW=FUZZY PREVIEW STATUS=SIZE SAVEDATE LITERAL+ NOTIFY SPECIAL-USE ACL RIGHTS=texk] Logged in n namespace * NAMESPACE (("" "/")) NIL NIL n OK Namespace completed (0.001 + 0.000 secs). a02 LIST "" "*" * LIST (\HasNoChildren \Trash) "/" Trash * LIST (\HasNoChildren \Junk) "/" Junk * LIST (\HasNoChildren \Archive) "/" Archive * LIST (\HasNoChildren \Sent) "/" "Sent Messages" * LIST (\HasNoChildren \Sent) "/" Sent * LIST (\HasNoChildren \Drafts) "/" Drafts * LIST (\HasNoChildren) "/" INBOX a02 OK List completed (0.001 + 0.000 secs). a03 LIST "INBOX" "*" * LIST (\HasNoChildren) "/" INBOX a03 OK List completed (0.001 + 0.000 secs). A04 SELECT "INBOX" * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1712661597] UIDs valid * OK [UIDNEXT 1] Predicted next UID A04 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). a05 LOGOUT * BYE Logging out a05 OK Logout completed (0.001 + 0.000 secs). In order do deliver emails from a selected remote folder to a specific local folder one has to use the MDA parameter. How and which MDA? Thanks very much in advance Jan |