fetchmail-users — User questions and discussion

Re: [Fetchmail-users] delay interval

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



El 2017-01-04 a las 17:24 -0000, piequiex escribió:

> The problem is I loss all messages, except first two. They all must be parsed
> with script, which I execute from procmailrc.
>
> I have discovered that all messages will delivered in case when delay
> interval present in loop. For example:
>
> for msg in file.???; do
> cat $msg | script;
> sleep 1;
> done

Probably your script is exiting too early, before it finishes 
processing.

Depending on how you do things, procmail can be called in parallel by 
several emails, so you either change your script to be able to cope with 
that situation, or tell the other software to only send one.

For example, if you are using postfix in the mix, you can tell it to 
process one email at a time for local delivery (slowing things down a 
lot).

You can also use lock files in procmail so that a section blocks if a 
parallel process is already in there.


Procmail is offtopic here, and you don't say what distribution you are 
using, but surely it has a help forum or mail list. I use openSUSE, you 
can find me there and I'll be happy to try to help. Otherwise, mail me 
directly, and time permitting, I'll try to help.


- -- 
Cheers
        Carlos E. R.

        (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlhuwQQACgkQja8UbcUWM1ypHgD8C6ef8G4HACmIfjZm+rPHPj6K
RgeHPDDSE0ijupeSbyUA/2QcceAc3PSFv2OLmoMXRpdZAWThKHiWVihQOAah/oRb
=mR5g
-----END PGP SIGNATURE-----

Re: [Fetchmail-users] delay interval

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

Am 04.01.2017 um 18:24 schrieb piequiex:
>> Am 03.01.2017 um 18:00 schrieb piequiex:
>>> Hello.
>>>
>>> Is it possible to set delay interval after every received message? 1-2
>>> seconds.
>>>
>> Hi,
>> no there isn't unless you want to change code or are using the --mda option.
> I have use --mda.
>
>> However, this should never be necessary. Why do you try to do that?
> The problem is I loss all messages, except first two. They all must be parsed
> with script, which I execute from procmailrc.

Then your script or the corresponding .procmailrc is faulty, or procmail
is, or your upstream server is, and it appears something's
asynchronously messing up things for you.

I don't see how you could find a delay interval that would *guarantee*
your setup to not lose mail. Imagine your computer running fetchmail
gets under load or swap pressure and the given delay that worked "in
good weather" is insufficient "in bad weather".

fetchmail waits until the command --mda has completed and obtains its
exit code (or termination signal) through pclose(), before fetching the
next message. You must make sure your script does not terminate
prematurely without losing its exit status, and that procmail properly
processes your script's exit status and conveys it back to fetchmail.
I know this is hard to get really robust with procmail, which is why
I've replaced it more than a decade ago, and warnings against using
procmail have been in fetchmail's manual for years.
(Error-handling endeavours get the typical non-trivial procmailrc on the
brink of becoming unreadable because you need to code all error-trapping
yourself.)

I am not going to help with debugging your procmailrc though, procmail
was abandoned more than 15 years and was retired more than 2 years
ago[1], and its website has disappeared.
I suggest that you debug your script and rigging and plan to migrate to
maildrop or another filtering solution that is still maintained and
supported.

Questions on how to use maildrop with fetchmail's --mda option can be
asked here, for maildrop itself, it has lists on its own.

[1] <https://marc.info/?l=openbsd-ports&m=141634350915839&w=2>

Sorry, this isn't terribly helpful on the short term, but I don't think
that changes to fetchmail's setup would make your script setup robust.
You really need to debug it and prepare yourself to exchange procmail in
the long run.

Re: [Fetchmail-users] delay interval

[piequiex <pie...@ny...>]

> Am 03.01.2017 um 18:00 schrieb piequiex:
> > Hello.
> >
> > Is it possible to set delay interval after every received message? 1-2
> > seconds.
> >
> Hi,
> no there isn't unless you want to change code or are using the --mda option.
I have use --mda.

> However, this should never be necessary. Why do you try to do that?
The problem is I loss all messages, except first two. They all must be parsed
with script, which I execute from procmailrc.

I have discovered that all messages will delivered in case when delay
interval present in loop. For example:

for msg in file.???; do
 cat $msg | script;
 sleep 1;
done

-- 
0x16E684E1A170D8A3

Re: [Fetchmail-users] delay interval

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

Am 03.01.2017 um 18:00 schrieb piequiex:
> Hello.
>
> Is it possible to set delay interval after every received message? 1-2
> seconds.
>
Hi,


no there isn't unless you want to change code or are using the --mda option.

However, this should never be necessary. Why do you try to do that?

[Fetchmail-users] delay interval

[piequiex <pie...@ny...>]

Hello.

Is it possible to set delay interval after every received message? 1-2
seconds.

-- 
Have a nice day!

Re: [Fetchmail-users] using logrotate to rotate the fetchmail log

[Chris <cpo...@em...>]

On Sat, 2016-09-24 at 19:28 -0500, Chris wrote:
> Is there a way that this can be done somehow? 
> 
> Thanks
> Chris
> 
I started this thread in Sept and I'm just now digging into this again.
Some things I've done and also some I've found I need but not sure how
to accomplish. I've got a 'fetchmail.logrotate' file in
/etc/logrotate.d:

/home/chris/fetchmaillog {
        prerotate
        /usr/local/bin/fetchmail --quit
        endscript
	daily
	rotate 8
	compress
	dateext
	missingok
	notifempty
	create 0664 chris chris
	postrotate
	/usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile
/home/chris/fetchmaillog --uidl -m procmail
	endscript
}

Running sudo logrotate -vd /etc/logrotate.conf shows me it reads the
fetchmail.logrotate file

rotating pattern: /home/chris/fetchmaillog  after 1 days (8 rotations)
empty log files are not rotated, old logs are removed
switching euid to 0 and egid to 104
considering log /home/chris/fetchmaillog
  log does not need rotating
switching euid to 0 and egid to 0

When the daily cron job for logrotate was run this morning I got this
output mailed to me:

/etc/cron.daily/logrotate:
error: fetchmail.logrotate:43 unknown option 'datext' -- ignoring line
fetchmail: WARNING: Running as root is discouraged.
fetchmail: no other fetchmail is running
fetchmail: WARNING: Running as root is discouraged.
fetchmail: no mailservers have been specified.
error: error running shared postrotate script for
'/home/chris/fetchmaillog '
run-parts: /etc/cron.daily/logrotate exited with return code 1

I've corrected the misspelling of 'dateext' however as can be seen it
tried to restart fetchmail as root. I've discovered that what I need is
a different state file for user chris

-s, --state <statefile>
    Tells logrotate to use an alternate state file. This is useful if
logrotate is being run as a different user for various sets of log
files. The default state file is /var/lib/logrotate.status. 

I imagine I need something like this which is in the /etc/cron.daily
folder

#!/bin/sh

# Clean non existent log file entries from status file
cd /var/lib/logrotate
test -e status || touch status
head -1 status > status.clean
sed 's/"//g' status | while read logfile date
do
    [ -e "$logfile" ] && echo "\"$logfile\" $date"
done >> status.clean
mv status.clean status

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

So, can I modify the above and call it something else while changing
the first line to read something like

cd /home/chris/.logrotate

and the last line to be something like 

sudo -u chris /usr/sbin/logrotate /home/chris/.logrotate.conf

and put this

/home/chris/fetchmaillog {
        prerotate
        /usr/local/bin/fetchmail --quit
        endscript
	daily
	rotate 8
	compress
	dateext
	missingok
	notifempty
	create 0664 chris chris
	postrotate
	/usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile
/home/chris/fetchmaillog --uidl -m procmail
	endscript
}

into the /home/chris/.logrotate.conf file?

Apologies for the lengthy post but I think I've covered everything I've
done so far and the results or lack there of.

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
14:57:23 up 7 days, 3 min, 1 user, load average: 0.15, 0.21, 0.14
Ubuntu 16.04.1 LTS, kernel 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9
23:50:32 UTC 2016

Re: [Fetchmail-users] Removing 6.3.26 (Ubuntu version)

[Chris <cpo...@em...>]

On Mon, 2016-12-26 at 13:16 +0100, Matthias Andree wrote:
> 
> On 12/24/16 15:56, Chris wrote:
> > 
> > Would removing this cause any issues with the beta I'm running now?
> 
> Hi Chris,
> 
> you'd probably lose all the glue that the Debian/Ubuntu package
> brought 
> in, such as Upstart or systemd launch and thereabouts.
> 
> If you've manually set up your personal crontab to re-launch
> fetchmail, 
> that may be OK.
> 
> HTH
> Matthias
> 
Good morning Matthias, I ran into a problem a long time ago with
fetchmail being restarted on boot so I have this crontab setup which
runs during a reboot. I actually just set it up using Webmin.

/usr/local/bin/fetchmail --quit; fetchmail -v --nokeep --nosyslog --
logfile /home/chris/fetchmaillog --uidl -m procmail

I just added the full path to ensure that now it calls the beta instead
of the 6.3.26 version. The older version isn't taking up that much
space so I'll just leave it as it is.

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:28:00 up 5 days, 17:33, 1 user, load average: 0.81, 0.51, 0.44
Ubuntu 16.04.1 LTS, kernel 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9
23:50:32 UTC 2016

Re: [Fetchmail-users] Removing 6.3.26 (Ubuntu version)

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

On 12/24/16 15:56, Chris wrote:
> Would removing this cause any issues with the beta I'm running now?

Hi Chris,

you'd probably lose all the glue that the Debian/Ubuntu package brought 
in, such as Upstart or systemd launch and thereabouts.

If you've manually set up your personal crontab to re-launch fetchmail, 
that may be OK.

HTH
Matthias

[Fetchmail-users] Removing 6.3.26 (Ubuntu version)

[Chris <cpo...@em...>]

Would removing this cause any issues with the beta I'm running now? 

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:54:22 up 3 days, 18:00, 1 user, load average: 0.15, 0.25, 0.30
Ubuntu 16.04.1 LTS, kernel 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9
23:50:32 UTC 2016

Re: [Fetchmail-users] fetchmail 6.4.0-beta2 released - please test

[Chris <cpo...@em...>]

On Fri, 2016-12-23 at 18:39 +0100, Matthias Andree wrote:
> Am 23.12.2016 um 00:50 schrieb Chris:
> > 
> > 

> Hi Chris,
> 
> thanks for taking the time to test the beta and report back!

You're welcome, don't mind at all. 
> 
> 
> Your logs:
> > 
> > fetchmail: 6.3.26 querying toadnet.com (protocol POP3) at Thu 22
> > Dec
> > 2016 03:56:18 PM CST: poll started
> > [...]
> > fetchmail: Server certificate:
> > fetchmail: Issuer Organization: cPanel, Inc.
> > fetchmail: Issuer CommonName: cPanel, Inc. Certification Authority
> > fetchmail: Subject CommonName: linuxsrv02.usdcservers.net
> > fetchmail: Subject Alternative Name: linuxsrv02.usdcservers.net
> > fetchmail: Subject Alternative Name: www.linuxsrv02.usdcservers.net
> > fetchmail: Server CommonName mismatch: linuxsrv02.usdcservers.net
> > !=
> > toadnet.com
> > fetchmail: toadnet.com key fingerprint:
> > EE:5B:31:D6:26:5B:74:9A:19:BF:2F:40:4A:0F:F9:E4
> > fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-
> > AES256-
> > GCM-SHA384, 256/256 secret/processed bits
> > fetchmail: Warning: the connection is insecure, continuing anyways.
> > (Better use --sslcertck!)
> So you see it complains, because it can't establish that it's talking
> directly to toadnet.com - the server it connected to can prove the
> identities "linuxsrv02.usdcservers.net"
> and "www.linuxsrv02.usdcservers.net, but not "toadnet.com" (which is
> missing from the subAltName = Subject Alternative Name list).
> 
> Normally you'd need to get a certificate that also mentions
> "toadnet.com" in its Subject Alternative Names, but in your
> particular
> case, since the server appears to also be reachable by the name
> linuxsrv02.usdcservers.net, it would be easiest to shut down
> fetchmail,
> edit the .fetchmailrc to start with what's shown below, and restart
> fetchmail (you may want to use --keep on the command line initially
> in
> case you need to fix mail routing after that):
> 
> poll linuxsrv02.usdcservers.net aka toadnet.com
> ... (other options remain here) ...
> 
> The "aka toadnet.com" part is needed for multidrop mailboxes only
> (such
> that fetchmail knows it needs to rewrite toadnet.com domains).
> 
> > 
> > After installing the beta the poll shows:
> > 
> > fetchmail: 6.4.0.beta2 querying toadnet.com (protocol POP3) at Thu
> > 22
> > Dec 2016 05:29:14 PM CST: poll started
> > [...]
> > fetchmail: Server certificate:
> > fetchmail: Issuer Organization: cPanel, Inc.
> > fetchmail: Issuer CommonName: cPanel, Inc. Certification Authority
> > fetchmail: Subject CommonName: linuxsrv02.usdcservers.net
> > fetchmail: Subject Alternative Name: linuxsrv02.usdcservers.net
> > fetchmail: Subject Alternative Name: www.linuxsrv02.usdcservers.net
> > fetchmail: Server CommonName mismatch: linuxsrv02.usdcservers.net
> > !=
> > toadnet.com
> > fetchmail: toadnet.com key fingerprint:
> > EE:5B:31:D6:26:5B:74:9A:19:BF:2F:40:4A:0F:F9:E4
> > fetchmail: OpenSSL reported: error:14090086:SSL
> > routines:ssl3_get_server_certificate:certificate verify failed
> > fetchmail: toadnet.com: upgrade to TLS failed.
> > fetchmail: Unknown login or authentication error on *@toadnet.com@t
> > oadn
> > et.com
> > fetchmail: socket error while fetching from *@toadnet.com@toadnet.c
> > om
> 
Changing my .fetchmailrc to:
poll linuxsrv02.usdcservers.net aka toadnet.com proto pop3 timeout 180
interval 60
username "@toadnet.com" password "" is cpollock here

