On Tue, May 18, 2004 at 09:10:23PM +0000, Mooky Mooksgill wrote:
....fetchmail: message
abel%moose(_dot_)net(_at_)imail9(_dot_)bigisp(_dot_)net:8 was not the
expected length (5464 actual != 5462 expected)
not flushed
fetchmail: POP3> LIST 9
fetchmail: socket error while fetching from imail9.bigisp.net
fetchmail: 6.2.5 querying imail9.bigisp.net (protocol POP3) at Tue May
18
15:38:07 2004: poll completed
Looks like your POP3 server has sent a corrupted message for message 8,
probably not terminated with \r\n.\r\n
Again, nothing fetchmail can do if your POP3 server violates the protocol
in
a gross manner.
why is there nothing fetchmail can do? could the code be written to deal
with improperly terminated emails?
Nope. There's no sensible, conceivable way to resynchronise after this sort
of error.
The POP3 protocol says that the response to a RETR command is +OK, followed
by a splurge of text, ending with "\r\n.\r\n"
If the POP3 server sends something different as the terminator, then
fetchmail believes that there's more mail to come and just keeps waiting. If
POP3 sends some garbage after the terminating sequence, then fetchmail must
interpret that as the response to the next command. If the POP3 server
disconnects by itself, then fetchmail can't reconnect.
I can't say exactly what's going on here without seeing a full tcpdump of
the session. But from the above, it looks like the POP3 server is doing
something which you couldn't possibly recover from.
Brian.