400043 - Wrong IMAP draft msg deleted when another draft msg sent (UW IMAP with UIDPLUS extension doesn't return [APPENUID x y])

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[Mabry Tyson]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: 2.0.0.6 (20070728)

Sending a message (auto)saved in the Drafts folder will delete the prior message in the IMAP-based Drafts folder rather than the draft of the sent message.  The newly-sent draft message remains in the drafts folder.

This is different than Bug 396317 as this is on the same computer, and involves two different messages, not one.

This problem happens on an IMAP-based draft folder but not when using the Local Folders for Drafts.

We confirmed that it continues to happen even if the draft folder's index is rebuilt.

We've reproduced it on an Intel Mac (10.4.10) Tbird 2.0.0.6 (20070728) and Windows XP Tbird 2.0.0.6 (20070728).  I've confirmed it with two different IMAP servers.


Reproducible: Always

Steps to Reproduce:
1. Set autosave to 1 minute (for convenience)
2. Set the account's draft folder to be on the IMAP server
3. View the draft folder
4. Compose a new message "A".  Click on SAVE to save it in the drafts folder.  You should see it appear.  Leave the compose window open.
5. Compose a second new message "B".  Wait for autosave to happen.  You should see the message appear in the drafts folder.
6. Send message "B".  (Message "A" is still open.)
7. You should see that message "A" disappeared from the drafts folder.  Message "B" remains in the drafts folder.  (If you use Local Folders for the Drafts folder, message "B" disappears while message "A" remains.)

Actual Results:  
Message "A" is removed from the Drafts folder
Message "B" remains in the Drafts folder.

Expected Results:  
Message "B" is removed from the Drafts folder
Message "A" remains in the Drafts folder.

It doesn't technically matter that the message was autosaved rather than manually saved.  However, the autosave mechanism triggers this when the user isn't thinking about Drafts at all.  All of a sudden, the user finds that messages have disappeared out of the Drafts folder without ever touching it.

I'm marking this Critical because it causes messages to be deleted. 

Workaround:  Use Local Folders for Drafts.

Comment 1

[Magnus Melin [:mkmelin]]

WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101603 Thunderbird/3.0a1pre ID:2007101603

Comment 2

[Mabry Tyson]

Bug still exists in today's nightly build: version 3.0a1pre (2008021103)

When I went through the steps above, at step 7, message A (the one not sent) was removed from the drafts folder when it should not have been.

Since it seems unlikely that this bug was fixed and then broken again, I reviewed the bug report to see how the first commenter might have misread the report.  To avoid possible confusion, step 7 should be amended to read:

7. Improperly, message "A" has now disappeared from the drafts folder.  Message
"B" remains in the drafts folder.  (If you use Local Folders for the Drafts
folder, message "B" disappears while message "A" remains.)


[I hadn't tested it before in 3.0 as I didn't know where to find a 3.0 version of Thunderbird.]

Comment 3

[Mabry Tyson]

This bug still exists in version 3.0a2pre (2008051803)

Comment 4

[Magnus Melin [:mkmelin]]

Still WFM for me. You might want to get an imap protocol log. Perhaps it's a server bug...
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 5

[Mabry Tyson]

The user who first pointed this out was using a
Windows version of Thunderbird while mine is a Mac version.

Our server is a UW imaps server which identifies itself as
* OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS LOGINDISABLED] imaps.sample.COM IMAP4rev1 2006c.374 at Mon, 19 May 2008 23:50:50 -0700 (PDT)


I've made an attachment of a sanitized log of the imap
interactions.  Here's what seems relevant in the log.
(C: client;  S: server)
[This log is from version 2.0.0.14 (20080421) as the latest version kept
crashing when I tried to make this log.]