it works perfectly. 

The log file now shows

fetchmail: 6.4.0.beta2 querying linuxsrv02.usdcservers.net (protocol
POP3) at Fri 23 Dec 2016 11:54:48 AM CST: poll started
fetchmail: Trying to connect to 107.181.163.242/110...connected.
fetchmail: POP3< +OK Dovecot ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< STLS
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation now.
fetchmail: Certificate chain, from root to peer, starting at depth 3:
fetchmail: Issuer Organization: AddTrust AB
fetchmail: Issuer CommonName: AddTrust External CA Root
fetchmail: Subject CommonName: AddTrust External CA Root
fetchmail: Certificate at depth 2:
fetchmail: Issuer Organization: AddTrust AB
fetchmail: Issuer CommonName: AddTrust External CA Root
fetchmail: Subject CommonName: COMODO RSA Certification Authority
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: COMODO CA Limited
fetchmail: Issuer CommonName: COMODO RSA Certification Authority
fetchmail: Subject CommonName: cPanel, Inc. Certification Authority
fetchmail: Server certificate:
fetchmail: Issuer Organization: cPanel, Inc.
fetchmail: Issuer CommonName: cPanel, Inc. Certification Authority
fetchmail: Subject CommonName: linuxsrv02.usdcservers.net
fetchmail: Subject Alternative Name: linuxsrv02.usdcservers.net
fetchmail: Subject Alternative Name: www.linuxsrv02.usdcservers.net
fetchmail: linuxsrv02.usdcservers.net key fingerprint:
EE:5B:31:D6:26:5B:74:9A:19:BF:2F:40:4A:0F:F9:E4
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-
GCM-SHA384, 256/256 secret/processed bits
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: linuxsrv02.usdcservers.net: upgrade to TLS succeeded.
fetchmail: POP3> USER *@toadnet.com
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Logged in.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for *@toadnet.com at linuxsrv02.usdcservers.net
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Logging out.

