Open Bug 335293 Opened 14 years ago Updated 12 years ago
Thunderbird should use \Flagged IMAP flag to indicate "Important"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060418 Fedora/1.0.8-1.1.fc4 Firefox/1.0.8 Build Identifier: Thunderbird 1.5 The IMAP protocol specification specifies several "pre-defined" message flags. RFC2060 section 2.3.2 says: A system flag is a flag name that is pre-defined in this specification. All system flags begin with "\". Certain system flags (\Deleted and \Seen) have special semantics described elsewhere. The currently-defined system flags are: \Seen Message has been read \Answered Message has been answered \Flagged Message is "flagged" for urgent/special attention \Deleted Message is "deleted" for removal by later EXPUNGE \Draft Message has not completed composition (marked as a draft). \Recent Message is "recently" arrived in this mailbox. This session is the first session to have been notified about this message; subsequent sessions will not see \Recent set for this message. This flag can not be altered by the client. Thunderbird utilizes the \Seen, \Answered, and \Deleted flags. Thunderbird does not utilize the \Draft flag. If I start composing a new message and save it before sending it, the draft is correctly saved to my "Drafts" folder, but the \Draft flag is not set. One could argue that anything that is in my Drafts folder should be treated as a draft, and thus setting the \Draft flag is superfluous. But this ignores the fact that people use IMAP clients other than Thunderbird, and in my experience most IMAP clients correctly set the \Draft flag on drafts. Thunderbird compounds this situation by ignoring the \Draft flag. So, if I start composing a message using a different IMAP client and save it as a draft to a folder other than the one I have configured Thunderbird to use for drafts, if I then open that message in Thunderbird, Thunderbird fails to recognize that the message is a draft and opens the message for display instead of launching the composer. The fundamental issue here is the same one as with the Trash folder: Thunderbird (nee Mozilla, nee Netscape) deliberately ignored the IMAP standard model of doing things in favor of doing things their own way. The problem is that the world is not a homogeneous place, and Thunderbird's "draft" model doesn't play nicely with other IMAP clients that *do* follow the IMAP standard. Thunderbird should have an option that means "follow the IMAP standard model for drafts". When this option is enabled, the following behavior occurs: 1. Thunderbird correctly sets the \Draft flag on drafts it saves. 2. When opening a message, Thunderbird checks for the \Draft flag and launches the composer if it is set, regardless of whether the message being opened is in the "Drafts" folder. Furthermore, I think it would make sense to have an "always ask where to save drafts" option (similar to Firefox's option to always ask where to save downloads): if I'm using the standard IMAP drafts model, I probably will want to save drafts into arbitrary folders. And finally, in terms of Thunderbird's support for pre-defined flags... Thunderbird doesn't use the \Flagged flag (commonly referred to as the "important" flag) at all. There is no way to set the \Flagged flag, and Thunderbird does not differentiate messages with the \Flagged flag in the mailbox display. Thunderbird has the ability to flag a message as "Important", but the flag Thunderbird sets for "Important" messages *is not the \Flagged flag*. Rather, Thunderbird is setting a non-pre-defined flag. It could be argued that requesting proper handling of the \Draft flag is a feature request, not a bug. But Thunderbird's failure to properly use the \Flagged flag is an outright bug. Consider, for example, a shared IMAP folder. Let's say that 10 different people have write access to the shared folder. Furthermore, let's say that those people are using the \Flagged flag to communicate information to each other, and that 3 of the people use Thunderbird and 7 use other IMAP mail clients. Because Thunderbird doesn't follow the IMAP standard model, the Thunderbird users won't see any of the messages that the non-Thunderbird users have flagged as being important, and the non-Thunderbird users won't see any of the messages that the Thunderbird users have flagged as being important. Even worse, consider the case of sites using the Cyrus IMAP server. The Cyrus IMAP server has a utility program called ipurge that is designed to be run by crond to automatically purge old messages from shared folders: http://www.linuxmanpages.com/man8/ipurge.8.php The -s option to ipurge causes ipurge to skip messages with the \Flagged flag set. This is specifically so that people with write access to the folder can mark messages that they don't want to be automatically deleted as important. But because Thunderbird doesn't use the \Flagged flag, there is no way whatsoever for a Thunderbird user to take advantage of ipurge's exception mechanism. Thunderbird needs to stop its non-standard use of the "important" flag. Setting a message as "important" should set the pre-defined \Flagged flag, not some non-pre-defined flag. Deviating from this expected behavior causes big-time interoperability problems with other IMAP clients. (As an aside, it makes no sense that the other custom flags Thunderbird can set are mutually exclusive in the interface. Who says I can't have a message that's both "Work" and "Important"? And for that matter, why can't I create my own flags for servers that include "\*" in the PERMANENTFLAGS response?) Reproducible: Always
\Draft is bug 156347.
So it is. Thanks; I missed that one. Since the \Draft flag is being tracked in bug 156347, I've updated the Summary of this bug to indicate that it's primarily about Thunderbird's use (or lack thereof) of the \Flagged flag.
Summary: Thunderbird should understand/support all IMAP pre-defined flags → Thunderbird should use \Flagged IMAP flag to indicate "Important"
Has there been any progress on this issue? I am thinking that the easiest way to fix this bug without breaking backwards compatibility is to modify Thunderbird to behave as follows: setting "Important" sets both \Flagged and the current custom flag unsetting "Important" clears both \Flagged and the current custom flag a message is considered to be "Important" if either flag is set Optionally, a message could be re-flagged (if necessary) whenever it is opened. Thoughts?
I'm just switching to Thunderbird, and for me it appears that Thunderbird *does* use the \Flagged IMAP tag, but in order to view it you have to enable the Flagged column in the threadTree. You get a column that may have little flags in it. But this behavior does seem sub-optimal, really Flagged and Important should be the same thing, as the summary requests. I think that this is somewhat related to bug 342009, where the appearance of flagged messages isn't configurable like most other things. If the appearance of flagged messages was configurable instead of it being hidden in a very small single column of things, the importance of having \Flagged and Important be the same thing would be lower. (But it would still be good)
I though we already fixed that in 2.x tree using tag important will mark it \Flagged
Version: unspecified → 1.5
Nope. Here's an IMAP telemetry log of Thunderbird 126.96.36.199 (Fedora 9 standard build) flagging a message as Important: C: 23 uid store 158341 +FLAGS ($label1) S: * 327 FETCH (FLAGS (\Seen $label1) UID 158341) S: 23 OK Completed Removing the Important flag: C: 30 uid store 158341 +FLAGS ($label1) S: * 327 FETCH (FLAGS (\Seen $label1) UID 158341) S: 30 OK Completed C: 31 uid store 158341 -FLAGS ($label1) S: * 327 FETCH (FLAGS (\Seen) UID 158341) S: 31 OK Completed Furthermore, if I mark a message as \Flagged (using a different IMAP client), Thunderbird gives the user no indication that the message has the \Flagged flag set. So, as far as I can tell, nothing has changed in Thunderbird's behavior since I originally reported this bug...
Can you test it using latest trunk or TB alpha1?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.5 → 2.0
I mean TB 3 alpha1
Assignee: mscott → nobody
Behavior is exactly the same with TB 3a1: C: 17 uid store 158341 +FLAGS ($label1) S: * 327 FETCH (FLAGS (\Seen $label1) UID 158341) S: 17 OK Completed
Wayne, I suppose this belongs to Core->IMAP? But in same time also UI behavior not displaying \Flagged - flag.
Version: 2.0 → Trunk
David, does this apply to both imap & pop?
OS: Linux → All
Hardware: PC → All
You need to log in before you can comment on or make changes to this bug.