Hi,
the behavior for broken headers changed between 6.1.1 and 6.1.2 ("try to
bulletproof error handling against read failures").
I think it is buggy the way it is now:
if there are broken headers found (readheaders() == PS_TRUNCATED) while
getting mails by POP3 (or other protocols without fetch_body), fetchmail
won't get/parse the message body, because we set len=0 in driver.c:528.
The server isn't able to notice this and will continue to send the message
body - resulting in a protocol error for the next mail:
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 62984 octets
fetchmail: reading message XXX:1 of 3 (62984 octets)
fetchmail: message delimiter found while scanning headers
fetchmail: message XXX:1 was not the expected length (1122 actual != 62984
expected)
fetchmail: SMTP>. (EOM)
fetchmail: smtp listener protocol errorfetchmail: not flushed
fetchmail: POP3> RETR 2
fetchmail: POP3< Content-Type: text/plain; charset=iso-8859-1
fetchmail: POP3> QUIT
fetchmail: POP3< X-MDRemoteIP: 172.29.1.3
fetchmail: client/server protocol error while fetching from XXX
fetchmail: 6.1.2 querying XXX (protocol POP3) at Wed, 20 Nov 2002 15:38:11
+0100 (CET): poll completed
fetchmail: Query status=4 (PROTOCOL)
The net effect is that one broken mail can block the whole account until an
admin deletes this mail.
In 6.1.1 we get the complete mail and try to send it somehow. I would propose
the best way to handle this is to retrieve the body but leave the mail on the
server and not forward it - as currently done with e.g. IMAP.
The attached patch tries to implement this. Since I'm not very much into the
fetchmail code and it's sometimes difficult error state handling I would
appreciate comments from experienced fetchmail hackers - especially ESR and
Sunil.
Looking forward for comments,
kind regards,
Gerd
fetchmail-6.1.2-brokenheader.patch
Description: Text Data