987626 - Deleted or moved IMAP messages from another device still appear in Thunderbird

Status: RESOLVED DUPLICATE of bug 693204

(MailNews Core :: Networking: IMAP, defect)

Description

[The Merg]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36

Steps to reproduce:

I delete an email or move an email using another device/client from my IMAP inboxes (usually using iPhone or iPad). I am using DreamHost as my email host provider. I did not seem to have this issue when GoDaddy was my email host provider.


Actual results:

When viewing my email in Thunderbird, the deleted or moved emails are still present in the Inbox. Hitting "Get Mail" does not update the Inbox. In order to get the emails to "disappear" from the Inbox, I need to perform a "Repair Folder". Looking in the folder to where the email had been moved shows that it is there in Thunderbird. However, it is still shown in the Inbox in Thunderbird.


Expected results:

When viewing the Inbox in Thunderbird, the email messages that were moved or deleted should have been removed from the Inbox in Thunderbird.

Comment 1

[WADA:World Anti-bad-Duping Agency]

"Delete os a mail" is "add imap flag named \Deleted to mail" in IMAP, and there is two states in "Deleted mail(UID=A) by other client" in Mbox at IMAP server.
  (initial) mail of UID=A doesn't have \Deleted flag.
  (a) mail of UID=A has \Deleted flag.
  (b) "mail of UID=A which had \Deleted flag" was permanently removed from Mbox by EXPUNGE.
      i.e. mail of UID doesn't exist in Mbox any more.
"Move mail from MboxA to MboxB"  is;
- if "move" command is not supported by server,
  at MboxA, "uid x copy MboxB" + "uid x store +Flag(\Deleted)"
- if "move" command is supported by server, at MboxA, "uid x move MboxB".
  Because of "Move", same action as expunge is executed by server at MboxA.

There is only two way to know state change "from (initial)->(a)", "from (a)->(initial)"Undelete), "from (a)->(b)", "from (initial)->(a)" etc.
  (i)  Send IMAP command from IMAP client to IMAP server, and receives mail's status as IMAP response.
  (ii) IMAP server notifies state change via IDLE if IMAP client issued IDLE.
i.e.
- After state change was done by other IMAP client,
  - if command to know mail's state is sent by IMAP client, IMAP client can know state change.
    if command to know mail's state is not sent by IMAP client, IMAP client doesn' know state change.
  - if IDLE is sent, and if IMAP server notify state change, IMAP client can know state change.
    if IDLE is sent, and if server doesn't notify state change, IMAP client doesn't know state change.
So, if you get IMAP log and check IMAP level flow(IMAP command sent by Tb, IMAP command response from server), you can know easily why Tb can't or doesn't know state change of mail whch was done by other IMAP client.

"What extention is supported by server" or "server's behavior" depends on server. All is up to server. So, if different server, "phenomenon is different" is pretty normal.

There are two known issues in Tb around it.
(1) Tb uses IDLE if server supports IDLE command and if you enable IDLE command use in Tb,
    but server doesn't notify mail's state change via IDLE.
    So, Tb can't know state change done by other mail client.
(2) Even if IDLE command use is disabled, following occurs on Inbox.
    Tb reserves a cached connection for Inbox, and Tb uses the cached connection for Inbox only,
    and Tb keeps "Inbox is seleted at a cached connection" state always while Work online mode.
    When an Mbox is already selected at a cached connection, Tb uses "uid HighestUID_TbAlreadyKnow:*
    Flags()" for next new mail check of Inbox, instead of "uid 1:* fetch Flags()".
    So, "mail's state change done by other client on UID=1 to (HighestUID_TbAlreadyKnow-1)" is not
    returned upon next new mail check of Inbox.
    This is normal behavior, because Inbox is "tray to receive new mail" and Inbox is never
    "repository of all mails which ware received in the past". 
    This is to avoid "many many response lines upon each new mail check".
    Imagine "1000000 mails in an Mbox" case, please.
These are problem known in bug 693204.

Is your problem same as bug 693204? Or different problem from bug 693204?
(possible answer is true or false only, because problem of bug 693204 is pretty clear)

Is following a workaround in your problem?
 go Work Offline mode, select account instead of Inbox at folder pane,
 go Work Online mode again, select Inbox at folder pane

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #1)
> Is your problem same as bug 693204? Or different problem from bug 693204?
> (possible answer is true or false only, because problem of bug 693204 is
> pretty clear)
> 
> Is following a workaround in your problem?
>  go Work Offline mode, select account instead of Inbox at folder pane,
>  go Work Online mode again, select Inbox at folder pane

Comment 3

[The Merg]

This appears to be very similar to the bug 693204. The one difference that I see is that in the other bug, it states that after 2 or 3 hours, the mark read flag would appear to kick in. I don't remember seeing that happen in my case. I would need to perform a Repair Folder for the deleted or moved messages to disappear.

With regards to the workaround, it would not work. Also, just the process of going offline and back online could sometimes take upwards of 5 minutes due to the size of my account. Not really a feasible solution then.