Skip to main content

Sieve Email Filtering: Imap4flags Extension
RFC 5232

Revision differences

Document history

Date Rev. By Action
2020-01-21
05 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
05 (System)
Received changes through RFC Editor sync (changed abstract to 'Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) …
Received changes through RFC Editor sync (changed abstract to 'Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent.

This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]')
2017-02-28
05 (System) Received changes through RFC Editor sync (added Errata tag)
2015-10-14
05 (System) Notify list changed from sieve-chairs@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2008-01-28
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2008-01-28
05 Amy Vezza [Note]: 'RFC 5232' added by Amy Vezza
2008-01-16
05 (System) RFC published
2006-11-08
05 (System) Request for Early review by SECDIR Completed. Reviewer: Rob Austein.
2006-10-12
05 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2006-10-12
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-09-24
05 (System) IANA Action state changed to In Progress from Waiting on RFC Editor
2006-07-25
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-07-21
05 Amy Vezza IESG state changed to Approved-announcement sent
2006-07-21
05 Amy Vezza IESG has approved the document
2006-07-21
05 Amy Vezza Closed "Approve" ballot
2006-05-15
05 Lisa Dusseault State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lisa Dusseault
2006-05-13
05 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2006-05-12
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-05-12
05 (System) New version available: draft-ietf-sieve-imapflags-05.txt
2006-05-12
05 (System) Removed from agenda for telechat - 2006-05-11
2006-05-11
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-05-11
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by IESG Secretary
2006-05-11
05 Jari Arkko [Ballot comment]
> The extension decribed in this document doesn't change the implicit
> keep (see section 2.10.2 of [SIEVE]).

s/decribed/described/
2006-05-11
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-05-11
05 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-05-10
05 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2006-05-10
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon
2006-05-10
05 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2006-05-10
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-05-10
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-05-09
05 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Undefined by Cullen Jennings
2006-05-09
05 Cullen Jennings
[Ballot comment]
It would benefit from more use of normative language. For example, I have no idea if you actually have to implement "hasflag" or …
[Ballot comment]
It would benefit from more use of normative language. For example, I have no idea if you actually have to implement "hasflag" or if it is optional.

I find this document very hard to understand or follow. It lacks a coherent overview of the environment it fits into and it reads half way like an programmer guide instead of a specification of all the details an implementer needs to know.

The document does not pass idnits (but the important stuff is OK).
2006-05-09
05 Cullen Jennings [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings
2006-05-09
05 Sam Hartman
[Ballot comment]
I did not find this specification very clear.  In particular, the
internal variable was quite mystifying.  I eventually figured out what
it is …
[Ballot comment]
I did not find this specification very clear.  In particular, the
internal variable was quite mystifying.  I eventually figured out what
it is for, but there is not a description of the intuitive use of the
internal variable.  The internal variable seems to act as a default
for the flags that will be set on a message that is kept or filed.
Nothing actually seems to say this though.  Also calling it the
internal variable is confusing.  However this is non-blocking.
2006-05-09
05 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2006-05-09
05 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2006-05-09
05 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2006-05-09
05 Magnus Westerlund [Ballot discuss]
2006-05-09
05 Brian Carpenter
[Ballot comment]
Nits from gen-art review by Eric Gray:

Section 3, third paragraph, last sentence: "MUST cause a runtime
error" as opposed to "MUST cause …
[Ballot comment]
Nits from gen-art review by Eric Gray:

Section 3, third paragraph, last sentence: "MUST cause a runtime
error" as opposed to "MUST cause runtime error"...

Section 6, first paragraph, last line: "side effect" as opposed to "side affect"...
2006-05-09
05 Brian Carpenter
[Ballot discuss]
In the third paragraph of section 2.1:

"The Sieve interpreter SHOULD check the list of flags for validity
as described by [IMAP] ABNF. …
[Ballot discuss]
In the third paragraph of section 2.1:

"The Sieve interpreter SHOULD check the list of flags for validity
as described by [IMAP] ABNF. In particular non-ASCII characters
are not allowed in flag names. However spaces MUST be always
allowed."

This last sentence makes no sense since according to [IMAP],
flags are atomic names containing no white space.

(based on gen-art review by Eric Gray)
2006-05-09
05 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter
2006-05-09
05 Magnus Westerlund
[Ballot discuss]
Section 3:
  If the SIEVE interpreter doesn't support the "variables" extension
  [VARIABLES], the presence of the variable name parameter MUST cause …
[Ballot discuss]
Section 3:
  If the SIEVE interpreter doesn't support the "variables" extension
  [VARIABLES], the presence of the variable name parameter MUST cause
  runtime error.

Putting normative requirement on an implementation to do an action when it does
not support a feature is not possible. This should be a informative statement that
points on base spec that define this behavior.

Example of acceptable statement:

  If the SIEVE interpreter doesn't support the "variables" extension
  [VARIABLES], the presence of the variable name parameter will cause
  runtime error, see section X [RFC YYYY].
2006-05-09
05 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-05-08
05 Russ Housley
[Ballot comment]
The Abstract should not include the [IMAP] reference.  Minor rewrite
  is needed.

  Section 2 should contain the standard sentence from RFC …
[Ballot comment]
The Abstract should not include the [IMAP] reference.  Minor rewrite
  is needed.

  Section 2 should contain the standard sentence from RFC 2119.
2006-05-08
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2006-05-08
05 Lisa Dusseault
Alexey has a couple answers for the GEN-ART review which I'll try to summarize here:
- He explained to the reviewer how IMAP flags/keywords MUST …
Alexey has a couple answers for the GEN-ART review which I'll try to summarize here:
- He explained to the reviewer how IMAP flags/keywords MUST NOT contain spaces according to RFC3501
- explained that "forward" does match with "gnus-forward" as a case-insensitive substring match
- confirmed that any alpha-numeric value may be used as a keyword name
- acknowledged the nits to be fixed.
2006-05-06
05 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault
2006-05-06
05 Lisa Dusseault Ballot has been issued by Lisa Dusseault
2006-05-06
05 Lisa Dusseault Created "Approve" ballot
2006-05-06
05 Lisa Dusseault State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lisa Dusseault
2006-05-06
05 Lisa Dusseault Placed on agenda for telechat - 2006-05-11 by Lisa Dusseault
2006-05-04
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-04-24
05 Michelle Cotton
IANA Last Call Comments:

Upon approval of this document the IANA will register a new Sieve extension for imap4flags
in the following registry:
http://www.iana.org/assignments/sieve-extensions. …
IANA Last Call Comments:

Upon approval of this document the IANA will register a new Sieve extension for imap4flags
in the following registry:
http://www.iana.org/assignments/sieve-extensions.

We understand this to be the only IANA Action.
2006-04-24
05 (System) IANA Action state changed to In Progress
2006-04-20
05 Amy Vezza Last call sent
2006-04-20
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-04-19
05 Lisa Dusseault Last Call was requested by Lisa Dusseault
2006-04-19
05 Lisa Dusseault State Changes to Last Call Requested from Publication Requested by Lisa Dusseault
2006-04-19
05 (System) Ballot writeup text was added
2006-04-19
05 (System) Last call text was added
2006-04-19
05 (System) Ballot approval text was added
2006-04-19
05 Lisa Dusseault Intended Status has been changed to Proposed Standard from None
2006-04-19
05 Lisa Dusseault
SIEVE imap-flags extension WG Chairs Write-up for IESG

Questionnaire:

1. Have the chairs personally reviewed this version of the ID and do  they believe this …
SIEVE imap-flags extension WG Chairs Write-up for IESG

Questionnaire:

1. Have the chairs personally reviewed this version of the ID and do  they believe this ID is sufficiently baked to forward to the IESG for publication?

Yes and yes.

2. Has the document had adequate review from both key WG members and key non-WG members?

Yes for WG members.

Do you have any concerns about the depth or breadth  of the reviews that have been performed?

No.

3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational  complexity, someone familiar with AAA, etc.)?

No concerns along those lines.

4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps  you are uncomfortable with certain parts of the document, or whether  there really is a need for it, etc., but at the same time these  issues have been discussed in the WG and the WG has indicated it  wishes to advance the document anyway.

No concerns with this document.

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

There is strong WG consensus behind this.

6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about.

No.

7. Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html).

