Support for Internet Message Access Protocol (IMAP) Events in Sieve
draft-ietf-sieve-imap-sieve-09

[Ballot discuss]
Can the document make it clearer that actions like fileinto don't trigger the script associated with the mailbox being filed into? That is, make it clearer that ONLY IMAP events cause these scripts to be called.

There are places where loop prevention is discussed that currently focus only on flag changes. Should they encompass all IMAP events that cause these scripts to be run? (Can a script cause an IMAP COPY to happen)?

[Ballot comment]
Please check example 2 - it should only fire when the flagged flag is set. From a conversation with Barry, the 'not' in the condition may be wrong.

Section 3.4 speaks of a message submission server possibly rejecting a script's submission attempt. Is there anywhere it can point to for advice on how the sieve implementation should let the script user know that happened?

The environment names live in a global space - other extensions might want to put a cause into the environment. Would it be worth the pain to scope the name _this_ extension is adding to this extension ("imapcause" or something like that)?

[Ballot discuss]

This should be easily sorted if there's a real issue (I'm not
sure).

Potential s/mime and openpgp interactions with the redirect
action (3.4) aren't called out, don't they need to be? For
example, if a user has set the UA to sign all messages and a
redirect action is caused because a user moves a message
between mailboxes (or whatever) and the private key is only at
the UA, then some kind of error handling would seem to be
needed. Am I confused (always possible:-) or is there
something missing here? If I'm not confused, then this might
just require text saying "don't do that" or in the very worst
case, maybe a way for the UA to say "I want to sign everthing,
don't do stuff that messes that up," I'm not sure. There may
also be corner-cases with message encryption, or to get into
teeny-weeny corner cases, I guess there'd be issues if a UA
for some reason wanted to DKIM-sign all outbound messages.

[Ballot comment]

- 1.2 makes this sound somewhat experimental, just wondering
if the WG considered that that status might be more
appropriate. Either way, it might be nice if the WG in future
try to get someone to write up an "experiences with
imap-sieve" draft since I can imagine there may be gotchas
discovered during implementtion/testing.

- 2.3.1 could be a little clearer about what happens when the
mailbox has a "/shared/imapsieve/script" metadata entry with a
value of "" (or some script name where no such script exists)
but there is a (global) IMAP metadata entry for
"/shared/imapsieve/script" that names a script. I think the
current text means that no script will be executed in this
case but I'm not 100% sure so clarifying this would seem like
a good thing to do.

[Ballot comment]

  As noted in the Gen-ART Review by Roni Even on 22-Aug-2012, at the
  end of sections 3.7 and 3.8 "acton" should be "action"

[Ballot comment]
I have no objection to the publication of this document. Please
consider the following Comments.

---

Section 2.1

  Only one "imapsieve" capability string, specifying one sieveurl-
  server, can be present.

Are you sure? Or do you mean "More than one "imapsieve" capability
string MUST NOT be present"? And then a description of how to process
the error case.

---
                                                                       
Section 2.2.4 (see also 3.8)

  In a server that advertises "imapsieve", messages whose flags are
  changed in any way (except as explained in the next sentence) MUST
  trigger the execution of a Sieve script, subject to the settings
  defined through Metadata.  The exception is that in order to avoid
  script loops, flag changes that are made as a result of a script that
  was itself invoked because of flag changes SHOULD NOT result in
  another script invocation.  In any case, implementations MUST take
  steps to avoid such loops.

Yes, the script recursion or loop is to be avoided.
But isn't what you have here too strict?
Might you not have a script that reacts to a flag (X) that is set by a
command. That script sets another flag (Y). Then you want a script that
reacts to flag (Y) being set.

I think you probably only need that a script MUST NOT be invoked more
than once in the sequence of events following a "top-level" event
(presumably a command or "cause" in the language of 4.3).

Noting that 2.3.1 has:
  Only one Sieve script may currently be defined per mailbox,
I wonder whether this debate is moot.

---

Section 2.3.1

  Support for IMAP events in Sieve requires support for IMAP Metadata
  [RFC5464] as well, since the latter is used to associate scripts with
  IMAP mailboxes.

Want to play with that so it is in 2119 language?

---

Section 3.3

  If a keep action is NOT also in effect, the original message is then
  marked with the \Deleted flag (and a flag-change Sieve script is NOT
  invoked). 

I don't think the emphasis of uppercase "NOT" is needed.

We find similar text in 3.4 and 3.5.

---

Section 3.3 (this paragraph is having a bad day)
 
  The implementation MAY then expunge the original message
  (WITHOUT expunging other messages in the mailbox), or it MAY choose
  to have expunges batched, or done by a user.

I find this ambiguous. I cannot tell whether one of the three actions
MUST be selected, or whether each action is OPTIONAL (and mutually
exclusive).

We find similar text in 3.4 and 3.5.

---

3.11

  Future extensions that are specifically designed to respond to
  delivery of a new email message will likewise not be applicable to
  this extension.

This is fine, but I wonder whether you want to move this text to a new
subsection "3.12 Future Seive Actions".

In that section, I think you also want to require that new
specifications of Seive actions must specifiy their interaction with
the function defined in this document.

IANA has reviewed draft-ietf-sieve-imap-sieve-06 and has the following comments:

IANA understands that, upon approval of this document, there are five actions
which IANA must complete.

First in the IMAP 4 Capabilities subregistry of the Internet Message Access
Protocol (IMAP) 4 Capabilities Registry located at:

http://www.iana.org/assignments/imap4-capabilities/imap4-capabilities.xml

A new capability will be registered as follows

