fetchmail-users — User questions and discussion

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

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

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

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?


>> fetchmail: POP3> LAST
>> fetchmail: POP3< -ERR bad command
>> fetchmail: bad command
>>
>>
>> It seems this is "expected" ... it would be nice if the verbose log
>> added that info "LAST is often not supported, it's OK"
>
> I am not sure if fetchmail should lecture people on defunct/superseded
> versions of the standard (RFC-1460), this is a compatibility hack that
> is quite assuming... and LAST was removed 30 years ago, for good
> reasons. Arguably we should probably remove the remnants in the code.
> For robustness, it's either UIDL or "take it all". It should be clear
> from fetchmail's not reporting an error and continuing that it is up to
> more useful protocol things.
>
Well I guess in the code there is some logic of the the form



     if (0 != ( rc=do_operation()))

         {

         if (condition(op, rc) == FATAL

             ...die

         else

             ..carry on

         }


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.



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


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?




>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

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

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

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


> There are a few interesting "gotchas" along the way  which may be of
> interest.
>
>
> Using -vv :
>
>
> fetchmail: POP3> LAST
> fetchmail: POP3< -ERR bad command
> fetchmail: bad command
>
>
> It seems this is "expected" ... it would be nice if the verbose log
> added that info "LAST is often not supported, it's OK"

I am not sure if fetchmail should lecture people on defunct/superseded
versions of the standard (RFC-1460), this is a compatibility hack that
is quite assuming... and LAST was removed 30 years ago, for good
reasons. Arguably we should probably remove the remnants in the code.
For robustness, it's either UIDL or "take it all". It should be clear
from fetchmail's not reporting an error and continuing that it is up to
more useful protocol things.

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

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

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

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.


I've made a little progress . I tried using pop3 (instead of imap) and 
it's working much more as I would like. My most recent settings are:


poll pop3.my.provider.net tracepolls with proto POP3 uidl
     user 'gr...@ma...' there with password 'XXXXX' is 
'graeme' here options ssl sslproto "auto" keep fastuidl 24
     mda "/usr/bin/maildrop -d graeme"


There are a few interesting "gotchas" along the way  which may be of 
interest.


Using -vv :


fetchmail: POP3> LAST
fetchmail: POP3< -ERR bad command
fetchmail: bad command


It seems this is "expected" ... it would be nice if the verbose log 
added that info "LAST is often not supported, it's OK"


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


...so you can see why  the "bad command" looked like an issue, it 
immediately preceded the failure.


This was "fixed" by adding the option uidl (and later fastuidl 24) as 
shown above.


My understanding was without the uidl option, it would have possibly got 
the "wrong" mails ...ie ones that another client

had read , I did not understand it would actually fail.


--


Graeme

[Fetchmail-users] An approach to mixing lave & historic email

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

All,

I'm trying to achieve something using fetchmail and I seem to rather 
"swimming against the tide". I
wonder if a different approach is in order.

I run an SMTP server @ home (actually called smtp.home [via CNAME] ) and 
I have recently
rented use of smtp.remote (not it's real name)

Stage1:  I did fetchmail(imap) every 5 minutes of smtp.remote (using 
fetchall option) and delivered to smtp.home
          People then read email via Thunderbird via imap to imap.home 
(dovecot access to local files)


All works well, but you can only send and receive email while you can 
"see" smtp.home (so on local LAN ... no holes in firewall)

So

Stage2: Do the fetchmail(imap) less frequently (e.g. daily) and use the 
keep option (and no fetchall)
         Users can now imap to both imap.home and imap.remote and see 
similar (but more or less up to date)
     views. They can also send mail from both locations.


Stage3: Delete mail from imap.remote older than say 1 year


Now "recent email" is on imap.remote while historic is held on 
imap.home, there is significant overlap.
The idea being , when you're out "on the road" you lack access to 
history but you can deal with current day-to-day issues using a phone.

================ Problems =============

1: Getting copies of "Sent" mail from imap.remote ... Solved using 
maildrop(1) ...needed to save by sender not recipient

2: Mail in inbox at imap.remote that had been "read" by "a phone" , was 
not downloaded by fetchmail(imap)....Looks like the rule
    for --keep and "no fetchall" is only download stuff not already 
"seen" by **somebody**.

What I really want of course is "stuff not already seen by **me**".


Now I note from uidl.c that pop3 does this differently...should I pop 
the mail to achieve the desired effect ... bear in mind
I'd be skipping a years worth of mail to read one message?

...I guess I'm looking for a "cursor" to mark where "I" have downloaded 
to ... so e.g. multiple clients could "mark their place"
and download ...anything after message No XXX.

Re: [Fetchmail-users] ANNOUNCE: fetchmail 6.4.38 is available (translation updates, updated OpenSSL/wolfSSL version requirements)

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

Note that the shipped NEWS file in the tarball and this release message 
claim fetchmail-6.4.38 were "not yet released", but I have released iti 
today intentionally, not by accident.

That line should have read instead:

"fetchmail-6.4.38 (released 2024-01-31, 31720 LoC)"

and has been pushed with a GnuPG-signed tag to the Git repos,
https://gitlab.com/fetchmail/fetchmail and 
https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/


Am Wed, Jan 31, 2024 at 10:00:33PM +0100 schrieb Matthias Andree:
> The 6.4.38 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.38.tar.xz/download>
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz/download>
> 
> The detached GnuPG signature is available at:
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.xz.asc/download>
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz.asc/download>
> 
> The SHA256 hashes for the tarballs are:
> SHA2-256(fetchmail-6.4.38.tar.xz)= a6cb4ea863ac61d242ffb2db564a39123761578d3e40d71ce7b6f2905be609d9
> SHA2-256(fetchmail-6.4.38.tar.lz)= be82b520d9698c1378c3a9a4dbab4d392c8c90d457af11a97ce9b85a3fedc70a
> 
> 
> Here are the release notes:
> --------------------------------------------------------------------------------
> fetchmail-6.4.38 (not yet released):
> 
> # BREAKING CHANGES:
> * Tighten OpenSSL and wolfSSL version requirements again. See README.SSL.
>   Distributors providing older versions that they backport security fixes for 
>   may want to patch socket.c but remember to redirect support to your 
>   distribution's support channels.
>   The fetchmail maintainer only supports functionally unmodified builds with 
>   publicly available SSL/TLS library versions.
>   fetchmail will refuse to build against OpenSSL 1.0.2 older than 1.0.2u,
>   or wolfSSL older than 5.6.2. It will warn about OpenSSL older than 3.0.9,
>   or between 3.1.0 and 3.1.4, or wolfSSL older than 5.6.6.
> 
> # TRANSLATIONS: language translations were updated by these fine people:
> (in reverse alphabetical order of language codes):
> * ru:    Kirill Isakov [Russian]
> * eo:    Keith Bowes [Esperanto]
> 
> --------------------------------------------------------------------------------

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.38 is available (translation updates, updated OpenSSL/wolfSSL version requirements)

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

The 6.4.38 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.38.tar.xz/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz/download>

The detached GnuPG signature is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.xz.asc/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.4.38.tar.xz)= a6cb4ea863ac61d242ffb2db564a39123761578d3e40d71ce7b6f2905be609d9
SHA2-256(fetchmail-6.4.38.tar.lz)= be82b520d9698c1378c3a9a4dbab4d392c8c90d457af11a97ce9b85a3fedc70a


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.4.38 (not yet released):

# BREAKING CHANGES:
* Tighten OpenSSL and wolfSSL version requirements again. See README.SSL.
  Distributors providing older versions that they backport security fixes for 
  may want to patch socket.c but remember to redirect support to your 
  distribution's support channels.
  The fetchmail maintainer only supports functionally unmodified builds with 
  publicly available SSL/TLS library versions.
  fetchmail will refuse to build against OpenSSL 1.0.2 older than 1.0.2u,
  or wolfSSL older than 5.6.2. It will warn about OpenSSL older than 3.0.9,
  or between 3.1.0 and 3.1.4, or wolfSSL older than 5.6.6.

# TRANSLATIONS: language translations were updated by these fine people:
(in reverse alphabetical order of language codes):
* ru:    Kirill Isakov [Russian]
* eo:    Keith Bowes [Esperanto]

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

Re: [Fetchmail-users] EarthLink issue

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

Am 29.01.24 um 17:49 schrieb Michael Burgoon:
> Thanks very much Lucio.  I reran fetchmail with your debug args and got the following output.  the IPA for my internal mail server is 192.168.1.111 and that this the address that my router port forwards to.  I do not have anything located at 192.168.1.203, the spa that is causing the error, so I’m at a loss as to why fetchmail now, all of a sudden, has decided to use that address for my internal mail/smtp server.
> Question: where does fetchmail get that address to query? Wherever it is, it’s getting the wrong ipa.
>
> Thanks for anyone’s additional assistance.
>
> Mike B
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> mburgoon@mbdiskstation:/opt/etc/init.d$  sudo /opt/bin/fetchmail -vvv --nodetach --nosyslog -f /opt/etc/fetchmailrc
> Password:
> fetchmail: WARNING: Running as root is discouraged.
> gethostbyname failed for mbdiskstation
> Name or service not knownCannot find my own host in hosts database to qualify it!
> Trying to continue with unqualified hostname.
> DO NOT report broken Received: headers, HELO/EHLO lines or similar problems!
> DO repair your /etc/hosts, DNS, NIS or LDAP instead.

Mike,

^ these warnings you quoted above are relevant. The host running
fetchmail needs fixing. Also, your fetchmail is nine years old. Who is
maintaining the software and providing bug fixes? What software is it?
Some NAS?

> [...]
> Trying to connect to 192.168.1.203/25...connection failed.
> fetchmail: connection to localhost:smtp [192.168.1.203/25] failed: No route to host.

Why does your mail server believe that "localhost" has address
192.168.1.203? You write you don't have something there (that's what you
intend), but your host running fetchmail that localhost isn't 127.0.0.1
(or possibly 127.0.1.1 on some systems), but 192.168.1.203, which is
non-standard and probably part of the problem you are posing. This is an
issue on your operating system on the fetchmail host - and you need to
find out where that address comes from.

