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

["Chris Newman" <[e-mail]>]

On 19 Jul 2018, at 9: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.
>
> 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 believe that's an incorrect interpretation of the spec. RFC 6154 
states:

    ...  If the client specifies the "SPECIAL-USE" selection option,
    the LIST command MUST return only those mailboxes that have a
    special-use attribute set.  If the client specifies the 
"SPECIAL-USE"
    return option, the LIST command MUST return the new special-use
    attributes on those mailboxes that have them set. ...

This spec applies to all servers that advertise SPECIAL-USE. Those two 
MUST clauses do not have an exception for servers that do not advertise 
LIST-EXTENDED. The example in section 5.2 supports this interpretation, 
since it does not include LIST-EXTENDED in the capabilities response.

Contrast that with section 4:

    If a server supports this extension and the METADATA extension
    [RFC5464], it SHOULD tie the special-use attributes for a mailbox to
    its metadata entry "/private/specialuse".

where there's an explicit exception to the SHOULD for servers that do 
not implement METADATA due to the "if" clause.

If I recall correctly, the difference in normative language between 
these two sections was deliberate.

		- Chris

> 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.)
>
>> > 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.
>> > 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
>
> _______________________________________________
> Extra mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=fqjptcmWVzu3waxuhECJKbXvzfSuBPDLN9t7KQMtjW8&s=G51gQpE9MxifdONliqnLO9agM4akhpX0R2j_SbJQvi8&e=