Capability Name: IMAPSIEVE=
Reference: [ RFC-to-be ]

Second, in the Sieve Extensions registry located at:

http://www.iana.org/assignments/sieve-extensions/sieve-extensions.xml

a new Sieve Extension will be registered as follows:

Capability name: imapsieve
Description: Add Sieve processing for IMAP events.
Reference: [ RFC-to-be ]
Contact address: Sieve mailing list

Third, in the Sieve Environment Items registry located at:

http://www.iana.org/assignments/sieve-environment-items/sieve-environment-items.xml

five new Sieve Environment Items are to be registered as follows:

1st Item:

Capability name: cause
Description: The name of the action that caused the script to be invoked. Its
value is one of the following:
o APPEND (for invocations resulting from APPEND or MULTIAPPEND)
o COPY (for invocations resulting from COPY)
o FLAG (for invocations resulting from flag changes)
Reference: [ RFC-to-be ]
Contact address: Sieve mailing list

2nd Item:

Capability name: mailbox
Description: The name of the mailbox that the affected message is in, in the
case of existing messages, or is targeted to be stored into, in the case of new
messages. The value of this item is fixed when the script begins, and, in
particular, MUST NOT change as a result of any action, such as "fileinto".
Reference: [ RFC-to-be ]
Contact address: Sieve mailing list

3rd Item:

Capability name: changedflags
Description: If the script was invoked because of flag changes to an existing
message, this contains the name(s) of the flag(s) that have changed. Otherwise,
the value of this item MUST be the empty string.
Reference: [ RFC-to-be ]
Contact address: Sieve mailing list

4th Item:

Capability name: imapuser
Description: The identity (IMAP login ID) of the IMAP user that caused the action.
Reference: [ RFC-to-be ]
Contact address: Sieve mailing list

5th Item:

Capability name: imapemail
Description: The primary email address of the IMAP user that caused the action
(the user identified by "imapuser").
Reference: [ RFC-to-be ]
Contact address: Sieve mailing list

Fourth, in the IMAP METADATA Mailbox Entry subregistry in the IMAP METADATA
Entry Registrations registry located at:

http://www.iana.org/assignments/imap-metadata/imap-metadata.xml

a new registration will be made as follows:

Name: /shared/imapsieve/script
Content-type: text/plain; charset=utf-8
Reference: [ RFC-to-be ]

Fifth, in the IMAP METADATA Server Entry Registry subregistry of the IMAP
METADATA Entry Registrations registry located at:

http://www.iana.org/assignments/imap-metadata/imap-metadata.xml

a new registration will be made as follows:

Name: /shared/imapsieve/script
Content-type: text/plain; charset=utf-8
Reference: [ RFC-to-be ]

IANA understands that these five actions are the only ones required
to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until
the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Support for Internet Message Access Protocol (IMAP) Events in Sieve) to Proposed Standard


The IESG has received a request from the Sieve Mail Filtering Language WG
(sieve) to consider the following document:
- 'Support for Internet Message Access Protocol (IMAP) Events in Sieve'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-08-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Sieve defines an email filtering language that can, in principle,
  plug into any point in the processing of an email message.  As
  defined in the base specification, it plugs into mail delivery.  This
  document defines how Sieve can plug into points in the IMAP protocol
  where messages are created or changed, adding the option of user-
  defined or installation-defined filtering (or, with Sieve extensions,
  features such as notifications).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sieve-imap-sieve/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sieve-imap-sieve/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

  This document defines how the Sieve email filtering language  can plug
  into points in the IMAP protocol where messages are created or changed,
  adding the option of user-defined or installation-defined filtering (or,
  with Sieve extensions, features such as notifications).

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  This document originated from the Lemonade WG and was initially submitted
  back in 2005. In 2010 it was adopted by the SIEVE WG as Lemonade was
  closed. Since that time there have been several revision of the document
  prompted by mailing list discussions and face-to-face meetings. Note that
  many of the participants in the SIEVE WG are also IMAP "experts" so the
  interactions between SIEVE and IMAP have been fully covered. Whilst many
  people have reviewed and contributed to this document over its lifetime,
  the recent working group last call only garnered a few responses (all
  positive and supporting publication). That said, there has not been any
  significant controversy surrounding this document, and in the Chairs'
  opinion there is consensus to publish it.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  There are no known implementations of this protocol to date. A number of
  vendors have indicated interest in it, with at least one stating they will
  start work on that soon.
 
Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Document Shepherd: Cyrus Daboo
  AD: Pete Resnick

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have reviewed this document and have found no nits or issues.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  There were only a few reviews completed in the recent last call, however,
  the document has had many reviews over the course of its lifetime.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No special review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  There has been some discussion as to the intended status of this document
  - in particular whether it ought to be classified as Experimental until at
  least one or more implementations have been completed. The primary reason
  for suggesting this is that there could be complex interactions within the
  IMAP protocol that are not obvious (mostly due to the complex nature of
  IMAP itself). That said, many of the SIEVE reviewers are IMAP server
  implementors and thus well aware of the complexities of IMAP extensions.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  The author has confirmed that there is no known IPR associated with this
  document and that it is in full compliance with BCPs 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR disclosures filed for this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Recent consensus comes from a few key working group participants, mostly
  vendors who expressed interest in developing their own implementations.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  There has not been any discontent voiced by anyone.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No ID nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

  References are correctly identified.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative and informative references are to published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

There are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any other.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document registers new items in both IMAP and SIEVE registries. Those
  registrations have been reviewed and all appear to be correct, complete
  and clear.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.


  There is only one new formal syntax item: ABNF for the new IMAP
  capability, and that is correct.