Justin Guyett <jfg(_at_)sonicity(_dot_)com>:
not really. returning a fatal error so that the message retrieval loop
exits is almost just as bad. one fucked up message (for Microsoft's
definition of fucked) shouldn't make all subsequent messages
unretrievable. IMHO fetchmail should take a best effort approach toward
mail retrieval, not quit at the first sign of trouble, even if the problem
is a Redmond, Inc. mailserver.
Another problem with .15 is that mail server replies aren't read to
completion (this was happening before, but wasn't breaking things as it
seems to be doing now)... so there can be trailing lines from server
responses to old commands that must be read and dealt with before seeing
responses from the command that fetchmail just sent.
also NO and BAD responses don't start with "* ", so the buf+2 guess has
to be improved.
OK, I screwed the pooch. I plead in my defence only that *my* mailserver
doesn't generate the botch response that would actually have tested this
code ;-).
fetchmail: about to deliver with: /usr/bin/procmail -d alt
#
fetchmail: IMAP< )
fetchmail: IMAP< A0995 OK FETCH completed.
fetchmail: IMAP> A0996 FETCH 496 BODY[TEXT]
fetchmail: IMAP< * 496 FETCH (BODY[TEXT] {0}
(0 body octets) not flushed
fetchmail: IMAP> A0997 FETCH 497 RFC822.HEADER
beginning to look for response...
fetchmail: IMAP< )
buffer: )
fetchmail: IMAP< A0996 OK FETCH completed.
buffer: A0996 OK FETCH completed.
+++returning PS_ERROR, NO found
Am I blind or am I not seeing the actual "NO"?
fetchmail: IMAP> A0998 LOGOUT
fetchmail: IMAP< * 497 FETCH (RFC822.HEADER {745}
<rest of 497>
fetchmail: IMAP< A0997 OK FETCH completed.
fetchmail: IMAP< * BYE Microsoft Exchange 2000 IMAP4rev1 server version
6.0.4417.0 signing off.
fetchmail: IMAP< A0998 OK LOGOUT completed.
should be obvious, the buffer is printed just after being read, before
the checks for FETCH, NO, and BAD.
so basically, besides this patch, you probably need to add a transient
error that means continue, not break, the message loop.
Here you go:
--- driver.c 2001/06/25 21:08:04 1.667
+++ driver.c 2001/08/01 07:26:52
@@ -428,7 +428,14 @@
/* request a message */
err =
(ctl->server.base_protocol->fetch_headers)(mailserver_socket,ctl,num, &len);
- if (err != 0)
+ if (err == PS_TRANSIENT) /* server said they're not there */
+ {
+ report_build(stdout,
+ _("couldn't fetch headers on message %d (%d
octets)"),
+ num, msgsizes[num-1]);
+ continue;
+ }
+ else if (err != 0)
return(err);
/* -1 means we didn't see a size in the response */
Now *you* figure out how to detect BAD and NO reliably. If you make
imap_fetch_headers() return PS_TRANSIENT, the right thing should happen.
Send me back a patch including the above and I'll take it.
also the end-of-message checking may be broken... it over-reads a
message (with the following patch):
That fscking broken pile of shite that Microsoft calls a mailserver is
notorious for returning bogus message sizes. The driver loop plays
various games to try to cope, but given the way IMAP is delimited it's
hard to compensate. It wouldn't surprise me a bit if Exchange had
found another clever way to give fetchmail indigestion.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
-- Daniel Webster