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

[Bron Gondwana <[e-mail]>]

Hi all, sorry about dropping the ball on following up on this.  I'm just
putting together the slides for Thursday now.
On Thu, Jun 14, 2018, at 01:40, Ned Freed wrote:
>>> This, incidentially, is one of those places where providing the
>>> actual IMAP>>> commands will be especially valuable: Pointing out that you should
>>> use the>>> NAMESPACE extension and if it isn't present, fallback to LIST ""
>>> would be very>>> helpful.
> 
>> Here's my initial attempt at addressing this point (separate
>> branch in>> Github):
> 
>> https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/035a1af6137a383089c8d54cd733238dc2dfebda> 
>> This adds an IMAP example for specialuse_exists.
> 
>> What do you think?
> 
> The first step seems fine:
> 
>   C: A01 NAMESPACE
>   S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/"
>      "/"))>   S: A01 OK NAMESPACE command completed
> 
> 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.> 
> The final step is:
> 
>     C: A03 SELECT Archive/Default
>     S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
>     S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \Draft \*)]
>        Flags permitted.>     S: * 11211 EXISTS
>     S: * 3 RECENT
>     S: * OK [UIDVALIDITY 1526903163] UIDs valid
>     S: * OK [UIDNEXT 11278] Predicted next UID
>     S: A03 OK [READ-WRITE] SELECT command completed
> 
> There are several issues here.
> 
> First, if you're going to use SELECT it's probably worth noting
> that since> inclusion of [READ-WRITE] for writable mailboxes is a SHOULD in RFC
> 3501 while> inclusion of [READ-ONLY] for non-writable is a MUST, a writability
> check really> needs to based on the absence of [READ-ONLY]. (RFC 5490 3.1.a appears
> incorrect> to me in this regard - should I file an errata?)
> 
> 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?
> 
> And as a bonus, if it's available you could use the just-standardized> LIST-MYRIGHTS extension to piggyback getting the rights while getting
> the list> of special-use mailboxes.
> 
> More generally, this is why documenting the things necessary to
> implement the> necessary semantics of an extension is helpful - there may be
> optimizations and> concerns that should be called out lest implementors miss them.
> 
> It also helps clarify overall implementation difficulty. And
> while this> extension may be easy to implement in the Sieve-in-IMAP case, from the> perspective of an MTA/MDA implementation, even if all of the steps
> can be done> efficiently, there's still the question of IMAP server
> availability and the> handling of temporary errors.
> 
> 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.

Stephan, are you happy to revise based on Ned's feedback above?

> I also reviewed the rest of the revised draft, and it's looking
> good. My one> remaining concern is with the handling of multiple mailboxes
> having the> same special-use flag assigned. The draft currently says:
> 
>   More than one mailbox in the user's personal namespace can have a
>   particular special-use flag assigned.  In case of such
>   ambiguity, the>   mailbox that is chosen for delivery is implementation-defined.
>   However, while the set of mailboxes to which the involved special-
>   use>   flags are assigned remains unchanged, implementations MUST ensure
>   that the mailbox choice is made consistently, so that the same
>   mailbox is used every time.  Conversely, the chosen mailbox MAY
>   change once the special-use flag assignments that are relevant for
>   the mailbox choice are changed (usually by user interaction).
> 
> I don't see a way I can reasonably implement this MUST via IMAP
> unless the> IMAP server always returns the list of special-use mailboxes in the
> same order.> Sure, I can cache the user/special-use-attribute/actual-mailbox-
> list tuple> somewhere, but caches can always be lost. And mailbox metadata is (a)> Potentially much too expensive and (b) Subject to the
> vagarities of user> actions.
> 
> I'm not happy about it, but I think this needs to become a SHOULD.

I can live with SHOULD for cases where there are multiple mailboxes with
the same special-use.
> Another possibility is to use the default mailbox name as a means of
> disambiguating multiple mailboxes with the same special-use attribute:> If the default mailbox is one of these deliver to it preferentially,
> otherwise the behavior is implementation-defined. Not perfect, but it> provides a bit more consistent behavior that's easily achievable.
> 
> Aside from these issues, this draft looks good to go to me.

Thanks for the great feedback!

Cheers,

Bron.

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