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.
Provided this particular server behaves predictably (although
wrongly), it might be possible to recognize the server -- or add
a .fetchmailrc option to identify it -- and react accordingly.
It would not be the first time fetchmail got patched to deal with
a broken server :(
Getting a tcpdump of the failing session would be a first step
towards developing such a patch.
However, if the server also supports IMAP, it would likely be worth
your while to try that first.