2.1.10 Sieve Mail Filtering Language (sieve)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-11


Cyrus Daboo <cyrus@daboo.name>
Alexey Melnikov <alexey.melnikov@isode.com>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>

Applications Area Advisor:

Scott Hollenbeck <shollenbeck@verisign.com>

Mailing Lists:

General Discussion: ietf-mta-filters@imc.org
To Subscribe: ietf-mta-filters-request@imc.org
In Body: body=subscribe
Archive: http://www.imc.org/ietf-mta-filters/mail-archive/

Description of Working Group:

The sieve mail filtering language specified in RFC 3028 has now been
implemented in a wide variety of user agents (UAs), mail delivery
agents (MDAs), and mail transfer agents (MTAs). Several extensions have
been specified (RFCs 3431, 3598, 3685, 3894) and have also been widely
implemented. Several additional sieve extensions have been defined in
various internet-drafts.

All of these documents are individual submissions; up to this point
work on sieve has been done informally and not under the auspices of
any IETF working group.

The sieve working group is being chartered to:

(1) Revise the base sieve specification, RFC 3028, with the intention
of moving it to draft standard. Substantive additions or revisions to
the base specification are out of scope of this working group. However,
the need to loosen current restrictions on side effects of tests as
as the need for a normative reference to the newly-defined comparators
registry may necessitate a recycle at proposed.

(2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598),
spamtest/virustest (RFC 3685), and copy (RFC 3894) extension
specifications, again with the intention of making a move to
draft standard possible. It may be necessary to recycle some or all
of these documents at proposed, depending on the scope of any changes.

(3) Finalize and publish the sieve extensions as proposed standards:

(a) Variables (draft-homme-sieve-variables-04.txt)
(b) Vacation action (draft-showalter-sieve-vacation-05.txt)
(c) Message body tests (draft-degener-sieve-body-02.txt)
(d) Regular expressions (draft-murchison-sieve-regex-07.txt)
(e) MIME part tests (draft-daboo-sieve-mime-00.txt)
(f) Notification action (draft-martin-sieve-notify-02.txt)
(g) IMAP flags (draft-melnikov-sieve-imapflags-06.txt)
(h) Header editing actions (draft-degener-sieve-editheader-01.txt)
(i) Reject before delivery (draft-elvey-refuse-sieve-01.txt)

Additional drafts may be added this list, but only via a charter
revision. There must also be demonstrable willingness in the sieve
development community to actually implement a given extension before
it can be added to this charter.

Some aspects of sieve have complex internationalization issues; the
working group will seek out internationalization expertise as needed
to complete its work.

Goals and Milestones:

