Any IMAP gurus out there?

[BackSeat]

I'm trying to investigate why copying mails from one IMAP folder to
another fails silently about 50% of the time with the sylpheed-claws
MUA (v.0.8.5). By "fails silently" I mean that there are no indications
that the copy has not taken place save for the fact that the mail
concerned does not appear in the destination folder.

Here is my analysis of the IMAPDEBUGFILE output from one such
unsuccessful copy attempt. Have I misinterpreted something
somewhere? Sylpheed-claws issues five commands to implement the
copy; is it contravening the RFC somewhere (I don't think so, but
_something_ isn't right here)?

First command:

READ: NUMBER: 981
READ: ATOM: UID
READ: ATOM: STORE
READ: ATOM: 3501:3501
READ: ATOM: -FLAGS
READ: LPAREN
READ: ATOM: \FLAGGED
READ: RPAREN
READ: EOL
WRITE: 981 OK STORE completed.

This seems to be setting the "\FLAGGED" flag on the message to be moved.

Second command:

READ: NUMBER: 982
READ: ATOM: STATUS
READ: ATOM: INBOX.Scratch
READ: LPAREN
READ: ATOM: MESSAGES
READ: ATOM: RECENT
READ: ATOM: UIDNEXT
READ: ATOM: UIDVALIDITY
READ: ATOM: UNSEEN
READ: RPAREN
READ: EOL
WRITE: * STATUS "INBOX.Scratch" (MESSAGES 3 RECENT 0 UIDNEXT 4
UIDVALIDITY 1035476717 UNSEEN 0) 982 OK STATUS Completed.

This seems to be a STATUS command performed on the intended destination
folder, and indicates that there are currently 3 messages in that
folder.

Third command:

READ: NUMBER: 983
READ: ATOM: UID
READ: ATOM: COPY
READ: NUMBER: 3501
READ: ATOM: INBOX.Scratch
READ: EOL
WRITE: 983 OK COPY completed.

This seems to be the actual UID COPY, and seems to be successful.

Fourth command:

READ: NUMBER: 984
READ: ATOM: SELECT
READ: ATOM: INBOX.Scratch
READ: EOL
WRITE: * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited
* 3 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1035476717] Ok
984 OK [READ-WRITE] Ok

The destination folder from the UID COPY is selected; note that it still
appears to have 3 messages in it (I would have thought it should have
4 now).

Fifth and final command:

READ: NUMBER: 985
READ: ATOM: UID
READ: ATOM: FETCH
READ: ATOM: 4:4
READ: LPAREN
READ: ATOM: UID
READ: ATOM: FLAGS
READ: ATOM: RFC822.SIZE
READ: ATOM: RFC822.HEADER
READ: RPAREN
READ: EOL
WRITE: 985 OK FETCH completed.

This seems to be a FETCH of what would be the new message (number 4),
but which, as we know from the SELECT command, does not exist. It still
appears to be successful, returning an "OK".

I would be grateful for any pointers to how to progress this issue;
thanks.

BS

[mglauche]

which imap server are you using ? maybe its an bug in the server, as it seems it didn't execute the copy at all ...