Am 19.11.2011 00:43, schrieb Mikulas Patocka:
> Hi
>
> Zimbra occasionally returns this response:
>
> fetchmail: IMAP> A0007 FETCH 1 RFC822.HEADER
> fetchmail: IMAP< * 1 FETCH ()
> fetchmail: IMAP< A0007 OK FETCH completed
>
> It happens when there is a corrupted message without a header in the
> database. (I don't know how this message could be created, I just see it
> there).
>
> When fetchmail encounters such resonse, it gives up and disconnects.
>
> The attached patch changes it so that PS_TRANSIENT is returned in this
> case and fetchmail continues to fetch following messages correctly.
>
> Mikulas
>
> --- imap.c_ 2011-11-18 17:28:35.638698000 -0500
> +++ imap.c 2011-11-18 18:04:41.745220000 -0500
> @@ -1166,7 +1166,8 @@
>
> /* try to recover for some responses */
> if (!strncmp(buf, "* NO", 4) ||
> - !strncmp(buf, "* BAD", 5))
> + !strncmp(buf, "* BAD", 5) ||
> + strstr(buf, "FETCH ()"))
> {
> return(PS_TRANSIENT);
> }
Dear Mikulas,
thanks a lot for the contribution. I have applied the patch, currently
on the legacy_63 branch (gitorious.org), for inclusion in the next 6.3.X
release (6.3.22). I don't currently foresee a release date, as there
aren't many, or critical, fixes since 6.3.21 yet. A release might be a
couple of weeks out.
For 7.X and later versions, I have considered rewriting the IMAP reply
parser, but chances are that the behaviour is in violation of RFC3501
and will still need special casing/work arounds.
I'll have to check more places of the RFC than my time currently allows;
Dovecot for one returns
. FETCH 248 RFC822.HEADER
* 248 FETCH (RFC822.HEADER {0}
)
in response to a blank message which seems more useful.
Best regards
Matthias
|
