Rodolfo Borges <barrett(_at_)9hells(_dot_)org> writes:
No, it does not help. :(
I just left the .fetchmailrc as it was, and waited for another offending
message. I keep watching a tail -f on the log file to detect the problem..
Today I saw it was stalled, so I
$ kill `pidof fetchmail`
$ echo forcecr >> ~/.fetchmailrc
and restarted it, just to see it still stalls.
Maybe I should try to patch fetchmail myself?
Well, my problem is that I don't currently see how the error manifests
itself. That line:
Or just write a script that watches the logfile, detect the situation,
and telnet mail.example.com 110 to delete the message.
makes me think you're using POP3, and the server MUST have sent a
properly terminated message, else the POP3 protocol would hang, not
SMTP. It MIGHT be related to embedded NUL files; if there is any way you
could download the message and send it to me off-list, as an attachment,
that might help.
To obtain such a dump, if you're somewhat familiar with the POP3
protocol, just type "script", then telnet, then type the login commands
(USER/PASS in many cases), the RETR command for the failing message,
then QUIT. Exit the shell that "script" has opened, edit the typescript
file and remove your password, gzip it (so it bypasses my spam filter)
and send it to me off-list, preferably to
matthias.andree>AT<gmx.de.
Using fetchmail -vv might not dump the NUL bytes; I hope telnet does.
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)