Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt

[Bron Gondwana <[e-mail]>]

On Thu, Jul 19, 2018, at 23:40, Ned Freed wrote:
>>> In the next step:
>>> 
>>>    Subsequently, when no particular mailbox is of interest (i.e.,
>>>    the>>>    "specialuse_exists" test has no mailbox argument), the client
>>>    lists>>>    all mailboxes with special-use flags in the two returned personal>>>    namespaces:
>>> 
>>>    C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN
>>> (SPECIAL-USE)
>>>    S: * LIST (\Drafts) "/" INBOX/Drafts
>>>    S: * LIST (\Trash) "/" INBOX/Trash
>>>    S: * LIST (\Sent) "/" INBOX/Sent
>>>    S: * LIST (\Archive) "/" Archive/Default
>>> 
>>> It should be noted that this depends on extended list being
>>> available.> 
>> True. I thought LIST-EXTENDED is pretty much required for SPECIAL-
>> USE,>> but the specification doesn't actually mention anything like that. Is>> there another way to obtain information on which mailboxes have a
>> particular special-use flag assigned?
> 
> Yes, according to RFC 6154 section 2 special use attributes MAY
> appear in> non-extended LIST responses. There's an example of this in
> section 5.1.> 
> However, the fact that this is a MAY makes it effectively useless
> since you> can't tell the difference between a case where there are no
> special use> attributes assigned and one where the server has simply elected not
> to include> these attributes in its responses. And it's expected that the
> overwhelming> majority of mailboxes won't have any special use assigned.

MAY fricking shmay.  There are clients out there which flat out expect
that you return the SPECIAL-USE for an unadorned LIST, and customers
report your server as buggy if it doesn't do what their client expects.
> In fact I'd go so far to say that this is a design error. It's
> one thing> to want to support existing implementations of special use
> attributes, it's> another to be so permissive that a compliant implementation - one that> supports SPECIAL-USE but not LIST-EXTENDED - can have no way to
> determine> what the special use mailboxes are actually present.

I'm sure that RFC3501bis (IMAP4rev2) will fix this.

> All that said, all I was asking for here was a note saying this
> depended on> LIST-EXTENDED. Nothing more. (Personally, I don't intend to even
> bother to> check if it's supported.)

That seems very reasonable.

>>> However, I think use of SELECT for this purpose is problematic: It's>>> potentially expensive and worse, may cause undesireable state
>>> changes.>>> Why
>>> not use the MYRIGHTS command to obtain the access rights (and check>>> for "p" or
>>> "i") without having to select the mailbox?
> 
>> Sure, if the ACL capability is available. I can mention that.
>> If it is>> not available, there is really no alternative to using SELECT, right?> 
> Not as far as I know. But again, the problem is that SELECTing
> a mailbox> on behalf of a user can change its state, with all that implies.
> I'd rather> have my implementation fail if ACL isn't present than have a sieve
> operation> cause a state change.

Thanks \Recent.  But at least EXAMINE rather than SELECT should also
mean no change made (in theory).
>>> All of which is roundabout way of saying I now think that we may
>>> want a>>> capability for specialuse_exists that's separate from
>>> "special-use"/:specialuse. Or better still, since we already
>>> have the>>> "mailbox"
>>> capability for "mailbox access stuff", I think we should require the>>> presence
>>> of both "mailbox" and "special-use" capabilities in order to use
>>> specialuse_exists.
> 
>> Can you clarify this point? I don't see how this leads to
>> requiring the>> mailbox extension.
> 
> It doesn't unless we want it to, and I think we want it to. We
> have this> collection of stuff collected under the mailbox extension that lets
> sieve peek> at the state of the mailbox. And here we have an extension that
> consists of two> parts: One extending fileinto and the other adding to things you can
> peek at.> 
> From an MTA implementation perspective, these are very distinct
> things, and> the latter shares a ton of code with the mailbox extension. It
> therefore> makes sense to me to separate the two and link it to the mailbox
> extension.> 
> It's really no different than the way SPECIAL-USE and LIST-EXTENDED
> interact on the IMAP side of things: Both have to be present for the
> RETURN (SPECIAL-USE) stuff to work.
> 
> Ned

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]