Check your /etc/hosts on the host running fetchmail, and local name
servers if any (including on your router).

You may find out with (as root): grep -r 192.168.1.203 /etc

Also, you did not tell fetchmail to your internal mail server - there is
no smtphost argument or similar which would mention that 192.168.1.111
that you intend to use. Where you did intend this to happen?

> # Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE".
>
> poll pop.earthlink.net proto pop3 localdomains mindspring.com user"mbu...@mi..."  password “XXXXXXXX", is "mbu...@mb...” here

Re: [Fetchmail-users] EarthLink issue

[Michael B. <mbu...@mi...>]

Thanks very much Lucio.  I reran fetchmail with your debug args and got the following output.  the IPA for my internal mail server is 192.168.1.111 and that this the address that my router port forwards to.  I do not have anything located at 192.168.1.203, the spa that is causing the error, so I’m at a loss as to why fetchmail now, all of a sudden, has decided to use that address for my internal mail/smtp server.  
Question: where does fetchmail get that address to query? Wherever it is, it’s getting the wrong ipa.

Thanks for anyone’s additional assistance.

Mike B

++++++++++++++++++++++++++++++++++++++++++++++++++++

mburgoon@mbdiskstation:/opt/etc/init.d$ sudo /opt/bin/fetchmail -vvv --nodetach --nosyslog -f /opt/etc/fetchmailrc
Password: 
fetchmail: WARNING: Running as root is discouraged.
gethostbyname failed for mbdiskstation
Name or service not knownCannot find my own host in hosts database to qualify it!
Trying to continue with unqualified hostname.
DO NOT report broken Received: headers, HELO/EHLO lines or similar problems!
DO repair your /etc/hosts, DNS, NIS or LDAP instead.
Old UID list from pop.earthlink.net: <empty>
Scratch list of UIDs: <empty>
fetchmail: 6.3.26 querying pop.earthlink.net (protocol POP3) at Mon, 29 Jan 2024 16:34:57 +0000 (UTC): poll started
Trying to connect to 24.41.66.181/110...connected.
fetchmail: POP3< +OK NGPopper vEL_0_1_42_MP_1_P at earthlink.net ready <208...@mp...>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< apop
fetchmail: POP3< pass
fetchmail: POP3< top
fetchmail: POP3< uidl
fetchmail: POP3< user
fetchmail: POP3< .
fetchmail: POP3> USER mbu...@mi...
fetchmail: POP3< +OK Pass required for mbu...@mi...
fetchmail: POP3> PASS *
fetchmail: POP3< +OK mburgoon has 25 messages (35879814 octets).
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 25 35879814
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
25 messages for mbu...@mi... at pop.earthlink.net (35879814 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 19510
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK
reading message mbu...@mi...@pop.earthlink.net:1 of 25 (19510 octets) About to rewrite Return-Path: <bounce+f5af3c.44e7ac-mburgoon=min...@mg...>...
...rewritten version is Return-Path: <bounce+f5af3c.44e7ac-mburgoon=min...@mg...>.
About to rewrite Sender: reply=tvi...@mg......
...rewritten version is Sender: reply=tvi...@mg....
About to rewrite From: Jerrys Leesburg Chevrolet <re...@tv...>...
...rewritten version is From: Jerrys Leesburg Chevrolet <re...@tv...>.
About to rewrite To: mbu...@mi......
...rewritten version is To: mbu...@mi....

Trying to connect to 192.168.1.203/25...connection failed.
fetchmail: connection to localhost:smtp [192.168.1.203/25] failed: No route to host.
fetchmail: Connection errors for this poll:
name 0: connection to localhost:smtp [192.168.1.203/25] failed: No route to host.
fetchmail: SMTP connect to localhost failed
fetchmail: POP3> QUIT
fetchmail: POP3< <!DOCTYPE html>
fetchmail: SMTP transaction error while fetching from mbu...@mi...@pop.earthlink.net and delivering to SMTP host localhost
fetchmail: 6.3.26 querying pop.earthlink.net (protocol POP3) at Mon, 29 Jan 2024 16:35:01 +0000 (UTC): poll completed
Merged UID list from pop.earthlink.net: <empty>
fetchmail: Query status=10 (SMTP)
fetchmail: normal termination, status 10

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

FETCHMAILRC

# Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE".

poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXX", is "mbu...@mb...” here


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


On Jan 27, 2024, at 8:09 AM, Lucio Chiappetti <lu...@la...> wrote:

On Fri, 26 Jan 2024, Michael Burgoon wrote:

> explain where the following statements go:
> 
> The output of env LC_ALL=C fetchmail -V called with whatever other command-line options you used.
> The output of env LC_ALL=C fetchmail --nodetach -vvv --nosyslog with whatever other command-line options you use routinely.

The statements shall be issued from a terminal emulator (xterm, console etc.). It depends how you call procmail (as a daemon, or via crontab, whether you use .fetchmailrc  or a custom .fetchmailrc.SOMETHING

(for instance I had two (now three) different .fetchmailrc.SOMETHING fopr different servers, and call by crontab at different frequencies.

If I wanto to debug a particular .fetchmailrc.SOMETHING

fetchmail -V -v --nodetach --nosyslog  -f /path/to/.fetchmailrc.SOMETHING

will analyse the .fetchmailrc.SOMETHING for syntax errors (and do nothing)

fetchmail -vvv --nodetach --nosyslog  -f /path/to/.fetchmailrc.SOMETHING

will executw it and produce verbose diagnostic messages.

It's all written in the man pages (where I found it recently when I needed to make checks for a new server)

-- 
Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
A middle rank researcher at end career is not rich but is in the top 5% of the Italian income tax taxpayers. Does it not sound strange ?

Re: [Fetchmail-users] downloading by date range

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

OK, part way there....

On 22/01/2024 12:41, Mihai Lazarescu wrote:
> On Monday, January 22, 2024 at 10:54:07 +0000, graeme vetterlein:
>
>> I'd like to setup something for the whole household (Family) as I 
>> know for a
>> fact they never organise their historic email :-) and I don't want 
>> their junk
>> using my whole allocation
>
> I'm a mutt user :-) and I'm pretty sure that it allows creating a 
> script that automatically selects, deletes and purges messages older 
> than 1 year (~d >1y) for each account in sequence, which you can then 
> run periodically (interactively or cron).
>
So I think I plan to knock up a small python script that runs monthly 
and just deletes any mail older than 12 months.

Working it though it however leaves another little "kink" ...


1: I download inbox say once a day (with --keep)

2: I run the delete python script once a month (leaves a year online)


So now I have 12 months online and everything up to today on "local" 
(e.g. /var/mail/myuser)


If I want to send *while I'm at home*, I use a *local SMTP* server and a 
copy of the outgoing mail gets saved in local-IMAPed-directory/Sent


While I'm "on the road" I can view recent (year) mails via imap to 
"online provider". However if I send an email, while I'm out I'll need 
to use

online_provider.SMTP a copy will need to be saved in 
online_provider-IMAPed-directory/Sent


So my *outgoing mail is saved in 2 different places* depending on where 
I was when I sent it.


The obvious solution would be to run fetchmail+imap on 
online_provider-IMAPed-directory/Sent ... However, this seems odd, for 
example, what would I do with it?

If I pass it to local sendmail its going to send it to the original 
"TO:" header again ... when really it just needs to go into ~/mail/Sent 
(or similar) .

If it's not going though sendmail, then I really should be doing some 
locking?


(now I know "Sent" is a function of the MUA (Thunderbird) not the MTA  
..but while I'm out of the house ~/mail/Sent is inaccessible . (while 
online_provider-IMAPed-directory/Sent is available)


--


Graeme

Re: [Fetchmail-users] EarthLink issue

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

On Fri, 26 Jan 2024, Michael Burgoon wrote:

> explain where the following statements go:
>
> The output of env LC_ALL=C fetchmail -V called with whatever other command-line options you used.
> The output of env LC_ALL=C fetchmail --nodetach -vvv --nosyslog with whatever other command-line options you use routinely.

The statements shall be issued from a terminal emulator (xterm, console 
etc.). It depends how you call procmail (as a daemon, or via crontab, 
whether you use .fetchmailrc  or a custom .fetchmailrc.SOMETHING

(for instance I had two (now three) different .fetchmailrc.SOMETHING fopr 
different servers, and call by crontab at different frequencies.

If I wanto to debug a particular .fetchmailrc.SOMETHING

fetchmail -V -v --nodetach --nosyslog  -f /path/to/.fetchmailrc.SOMETHING

will analyse the .fetchmailrc.SOMETHING for syntax errors (and do nothing)

fetchmail -vvv --nodetach --nosyslog  -f /path/to/.fetchmailrc.SOMETHING

will executw it and produce verbose diagnostic messages.

It's all written in the man pages (where I found it recently when I needed 
to make checks for a new server)

-- 
Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
A middle rank researcher at end career is not rich but is in the top 5% 
of the Italian income tax taxpayers. Does it not sound strange ?

Re: [Fetchmail-users] EarthLink issue

[Michael B. <mbu...@mi...>]

Greeting Matthias, I would like to provlde the info specified in the referenced document, please explain where the following statements go:


The output of env LC_ALL=C fetchmail -V called with whatever other command-line options you used.
The output of env LC_ALL=C fetchmail --nodetach -vvv --nosyslog with whatever other command-line options you use routinely.



On Jan 25, 2024, at 7:48 PM, Matthias Andree via Fetchmail-users <fet...@li...> wrote:

Am 25.01.24 um 19:43 schrieb Michael Burgoon:
> Been using Fecthmail for years to pull mail down from EarthLink.net. It’s worked fine for years, now all of a sudden it just stopped working. Checked to make sure nothing changed on my end, so it’s something at the other end.  Anyone know if Earthlink has adjusted anything that would affect this?
> 
> fetchmailrc poll command:
> 
> poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXXX", is "mbu...@mb...” here
https://www.fetchmail.info/fetchmail-FAQ.html#G3


_______________________________________________
Fetchmail-users mailing list
Fet...@li...
https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] EarthLink issue

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

Am 25.01.24 um 19:43 schrieb Michael Burgoon:
> Been using Fecthmail for years to pull mail down from EarthLink.net. It’s worked fine for years, now all of a sudden it just stopped working. Checked to make sure nothing changed on my end, so it’s something at the other end.  Anyone know if Earthlink has adjusted anything that would affect this?
>
> fetchmailrc poll command:
>
> poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXXX", is "mbu...@mb...” here
https://www.fetchmail.info/fetchmail-FAQ.html#G3

[Fetchmail-users] EarthLink issue

[Michael B. <mbu...@mi...>]

Been using Fecthmail for years to pull mail down from EarthLink.net. It’s worked fine for years, now all of a sudden it just stopped working. Checked to make sure nothing changed on my end, so it’s something at the other end.  Anyone know if Earthlink has adjusted anything that would affect this?

fetchmailrc poll command:

poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXXX", is "mbu...@mb...” here

Thanks,

Mike B

Re: [Fetchmail-users] my solution to recent gmail issues

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

https://support.google.com/a/answer/6260879 
suggests that less secure apps are still going away.

On Mon, 22 Jan 2024, Lucio Chiappetti wrote:

> I have recently received a message that I *SHALL* move to 2 
> Factor Authentication in Gsuite, and, as I suspected, this broke 
> my arrangement (which exists sicne years and years) and I took 
> my counter-measures, and I wish to share.
>
> In a nutshell what I wanted to achieve and what I did is:
>
> (1) I want to have mail stored locally on my machine, and to 
> have
>     incoming mails processed by procmail (this is not just for 
> my fun,
>     I have a couple of cases where procmail post-processes mail 
> from
>     forms to update a local database for service reasons).
>
> (2) The simplest way to feed incoming mails into procmail is to 
> use
>    fetchmail, which I am happily using since 2018, when my 
> institution
>    moved from howgrown sendmail to Gsuite
>
> (3) The simplest way to have fetchmail working (after I 
> activated
>     2FA on Gsuite fetchmail was not authenticateds) is to 
> "bypass" Gmail,
>     i.e. instruct Gsuite to forward all mail to another 
> provider which
>     provides *standard* IMAP.
>
>     This solves 98% of my problems, because
>
>     - Spam is not forwarded from Gmail to the alternate 
> provider
>     - messages forwrded *and deleted* are not actually deleted
>       but staged in Gmail's Bin for 30 days
>
> (4)  The solution is ... "app passwords". Gmail with 2FA allows 
> to
>     define a 16-char password THEY generate to be used with 
> what in
>     the past were called provocatorily "less secure 
> applications"
>
>     So I generated such an "app passwords" and I can use it 
> from my
>     preferred mail client (Alpine). And this solves my problem.
>
> (5)  Actually the same app password can work also with 
> fetchmail,
>     so in theory I would not need the alternate provider of 
> point (3) and
>     could work "as previously", but I left it in.
>
> I had no need to move to OAUTH2, or learn it, or get an 
> OAUTH2-capable version of fetchmail (I use the OS-bundled one).
>
> I think I could be happy with the new arrangement.
>
> I hope the above is useful to somebody else.

-- 
Andrew C. Aitchison                      Kendal, UK
                    an...@ai...

Re: [Fetchmail-users] my solution to recent gmail issues

[Mihai L. <mt...@gm...>]

For pretty much the same setup (fetchmail, procmail, 
and mutt), I found that the Email OAuth 2.0 Proxy 
https://github.com/simonrob/email-oauth2-proxy was very easy 
to blend in.

Best,
Mihai

On Monday, January 22, 2024 at 16:39:54 +0100, Lucio Chiappetti:

> I have recently received a message that I *SHALL* move to 2 Factor
> Authentication in Gsuite, and, as I suspected, this broke my
> arrangement (which exists sicne years and years) and I took my
> counter-measures, and I wish to share.
>
> In a nutshell what I wanted to achieve and what I did is:
>
> (1) I want to have mail stored locally on my machine, and to have
>     incoming mails processed by procmail (this is not just for my fun,
>     I have a couple of cases where procmail post-processes mail from
>     forms to update a local database for service reasons).
>
> (2) The simplest way to feed incoming mails into procmail is to use
>    fetchmail, which I am happily using since 2018, when my institution
>    moved from howgrown sendmail to Gsuite
>
> (3) The simplest way to have fetchmail working (after I activated
>     2FA on Gsuite fetchmail was not authenticateds) is to "bypass" Gmail,
>     i.e. instruct Gsuite to forward all mail to another provider which
>     provides *standard* IMAP.
>
>     This solves 98% of my problems, because
>
>     - Spam is not forwarded from Gmail to the alternate provider
>     - messages forwrded *and deleted* are not actually deleted
>       but staged in Gmail's Bin for 30 days
>
> (4)  The solution is ... "app passwords". Gmail with 2FA allows to
>     define a 16-char password THEY generate to be used with what in
>     the past were called provocatorily "less secure applications"
>
>     So I generated such an "app passwords" and I can use it from my
>     preferred mail client (Alpine). And this solves my problem.
>
> (5)  Actually the same app password can work also with fetchmail,
>     so in theory I would not need the alternate provider of point (3) and
>     could work "as previously", but I left it in.
>
> I had no need to move to OAUTH2, or learn it, or get an
> OAUTH2-capable version of fetchmail (I use the OS-bundled one).
>
> I think I could be happy with the new arrangement.
>
> I hope the above is useful to somebody else.
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] my solution to recent gmail issues

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

Lucio,

This is also what I was forced to may years ago. Yes a password THEY set 
does not seem so secure (although I do agree with them simply have a 
password is less secure ...far better if they accepted *my* key)


ABTW, you also show as having a bad DKIM:

(Invalid SPF: Pass  DMARC None)


On 22/01/2024 15:39, Lucio Chiappetti wrote:
> I have recently received a message that I *SHALL* move to 2 Factor 
> Authentication in Gsuite, and, as I suspected, this broke my 
> arrangement (which exists sicne years and years) and I took my 
> counter-measures, and I wish to share.
>
> In a nutshell what I wanted to achieve and what I did is:
>
> (1) I want to have mail stored locally on my machine, and to have
>      incoming mails processed by procmail (this is not just for my fun,
>      I have a couple of cases where procmail post-processes mail from
>      forms to update a local database for service reasons).
>
> (2) The simplest way to feed incoming mails into procmail is to use
>     fetchmail, which I am happily using since 2018, when my institution
>     moved from howgrown sendmail to Gsuite
>
> (3) The simplest way to have fetchmail working (after I activated
>      2FA on Gsuite fetchmail was not authenticateds) is to "bypass" 
> Gmail,
>      i.e. instruct Gsuite to forward all mail to another provider which
>      provides *standard* IMAP.
>
>      This solves 98% of my problems, because
>
>      - Spam is not forwarded from Gmail to the alternate provider
>      - messages forwrded *and deleted* are not actually deleted
>        but staged in Gmail's Bin for 30 days
>
> (4)  The solution is ... "app passwords". Gmail with 2FA allows to
>      define a 16-char password THEY generate to be used with what in
>      the past were called provocatorily "less secure applications"
>
>      So I generated such an "app passwords" and I can use it from my
>      preferred mail client (Alpine). And this solves my problem.
>
> (5)  Actually the same app password can work also with fetchmail,
>      so in theory I would not need the alternate provider of point (3) 
> and
>      could work "as previously", but I left it in.
>
> I had no need to move to OAUTH2, or learn it, or get an OAUTH2-capable 
> version of fetchmail (I use the OS-bundled one).
>
> I think I could be happy with the new arrangement.
>
> I hope the above is useful to somebody else.
>

[Fetchmail-users] my solution to recent gmail issues

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

I have recently received a message that I *SHALL* move to 2 Factor 
Authentication in Gsuite, and, as I suspected, this broke my arrangement 
(which exists sicne years and years) and I took my counter-measures, and I 
wish to share.

In a nutshell what I wanted to achieve and what I did is:

(1) I want to have mail stored locally on my machine, and to have
      incoming mails processed by procmail (this is not just for my fun,
      I have a couple of cases where procmail post-processes mail from
      forms to update a local database for service reasons).

(2) The simplest way to feed incoming mails into procmail is to use
     fetchmail, which I am happily using since 2018, when my institution
     moved from howgrown sendmail to Gsuite

(3) The simplest way to have fetchmail working (after I activated
      2FA on Gsuite fetchmail was not authenticateds) is to "bypass" Gmail,
      i.e. instruct Gsuite to forward all mail to another provider which
      provides *standard* IMAP.

      This solves 98% of my problems, because

      - Spam is not forwarded from Gmail to the alternate provider
      - messages forwrded *and deleted* are not actually deleted
        but staged in Gmail's Bin for 30 days

(4)  The solution is ... "app passwords". Gmail with 2FA allows to
      define a 16-char password THEY generate to be used with what in
      the past were called provocatorily "less secure applications"

      So I generated such an "app passwords" and I can use it from my
      preferred mail client (Alpine). And this solves my problem.

(5)  Actually the same app password can work also with fetchmail,
      so in theory I would not need the alternate provider of point (3) and
      could work "as previously", but I left it in.

I had no need to move to OAUTH2, or learn it, or get an OAUTH2-capable 
version of fetchmail (I use the OS-bundled one).

I think I could be happy with the new arrangement.

I hope the above is useful to somebody else.

-- 
Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
A middle rank researcher at end career is not rich but is in the top 5% 
of the Italian income tax taxpayers. Does it not sound strange ?

Re: [Fetchmail-users] downloading by date range

[Mihai L. <mt...@gm...>]

On Sunday, January 21, 2024 at 21:57:26 +0000, graeme vetterlein:

> Then, maybe about once a month, download WITHOUT KEEP mail over 12
> months old.
>
> This would have th effect of keeping about a years worth of mail
> available online, while having a backup kept daily.
>
> It's not obvious to me what the best way to achieve this is?

I am not aware of a fetchmail feature to do this, but I do annual 
cleanups using a MUA connected directly to the server (mutt or 
the provider's webmail) and then use it to delete messages by 
date ranges.

Hope it helps.

Mihai

[Fetchmail-users] downloading by date range

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

Good day, my 1st post.


I've been using fetchmail for the past many years (decades?) . I always 
used it in the same fashion

I polled my ISP every 5 minutes and poped or imapped (without -keep) the 
mail down to a local server.  This has worked

well.


However I have needed to change my ISP (after about 20 years) and my new 
mail solution has an online mailbox of around 10GB.


Looking at the sizes, it seems as if I could actually leave the mail on 
the online server (which has the advantage I can access it outside the 
house network) for at least a year.


I don't want to simply leave all my email online. So what I'd like to do 
is something like.


Pulldown my current email once a day , but with -keep, so it stays on 
the remote mailserver.


Then, maybe about once a month, download WITHOUT KEEP mail over 12 
months old.


This would have th effect of keeping about a years worth of mail 
available online, while having a backup kept daily.


It's not obvious to me what the best way to achieve this is?



--


Graeme

Re: [Fetchmail-users] Trouble with --expunge option

[Norman R. <nr...@cs...>]

 > thanks for a thorough report. What you are writing looks strange, and I
 > looked through the relevant source files (imap.c, driver.c, transact.c),
 > around the expunge_period variable, and it is confusing. There do not
 > appear to be strange patches inside Debian's package tracker, and I
 > think I will need to debug a bit deeper. Normally, Dovecot is also
 > well-behaved as a server and rather efficient, but if the host system is
 > under I/O strain and using mbox-like mailbox storage, it may be
 > inefficient with expunges because it might rewrite the mbox without the
 > expunged single message again and again - but then again the mailbox has
 > some mere 30 kByte in 10 messages, so that should not be it...

I worked with my best sysadmin this morning, and he confirmed that on
our Dovecot configuration, EXPUNGE can be expected to be slow.

I did poke at the source code for `imap.c`, but I did not figure out
where the expunges might be coming from.  Worst case I suppose I could
try to find or build a debug binary and run it under gdb, see what the
stack trace looks like when `internal_expunge` is being called.
But I'm hoping there might be an easier path.

 > Can you send only the .fetchmailrc part on imap.eecs.tufts.edu *without
 > password* so it's more concise to see?

It looks like this:

```
poll imap.eecs.tufts.edu protocol imap:
  user "nr" there is "nr" here mda "/home/nr/lib/osbf-mda" fetchall expunge 500;
```


Norman

Re: [Fetchmail-users] Trouble with --expunge option

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

Am 07.11.23 um 21:37 schrieb Norman Ramsey:
> I'm using fetchmail with IMAP, and it appears to be slamming my server
> pretty hard.  The issue shows when there are hundreds of messages
> waiting on the server; fetchmail appears to send an EXPUNGE after each
> message, and those are slow.
>
> In my configuration, I've set `expunge` to 500, but fetchmail still
> seems to be sending EXPUNGE after every message, and I've noticed no
> improvement in speed.
>
> I'm not sure if I misunderstand the use of the `expunge` parameter or
> if I'm overlooking something else.
>
> As per the FAQ,
>
>   1. My operating system is Debian GNU/Linux 12 (bookworm)
>
>   2. Fetchmail is installed from the Debian stable package repository.
>      Partial info:
>
>          Package: fetchmail
>          Status: install ok installed
>          Priority: optional
>          Section: mail
>          Installed-Size: 789
>          Maintainer: Laszlo Boszormenyi (GCS) <gc...@de...>
>          Architecture: amd64
>          Version: 6.4.37-1
>
>   3. I'm not sure how to tell what IMAP server I am talking to, but I
>      got this info from telnet:
>
>          $ telnet imap.eecs.tufts.edu 143
>          Trying 130.64.23.48...
>          Connected to imap.eecs.tufts.edu.
>          Escape character is '^]'.
>          * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.
>
>   4. I used these command lines:
>
>          env LC_ALL=C fetchmail -V > version.out
>          env LC_ALL=C fetchmail -v -L verbose.log
>          env LC_ALL=C fetchmail -vvv -L vvv.log
>          env LC_ALL=C fetchmail --nodetach -vvv --nosyslog > vvv.1
>
>   5. Outputs are attached.
>
> Any help would be appreciated.

Norman,

thanks for a thorough report. What you are writing looks strange, and I
looked through the relevant source files (imap.c, driver.c, transact.c),
around the expunge_period variable, and it is confusing. There do not
appear to be strange patches inside Debian's package tracker, and I
think I will need to debug a bit deeper. Normally, Dovecot is also
well-behaved as a server and rather efficient, but if the host system is
under I/O strain and using mbox-like mailbox storage, it may be
inefficient with expunges because it might rewrite the mbox without the
expunged single message again and again - but then again the mailbox has
some mere 30 kByte in 10 messages, so that should not be it...   I am
not sure if the --all option spoils things - but nothing strikes my eye
in the source code.

Can you send only the .fetchmailrc part on imap.eecs.tufts.edu *without
password* so it's more concise to see?

Regards,
Matthias

[Fetchmail-users] Trouble with --expunge option

[Norman R. <nr...@cs...>]

I'm using fetchmail with IMAP, and it appears to be slamming my server
pretty hard.  The issue shows when there are hundreds of messages
waiting on the server; fetchmail appears to send an EXPUNGE after each
message, and those are slow.

In my configuration, I've set `expunge` to 500, but fetchmail still
seems to be sending EXPUNGE after every message, and I've noticed no
improvement in speed.

I'm not sure if I misunderstand the use of the `expunge` parameter or
if I'm overlooking something else.

As per the FAQ,

 1. My operating system is Debian GNU/Linux 12 (bookworm)

 2. Fetchmail is installed from the Debian stable package repository.
    Partial info:
    
        Package: fetchmail
        Status: install ok installed
        Priority: optional
        Section: mail
        Installed-Size: 789
        Maintainer: Laszlo Boszormenyi (GCS) <gc...@de...>
        Architecture: amd64
        Version: 6.4.37-1

 3. I'm not sure how to tell what IMAP server I am talking to, but I
    got this info from telnet:
    
        $ telnet imap.eecs.tufts.edu 143
        Trying 130.64.23.48...
        Connected to imap.eecs.tufts.edu.
        Escape character is '^]'.
        * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.

 4. I used these command lines:
 
        env LC_ALL=C fetchmail -V > version.out
        env LC_ALL=C fetchmail -v -L verbose.log
        env LC_ALL=C fetchmail -vvv -L vvv.log
        env LC_ALL=C fetchmail --nodetach -vvv --nosyslog > vvv.1

 5. Outputs are attached.

Any help would be appreciated.


Norman Ramsey