[horde] Doubling emails-problem in Outlook 2013
Michael J Rubinsky
mrubinsk at horde.org
Tue May 20 17:02:02 UTC 2014
Quoting Patrick De Zordo <patrick at spamreducer.eu>:
> Am 20.05.2014 16:00, schrieb Michael J Rubinsky:
>> WTF? This worked for me perfectly for about an hour yesterday, and
>> now it only works sporadically. The log shows the same WBXML being
>> sent (we add the new email to the destination folder and delete the
>> email from the source folder). If this isn't happening in a
>> deterministic way, there is REALLY nothing we can do. A search on
>> Google reveals that this IS a known issue in OL, so I'm going to
>> have to say "not our problem" at this point.
> Me too, so I was sure this is perfekt! But..god.. this are the
> badest news for this week.
Ok. I have one more idea, but it is going to require a bit of surgery.
Right now, we send the message ids as the raw IMAP UID for the
message. This means the id's, by themselves are not unique across
mailboxes. The specs state that the field for the message ids can be a
string up to 64 characters in length.
Further, when I originally tested this fix, I was using a test IMAP
server - with only a few mailboxes and messages. When I go back to
test this on THAT server, it works again. It's only on my production
server that this fails. My guess is that this is what is happening:
1. Message with a UID of 221 is moved by user from FolderOne to FolderTwo.
2. OL (incorrectly) automatically moves the message (maybe to provide
quicker UI feedback?) to FolderTwo when sending the MOVEITEMS command.
3. When OL receives the DELETE command from the server to remove UID
221 from FolderOne - it can't find it since it's already moved to
FolderTwo and there are probably more than one message with a UID of
221 so it doesn't know what to do. I'm thinking that in this case, OL
expects the UID to be a *unique* identifier across all mailboxes. So,
regardless of what mailbox the email is currently in, OL will know
where it is.
To do this, though, we would have to perform some magic - like maybe
prepending the folder's UID to the message UID before sending it and
stripping it on the way back. Though off hand, I think this would
cause problems in some commands when we don't already know the folder
id. The other option is to store this UID -> OL UID mapping in the
device state. However, this will increase the storage requirements.
I'll have to think on this some more and play around when I get time.
The Horde Project
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5869 bytes
Desc: S/MIME Signature
More information about the horde