402468 - GMail IMAP - message moved by a filter are marked as read

Status: RESOLVED INVALID

(Thunderbird :: Mail Window Front End, defect)

Description

[Stephen Moehle]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110219 Firefox/3.0a9pre
Build Identifier: 

Using GMail IMAP, messages moved by a Thunderbird filter to an IMAP folder are marked as read as soon as I click on the folder in Thunderbird. GMail's web interface shows the messages as read as well.

Reproducible: Always

Steps to Reproduce:
1. Create an IMAP folder.
2. Create a Thunderbird filter to move messages to the new folder.
3. Send a message from some other account
4. Note that the message is in Inbox and is unread.
5. Run the filter (Tools/Message Filters/Run Now) on Inbox.
6. Note that the folder is bolded to denote unread messages.
7. Click on the folder. Thunderbird thinks a bit contacting GMail
8. Folder is unbolded and no messages are marked as unread 
Actual Results:  
No unread messages in folder.

Expected Results:  
Filtered messages should remain unread.

Comment 1

[Stephen Moehle]

Attachment: IMAP log file

This Thunderbird IMAP log file (NSPR_LOG_MODULES=IMAP:5) starts with receiving a new message. Line 150 is filtering the message to the Subscription folder. Line 179 or so is clicking on the Subscription folder in Thunderbird.

Comment 2

[Magnus Melin [:mkmelin]]

I'm can confirm the behavior, but I'm no so sure it's thunderbird's fault. Marking NEW for further investigation.

Comment 3

[WADA:World Anti-bad-Duping Agency]

Current Gmail IMAP spec around "fetching" is as follows.
> Google Help >  Gmail Help > IMAP Access
>   http://mail.google.com/support/bin/topic.py?topic=12760
>   How do actions sync in IMAP?
>    http://mail.google.com/support/bin/answer.py?answer=77657&topic=12762
>Action on mobile device/client(e.g.iPhone/Outlook) | Result in Gmail on the web
>  Open a message                                   |   Mark a message as read

"Move by filter" consists of (a) FETCH, (b) APPEND, (c) delete(flag as \Deleted, EXPUNGE later if required).
"Read" status is probably set by Gmail IMAP server, even though flag of \Seen is not requested by MUA explicitly.
I believe that \Seen flag is not set by "move of a mail" (i.e not_seen==unread is kept) when usual IMAP server.
> RFC 3501  :  http://www.faqs.org/rfcs/rfc3501.html

Comment 4

[WADA:World Anti-bad-Duping Agency]

As written in following articles, 
> Why don't all my views and labels appear?
>  http://mail.google.com/support/bin/answer.py?answer=78772&topic=12763
>    We’re working on making Gmail for IMAP as much like
>    the web interface as we can, (snip)
> Does Gmail support all IMAP features?
>  http://mail.google.com/support/bin/answer.py?answer=78761&topic=12762
>    Gmail IMAP is a fairly complete implementation of IMAP,
>    but the following features are currently unsupported: (snip)
Gmail IMAP is still under construction, even after official release.

To bug opener:
Open Gmail IMAP related bug at bugzilla.mozilla.org with apparent evidence of "Tb's bug" and/or with apparent grounds of "Tb's bug", please.
I think problem analysis at both MozillaZine forums and Gmail forums is required before bug open at bugzilla.mozilla.org, because specs of Gmail IMAP is still unclear.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Correction. Sorry for spam.
It was "COPY" instead of "APPEND" at step (b) in "moving of a mail".
"\Seen" looks to be returned when first "FETCH" of the copied mail to Subscription folder, even though "store FLAGS \Seen" was never requested for the mail by Tb.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Article in Gmail IMAP Help says followings too. 
> How do actions sync in IMAP?
>   http://mail.google.com/support/bin/answer.py?answer=77657&topic=12762
> Action on mobile device/client  |  Result in Gmail on the web
> (e.g.iPhone/Outlook)            |
>  Move a message to a folder     |   Apply a label to the message
>  Move a message to a folder     |   Apply a label showing folder hierarchy
>   within a folder*              |    ('MainFolder/SubFolder')*

It probably implies that ;
A) "FETCH step for move mail via IMAP" is treated as "open a message via IMAP".
B) Then "Mark a message as read" via "Gmail on the web" is applied to the mail.

Comment 7

[bill baritompa]

I have this problem with my servers IMAP host as well. So it is not restricted to Gmail IMAP only. After the filter moves mail, I see the folder bolded momentarily and then it becomes unbolded. 

Comment 8

[WADA:World Anti-bad-Duping Agency]

FYI.
According to RFC 4314, action of "set \SEEN during FETCH BODY[...])" looks to be an intended/proper action of an IMAP server, when "IMAP4 Access Control List (ACL) Extension" is supported by the IMAP server, and when "s" is properly returned to LISTRIGHTS command by the IMAP server based on correct/intentional server side setup's of the IMAP server.
> http://www.faqs.org/rfcs/rfc4314.html
> IMAP4 Access Control List (ACL) Extension
> 2.1.  Standard Rights
>(snip)
>  s - keep seen/unseen information across sessions (set or clear
>      \SEEN flag via STORE, also set \SEEN during APPEND/COPY/
>      FETCH BODY[...])
>(snip)

Comment 9

[David :Bienvenu]

So, we're doing a FETCH BODY.PEEK - .PEEK means DON'T set the \SEEN flag. GMail seems to be ignoring that, judging from its response.

The other thing that occasionally confuses some imap servers is that immediately after the copy message command, we mark the original message as \SEEN + \DELETED, and some bad servers propagate the \SEEN flag to the copied message, even though we copied the message first, then marked the original message as \SEEN. (These tend to be non-native IMAP servers, where IMAP is grafted on the side of an existing mail server).

However, I'm using a filter with gmail imap and I'm not seeing this problem at all.

Comment 10

[Brian Kennelly]

(In reply to comment #9)
> The other thing that occasionally confuses some imap servers is that
> immediately after the copy message command, we mark the original message as
> \SEEN + \DELETED, 
That actually would explain it.  Google only has one copy of the message, and the flags apply to that copy in all the virtual folders.  So, if TB flags the message \Seen, it is set for the copy.  (\Deleted is special.)

> However, I'm using a filter with gmail imap and I'm not seeing this problem at
> all.
I no longer see this problem, either.  I suspect that Google made a change to ignore flags being set with \Deleted, but, so far, that is just a guess.

Comment 11

[Brian Kennelly]

I did some testing from a terminal, and confirmed that, if a client sets the \Deleted flag, all other flags included in the same STORE (our UID STORE) command are ignored.  

I think this bug can be closed, as a server-side problem that has been fixed.

Comment 12

[WADA:World Anti-bad-Duping Agency]

Closing as INVALID(Gmail's bug or design or restriction).