fetchmail-users — User questions and discussion

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.39 is available (two bugfixes)

[Matthias A. <mat...@gm...>]

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.

--------------------------------------------------------------------------------

Re: [Fetchmail-users] authentication fail

[Matthias A. <mat...@gm...>]

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

Re: [Fetchmail-users] authentication fail

[Matthias A. <mat...@gm...>]

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.

Re: [Fetchmail-users] Automatically decrypt fetched PGP/Mime mail?

[Peter P. <ro...@ri...>]

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

Re: [Fetchmail-users] Automatically decrypt fetched PGP/Mime mail?

[Carlos E. R. <rob...@te...>]

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)

[Fetchmail-users] Automatically decrypt fetched PGP/Mime mail?

[<q17...@du...>]

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?

Re: [Fetchmail-users] authentication fail

[Michael P. <mpo...@gm...>]

> 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

Re: [Fetchmail-users] Fwd: authentication fail

[Matthias A. <mat...@gm...>]

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

Re: [Fetchmail-users] Fwd: authentication fail

[Matthias A. <mat...@gm...>]

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

[Fetchmail-users] Fwd: authentication fail

[Michael P. <mpo...@gm...>]

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

Re: [Fetchmail-users] Google Less Secure Apps - End Of Life

[Carlos E. R. <rob...@te...>]

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)

Re: [Fetchmail-users] Google Less Secure Apps - End Of Life

[Matthias A. <mat...@gm...>]

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.

Re: [Fetchmail-users] Google Less Secure Apps - End Of Life

[Carlos E. R. <rob...@te...>]

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)

Re: [Fetchmail-users] Google Less Secure Apps - End Of Life

[Matthias A. <mat...@gm...>]

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.

Re: [Fetchmail-users] Google Less Secure Apps - End Of Life

[Lucio C. <lu...@la...>]

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"

[Fetchmail-users] ANNOUNCE: The 6.5.0.beta10 snapshot of fetchmail is available

[Matthias A. <mat...@gm...>]

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
============================================================================

Re: [Fetchmail-users] Google Less Secure Apps - End Of Life

[<rb...@al...>]

	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

Re: [Fetchmail-users] Google Less Secure Apps - End Of Life

[Matthias A. <mat...@gm...>]

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

Re: [Fetchmail-users] I'm wondering if I've somehow dropped off the list?

[graeme v. <gra...@ve...>]

>>
>> 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)

[Fetchmail-users] Google Less Secure Apps - End Of Life

[Andrew C A. <fet...@ai...>]

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...

[Fetchmail-users] Google Less Secure Apps - End Of Life

[Andrew C A. <fet...@ai...>]

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...

Re: [Fetchmail-users] I'm wondering if I've somehow dropped off the list?

[Matthias A. <mat...@gm...>]

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.

Re: [Fetchmail-users] selected remote folder to a specific local folder

[Matthias A. <mat...@gm...>]

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.

Re: [Fetchmail-users] I'm wondering if I've somehow dropped off the list?

[Matthias A. <mat...@gm...>]

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.

[Fetchmail-users] selected remote folder to a specific local folder

[Info <in...@wc...>]

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