Yes.

8. Does the document a) split references into normative/informative

Yes, though there are no informative references.

b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note:  the RFC editor will not publish an RFC with normative references to  IDs, it will delay publication until all such IDs are also ready for  publication as RFCs.)

There are three normative references to an I-D. The normative references are to the variables ande relational documents which are in the RFC Editor queue, and the SIEVE base spec revision which is currently being worked on in the WG.

9. For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections:


Technical Summary

The SIEVE imap4flags extension provides the ability for a SIEVE script to set flags on messages as they are delivered into an IMAP message store.

The extension defines a number of new actions, and modifies two existing actions to allow the setting of flags. It can be used in the presence of the variables extension, or without it.

The draft has a description of how interactions with other SIEVE extensions/actions are handled.

There is a security considerations section.

This draft is being submitted for Proposed Standard.

Working Group Summary

The imap4flags extension was originally submitted as an individual contribution several years ago. It has had minor changes since then, mostly in relation to its interaction with the variable extension. There are now several deployed implementations of this specification. Working group last call was issued in September 2005 and a number of minor clarifications and errors were fixed based on comments, and subsequent post-last-call comments.

Protocol Quality

Many implementations of this extension have already been developed and deployed. Most participants are eager to see this spec published as an RFC.

There were at least 6 individuals (not including WG chairs) who posted comments during or post WG last call, and who indicated approval of the spec, with the WGLC changes included.

The SIEVE WG has reviewed the draft and discussed it at several meetings.
Last-call (and post last-call) reviews included:
- Philip Guenther
- David Cridland
- Aaron Stone
- Ken Murchison
- Ned Freed
2006-04-19
05 Lisa Dusseault Draft Added by Lisa Dusseault in state Publication Requested
2006-02-02
04 (System) New version available: draft-ietf-sieve-imapflags-04.txt
2006-01-20
03 (System) New version available: draft-ietf-sieve-imapflags-03.txt
2005-10-18
02 (System) New version available: draft-ietf-sieve-imapflags-02.txt
2005-05-13
01 (System) New version available: draft-ietf-sieve-imapflags-01.txt
2005-02-08
00 (System) New version available: draft-ietf-sieve-imapflags-00.txt