#65 IMAP error: received extraneous data in FETCH response

[Pavel Murat]

Dear isync developers,

I'm using isync 1.4.4-x (whatever comes with the Fedora rpms 1.4.4-x, where x=1,2) to sync a local
email storage with a remote Exchange365 server. Since some time ago, after some changes on the server side, any copy from a local folder to a remote one ends up with the error diagnostics below. It doesn't seem to be a sync error per se, but rather a hand-shaking error on closing after a successful sync - resyncing the folder completes w/o any problem. Below is the end of the mbsync log in debugging (-D) mode. This happens for every local-->remote copy, and I wonder if this is a known problem.

-- thanks for the great product, Pavel Murat

... snip
F: 638 OK APPEND completed
F: [ 1296] Callback enter store_msg, sts=0, uid=0
-> log: * 0 622 24 (pushed with flags)
expunging near side
N: [ 1297] Enter close_box
N: [ 1297] Callback enter close_box, sts=0
N: [ 1297] Callback leave close_box
N: [ 1297] Leave close_box
finding just copied messages on far side
F: [ 1298] Enter find_new_msgs, newuid=1159
F: >>> 639 CHECK
F: [ 1298] Leave find_new_msgs
F: [ 1296] Callback leave store_msg
F: * 582 EXISTS
F: * 0 RECENT
F: 639 OK CHECK completed
F: >>> 640 UID FETCH * (UID)
F: * 582 FETCH (UID 1169)
F: 640 OK UID FETCH completed
F: >>> 641 UID FETCH 1159:1169 (UID BODY.PEEK[HEADER.FIELDS (X-TUID)])
F: * 577 FETCH (UID 1162 BODY[HEADER.FIELDS (X-TUID)] {22}
F: )
IMAP error: received extraneous data in FETCH response
F: Callback enter bad store
F: Enter cancel_store
F: [ 1298] Callback enter find_new_msgs, sts=4
F: [ 1298] Callback leave find_new_msgs
F: Leave cancel_store
N: [ 1299] Enter cancel_cmds
N: [ 1299] Callback enter cancel_cmds
N: [ 1300] Enter cancel_cmds
N: [ 1300] Callback enter cancel_cmds
N: Enter free_store
N: Leave free_store
N: [ 1300] Callback leave cancel_cmds
N: [ 1300] Leave cancel_cmds
N: [ 1299] Callback leave cancel_cmds
N: [ 1299] Leave cancel_cmds
F: Callback leave bad store

[Oswald Buddenhagen]

yes, this is already fixed in master by commit 4c2fb742. unfortunately, the release is delayed due to an unrelated issue.