Done  Submit revised variables draft.
Done  Submit revised vacation draft.
Done  WG last call for variables draft.
Done  Initial submission of RFC 3028bis.
Done  WG last call for RFC 3028bis.
Done  Initial submission of revised relational draft.
Done  Initial submission of revised subaddress draft.
Done  Initial submission of revised spamtest/virustest draft.
Done  Submit revised editheader draft.
Done  Submit revised imapflags draft.
Done  WG last call of revised subaddress draft.
Done  Submit revised body test draft.
Done  WG last call for editheader draft.
Done  Submit revised reject before delivery draft.
Done  WG last call for body test draft.
Aug 2005  Submit editheader draft to IESG
Done  WG last call for refuse draft
Done  WG last call of revised spamtest draft
Done  Submit variables draft to IESG
Sep 2005  Submit revised loop draft
Sep 2005  Submit revised spamtest draft to IESG
Sep 2005  Submit 3028bis to IESG
Done  Submit revised notification action draft
Done  WG last call of revised relational draft
Done  WG last call for imap-flags draft
Done  WG last call for vacation draft
Oct 2005  Submit revised regex draft
Oct 2005  WG last call of revised subaddress draft
Oct 2005  Submit revised relational draft to IESG
Oct 2005  Submit imapflags draft to IESG
Oct 2005  Submit refuse draft to IESG
Oct 2005  Submit vacation draft to IESG
Nov 2005  Submit revised subaddress draft to IESG
Nov 2005  Submit body test draft to IESG
Nov 2005  3028bis interop report
Nov 2005  WG last call of regex subaddress draft
Nov 2005  WG last call for loop draft
Nov 2005  WG last call for notification action draft
Jan 2006  Submit loop draft to IESG
Jan 2006  Submit regex action draft to IESG
Feb 2006  Submit notification action draft to IESG


  • draft-ietf-sieve-variables-07.txt
  • draft-ietf-sieve-spamtestbis-01.txt
  • draft-ietf-sieve-body-02.txt
  • draft-ietf-sieve-editheader-03.txt
  • draft-ietf-sieve-imapflags-02.txt
  • draft-ietf-sieve-rfc3598bis-01.txt
  • draft-ietf-sieve-3431bis-01.txt
  • draft-ietf-sieve-vacation-04.txt
  • draft-ietf-sieve-3028bis-04.txt
  • draft-ietf-sieve-refuse-reject-00.txt
  • draft-ietf-sieve-notify-01.txt

    No Request For Comments

    Current Meeting Report

    Sieve WG minutes, IETF 64 The meeting has started with a quick review of documents ready for IESG writeup (or nearly ready). The vacation extension has two minor outstanding issues: clarification on how hash should be constructed when some tagged arguments like :subject are omitted; default auto reply subject when the original message had no subject.
    Scott Hollenbeck has asked what was the resolution on "multiple executed vacation actions in a script". Alexey has replied that after a long discussion on the mailing list there was no change in the behaviour of the vacation action.

    Spamtest, imap flags, relational extensions are ready for IESG writeup.
    Edit header needs to say something about stripping leading/trailing spaces, but it is done otherwise. Barry has mentioned that the relational draft got bounced by Internet Draft editor, resubmitted.

    The body draft is waiting for resolution on comparators in the base document, but otherwise is done. Once comparator issues are addressed, the body can be revised in a couple of days.

    IESG has raised a discuss comment on Sieve variables: ":lower" and ":upper" were underspecified, the vague text about using comparators is not good enough to implement. Two ways to solve the issue:
    a). just say that :lower and :upper only affect US-ASCII subset, other characters are not affected;
    b). do stringprep like approach (full Unicode).

    Several people are in favour of US-ASCII-only approach, which is perceived to be quicker and will satisfy IESG. 6 people in the room are in favour of US-ASCII-only approach, plus some more in jabber. No people objecting. Need to confirm the decision on the mailing list.

    Alexey has expressed his desire to get resolution on comparators by the end of November.

    There are several open issues with the base document:
    1). ABNF for match types (done)
    2). Matching uses glob characters, but is not fully specified in the document. Need to clarify that matching depends on substring operation of collation.
    3). Base spec and variables: Clarify that when matching is done then pieces of the original value are returned in match variables, not the result of applying the selected comparator.
    4). Stripping leading/trailing whitespaces in the relational draft - text needs to be moved to the base spec.

    Short discussion about Barry's proposal to string leading/trailing whitespaces any time a header field is touched. No objections from people who've seen the new text (Alexey, Philip). Barry will send the text to the mailing list.

    Philip has promised a new revision of base document by November 18th.

    Alexey has talked about the notification draft. Received many comments, much more than expected :-). Separate documents will be created for different Sieve notification methods.

    Alexey & Barry will co-edit the main notification document. Barry & Michael will co-edit SMTP notification draft. Alexey will do XMPP, but need a co-editor. Peter Saint-Andre has agreed to co-edit. No editor for SMS notifications, but Stephane might be working on the drafts.

    Discussion about SMS has followed: what does it mean to implement SMS notifications, what kind of payload is used (do we need multiple different ones?), what kind of parameters are needed, how payload is generated and delivered, etc. Ray Cromwell has mentioned that there are a lot of requests to limit number of SMS generated per day, in order to limit cost. Discussion on whether URIs are the best way to specify notification methods and whether a generic Lemonade notification method should be defined. Discussion on complexity of different SMS gateways - different gateways need different parameters, in most cases users of Sieve scripts wouldn't care about such parameters. Consensus from the group that it is too premature to discuss details until we see a first revision of the SMS notification draft.

    A detailed discussion about current issues in the base Sieve Notifications document has followed. Alexey has presented open issues.
    1) Many people have requested to remove "denotify", it will be removed in the next revision, as there were no requests to keep it.
    2) Comments from Jabber that "mailto" should be a mandatory to implement notification method, as Sieve engines already able to send mail.
    3) Need a way to extract textual message body. Kjetil's suggestion will not work, as "body" extension explicitly prohibits setting variables on body test. Barry has mentioned that we need the ability to send the whole body as well as first starting bytes.
    Alexey has asked Philip if "body" can be changed to relax the restriction? Philip said "no", "body" is already widely deployed. If body extraction is only useful for Sieve notification, we can add it to the Sieve notifications document. Otherwise we need a separate extension. Decision to bring the issue to the mailing list.
    4) Can notification method parameter be optional (i.e. if not present - use site specific default. If no default - noop)?
    Barry: keep it optional; if there is no default - "notify" action is a noop. No objections from the room.
    5) What should happen if an unrecognized notification method is specified in the "notify" action? Error or ignored?
    Alexey: scripts can't have "require" statements for notification methods, because a notification method can be specified as a variable, who's value can be obtained from an external service.
    Do we need to add a test "if a notification method is available"?  One use case is when notification method is stored as an IMAP server annotation. Agreement to add the test.

    Once the room has agreed to add the test for available notification methods, the room has reached the agreement to make an unrecognised notification method an error.

    Cyrus (in Jabber) suggested to add ManageSieve protocol capability to advertise supported notification methods. The room agrees.
    Cyrus suggested Sieve presence extension, so notification types can be customized based on presence and time of day. (The latter is already possible using Ned's time extension).
    6) Add :from to the "notify" action? It is useful for all envisioned notification mechanisms, but it might not be generally useful. However a notification method is free to ignore the parameter. No objection from the room.
    7) Ned (in Jabber) is bringing another issue: URI formats need URI "percent encoding" for different values, inserting variables into an URI will not work. He would like to avoid options, but can't see a way to do without them.
    8) Do we want to allow suppression of identical notifications?
    Greg: the answer might depend on whether we need to provide confidentiality. No consensus was reached, so the discussion should continue of the mailing list.

    Discussion about status of refuse/reject. Most people don't know the difference between MDNs, DSNs and protocol-level-refusal. Would script writer really care? Consensus from the room that script writers wouldn't care, so refuse and reject can be merged into a single action ("reject"). Confirm the decision on the mailing list.
    Cyrus has pointed out that sysadmins care about protocol-level refusals versa DSNs, however the draft is already recommending protocol level refusals whenever possible.
    Cyrus said that non-ascii text in the reject action can't be sent as a protocol level refusal. Ned added that if non-ascii text results in DSNs, sysadmins will disallow users to use the reject action. The draft needs more work in this area.
    Alexey and Philip will discuss if it make sense to put the new reject back into the base Sieve document.

    WG has covered the main agenda items. Barry will publish a new individual submission that describes how Sieve can be executed in IMAP store on different events, such as flag changes, message deletion, etc. He believes that this will require a small extension to Sieve and a detailed description on how this would work on IMAP side.

    Discussion of the main documents has concluded, so the room has discussed other Sieve related issues.

    Nobody wanted to talk about index or include extensions.

    Cyrus will address scoping issue and he hopes that this is going to be independent of the variables draft, i.e. it will be an extension to variables.

    Philip has promised a new revision of the base document on November 18th.

    Dave Cridland (in jabber) has asked about outcome of the comparator discussion. Philip did a quick review of the discussion that happened during the IMAPEXT meeting few days earlier. Match type is built on comparator's substring matching. <?> matches a single character as defined by the comparator (e.g. octet or sequence of UTF-8 octets corresponding to a single Unicode character).

    Alexey has asked the WG and IMAPEXT chairs if the collation (comparator) draft should be done in the Sieve WG, as it is moving much faster than IMAPEXT. The answer was no, as most people are participating in both working groups. Chairs of both WGs should nag authors of the collation draft to move it forward quicker.

    Variables need to be updated to say that matching with glob characters returns pieces of the original string, i.e. before any comparator was applied. Alexey wants to send the variables document back to IESG asap.


    Sieve WG Status