From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031014 Description of problem: Since the upgrade to -8, fetchmail started rejecting some e-mails that it used to get perfectly well from a remote imap server. It prints messages like this: reading message aoliva.ic.unicamp.br:1 of 7 (2077 header octets) ..fetchmail: message delimiter found while scanning headers not flushed and the message remains in the remote mailbox, while I get a message from FETCHMAIL-DAEMON in my local mailbox. This is a bad regressions. The fetchmail configuration file says: set daemon 900 set postmaster aoliva set no bouncemail defaults protocol imap auth ssh # mda "/usr/bin/procmail -d aoliva" to aoliva expunge 0 poll oliva@lsd via emilia.lsd.ic.unicamp.br. plugin "ssh -x -a -l oliva emilia bin/imapd" imapd on the remote end is imap-2001a-18 (from Shrike). I'll attach the contents of the remote mailbox after that fetchmail session was completed, with the not-flushed message by itself. Version-Release number of selected component (if applicable): fetchmail-6.2.0-8 How reproducible: Always Steps to Reproduce: 1.store the attached e-mail in your /var/spool/mail/box 2.set up fetchmail to do imap over ssh from there 3.run it Actual Results: the message isn't fetched. Expected Results: it should. the previous release did. fetchmail-6.2.0-3, that I still have handy, does as well. Additional info:
Created attachment 95376 [details] the mailbox that triggers the bug
I have the same problem. This is related to the patch fetchmail-6.2.0-reply_hack.patch. In my case the message is silently flushed from the server despite the error. The problem is that linelen is modified by reply_hack(), but its value is used elsewhere to decrement a char counter in the mainloop. Does this patch work for you ? --- transact.c 2003-11-13 18:09:39.000000000 +0100 +++ transact.c.new 2003-11-13 18:05:11.000000000 +0100 @@ -415,7 +415,7 @@ skipcount = 0; ctl->mimemsg = 0; - for (remaining = fetchlen; remaining > 0 || protocol->delimited; remaining -= linelen) + for (remaining = fetchlen; remaining > 0 || protocol->delimited; ) { char *line; int overlong = FALSE; @@ -433,6 +433,7 @@ return(PS_SOCKET); } set_timeout(0); + remaining -= n; linelen += n; msgblk.msglen += n;
Thanks, I can confirm that the patch fixes the problem, apparently without introducing any ill effects.
Maybe an updated package could be released for Fedora Core 1 (as this bug also applies to FC1) ?
Any reason why this patch didn't make it even to FC2test1?
Patch still applies cleanly atop of 6.2.0-10, and avoids the unfetchable-message problem we've had since 6.2.0-8. Could you please oh please merge the patch in? I've rolled my own RPMS to fix the issue, and I could provide diffs to spec files if you'd like.
Created attachment 99088 [details] Proposed patch
Created attachment 99089 [details] Proposed spec patch Now you don't have any excuse not to close this bug. ;)
In the meantime, for those interested, you can find the RPM at http://nomis80.org/rpms/fetchmail-6.2.0-8.1.i386.rpm.