Looks good here now. Everything works including yahoo where I had to
set the security to "Allow apps that use less secure sign in" which is
stupid in my opinion. 

Good job! 

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
11:58:53 up 2 days, 21:04, 1 user, load average: 1.00, 0.55, 0.37
Ubuntu 16.04.1 LTS, kernel 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9
23:50:32 UTC 2016

Re: [Fetchmail-users] fetchmail 6.4.0-beta2 released - please test

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

Am 23.12.2016 um 00:50 schrieb Chris:
> On Mon, 2016-12-12 at 04:07 +0100, Matthias Andree wrote:
>> [Attempt to re-send, this time with intact signature. I hope.]
>>
>> Greetings,
>>
>> I have just released fetchmail 6.4.0-beta2, and can be
>> downloaded from
>> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.
>>
>>  
> Hello Matthias, I've installed 6.4.0-beta2 on my Ubuntu 16.04.1 LTS
> system this afternoon. I must say this was the easiest and fastest
> install of any application I remember lately. So far, with the
> exception of the issue below it's running smoothly. The issue is with
> my domain which is hosted elsewhere. The poll with version 6.3.26
> worked correctly:

Hi Chris,

thanks for taking the time to test the beta and report back!

What you are seeing is an issue with the security certificate that
fetchmail 6.3.26 complained about, but due to different default did not
reject. 6.4.0 will flip the "--sslcertck" switch, as written in the NEWS
file, so it now drops the connection.
> * Fetchmail defaults to --sslcertck behaviour. A new option
> --nosslcertck to
>   override this has been added, but may be removed in future fetchmail
> versions
>   in favour of another configuration option that makes the insecurity
> in using
>   this option clearer.

