Am 21.01.25 um 19:34 schrieb Francesco Potortì:
Package: fetchmail
Version: 6.4.39-1
Severity: normal
I have observed occasionally this bug starting one year ago (approximately)
while downloading email from two different servers. In all cases fetchmail
stops downloading midway through a long message with a socket error and leaves
the message on the server. There is no way out: next time it polls, the same
thing happens and no new mail is downloaded. Only cure I found, login through
webmail and delete the offending message, which is tyipically a big spam
message. Here is the lastest instance seen on the log:
fetchmail: reading message u...@email.addr@provider.smtp.server:3 of 40
(3310505 octets) (log message incomplete)
fetchmail: socket error while fetching from u...@email.addr@provider.smtp.server
fetchmail: Query status=2 (SOCKET)
Fetchmail stops on error and retries indefinitely, but gives no sign of this
situation, so I am not alerted of it unless I notice that no mail is arriving.
Fetchmail should detect this situation and at least send an email signaling the
problem. At best, it could additionally mark the offending message and skip it.
Hi Francesco,
thanks for taking the time to report this bug. It would seem this is an
upstream issue at first glance. Sorry it hurts.
Can you attach strace (you just add strace to fetchmail's command line)
and report the last few lines around where things start looking like
fetchmail running into timeouts (SIGALRM is one such sign) or socket
trouble (read errors), and/or also the last few lines of a tcpdump
running in parallel and filtering on traffic to 79.98.45.16/110?
Also, does it take a long time between starting to read the message 3
(see below) and before fetchmail fails?
Here is the same log as above with -v. Info is obfuscated, but I will gladly
send the onubfuscated log privately upon request.
+ provider.smtp.server at 2025-01-21 17:54:04+0100
[...]
fetchmail: POP3> LIST 3
fetchmail: POP3< +OK 3 373082
fetchmail: POP3> RETR 3
fetchmail: POP3< +OK 373082 octets
fetchmail: reading message u...@email.addr@provider.smtp.server:3 of 112
(373082 octets) (log message incomplete)
fetchmail: socket error while fetching from u...@email.addr@provider.smtp.server
fetchmail: 6.4.39 querying provider.smtp.server (protocol APOP) at Tue Jan 21
17:54:04 2025: poll completed
fetchmail: Query status=2 (SOCKET)
I need to understand, from strace (or ltrace) and tcpdump, what are the
last few log lines around the connection getting reset and what the
software is doing.
If you feel that's too sensitive, feel free to e-mail me directly and
GnuPG encrypt. My key is available through key servers or from
https://docs.freebsd.org/en/articles/pgpkeys/#_matthias_andree_mandreefreebsd_org
Thanks again.
Regards,
Matthias
