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 firstname.lastname@example.org:1 of 7 (2077 header octets)
..fetchmail: message delimiter found while scanning headers
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
# mda "/usr/bin/procmail -d aoliva"
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):
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
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.
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; )
int overlong = FALSE;
@@ -433,6 +433,7 @@
+ 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]
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