Your logs:
> fetchmail: 6.3.26 querying toadnet.com (protocol POP3) at Thu 22 Dec
> 2016 03:56:18 PM CST: poll started
> [...]
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: cPanel, Inc.
> fetchmail: Issuer CommonName: cPanel, Inc. Certification Authority
> fetchmail: Subject CommonName: linuxsrv02.usdcservers.net
> fetchmail: Subject Alternative Name: linuxsrv02.usdcservers.net
> fetchmail: Subject Alternative Name: www.linuxsrv02.usdcservers.net
> fetchmail: Server CommonName mismatch: linuxsrv02.usdcservers.net !=
> toadnet.com
> fetchmail: toadnet.com key fingerprint:
> EE:5B:31:D6:26:5B:74:9A:19:BF:2F:40:4A:0F:F9:E4
> fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-
> GCM-SHA384, 256/256 secret/processed bits
> fetchmail: Warning: the connection is insecure, continuing anyways.
> (Better use --sslcertck!)
So you see it complains, because it can't establish that it's talking
directly to toadnet.com - the server it connected to can prove the
identities "linuxsrv02.usdcservers.net"
and "www.linuxsrv02.usdcservers.net, but not "toadnet.com" (which is
missing from the subAltName = Subject Alternative Name list).

Normally you'd need to get a certificate that also mentions
"toadnet.com" in its Subject Alternative Names, but in your particular
case, since the server appears to also be reachable by the name
linuxsrv02.usdcservers.net, it would be easiest to shut down fetchmail,
edit the .fetchmailrc to start with what's shown below, and restart
fetchmail (you may want to use --keep on the command line initially in
case you need to fix mail routing after that):

poll linuxsrv02.usdcservers.net aka toadnet.com
... (other options remain here) ...

The "aka toadnet.com" part is needed for multidrop mailboxes only (such
that fetchmail knows it needs to rewrite toadnet.com domains).

> After installing the beta the poll shows:
>
> fetchmail: 6.4.0.beta2 querying toadnet.com (protocol POP3) at Thu 22
> Dec 2016 05:29:14 PM CST: poll started
> [...]
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: cPanel, Inc.
> fetchmail: Issuer CommonName: cPanel, Inc. Certification Authority
> fetchmail: Subject CommonName: linuxsrv02.usdcservers.net
> fetchmail: Subject Alternative Name: linuxsrv02.usdcservers.net
> fetchmail: Subject Alternative Name: www.linuxsrv02.usdcservers.net
> fetchmail: Server CommonName mismatch: linuxsrv02.usdcservers.net !=
> toadnet.com
> fetchmail: toadnet.com key fingerprint:
> EE:5B:31:D6:26:5B:74:9A:19:BF:2F:40:4A:0F:F9:E4
> fetchmail: OpenSSL reported: error:14090086:SSL
> routines:ssl3_get_server_certificate:certificate verify failed
> fetchmail: toadnet.com: upgrade to TLS failed.
> fetchmail: Unknown login or authentication error on *@toadnet.com@toadn
> et.com
> fetchmail: socket error while fetching from *@toadnet.com@toadnet.com

Re: [Fetchmail-users] fetchmail 6.4.0-beta2 released - please test

[Chris <cpo...@em...>]

On Mon, 2016-12-12 at 04:07 +0100, Matthias Andree wrote:
> [Attempt to re-send, this time with intact signature. I hope.]
> 
> Greetings,
> 
> I have just released fetchmail 6.4.0-beta2, and can be
> downloaded from
> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.
> 
> 
Hello Matthias, I've installed 6.4.0-beta2 on my Ubuntu 16.04.1 LTS
system this afternoon. I must say this was the easiest and fastest
install of any application I remember lately. So far, with the
exception of the issue below it's running smoothly. The issue is with
my domain which is hosted elsewhere. The poll with version 6.3.26
worked correctly:

fetchmail: 6.3.26 querying toadnet.com (protocol POP3) at Thu 22 Dec
2016 03:56:18 PM CST: poll started
fetchmail: Trying to connect to 107.181.163.242/110...connected.
fetchmail: POP3< +OK Dovecot ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< STLS
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation now.
fetchmail: Certificate chain, from root to peer, starting at depth 3:
fetchmail: Issuer Organization: AddTrust AB
fetchmail: Issuer CommonName: AddTrust External CA Root
fetchmail: Subject CommonName: AddTrust External CA Root
fetchmail: Certificate at depth 2:
fetchmail: Issuer Organization: AddTrust AB
fetchmail: Issuer CommonName: AddTrust External CA Root
fetchmail: Subject CommonName: COMODO RSA Certification Authority
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: COMODO CA Limited
fetchmail: Issuer CommonName: COMODO RSA Certification Authority
fetchmail: Subject CommonName: cPanel, Inc. Certification Authority
fetchmail: Server certificate:
fetchmail: Issuer Organization: cPanel, Inc.
fetchmail: Issuer CommonName: cPanel, Inc. Certification Authority
fetchmail: Subject CommonName: linuxsrv02.usdcservers.net
fetchmail: Subject Alternative Name: linuxsrv02.usdcservers.net
fetchmail: Subject Alternative Name: www.linuxsrv02.usdcservers.net
fetchmail: Server CommonName mismatch: linuxsrv02.usdcservers.net !=
toadnet.com
fetchmail: toadnet.com key fingerprint:
EE:5B:31:D6:26:5B:74:9A:19:BF:2F:40:4A:0F:F9:E4
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-
GCM-SHA384, 256/256 secret/processed bits
fetchmail: Warning: the connection is insecure, continuing anyways.
(Better use --sslcertck!)
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: toadnet.com: upgrade to TLS succeeded.
fetchmail: POP3> USER *@toadnet.com
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Logged in.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for *@toadnet.com at toadnet.com

