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

[Stephan Bosch <[e-mail]>]

Hi Ned,

Thanks for the review!

Op 1/8/2018 om 5:50 PM schreef Ned Freed:
> I have a few observations and comments on this draft.
>
> The sieve language is designed not to be specific to IMAP. However, this
> extension seems to specifically tied to IMAP in general and to RFC 6154
> in particular. This means there's really no reason not to tighten the
> association - in particular, would it not make sense to provide sample
> IMAP command sequences to implement the various things in this specification?
>
> This would be quite helpful to implementors, who might otherwise overlook an
> important step.

Hmm, I am not exactly sure what you mean here. Can you give an example? 
At our end, there is no intermission of IMAP for executing Sieve rules;
both just use the same APIs to operate: i.e., one is not layered above
the other. Also, IMAP command sequences can only show the actions that
are performed, not the decisions that lead to those actions.

> Special use is, in effect, a many-to-many mapping of special use attributes to
> mailboxes. That is, mailboxes can have multiple special use attributes and a
> given attribute can be associated with multiple mailboxes.
>
> As far as choosing the right mailbox when more than one has the specified
> special-use attribute, the draft says "implementations MUST ensure that this
> choice is made consistently, so that the same mailbox is used every time."
>
> I don't know how to implement this short of keeping a per-user list of what
> mailbox was used for a given special use attribute. And even a list doesn't
> guarantee that no least astonishment violations will occur.
>
> Consider: Suppose there's only mailbox for a given special use and I deliver to
> it. Then the user adds an additional special use mailbox. No simple selection
> criteria, e.g., first alphabetically will work in general in this case, because
> I can alway construct an example where the new mailbox beats the old one.
>
> Creation date doesn't work either, because you can add a special use attribute
> to an existing, old maibox. Mailboxes can also be deleted and recreated.
>
> You can solve these problems by keeping a list of mailboxes you've used for a
> given special use attribute. But this is a royal PITA, and it still doesn't
> address sequences like
> createa-delivera-createb-deletea-deliverb-deleteb-createa-deliver? 
>
> The bottom line is I think this needs to be relaxed to a SHOULD. It probably
> should also be made clear that if a previously used mailbox no longer exists
> then the mailbox default from the command is used rather than recreating the
> old mailbox. That is, the mailbox explicitly listed in the command wins over
> consistency with the past.

I see what you mean. What about relaxing this statement so that
consistency is required only for as long as the set of mailboxes with
the specified special-use flag remains unchanged? Adding/removing
mailboxes is then allowed to change the effective mailbox of the
fileinto :specialuse action. The actual choice of the effective mailbox
after each change is still left to the implementation. Summarizing,
consistency is then only guaranteed while the user doesn't mess with the
assignments of the involved special-use flag.

> The other aspect of the many-many mapping is the fact that a single mailbox can
> have multiple special use attributes. The draft supports this in the context of
> specialuse_exists but not in the context of fileinto. I think this is fine, but
> I want to make sure everyone is happy with this limitation, including the fact
> that because of this you won't be able to create mailbox with fileinto with
> multiple special use attributes.

Good point. For sake of discussion, let's assume we allow a string list
for the :specialuse parameter. The semantics for creation of a mailbox
would be quite clear: all of those flags are assigned to the new
mailbox. But what would that mean for the mailbox lookup? Are we looking
for a mailbox that has all of these flags, one of these flags or just
the first flag listed?

Another question is whether mailboxes with several special-use flags are
really that useful.

> Section 3 says:
>
>    If the "mailbox" string argument is omitted, the "specialuse_exists"
>    test yields true if all of the following statements are true for each
>    of the special-use flags listed in the "special-use-flags" argument:
>
>    a.  at least one mailbox exists in the mail store that has that
>        particular special-use flag assigned, and
>
>    b.  that mailbox allows the user in whose context the Sieve script
>        runs to "deliver" messages into it.
>
> I'm concerned about a. - the phrase "the mail store" conjures up an image
> of searching through folders belonging to millions of users looking for
> one that has an ACL allowing the sieve owner to write to it.
>
> I'm pretty sure you don't intend this to cover shared folders, so I suggest
> changing the text to say something like:
>
>    a.  at least one mailbox exists in the user's personal namespace
>        [NAMESPACE]  that has that particular special-use flag assigned, and
>
> And add the [NAMESPACE] reference pointing at RFC 2342.

I must say I didn't consider any special problems with shared mailboxes.
The scenario you describe is that lots of people are sharing some of
their mailboxes with pretty much everyone. In that case, indeed, it
could be a lengthy lookup. I guess the impact is
implementation/deployment-dependent. I think we should warn about
situations like this, but not restrict access to the personal
namespace(s) in the specification.

Also, couldn't an account have more than one private namespace? For
example, there could be a main namespace containing the INBOX and
another namespace on a different slow storage that contains archived
messages.

> 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.

Sorry, I don't understand what you mean.

> The specialuse_exists makes use of an optional positional parameter. I'm
> fine with this, but I want to make sure everyone else is, and that we don't
> need to switch to something like:
>
>    specialuse_exists [:mailbox <mailbox: string>]
>                      <special-use-flags: string-list>

Well, this would not be the first extension doing that. E.g., the
imap4flags extension has similar optional positional arguments.

Still, I have no objection to the syntax you propose.

Anybody else have a preference?

> The text and examples showing the interaction of :specialuse with :create seem
> to assume that mailboxes won't be created without :create. This assumption is
> incorrect; the sieve base specification is quite clear that an implementation
> MAY create the specified mailbox if it doesn't exist even if :create isn't
> specified. (Our implementation is one that always creates missing mailboxes
> specified in fileinto; :create is therefore a no-op.)
>
> I think an implementation that creates by default SHOULD also assign the
> special use attribute by default if it able to do so. This should be covered in
> the text. A reference to the text about fileinto in RFC 5228 is probably in
> order here.

Good point.

> The first example should probably be changed to note that what happens in the
> event there's no mailbox with the \Junk attribute and a mailbox named "Spam"
> doesn't exist is implementation-dependent.
>
> The second example should be tweaked a bit to make it clear that the effect of 
> :create is to make the creation of the mailbox unconditional.

Yeah.

Regards,

Stephan.

-- 
Stephan Bosch
Senior Developer 


Phone: [phone]  Fax: [phone]
Email: [e-mail]


-------------------------------------------------------------------------------------
Open-Xchange AG,  Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein 
Chairman of the Board: Richard Seibt

Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland
Managing Director: Markku Kentta
Chairman of the Board: Timo Sirainen
Board Member: Carsten Dirks

-------------------------------------------------------------------------------------