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

From: [email-masked]
Date: Sun, 07 Jan 2018 06:49:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF.

        Title           : Sieve Email Filtering: Delivering to Special-Use Mailboxes
        Author          : Stephan Bosch
	Filename        : draft-ietf-extra-sieve-special-use-01.txt
	Pages           : 8
	Date            : 2018-01-07

Abstract:
   The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows
   clients to identify special-use mailboxes; e.g., where draft or sent
   messages should be put.  This simplifies client configuration.  In
   contrast, the Sieve mail filtering language (RFC 5228) currently has
   no such capability.  This memo defines a Sieve extension that fills
   this gap: it adds a test for checking whether a special-use attribute
   is assigned for a particular mailbox or any mailbox, and it adds the
   ability to file messages into an anonymous mailbox that has a
   particular special-use attribute assigned.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-01
https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-use-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-special-use-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephan Bosch <[email-masked]>
Date: Sun, 7 Jan 2018 15:57:23 +0100

> 	Filename        : draft-ietf-extra-sieve-special-use-01.txt

Submitted a new version of this draft. Not much has changed. The
significant changes are as follows:

- Addresses a comment by Stan Kalisch: refer to the variables extension
in Security Considerations section.
- Addresses a final FIXME item in the Acknowledgements section. It adds
credits for some borrowed text.

The revisions are tagged in the git repository, so you can check the
changes there in more detail.

Regards,

-- 

Stephan Bosch
Senior Developer 

Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: [email-masked]

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

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

---

From: Ned Freed <[email-masked]>
Date: Mon, 08 Jan 2018 08:50:27 -0800 (PST)

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.

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.

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.

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.

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.

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>

The same point about special use mailboxes being in the user's personal
namespace needs to be reiterated in the fileinto discussion in section 4.

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.

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.

That's it for now.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 9 Jan 2018 20:35:13 +0100

Hi Ned,

Thanks for the review!

> This would be quite helpful to implementors, who might otherwise overlook an

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.

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

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

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

> NAMESPACE extension and if it isn't present, fallback to LIST "" would be very

Sorry, I don't understand what you mean.

>                      <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. A reference to the text about fileinto in RFC 5228 is probably in

Good point.

> :create is to make the creation of the mailbox unconditional.

Yeah.

Regards,

Stephan.

-- 
Stephan Bosch
Senior Developer

---

From: Ned Freed <[email-masked]>
Date: Tue, 09 Jan 2018 13:44:08 -0800 (PST)

> Hmm, I am not exactly sure what you mean here. Can you give an example? 

Pretty simple: Where applicable, show the general sequence of IMAP operations
you'd need to perform to implement a given function.

> the other.

That's true of our implementation as well. But that's beside the point - we
to make sure that these things can be implemented over protocol reasonably,
and documenting how its done will help avoid implementation problems.

> Also, IMAP command sequences can only show the actions that

It doesn't have to be the exact sequence.

> the specified special-use flag remains unchanged?

I think that's acceptable.

> Adding/removing

That sounds reasonable.

> mailbox.

Seems reasonable.

> But what would that mean for the mailbox lookup? Are we looking

The convention elsewhere seems pretty clearly to be for it to be an AND rather
than an OR.

> Another question is whether mailboxes with several special-use flags are

Apart from \All, which I would hope is not up to clients to set, I don't see
them as being useful. But I may be missing some use cases, which is why I 
brought it up.

> their mailboxes with pretty much everyone.

It's not a question of lots of people doing it, it's a question of whether or
not you have an optimized way of looking through the entire list of mailboxes
in a deployment. 

Remember that per RFC 6154 section 2, special use attributes are not required
to be user-specific. (Although oddly, they only appear in private metadata.)

> In that case, indeed, it

I'm afraid I have to disagree. Restricting things to the personal
namespace needs to be an allowed implementation option. Frankly, I'm
not all that comfortable with even a MAY on allowing more, because I don't
think the implications of special-use flags on shared folders have
been given any real scrutiny, especially when they are not necessarily
per-user.

At an absolute minimum this is going to require some discussion
in the security considerations. A situation where someone can
create a shared folder, open it up with an ACL, and then gather
up sent mail from a new user is not really acceptable.

> Also, couldn't an account have more than one private namespace?

Indeed they can, and this is why you need to use the NAMESPACE extension
to find them all and then use LIST on each to find all the relevant
special use mailboxes.

And this is a good example of why documenting the IMAP command sequences is a
good idea. Not everyone is going to pick up on the fact that when implementing
this extension over protocol if the NAMESPACE extension is supported you need
to make use of it rather than just assuming that LIST "" * is going to give you
all the relevant mailboxes.

> For

Exactly.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 17 Jan 2018 00:14:49 +0100

Hi Ned,

> It doesn't have to be the exact sequence.

Ok, I'll give that a look.

>> assignments of the involved special-use flag.

Ok, I will make this change.

> The convention elsewhere seems pretty clearly to be for it to be an AND rather

I agree.

> them as being useful. But I may be missing some use cases, which is why I 

Ok.

> not you have an optimized way of looking through the entire list of mailboxes

Right. We have an (optional) list index for that.

> up sent mail from a new user is not really acceptable.

Hmm, I'll look into this when I make a new version.

> all the relevant mailboxes.

Ok.

I hope I have time make a new version by the end of this week. We'll see.

Regards,

-- 
Stephan Bosch
Senior Developer