After installing the beta the poll shows:

fetchmail: 6.4.0.beta2 querying toadnet.com (protocol POP3) at Thu 22
Dec 2016 05:29:14 PM CST: poll started
fetchmail: Trying to connect to 107.181.163.242/110...connected.
fetchmail: POP3< +OK Dovecot ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK
fetchmail: POP3< CAPA
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< STLS
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation now.
fetchmail: Certificate chain, from root to peer, starting at depth 3:
fetchmail: Issuer Organization: AddTrust AB
fetchmail: Issuer CommonName: AddTrust External CA Root
fetchmail: Subject CommonName: AddTrust External CA Root
fetchmail: Certificate at depth 2:
fetchmail: Issuer Organization: AddTrust AB
fetchmail: Issuer CommonName: AddTrust External CA Root
fetchmail: Subject CommonName: COMODO RSA Certification Authority
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: COMODO CA Limited
fetchmail: Issuer CommonName: COMODO RSA Certification Authority
fetchmail: Subject CommonName: cPanel, Inc. Certification Authority
fetchmail: Server certificate:
fetchmail: Issuer Organization: cPanel, Inc.
fetchmail: Issuer CommonName: cPanel, Inc. Certification Authority
fetchmail: Subject CommonName: linuxsrv02.usdcservers.net
fetchmail: Subject Alternative Name: linuxsrv02.usdcservers.net
fetchmail: Subject Alternative Name: www.linuxsrv02.usdcservers.net
fetchmail: Server CommonName mismatch: linuxsrv02.usdcservers.net !=
toadnet.com
fetchmail: toadnet.com key fingerprint:
EE:5B:31:D6:26:5B:74:9A:19:BF:2F:40:4A:0F:F9:E4
fetchmail: OpenSSL reported: error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed
fetchmail: toadnet.com: upgrade to TLS failed.
fetchmail: Unknown login or authentication error on *@toadnet.com@toadn
et.com
fetchmail: socket error while fetching from *@toadnet.com@toadnet.com
fetchmail: 6.4.0.beta2 querying toadnet.com (protocol POP3) at Thu 22
Dec 2016 05:29:14 PM CST: poll completed
fetchmail: Merged UID list from toadnet.com:
 <empty>

The commandline I'm using is:

fetchmail -v -v -v --nokeep --nosyslog --logfile
/home/chris/fetchmaillog --uidl -m procmail

The version of openssl I have installed

chris@localhost:~$ apt-cache policy openssl
openssl:
  Installed: 1.0.2g-1ubuntu4.5
  Candidate: 1.0.2g-1ubuntu4.5

Let me know If I can provide any other information. Other than the one
issue good work!

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
17:17:01 up 2 days, 2:22, 1 user, load average: 1.05, 0.70, 0.47
Ubuntu 16.04.1 LTS, kernel 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9
23:50:32 UTC 2016