[Upload msg A]
ProcessCurrentURL:imap://[e-mail]:143/appenddraftfromfile%3E/Drafts%3EUID%3E:  = currentUrl
C: 18 append "Drafts" (\Seen \Draft) {628+}
C: ...
C: Message-ID: <[e-mail]>
C: ...
C: Subject: Test A
C: ...
S: * 189 EXISTS
S: * 1 RECENT
S: 18 OK APPEND completed

[Download msg A]
C: 21 UID fetch 523:* (FLAGS) 
S: * 189 FETCH (UID 523 FLAGS (\Recent \Seen \Draft))
S: 21 OK UID FETCH completed 
C: 22 UID fetch 523 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type X-Action-Owner)])
S: * 189 FETCH (UID 523 RFC822.SIZE 628 FLAGS (\Recent \Seen \Draft) BODY[HEADER.FIELDS (FROM TO CC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE X-ACTION-OWNER)] {220}
S: ...
S: Message-ID: <[e-mail]>
S: ...
S: Subject: Test A
S: 22 OK UID FETCH completed

C: 25 UID fetch 524:* (FLAGS) 
S:  * 189 FETCH (UID 523 FLAGS (\Recent \Seen \Draft))
S: 25 OK UID FETCH completed
[So Message ID is 189 and UID is 523 for message A.  I don't understand why Thunderbird asked for 524:*, but according to RFC 3501, the return of UID 523 is proper]

[Upload msg B]
ProcessCurrentURL:imap://[e-mail]:143/appenddraftfromfile%3E/Drafts%3EUID%3E:  = currentUrl
C: 27 append "Drafts" (\Seen \Draft) {628+}
C: ...
C: Message-ID: <[e-mail]>
C: ...
S: * 190 EXISTS
S: * 2 RECENT
S: 27 OK APPEND completed

[Download msg B.  Since Thunderbird asks for UID 524 by number here, it knows the right number for that message.]
C: 30 UID fetch 524:* (FLAGS)
S: * 190 FETCH (UID 524 FLAGS (\Recent \Seen \Draft))
S: 30 OK UID FETCH completed
C: 31 UID fetch 524 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type X-Action-Owner)])
S: * 190 FETCH (UID 524 RFC822.SIZE 628 FLAGS (\Recent \Seen \Draft) BODY[HEADER.FIELDS (FROM TO CC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE X-ACTION-OWNER)] {220}
S: ...
S: Message-ID: <[e-mail]> 
S: ...
S: Subject: Test B
S: ...
S: 31 OK UID FETCH completed 
[So Message ID is 190 and UID is 524 for message B]

[Then I send message B. After that, these lines are in the log, in which Thunderbird tells the server to delete msg A:]
SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
ProcessCurrentURL: entering
ProcessCurrentURL:imap://[e-mail]:143/appendmsgfromfile%3E/Sent:  = currentUrl
ProcessCurrentURL: entering
ProcessCurrentURL:imap://[e-mail]:143/addmsgflags%3EUID%3E/Drafts%3E523%3E9:  = currentUrl
C: 33 uid store 523 +Flags (\Seen \Deleted)
S: * 189 FETCH (FLAGS (\Recent \Seen \Deleted \Draft) UID 523)                                                                                  
S: 33 OK UID STORE completed

Comment 6

[Mabry Tyson]

Attachment: Log of imap protocol when the wrong message is deleted from the Drafts folder

Comment 7

[WADA:World Anti-bad-Duping Agency]

>(1) Appended draft mail of A
> UID 523
>  S: Message-ID: <[e-mail]>
>  S: Subject: Test A

>(2) Appended draft mail of B
> UID 524
> S: Message-ID: <[e-mail]> 
> S: Subject: Test B

>(3) Send mail B, append to Sent, then "store +Flags \Deleted" for UID 523
> C: 33 uid store 523 +Flags (\Seen \Deleted)

As seen in IMAP log attached to Bug 402132(Gmail IMAP case), I think "store +Flags \Deleted" for draft mail was issued based on returned UID for "uid search HEADER Message-ID". (See Bug 402132 Comment #13)
> In your case, mail B, then following.
> uid SEARCH UNDELETED HEADER Message-ID [e-mail]

(Q1) No log of "uid search UNDELETED HEADER Message-ID" between above step (2) and step (3) in real log data?
(Q2) If exists, specified message id by Thunderbird is correct? (message id of draft mail B?)
(Q3) If exists and message id is correct, correct UID is returned for search from your IMAP server?

Comment 8

[Gervase Markham [:gerv]]

WADA: are those questions for the reporter or for an engineer? 

This bug is clearly being worked on, and so shouldn't be UNCONFIRMED.

Gerv

Comment 9

[Magnus Melin [:mkmelin]]

Well, I don't think we know what the issue is (thus unco). Looks a bit like a server bug to me...

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)
> WADA: are those questions for the reporter or for an engineer? 
To reporter. All of my questions in comment #7 is about not-opened-yet log data.

Comment 11

[Mabry Tyson]

(In reply to comment #7)
 
> As seen in IMAP log attached to Bug 402132(Gmail IMAP case), I think "store
> +Flags \Deleted" for draft mail was issued based on returned UID for "uid
> search HEADER Message-ID". (See Bug 402132 Comment #13)
> > In your case, mail B, then following.
> > uid SEARCH UNDELETED HEADER Message-ID [e-mail]
> 
> (Q1) No log of "uid search UNDELETED HEADER Message-ID" between above step (2)
> and step (3) in real log data?

There is no such command in my example (see the log).  I would guess that gmail issue is irrelevant.

> (Q2) If exists, specified message id by Thunderbird is correct? (message id of
> draft mail B?)
> (Q3) If exists and message id is correct, correct UID is returned for search
> from your IMAP server?
> 

I've compared the problematic log with a log of another IMAP server where the same problem does not occur.

In both cases, a SELECT results in a UIDNEXT.  Call that $UIDA.  I'll refer to $UIDA+1 as $UIDB.
Then a fetch of the flags of 1:* occurs.  
Then message A is appended to the drafts. 
Then the system does a fetch of the flags of $UIDA:*.  In both cases, the returned UID is the same as $UIDA.
Then the system fetches $UIDA (and the server again indicates it is $UIDA).

>>> Then, only in the problematic system, the client fetches the flags of $UIDA+1:*.   The server properly returns the last element which is $UIDA.
(This is command 24 in the log.)

Then the client appends message B to the drafts. 

Then the client asks for the flags of $UIDA+1:* (ie, $UIDB:*).  The server returns the flags for $UIDB.

Then the system fetches $UIDB.

At this point, message B is sent by me.

The problematic system sets the flags of $UIDA to (\Seen \Deleted).
The ok system sets the flags of $UIDB to (\Seen \Deleted)

====
The question is what is the difference between the problematic system and one that works.

Problematic system capabilities:
IMAP4rev1 2006c.374
IMAP4REV1 LITERAL+ IDLE UIDPLUS NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND


Working system:
IMAP4 service (Sun Java(tm) System Messaging Server 6.2-6.01 (built Apr  3 2006))
 IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY UNSELECT LANGUAGE XSENDER X-NETSCAPE XSERVERINFO

Comment 12

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #11)
> Problematic system capabilities:
> (snip) UIDPLUS (snip) MULTIAPPEND

RFC 3502 is for MULTIAPPEND Extension.
> http://www.ietf.org/rfc/rfc3502.txt
> MULTIAPPEND Interaction with UIDPLUS Extension
>   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
>   "resp-code-apnd" rule modified as follows:
>   resp-code-apnd  = "APPENDUID" SP nz-number SP set

If "FETCH for \Seen & \Draft" only is used to obtain UID of appended mail, I guess Message-ID: header is used by Tb to know UID for a draft mail. If so, I think deletion of different mail after mail send won't occur.
Tb uses multiappend upon autosave of 2 composing mails, when autosave occurs at same time?
Tb confuses relation between UID and composing mail?

> I would guess that gmail issue is irrelevant.
You are right. Gmail case is merely an example of IMAP flow of deletion of Draft mail with "uid search" command.
 
> There is no such command in my example (see the log).
Because you omitted many log lines, no log line in file you attached can not mean "A command was not really issued by your Tb in your test". So I asked you to see original log file.

It's very hard to know "what was done, what happened on Tb" from IMAP protocol log only. I recommend you to get log with following parameter,
> NSPR_LOG_MODULES=imap:5,smtp:5,DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5
and to enable next option.
> Copies&Folders / Drafts and Templates / Show confirmation dialog when messages are saved
With smtp:5, "when/which mail was sent" becomes clear in log, and by the confirmation dialog option, you can know when auto-save is executed for which mail, and with xxxLeak:5, "when dialog is issued" can be seen in log.  
This confirmation dialog option may prohibt MULTIAPPEND use by TB upon auto-save. If it's true, and if MULTIAPPEND+UIDPLUS is the reason, test without this option, please.

Comment 13

[Wayne Mery (:wsmwk)]

Marby, can you provide updated log mentioned last paragraph comment 12?

wada, is bug still "unconfirmed"?

Comment 14

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #13)
> wada, is bug still "unconfirmed"?

I trust "sent mail was Message B" written by bug opener. I never think "sent mail was Message A instead of Message B".
However, many log lines are deleted(i.e log file is manually edited). So I can't know "Subject: Test B" of mail appended to Sent is real log data or edited text. And, I don't have real log data with server supports UIDPLUS, because I don't have  account of IMAP who supports UIDPLUS. I can't duplicate problem.
So I can't confirm.

I guess "newest draft mail is deleted" instead of "UID is determined based on message-id by Tb himself" when UIDPLUS is used. But I'm not sure. So I requested non-edited log for "mutiple 'draft saving' at multiple compose window" followed by send at second compose window.

Comment 15

[WADA:World Anti-bad-Duping Agency]

Deletion of old draft just after append of new draft looks to be executed at;
http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#5721 thru 5753.
5754 thru 5845 is for non-UIDPLUS case, and "uid serach header message-id" is used.
I guess this logic is also called upon deletion of last draft just after mail send, with different folder for "append"(Sent) and "uid store flag \Delete"(Drafts).

Deletion when UIDPLUS is done by;
> 5745           rv = m_runningUrl->GetListOfMessageIds(oldMsgId);
> 5746           if (NS_SUCCEEDED(rv) && !oldMsgId.IsEmpty())
> 5747           {
> 5748             PRBool idsAreUids = PR_TRUE;
> 5749             m_runningUrl->MessageIdsAreUids(&idsAreUids);
> 5750             Store(oldMsgId, "+FLAGS (\\Deleted)", idsAreUids);
> 5751             UidExpunge(oldMsgId);

GetListOfMessageIds(oldMsgId) replaces content of "oldMsgId" by "UID of the old message"? 
Problem in GetListOfMessageIds? Or problem in Store(oldMsgId, "+FLAGS (\\Deleted)", idsAreUids)? Or problem in caller of them(this module)?

Comment 16

[Mabry Tyson]

Attachment: Log file as requested in comment 12

I'm attaching a log as requested in comment 12, done in Tb3 Beta 2, run on Mac OSX 10.5.6
The problem still exists.

(To avoid including my mail contents, I removed 350K lines from the log that dealt with S-INBOX and most of the lines dealing with S-SENT.  I had unsubscribed from most of my mailboxes to get it down to that few.  If that isn't satisfactory, I'll have to create a new user at the server and client & start from scratch.)

Comment 17

[WADA:World Anti-bad-Duping Agency]

Thanks for new non-edited log(delete of lines only).
Because you provided crisp log and summary in Comment #5 before, it was not so hard to understand log data.

(CAPABILITY command response in log)
> * CAPABILITY IMAP4REV1 LITERAL+ IDLE UIDPLUS NAMESPACE MAILBOX-REFERRALS BINARY
>   UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND
>   SASL-IR LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN

(RFC for UIDPLUS and MULTIAPPEND)
> UIDPLUS     http://tools.ietf.org/html/rfc2359
> MULTIAPPEND http://tools.ietf.org/html/rfc3502
UIDPLUS introduced new "APPENDUID response code" like "OK [APPENDUID 38505 3955] APPEND completed".
So next description is seen in rfc for MULTIAPPEND.
>(Re-citing of description in RFC 3502) 
> MULTIAPPEND Interaction with UIDPLUS Extension
>   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
>   "resp-code-apnd" rule modified as follows:
>   resp-code-apnd  = "APPENDUID" SP nz-number SP set

However, log says.
> S-Drafts:SendData: 20 append "Drafts" (\Seen \Draft) {763+}
>(snip)
> S-Drafts:CreateNewLineFromSocket: 20 OK APPEND completed

Server properly supports UIDPLUS?

Tb probably expects "OK [APPENDUID xxxxx yyyy] APPEND completed" because of UIDPLUS(+MULTIAPPEND). And Tb probably fails to get correct UID of appended mail because of "OK APPEND completed". (possibly UID in following FETCH is saved.)
It may cause "store flag  \Deleted" to wrong UID, if simultaneous draft saving is executed at mutiple composition window. 

Fall back to non-UIDPLUS logic(use "search header message-id") should be done in this case?

Comment 18

[Mabry Tyson]

The more recent RFC on UIDPLUS is RFC4315 http://tools.ietf.org/html/rfc4315

If I read the RFC correctly, the server SHOULD respond with APPENDUID.  The 2 exceptions (when the server MUST or MAY reply APPEND) listed do not apply.   I would treat this particular instance as a server bug (but see below!) but in other conditions APPENDUID may properly be missing.  (Even though the server was written by the author of RFC4315 in the year after that RFC!)

Ah... In UW's IMAP release notes is
http://www.washington.edu/imap/documentation/RELNOTES.html
imapd's attempt to return COPYUID/APPENDUID information for a traditional
UNIX (and MMDF) format mailbox when the mailbox is open by another process
has been declared to be a failure and is now revoked.  It was subject to a
timing race, loss of which involved an expensive reset of the mailbox's UID
regime.  Any imapd COPY or APPEND to a traditional UNIX or MMDF format that
is open by some other process will now no longer return COPYUID/APPEND.
Although this is technically in violation of RFC 4315, there is a loophole
in that document and the timing race/performance problem is worse.
(I presume Crispin mean to write COPYUID/APPENDUID.  The condition he states, mbox on Unix, applies to my Drafts folder.)


I was going to suggest writing this bug off as server bug, but it appears Crispin is using the SHOULD (vs MUST) requirement to allow his server to return APPEND rather than APPENDUID.

The version of the UW IMAP server we have is from the time he was installing UIDPLUS apparently and may not work the same as the later versions.   I will pressure our system people to install a newer version.

Comment 19

[WADA:World Anti-bad-Duping Agency]

Following comment is seen in source.
http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#5739
> 5739           // Courier imap server seems to have problems with recently
> 5740           // appended messages. Noop seems to clear its confusion.
> 5741           if (FolderIsSelected(mailboxName))
> 5742               Noop();
So, request of "if(UW IMAP && no APPENDUID){fall back to non-UIDPLUS;}" doesn't seem awesome request, if server returns result for search command even when UIDPLUS is installed(some servers don't return serch result if UIDPLUS is installed.)
Another possible solution by enhancement of RFC.
  [APPENDUID ?] : Sorry but I can't pass UID although I said UIDPLUS is supported.
Anyway, I believe simplest/correct solution is "remove UIDPLUS from capability response" in this case, if server has problems in inplemetation of UIDPLUS.

Comment 20

[WADA:World Anti-bad-Duping Agency]

Adding "UIDPLUS", "UW IMAP", "APPENDUID" to bug summary for ease of search.

Comment 21

[Mabry Tyson]

The original user who brought up this bug asked about it.

I used

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

and the server announces itself as

* OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS LOGINDISABLED] myhost.example.COM IMAP4rev1 2007e.404 at Wed, 22 Jun 2011 14:10:36 -0700 (PDT)

I repeated the steps in the problem description to test the problem.  The problem happened (the wrong message was deleted from the drafts file).

Comment 22

[David C.]

I recently moved from pop to imap, with uw-imap 2007e.404 server.
Tried with Thunderbird 3.0.11 (default version with openSUSE 11.2 and Ok with addons I like), 3.1.17, 9.0 (openSUSE repositories), 9.0.1 (linux-i686 from releases.mozilla.org) and 9.0/9.0.1 for Windows Seven and Mac OS X Lion : the problem is still occurring.

I even don't need to send a message : when saving a draft, previous (or sometimes oldest) message is deleted.
Steps to reproduce :
1. start composing a message
2. save (or wait for autosave) => message is saved in drafts
3. start composing a 2nd message
4. save (or wait for autosave) => 2nd message is saved in drafts
5. save (or wait for autosave, if modified) => 1st message is deleted (but not in trash),
   replaced by 2nd message which now appears 2 times

Sometimes it needs to compose/save 3 messages in order to see the bug.
A few times this was the oldest draft which is deleted, but I didn't found for now how to reproduce this case by myself.
If needed in addition to previous debug logs, I will join states of files at some steps which I listed above...

So as a workaround I store drafts in Local Folders, but this is not a good solution.
From side of uw-imap, I tried with mbox or mix format : same effect.

However our uw-imap is almost a latest release ; capabilities are :
> # echo . capability | imapd
> IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS
> BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT
> MULTIAPPEND SASL-IR LOGIN-REFERRALS STARTTLS LOGINDISABLED

I read several pages about uw-imap and uidplus :
http://www.washington.edu/imap/documentation/RELNOTES.html
http://objectmix.com/imap/201813-imap-server-implementation-details-unclear-rfc-3501-a-2.html#post714018
http://objectmix.com/imap/201662-how-find-new-message-id-after-append.html#post713427
http://objectmix.com/imap/201013-uw-imap-%5Buidplus%5D-extension.html#post711083
=> I can rebuild our imap server : if I try to hide "UIDPLUS" from capabilities (unless others email-clients will be disturbed), will Thunderbird use a safer way for deleting duplicate drafts ?

I also often see this error in activities when moving a message (and TB undoes the action) : "Bogus sequence in UID FETCH: UID sequence syntax error" -- is it also about uidplus ability ?

Comment 23

[David C.]

Attachment: States of tb/imap files at steps listed in comment 22

In addition to previous debug imap logs

Comment 24

[WADA:World Anti-bad-Duping Agency]

(In reply to Mabry Tyson from comment #21)
> and the server announces itself as
> * OK [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ SASL-IR LOGIN-REFERRALS
> STARTTLS LOGINDISABLED] myhost.example.COM IMAP4rev1 2007e.404 at Wed, 22
> Jun 2011 14:10:36 -0700 (PDT)
> I repeated the steps in the problem description to test the problem.
> The problem happened (the wrong message was deleted from the drafts file).

How did you create multiple draft mails?
Same Subject:? Different Subject:?
Different Message-ID: is guaranteed by you? 

Because Tb has bug 720646, multiple draft mails of same Message-ID: is easily generated. When UIDPLUS is not supported, "uid SEARCH UNDELETED HEADER Message-ID ..." is used, so multiple draft mails are returned from server if multiple draft mails has same Message-ID:. In this case, if multiple draft mails has different Subject:, Tb looks to be able to distingush mails. But if multiple draft mails has same Message-ID: and same Subject:, as seen in bug 704193, Tb looks to fail to distinguish multiple draft mails even if To: header is different.

Mabry Tyson,(bug opener), are you seeing same phenomenon as bug 704193 after successful disabling of UIDPLUS in order to avoid problem of this bug?

Comment 25

[WADA:World Anti-bad-Duping Agency]

(In reply to David C. from comment #22)
> => I can rebuild our imap server : if I try to hide "UIDPLUS" from
> capabilities (unless others email-clients will be disturbed), 
> will Thunderbird use a safer way for deleting duplicate drafts ?

(a) If UIDPLUS is not supported by server(UIDPLUS extention is not installed, no UIDPLUS in capability response), Tb uses SEARCH HEADER Message-Id command. So, if multiple drafts mails has same Message-Id: and same Subject:, problem like bug 704193 can occur.
(b) If UIDPLUS extention is installed/enabled but UIDPLUS is hidden from capability response, Tb uses SEARCH HEADER Message-Id command, but some IMAP servers return nothing to SEARCH if UIDPLUS is installed and enabled.
This happened when Proxy server faked capability response(Proxy hided UIDPLUS even though actual server returns UIDPLUS in capability response). 
(c) If UIDPLUS extention is not installed or enabled at server but UIDPLUS exists in capability response, Tb expects [APPENUID x y] in OK response to APPEND command according to RFC for UIDPLUS. However, server never returns [APPENUID x y], so Tb fails to use correct UID for the appended mail, then some problems occur.
This happened when Proxy server faked capability response(Proxy puts UIDPLUS in capability response even though actual server doesn't return UIDPLUS in capability response).
(d) This bug.
Phenomenon itself is absolutely same as (c).
But, reason why [APPENUID x y] is not returned from server even though server actually puts UIDPLUS in capability responce, is still unknown.
(e) If UIDPLUS is correctly supported by server,
    - UIDPLUS extention is installed/enabled at server,
    - UIDPLUS is correctly put in capability response,
    - Server correctly returns [APPENUID x y] to APPEND command,
Tb uses [APPENUID x y] correctly according to RFC for UIDPLUS.

Needless to say, safest way is (e).
I don't know what happens if you did (b) with your IMAP server.

> I also often see this error in activities when moving a message (and TB
> undoes the action) : "Bogus sequence in UID FETCH: UID sequence syntax
> error" -- is it also about uidplus ability ?

Different issue from this bug. Keep "one problem per a bug at B.M.O", please.

Comment 26

[Wayne Mery (:wsmwk)]

wada, do we still need a protocol log. Or, is the problem gone?

Comment 27

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk) from comment #26)
> wada, do we still need a protocol log. Or, is the problem gone?

What are problems is apparent. No need of addtional log.
For IMAP server's wrong/bad behaviour :
  I don't know whether the server side problem is already resolved or not.
For Tb side protection from "Wrong draft deletion when IMAP server violates IMAP protocol with UIDPLUS" :
  I don't think Tb's quirks for such server's RFC violation is implemented.

Wayne, why "needinfo" to me instead of bug opener?

Comment 28

[Wayne Mery (:wsmwk)]

Mabry, David,
Does your server still have this issue? (I'm guessing it will)
And, please see questions in comment 25.

(doubt we will hear from David, his email fails with "User unknown")


(In reply to WADA from comment #27)
> For IMAP server's wrong/bad behaviour :
>   I don't know whether the server side problem is already resolved or not.
> For Tb side protection from "Wrong draft deletion when IMAP server violates
> IMAP protocol with UIDPLUS" :
>   I don't think Tb's quirks for such server's RFC violation is implemented.
> 
> Wayne, why "needinfo" to me instead of bug opener?

Because I wanted to know about needing log before asking asking the reporter(s). :)
Doing needinfo that wada could have done :)

Comment 29

[Wayne Mery (:wsmwk)]

Mabry seems to be gone as well.