Quoting from Robert Gerlach's mail on Wed, Jan 15, 2003 at 12:56:03PM +0100:
I have tested this patch yesterday. Now, new mails getting only once,
but still only the header.
All works perfect for user1, only user2 has the problem (so, all users
with option "keep").
My fetchmailrc:
set postmaster "postmaster"
set bouncemail
set properties ""
set syslog
poll imap.gmx.de with proto IMAP
user 'lb(_dot_)user1(_at_)gmx(_dot_)de' there
with password ... is lb.user1 here fetchall
user 'lb(_dot_)user2(_at_)gmx(_dot_)de' there
with password ... is lb.user2 here keep
This looks fine...
fetchmail -v -v output:
fetchmail: 6.2.0 querying imap.gmx.de (protocol IMAP) at Mon Jan
13 17:42:05 2003: poll started
fetchmail: IMAP< * OK GMX IMAP4 StreamProxy ready.
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 AUTH=LOGIN
AUTH=CRAM-MD5
fetchmail: IMAP< A0001 OK CAPABILITY completed
fetchmail: Protocol identified as IMAP4 rev 1
...
fetchmail: selecting or re-polling default folder
fetchmail: IMAP> A0003 SELECT "INBOX"
fetchmail: IMAP< * 20 EXISTS
fetchmail: IMAP< * 1 RECENT
fetchmail: IMAP< * FLAGS (\New \Seen \Deleted \Answered
\Forwarded)
fetchmail: IMAP< * OK [PERMANENTFLAGS (\New \Seen \Deleted
\Answered \Forwarded)] Permanent flags
fetchmail: IMAP< * OK [UNSEEN 1] Is the first unseen message
fetchmail: IMAP< * OK [UIDVALIDITY 1042476353] UIDVALIDITY value
fetchmail: IMAP< A0003 OK [READ-WRITE] SELECT completed
fetchmail: 20 messages waiting after first poll
fetchmail: IMAP> A0004 SEARCH UNSEEN
fetchmail: IMAP< * SEARCH 20
fetchmail: 20 is unseen
fetchmail: IMAP< A0004 OK SEARCH completed
fetchmail: 20 is first unseen
20 messages (19 seen) for lb(_dot_)user2(_at_)gmx(_dot_)de at
imap.gmx.de.
fetchmail: IMAP> A0005 FETCH 20 RFC822.SIZE
fetchmail: IMAP< * 20 FETCH (RFC822.SIZE 737)
The server reports the size of the mail as 737 bytes here.
fetchmail: IMAP< A0005 OK FETCH completed
...
fetchmail: IMAP> A0006 FETCH 20 RFC822.HEADER
fetchmail: IMAP< * 20 FETCH (RFC822.HEADER {639}
The header size is 639 bytes.
reading message lb(_dot_)user2(_at_)gmx(_dot_)de@imap.gmx.de:20 of 20
(639 header
octets)
...
#fetchmail: IMAP< )
fetchmail: IMAP< A0006 OK FETCH completed
fetchmail: IMAP> A0007 FETCH 20 BODY.PEEK[TEXT]
fetchmail: IMAP< * 20 FETCH (BODY[TEXT] {0}
Here, the server reports the body size as 0 bytes! Obviously, there is
some mismatch.
(0 body octets) fetchmail: message
lb(_dot_)user2(_at_)gmx(_dot_)de@imap.gmx.de:20 was not the expected
length (639
actual != 737 expected)
...
not flushed
fetchmail: IMAP> A0008 STORE 20 +FLAGS (\Seen)
fetchmail: IMAP<
It doesn't seem like there is anything in the body.
fetchmail: IMAP< )
fetchmail: IMAP< A0007 OK FETCH completed
fetchmail: IMAP< * 20 FETCH (FLAGS (\Seen))
fetchmail: IMAP< A0008 OK STORE completed
fetchmail: IMAP> A0009 LOGOUT
fetchmail: IMAP< * BYE IMAP4 Server logging out
fetchmail: IMAP< A0009 OK LOGOUT complete
fetchmail: 6.2.0 querying imap.gmx.de (protocol IMAP) at Mon Jan
13 17:42:07 2003: poll completed
I do not see any problem as far as fetchmail is concerned. My opinion
is that your server is buggy.
Are you checking your mail through some other email client when
fetchmail is downloading mails? In that case, this kind of behaviour
can happen on unexpected mailbox changes. Note that this can happen if
your email client is modifying the mailbox in any way like sorting on
the server or modifying flags.
--
Sunil Shetye.