Re: [Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

[Rick H. <ric...@ya...>]

On Mon, 2016-12-19 at 19:30 +0100, Matthias Andree wrote:
> Am 19.12.2016 um 02:57 schrieb Rick Harris:
> 
> > > > Also since switching to --uidl, fetchmail no longer marks the
messages
> > on the remote server as being read.
> > > > Is there a way to tell fetchmail to mark the messages it downloads
as
> > read on the remote server using --uidl?
> 
> Yes, there is (since 6.3.9), but it's undocumented.
> 
> > You can set an environment variable named FETCHMAIL_POP3_FORCE_RETR
(it
> > only needs to exist even if empty, or can have any value), which
forces
> > fetchmail to use the "RETR msgno" command, whereas with UIDL,
fetchmail
> > would normally use "TOP msgno" with a huge number of lines to list
from
> the top.
> 
> > Note though that the POP3 protocol itself does not specify a notion
of
> > seen vs. unseen messages, so whatever the server does is
implementation-
> and operator-defined as far as fetchmail is concerned.
> 

That works perfectly!
Everything is back on track now and look forward to the next release.


Many thanks again,
Rick

Re: [Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

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

Am 19.12.2016 um 02:57 schrieb Rick Harris:

> Also since switching to --uidl, fetchmail no longer marks the messages
> on the remote server as being read.
> Is there a way to tell fetchmail to mark the messages it downloads as
> read on the remote server using --uidl?

Yes, there is (since 6.3.9), but it's undocumented.

You can set an environment variable named FETCHMAIL_POP3_FORCE_RETR (it
only needs to exist even if empty, or can have any value), which forces
fetchmail to use the "RETR msgno" command, whereas with UIDL, fetchmail
would normally use "TOP msgno" with a huge number of lines to list from
the top.

Note though that the POP3 protocol itself does not specify a notion of
seen vs. unseen messages, so whatever the server does is implementation-
and operator-defined as far as fetchmail is concerned.

HTH.

Cheers,
Matthias

Re: [Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

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

Am 17.12.2016 um 04:48 schrieb Matthias Andree:
> Greetings,
>
> Rick has sent me verbose traces off-list, and they show that fetchmail
> 6.3.26 talks "LAST" with the server, but not UIDL, so I presume any
> .fetchids are from other accounts.

hmm... this might not be the case. There appears to be a corner case
where the results from "LAST" are disregarded when there are saved UIDs
for the account that I can reproduce. So if your an that now runs off
LAST but has UIDs saved (for instance, because the LAST command ever
failed and a subequent "UIDL" succeeded, that might explain the behaviour).

I am not yet sure how to best tackle this in since I need to read more
code to get the complte overview.  The obvious workaround in my writing
new code is to avoid the LAST command if there is at least one UID
saved, to match the logic that the pop3_is_old() function uses to
establish whether it has previously downloaded a particular message
offered by the server.

Rick, do you happen to have an older .fetchids file from before you
switched to --uidl, perhaps in a backup? If so, I'd like to have it
(off-list).
Has there been at least one line in the .fetchids file related to the
Yahoo account that was now re-downloading mail?

At any rate, in your particular case, Rick, --uidl (or uidl in the
fetchmailrc file) is the safe fix for good. The CPU time use of UIDL has
always been a bit high up to and including the latest 6.3.X release,
6.4.0-beta2 improves on that and is available from
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

Re: [Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2016-12-18 00:31, Rick Harris wrote:

> Something else that perhaps confirms some changes by Yahoo in
> recent days is a new security settings popup that shows when
> logging into their webmail interface that states:"Some older email
> applications deploy an older security protocol to sign into your
> account. Going forward, to further improve the security of your
> Yahoo Mail experience, Yahoo may block sign in attempts from these
> older security protocols. We may block email applications that use
> a no longer recommended sign in method from accessing Yahoo
> accounts."

Google does the same. To interact with fetchmail and others you have
to disable the new security setting, which is impossible to support in
daemons. It is interactive and needs displaying web forms.

If they care about security, they could instead use certificates.


For instance, I travelled to a different city and google instantly
refused to work with one of my accounts, I had login on some form and
reactivate.

- -- 
Cheers / Saludos,

		Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlhV0ukACgkQja8UbcUWM1y3JgD/bQKv9tc/jnANV1YOgf1EI3IT
lujJhtLQ6RPNR0U3VoUA+waIpseH1lVbY27/8zOJnV7bkmRPhenBXc7ESMD/blOS
=ODYG
-----END PGP SIGNATURE-----

Re: [Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

[Rick H. <ric...@ya...>]

Hello again Matthias,
Setting 'uidl' in fetchmailrc was the magic solution thank you!!Fetchmail is now recognising 'seen' messages and not continually downloading all messages.
I've also set 'uidl' globally for the other POP3 mail providers I fetch from as these were complaining with:Dec 15 21:33:39 control fetchmail[23655]: POP3> LAST
Dec 15 21:33:39 control fetchmail[23655]: POP3< -ERR Unknown command: LAST
Dec 15 21:33:39 control fetchmail[23655]: Unknown command: LAST
Dec 15 21:33:39 control fetchmail[23655]: POP3> UIDL
Dec 15 21:33:39 control fetchmail[23655]: POP3< +OK

My thought is that some change at Yahoo's end has caused LAST to stop working as the only recent change I'd made on my side was that fetchmail-6.3.26 was installed in July.
Something else that perhaps confirms some changes by Yahoo in recent days is a new security settings popup that shows when logging into their webmail interface that states:"Some older email applications deploy an older security protocol to sign into your account. Going forward, to further improve the security of your Yahoo Mail experience, Yahoo may block sign in attempts from these older security protocols. We may block email applications that use a no longer recommended sign in method from accessing Yahoo accounts."

Not to mention the mad scramble with changes being made behind the scenes at Yahoo after their latest security breach.
Obviously they'd not blocked fetchmail but perhaps the changes they have made have had the affect of breaking the way fetchmail communicates with their servers using LAST.
Your suspicion of the .fetchids file entries being filled by other providers was also spot on.Once 'uidl' was set and fetchmail had re-fetched all the 'seen' messages one final time from Yahoo, the number of entries in .fetchids increased by roughly the same amount of Yahoo 'seen' messages.
Thanks again for providing a solution, let me know if you need me to do anything else to help debug.

Cheers,Rick 

    On Saturday, 17 December 2016, 14:19, Matthias Andree <mat...@gm...> wrote:
 

 Greetings,

Rick has sent me verbose traces off-list, and they show that fetchmail
6.3.26 talks "LAST" with the server, but not UIDL, so I presume any
.fetchids are from other accounts.

Rick, I propose, as a band-aid, to try the --uidl option on the command
line, or uidl in the rcfile, either one should be sufficient to try and
enforce the use of UIDL instead of LAST.

I haven't yet followed the fetchmail code paths because "LAST" is hardly
used and I don't recommend it, and I need some quality time to debug
that - and note that LAST has also been pulled from the standard¹
(because it gets confused and can cause clients to skip mail when a
second other client accesses the same mailbox), but chances are that
somewhen in the late 6.2 or in the 6.3 phase the LAST code has
regressed. I will remove it from one of the future fetchmail versions
anyhow, and to be honest I'll only do a 6.3.26.1 with that one fix if
it's low-hanging fruit or else add a FAQ item.

¹ it used to be part of RFC1725 of 1994, but was removed in RFC1939 in
May 1996.

Cheers,
Matthias


   

Re: [Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

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

Greetings,

Rick has sent me verbose traces off-list, and they show that fetchmail
6.3.26 talks "LAST" with the server, but not UIDL, so I presume any
.fetchids are from other accounts.

Rick, I propose, as a band-aid, to try the --uidl option on the command
line, or uidl in the rcfile, either one should be sufficient to try and
enforce the use of UIDL instead of LAST.

I haven't yet followed the fetchmail code paths because "LAST" is hardly
used and I don't recommend it, and I need some quality time to debug
that - and note that LAST has also been pulled from the standard¹
(because it gets confused and can cause clients to skip mail when a
second other client accesses the same mailbox), but chances are that
somewhen in the late 6.2 or in the 6.3 phase the LAST code has
regressed. I will remove it from one of the future fetchmail versions
anyhow, and to be honest I'll only do a 6.3.26.1 with that one fix if
it's low-hanging fruit or else add a FAQ item.

¹ it used to be part of RFC1725 of 1994, but was removed in RFC1939 in
May 1996.

Cheers,
Matthias

Re: [Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

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

Am 14. Dezember 2016 13:28:27 MEZ, schrieb Rick Harris
<ric...@ya...>:

    Hi,
    Been a constant user of fetchmail for many years now without issue but suddenly today it is now stuck in a loop constantly downloading all the messages off the remote POP3 server over and over.
    My /etc/fetchmailrc config has not changed nor has the machine fetchmail is running on received any software updates in some months.
    Here is a syslog snippet:fetchmail: reading message ric...@po...:1919 of 1919 (51608 octets) not flushed
    fetchmail: 1919 messages (1919 seen) for rickharris at pop.mail.yahoo.com.au <http://pop.mail.yahoo.com.au> (384268734 octets).
    fetchmail: reading message ric...@po...:1 of 1919 (11191 octets) not flushed
    fetchmail: reading message ric...@po...:2 of 1919 (9625 octets) not flushed
    <snip>...and onwards forever downloading the same messages over and over again.
    /etc/fetchmailrc
    set postmaster "postmaster"
    set no bouncemail
    set no spambounce
    set properties ""
    set syslog
    set invisible
    poll pop.mail.yahoo.com.au <http://pop.mail.yahoo.com.au> with proto POP3
           user "rickharris", with password "...", is "rickharris" here, nofetchall keep limit 20240000
           ssl

    The 'nofetchall' option was added after reading http://www.fetchmail.info/fetchmail-FAQ.html#O9 but
    <http://www.fetchmail.info/fetchmail-FAQ.html#O9%C2%A0but> has done nothing to fix the problem.
    I am not able to test removing the 'keep' option as I wish to keep the messages on the remote server (and it's always worked previously).
    Any guidance as to what might be causing this?
    The only workaround I have so far is to stop using fetchmail when I'd really like to continue using it.

    Regards,Rick
    ------------------------------------------------------------------------

    Check out the vibrant tech community on one of the world's most 
    engaging tech sites, SlashDot.org <http://SlashDot.org>! http://sdm.link/slashdot
    ------------------------------------------------------------------------

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

Hi Rick, That is mysterious. is the hardware failing, or was there a
brownout? Does the problem persist if you reboot the computer? Can you
run a memory check tool and see if it finds anything of concern? If it
does, can you send me verbose logs (FAQ item #G3) off-list? Regards,
Matthias

[Fetchmail-users] Fetchmail suddenly downloading the same messages over and over

[Rick H. <ric...@ya...>]

Hi,
Been a constant user of fetchmail for many years now without issue but suddenly today it is now stuck in a loop constantly downloading all the messages off the remote POP3 server over and over.
My /etc/fetchmailrc config has not changed nor has the machine fetchmail is running on received any software updates in some months.
Here is a syslog snippet:fetchmail: reading message ric...@po...:1919 of 1919 (51608 octets) not flushed
fetchmail: 1919 messages (1919 seen) for rickharris at pop.mail.yahoo.com.au (384268734 octets).
fetchmail: reading message ric...@po...:1 of 1919 (11191 octets) not flushed
fetchmail: reading message ric...@po...:2 of 1919 (9625 octets) not flushed
<snip>...and onwards forever downloading the same messages over and over again.
/etc/fetchmailrc
set postmaster "postmaster"
set no bouncemail
set no spambounce
set properties ""
set syslog
set invisible
poll pop.mail.yahoo.com.au with proto POP3
       user "rickharris", with password "...", is "rickharris" here, nofetchall keep limit 20240000
       ssl

The 'nofetchall' option was added after reading http://www.fetchmail.info/fetchmail-FAQ.html#O9 but has done nothing to fix the problem.
I am not able to test removing the 'keep' option as I wish to keep the messages on the remote server (and it's always worked previously).
Any guidance as to what might be causing this?
The only workaround I have so far is to stop using fetchmail when I'd really like to continue using it.

Regards,Rick

[Fetchmail-users] fetchmail 6.4.0-beta2 released - please test

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

[Attempt to re-send, this time with intact signature. I hope.]

Greetings,

I have just released fetchmail 6.4.0-beta2, and can be
downloaded from
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

Important changes:
- SSL code reworked a bit with support for newer TLS protocols, more
options for --sslproto, and some decoupling of the SSL protocol version
versus if a service is SSL-wrapped (--ssl option) or uses STARTTLS
(default).
- SSLv2 dropped, SSLv3 deprecated and not negotiated by default.
- Compatibility improved with newer OpenSSL releases, and - albeit
unsupported - LibreSSL.
- --sslcertck is now default.
- Optimized UIDL handling in POP3 configurations with --keep and servers
supporting the UIDL command. I meant to ship this only with fetchmail
7.0.x but there is no point in holding it back.
- .tar.bz2 is no longer created, the .tar.xz is much smaller and xz is
now mature and widely available.

Important non-changes:
- except where deprecated protocol versions are in use, the
configuration file and data files (.fetchids, .fetchmail.pid) should be
compatible with recent 6.3.X releases.

Future directions:
I intend to release fetchmail 6.4.0 formally in a few weeks, and abandon
the fetchmail 6.3.X branch (legacy_63). There are no features, and I
intend to keep the 6.4.X branch (legacy_64) only for important bug
fixes, features are merged onto the master branch that should end up as
fetchmail 7.0 some day.

The SSL changes in particular need thorough testing and possibly a bit
more documentation.
Let me know what you'll find. I am looking forward to your beta test
findings.

Happy fetching!

Matthias

[Fetchmail-users] fetchmail 6.4.0-beta2 released - please test

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

Greetings,

I have just released fetchmail 6.4.0-beta2, and can be
downloaded from
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

Important changes:
- SSL code reworked a bit with support for newer TLS protocols, more
options for --sslproto, and some decoupling of the SSL protocol version
versus if a service is SSL-wrapped (--ssl option) or uses STARTTLS
(default).
- SSLv2 dropped, SSLv3 deprecated and not negotiated by default.
- Compatibility improved with newer OpenSSL releases, and - albeit
unsupported - LibreSSL.
- --sslcertck is now default.
- Optimized UIDL handling in POP3 configurations with --keep and servers
supporting the UIDL command. I meant to ship this only with fetchmail
7.0.x but there is no point in holding it back.
- .tar.bz2 is no longer created, the .tar.xz is much smaller and xz is
now mature and widely available.

Important non-changes:
- except where deprecated protocol versions are in use, the
configuration file and data files (.fetchids, .fetchmail.pid) should be
compatible with recent 6.3.X releases.

Future directions:
I intend to release fetchmail 6.4.0 formally in a few weeks, and abandon
the fetchmail 6.3.X branch (legacy_63). There are no features, and I
intend to keep the 6.4.X branch (legacy_64) only for important bug
fixes, features are merged onto the master branch that should end up as
fetchmail 7.0 some day.

The SSL changes in particular need thorough testing and possibly a bit
more documentation.
Let me know what you'll find. I am looking forward to your beta test
findings.

Happy fetching!

Matthias

Re: [Fetchmail-users] IMAP IDLE works only somtiemes

[Volker W. <po...@vo...>]

Am Mittwoch, 30. November 2016, 00:14:41 CET schrieb Matthias Andree:
> Am 28.11.2016 um 14:18 schrieb Volker Wysk:
> > Hello!
> > 
> > I've set up fetchmail to fetch my mail via IMAP IDLE. This had worked.
> > 
> > But since a fews days, this works only sometimes. Sometimes, mail, which I
> > can see in the webmail interface of my webhoster, stays there, and
> > doesn't get collected. When I restart the fetchmail service, the mail
> > does get fetched.
> > 
> > I have set the "fetchall" parameter, that's not the reason.
> > 
> > Anyone with similar problems? Should I abstain from IMAP IDLE?
> 
> So, in the light of your other messages:
> - what did you change on your end?

Nothing that I'm aware of...

>     - what else has changed (OS updates, library updates,
> reconfiguration of network... anything related to ICMP, MSS, ...)?

I'm not sure. I just looked in the webmail backend, because I was suspicious, 
and saw some unfetched messages. Then I restarted fetchmail and the messages 
got fetched. This occured again afterwards. I don't know the exact moment when 
the problem occured first.

> - what did change on the server's end? It appears to be running an
> ancient version of Courier-IMAP...

The server isn't under my control. It's the mailserver of my web hoster. It 
might be the server's fault...

> - if you're willing to give IDLE another spin, does mail arrive if you
> wait for another half hour in IDLE mode?

I'd rather abstain from IMAP IDLE for now...

>   But without a smoking gun, i. e. a debug log showing missed IMAP
> messages, it's hard to judge anything, sorry.

Yes, I know. I've already given up. Guess it could be really hard to debug 
this.

Thanks,
Volker

Re: [Fetchmail-users] IMAP IDLE works only somtiemes

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

Am 28.11.2016 um 14:18 schrieb Volker Wysk:
> Hello!
>
> I've set up fetchmail to fetch my mail via IMAP IDLE. This had worked.
>
> But since a fews days, this works only sometimes. Sometimes, mail, which I can 
> see in the webmail interface of my webhoster, stays there, and doesn't get 
> collected. When I restart the fetchmail service, the mail does get fetched.
>
> I have set the "fetchall" parameter, that's not the reason.
>
> Anyone with similar problems? Should I abstain from IMAP IDLE?


So, in the light of your other messages:
- what did you change on your end?
    - what else has changed (OS updates, library updates,
reconfiguration of network... anything related to ICMP, MSS, ...)?
- what did change on the server's end? It appears to be running an
ancient version of Courier-IMAP...
- if you're willing to give IDLE another spin, does mail arrive if you
wait for another half hour in IDLE mode?
  But without a smoking gun, i. e. a debug log showing missed IMAP
messages, it's hard to judge anything, sorry.

Re: [Fetchmail-users] IMAP IDLE works only somtiemes

[Volker W. <po...@vo...>]

Am Dienstag, 29. November 2016, 10:39:54 CET schrieb Matthias Andree:
> <http://www.fetchmail.info/fetchmail-FAQ.html#G3>

The FAQ asks for the output of "LC_ALL=C fetchmail --nodetach -vvv --nosyslog 
...". But this won't trigger the problem right away, which occurs only when in 
IDLE mode. I haven't seen any output of the problem occuring, so far.

I could try to watch for debug output when in idle mode, when the problem 
occurs, but this is tricky, and a bit involved. 

I'm afraid that I can't be very helpful for debugging this, since I can't 
reproduce the problem. It just occurs sometimes. I thought this might be a 
known problem, so I asked if someone knows what's going on.

I'll just abstain from using IMAP IDLE for now.

Many Greetings
Volker