With the new cyrus-imapd 3.0.x, Outlook with syncroton duplicates mails after moving mails
Open, 60Public

Description

When moving a mail to another folder, it is duplicated using cyrus-imapd 3.0.1 (and 3.0.3, too). However, the server has only one copy of the message, it is only duplicated in the destination folder in Outlook 2013.

syncroton version:
kolab-syncroton-2.3.6-4.1.el7.kolab_16.noarch

I'm not sure about the EAS protocol, but there is a move message:
[23-Aug-2017 08:43:15 +0200]: [DEBUG] Syncroton_Server::_handlePost::127 xml request:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE AirSync PUBLIC "-AIRSYNCDTD AirSync//EN" "http://www.microsoft.com/">
<Moves xmlns="uri:Move">

<Move>
  <SrcMsgId>38b950ebd62cd9a66929c89615d0fc04::59677</SrcMsgId>
  <SrcFldId>38b950ebd62cd9a66929c89615d0fc04</SrcFldId>
  <DstFldId>c8262d968102ed0635c686a27d036b6a</DstFldId>
</Move>

</Moves>

then added/deleted events:
[23-Aug-2017 08:43:16 +0200]: [INFO] Syncroton_Command_Sync::getResponse::697 found (added/changed/deleted) 0/0/1 entries for sync from server to client
[23-Aug-2017 08:43:16 +0200]: [INFO] Syncroton_Command_Sync::getResponse::941 current synckey is 69
[23-Aug-2017 08:43:16 +0200]: [DEBUG] Syncroton_Command_Sync::getResponse::954 update syncState for collection: 38b950ebd62cd9a66929c89615d0fc04
[23-Aug-2017 08:43:16 +0200]: [DEBUG] kolab_sync_transaction_manager::startTransaction::102 startTransaction request
[23-Aug-2017 08:43:16 +0200]: [DEBUG] kolab_sync_transaction_manager::commitTransaction::132 commitTransaction request for 7d1c02c26cd905e00e10b59034dd8c33496fa908
[23-Aug-2017 08:43:16 +0200]: [INFO] Syncroton_Command_Sync::getResponse::941 current synckey is 4
[23-Aug-2017 08:43:16 +0200]: [INFO] Syncroton_Command_Sync::getResponse::941 current synckey is 4
[23-Aug-2017 08:43:16 +0200]: [INFO] Syncroton_Command_Sync::getResponse::697 found (added/changed/deleted) 1/0/0 entries for sync from server to client

Here's the full log:
https://pastebin.com/fsrM9s94

Details

Ticket Type
Task
gyurco created this task.Aug 23 2017, 9:57 AM

Another example
IMAP log:

`
[23-Aug-2017 11:45:32 +0200]: [EE2A] C: A0017 UID MOVE 59667 "T&APY-r&APY-lt elemek"
[23-Aug-2017 11:45:32 +0200]: [EE2A] S: * OK [COPYUID 1304109194 59667 4484] Completed
[23-Aug-2017 11:45:32 +0200]: [EE2A] S: * 217 EXPUNGE
[23-Aug-2017 11:45:32 +0200]: [EE2A] S: A0017 OK Completed

Syncroton response:

`
[23-Aug-2017 11:45:32 +0200]: [DEBUG] Syncroton_Server::_handlePost::177 xml response(0):
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE AirSync PUBLIC "-//AIRSYNC//DTD AirSync//EN" "http://www.microsoft.com/">
<Moves xmlns="uri:Move" xmlns:Syncroton="uri:Syncroton">
  <Response>
    <SrcMsgId>38b950ebd62cd9a66929c89615d0fc04::59667</SrcMsgId>
    <Status>3</Status>
    <DstMsgId/>
  </Response>
</Moves>

`

I don't know if the DstMsgId is mandatory or not, but seems it is missing.
Later on, Outlook re-download the message with the new ID 4484, which was in the IMAP log:

`
    <Collection xmlns:default="uri:Email" xmlns:default1="uri:AirSyncBase">
      <Class>Email</Class>
      <SyncKey>7</SyncKey>
      <CollectionId>c8262d968102ed0635c686a27d036b6a</CollectionId>
      <Status>1</Status>
      <Commands xmlns:default="uri:Email" xmlns:default1="uri:AirSyncBase">
        <Add xmlns:default="uri:Email" xmlns:default1="uri:AirSyncBase">
          <ServerId>c8262d968102ed0635c686a27d036b6a::4484</ServerId>
          <ApplicationData>
            <Email:DateReceived xmlns="uri:Email">2017-08-21T16:08:57.000Z</Email:DateReceived>
            <Email:From xmlns="uri:Email">"(Cron Daemon)" &lt;root@htm-hungary.com&gt;</Email:From>
 `

Well, reading through RFC6851 (MOVE command):

Servers implementing UIDPLUS are also advised to send the COPYUID
response code in an untagged OK before sending EXPUNGE or moved
responses.  (Sending COPYUID in the tagged OK, as described in the
UIDPLUS specification, means that clients first receive an EXPUNGE
for a message and afterwards COPYUID for the same message.  It can be
unnecessarily difficult to process that sequence usefully.)

So the untagged COPYUID seems to be OK. So Roundcube/rcube_imap_generic.php should parse the COPYUID response even in an untagged response (an ugly hack inserted to execute() method to do it solves the original issue).

pasik added a subscriber: pasik.Nov 25 2017, 2:30 PM