Quoting Patrick Ben Koetter <p...@state-of-mind.de>:

we want to implement SPECIAL-USE in Thunderbird (TB), but we've run into
problems. I believe you could help change that.

Here's the problem:

By default TB only lists subscribed (LSUB) folders when it accesses an IMAP
server. However when I do a LSUB on recent Dovecot 2.1 code from mercurial I
don't get to see the SPECIAL-USE flags. Therefore TB fails to identify which
folders it should use and map to until someone tells it to list all folders
(LIST) manually.

Central part of the SPECIAL-USE idea was/is to require as little user
interaction as possible to automatically setup a MUA to do the right thing.

Speculating that probably most MUAs will do a LSUB by default and never will
get to see SPECIAL-USE flags I think it is easier to have the server-side
promote the flags.

Except you never, never, never, never, never can rely on LSUB for mailbox attributes. It says so right in RFC 3501 [6.3.9]:

      The returned untagged LSUB response MAY contain different mailbox
      flags from a LIST untagged response.  If this should happen, the
      flags in the untagged LIST are considered more authoritative.

See also RFC 5258 [3.1], which discusses the difference between the base RFC 3501 LSUB command and the LIST-EXTENDED SUBSCRIBED option:

      This option is
      intended to supplement the LSUB command.  Of particular note are
      the mailbox attributes as returned by this option, compared with
      what is returned by LSUB.  With the latter, the attributes
      returned may not reflect the actual attribute status on the
      mailbox name, and the \NoSelect attribute has a second special
      meaning (it indicates that this mailbox is not, itself,
      subscribed, but that it has descendant mailboxes that are).  With
      the SUBSCRIBED selection option described here, the attributes are
      accurate and complete, and have no special meanings.  "LSUB" and
      "LIST (SUBSCRIBED)" are, thus, not the same thing, and some
      servers must do significant extra work to respond to "LIST
      (SUBSCRIBED)".  Because of this, clients SHOULD continue to use
      "LSUB" unless they specifically want the additional information
      offered by "LIST (SUBSCRIBED)".

Even if Timo changes things on Dovecot, you still can't rely on the flags returned from an LSUB command because other servers are not guaranteed to act the same way.

That's just the reality of IMAP. LSUB is only useful for grabbing the list of subscribed mailboxes (I *really* hope TB is not using flags from the LSUB response for any meaningful purpose - that is simply badly broken behavior).

In conclusion, there are 2 ways of handling special-use flags:

1. If the server that supports SPECIAL-USE also supports LIST-EXTENDED (RFC 5258), you are in luck. You can then use LIST-EXTENDED which can accurately retrieve both the list of subscribed mailboxes and special-use flags in a single command. 2. If the server supports SPECIAL-USE but does NOT support LIST-EXTENDED, you MUST make a LIST call. A LSUB call is not sufficient. It's inefficient, but that's the only way to be 100% sure the information in the response is accurate.

michael

Reply via email to