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 |