aboutsummaryrefslogtreecommitdiffstats
path: root/imap.c
diff options
context:
space:
mode:
authorMikulas Patocka <mpatocka@redhat.com>2011-11-18 18:43:11 -0500
committerMatthias Andree <matthias.andree@gmx.de>2011-11-22 01:44:52 +0100
commitc0afd60c07987a3519aea96b599e8558ea2361d6 (patch)
treefcfbd3cee92ac4a2e65c31f56c2142a4cfc0b6b3 /imap.c
parent9f9c3cbd8d825f80e99ddfdefa530be3955bcd56 (diff)
downloadfetchmail-c0afd60c07987a3519aea96b599e8558ea2361d6.tar.gz
fetchmail-c0afd60c07987a3519aea96b599e8558ea2361d6.tar.bz2
fetchmail-c0afd60c07987a3519aea96b599e8558ea2361d6.zip
fetchmail workaround for a bug in Zimbra
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. This patch changes it so that PS_TRANSIENT is returned in this case and fetchmail continues to fetch following messages correctly.
Diffstat (limited to 'imap.c')
-rw-r--r--imap.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/imap.c b/imap.c
index 5c3218d0..93f05f2c 100644
--- a/imap.c
+++ b/imap.c
@@ -1166,7 +1166,8 @@ static int imap_fetch_headers(int sock, struct query *ctl,int number,int *lenp)
/* 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);
}