Hello Eric,
On Tue, Jun 04, 2002 at 09:10:19AM -0400, Eric S Raymond wrote:
Mikhail Zabaluev <mhz(_at_)altlinux(_dot_)org>:
But then, in fetch_messages():
/*
* Read the message headers and ship them to the
* output sink.
*/
err = readheaders(mailserver_socket, len, msgsizes[num-1],
ctl, num);
if (err == PS_RETAINED)
suppress_forward = retained = TRUE;
else if (err == PS_TRANSIENT)
suppress_delete = suppress_forward = TRUE;
else if (err == PS_REFUSED)
suppress_forward = TRUE;
#if 0
/*
* readheaders does not read the body when it
* hits a non-header. It has been recently
* fixed to return PS_TRUNCATED (properly) when
* that happens, but apparently fixing that bug
* opened this one here (which looks like an
* inproper fix from some ancient thinko)
*/
else if (err == PS_TRUNCATED)
suppress_readbody = TRUE;
else if (err)
return(err);
#else
else if (err && err != PS_TRUNCATED)
return(err);
#endif
You're not reading very carefully. Look at the preprocessor directives.
I see that the #else branch, that goes in the actual code, doesn't set
suppress_readbody on PS_TRUNCATED, and the execution flow falls
through.
This is probably OK, but at some later point, fetchmail 5.9.11 just
stops retrieving subsequent messages. For some reason, I can't receive
empty messages without the delimiter line anymore; the admins at my
POP3 server have probably fixed it, as I lamented to them too.
I believe, this is still reproducible with the POP3 servers that
can issue such truncated responses (and, let me repeat, this is
valid by any standard).
--
Stay tuned,
MhZ JID: mookid(_at_)jabber(_dot_)org
___________
An expert is one who knows more and more about less and less until he knows
absolutely everything about nothing.