draft-ietf-sieve-editheader-10.txt   draft-ietf-sieve-editheader-11.txt 
Network Working Group Jutta Degener Network Working Group Jutta Degener
Internet Draft Philip Guenther Internet Draft Philip Guenther
Intended status: Standards Track Sendmail, Inc. Intended status: Standards Track Sendmail, Inc.
Expires: August 2008 February 2008
Sieve Email Filtering: Editheader Extension Sieve Email Filtering: Editheader Extension
draft-ietf-sieve-editheader-10.txt draft-ietf-sieve-editheader-11.txt
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 5 skipping to change at page 2, line 5
filtering language that add and delete email header fields. filtering language that add and delete email header fields.
1. Introduction 1. Introduction
Email header fields are a flexible and easy to understand means Email header fields are a flexible and easy to understand means
of communication between email processors. of communication between email processors.
This extension enables sieve scripts to interact with other This extension enables sieve scripts to interact with other
components that consume or produce header fields by allowing components that consume or produce header fields by allowing
the script to delete and add header fields. the script to delete and add header fields.
2. Conventions used. 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
Conventions for notations are as in [SIEVE] section 1.1, including Conventions for notations are as in [SIEVE] section 1.1, including
use of the "Usage:" label for the definition of action and tagged use of the "Usage:" label for the definition of action and tagged
arguments syntax. arguments syntax.
The term "header field" is used here as in [IMAIL] to mean a The term "header field" is used here as in [IMAIL] to mean a
logical line of an email message header. logical line of an email message header.
3. Capability Identifier
The capability string associated with the extension defined in The capability string associated with the extension defined in
this document is "editheader". this document is "editheader".
3. Action addheader 4. Action addheader
Usage: "addheader" [":last"] <field-name: string> <value: string> Usage: "addheader" [":last"] <field-name: string> <value: string>
The addheader action adds a header field to the existing message The addheader action adds a header field to the existing message
header. If the field-name is not a valid 7-bit US-ASCII header header. If the field-name is not a valid 7-bit US-ASCII header
field name as described by the [IMAIL] "field-name" nonterminal field name as described by the [IMAIL] "field-name" nonterminal
syntax element, the implementation MUST flag an error. The syntax element, the implementation MUST flag an error. The
addheader action does not affect Sieve's implicit keep. addheader action does not affect Sieve's implicit keep.
If the specified field value does not match the RFC 2822 If the specified field value does not match the RFC 2822
skipping to change at page 3, line 5 skipping to change at page 3, line 14
Example: Example:
/* Don't redirect if we already redirected */ /* Don't redirect if we already redirected */
if not header :contains "X-Sieve-Filtered" if not header :contains "X-Sieve-Filtered"
["<kim@job.example.com>", "<kim@home.example.com>"] ["<kim@job.example.com>", "<kim@home.example.com>"]
{ {
addheader "X-Sieve-Filtered" "<kim@job.example.com>"; addheader "X-Sieve-Filtered" "<kim@job.example.com>";
redirect "kim@home.example.com"; redirect "kim@home.example.com";
} }
4. Action deleteheader 5. Action deleteheader
Usage: "deleteheader" [":index" <fieldno: number> [":last"]] Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
[COMPARATOR] [MATCH-TYPE] [COMPARATOR] [MATCH-TYPE]
<field-name: string> <field-name: string>
[<value-patterns: string-list>] [<value-patterns: string-list>]
By default, the deleteheader action deletes all occurrences of By default, the deleteheader action deletes all occurrences of
the named header field. The deleteheader action does not affect the named header field. The deleteheader action does not affect
Sieve's implicit keep. Sieve's implicit keep.
skipping to change at page 3, line 36 skipping to change at page 3, line 45
field values is ignored. If no value-patterns are specified field values is ignored. If no value-patterns are specified
then the comparator and match-type options are silently ignored. then the comparator and match-type options are silently ignored.
If :index <fieldno> is specified, the attempts to match a value If :index <fieldno> is specified, the attempts to match a value
are limited to the <fieldno> occurrence of the named header are limited to the <fieldno> occurrence of the named header
field, beginning at 1, the first named header field. If :last field, beginning at 1, the first named header field. If :last
is specified, the count is backwards; 1 denotes the last named is specified, the count is backwards; 1 denotes the last named
header field, 2 the second to last, and so on. The counting header field, 2 the second to last, and so on. The counting
happens before the <value-patterns> match, if any. For example: happens before the <value-patterns> match, if any. For example:
deleteheader :index 2 :contains "Received" "via carrier-pigeon" deleteheader :index 1 :contains "Delivered-To"
"bob@example.com";
deletes the second "Received" header field if it contains deletes the first "Delivered-To" header field if it contains the
the string "via carrier-pigeon" (not the second "Received" field string "bob@example.com" (not the first "Delivered-To" field
that contains "via carrier-pigeon"). that contains "bob@example.com").
It is not an error if no header fields match the conditions in It is not an error if no header fields match the conditions in
the deleteheader action or if the :index argument is greater the deleteheader action or if the :index argument is greater
than the number of named header fields. than the number of named header fields.
The implementation MUST flag an error if :last is specified The implementation MUST flag an error if :last is specified
without also specifying :index. without also specifying :index.
5. Implementation Limitations on Changes 6. Implementation Limitations on Changes
As a matter of local policy, implementations MAY limit which As a matter of local policy, implementations MAY limit which
header fields may be deleted and which header fields may be header fields may be deleted and which header fields may be
added. However, implementations MUST NOT permit attempts to added. However, implementations MUST NOT permit attempts to
delete "Received" header fields and MUST permit both addition delete "Received" header fields and MUST permit both addition
and deletion of the "Subject" header field. and deletion of the "Subject" header field.
If a script tries to make a change that isn't permitted, the If a script tries to make a change that isn't permitted, the
attempt MUST be silently ignored. attempt MUST be silently ignored.
6. Interaction with Other Sieve Extensions 7. Interaction with Other Sieve Extensions
Actions that generate [MDN], [DSN], or similar disposition Actions that generate [MDN], [DSN], or similar disposition
messages MUST do so using the original, unmodified message header. messages MUST do so using the original, unmodified message header.
Similarly, if an error terminates processing of the script, the Similarly, if an error terminates processing of the script, the
original message header MUST be used when doing the implicit original message header MUST be used when doing the implicit
keep required by [SIEVE] section 2.10.6. keep required by [SIEVE] section 2.10.6.
With the exception of the special handling of redirect and With the exception of the special handling of redirect and
"Received" header fields described above, all other actions that "Received" header fields described above, all other actions that
store, send, or alter the message MUST do so with the current set store, send, or alter the message MUST do so with the current set
skipping to change at page 5, line 34 skipping to change at page 6, line 5
keep; keep;
MUST only file one message. It is up to the implementation MUST only file one message. It is up to the implementation
to pick which of the redundant "fileinto" or "keep" actions is to pick which of the redundant "fileinto" or "keep" actions is
executed, and which ones are ignored. executed, and which ones are ignored.
The "implicit keep" is thought to be executed at the end of The "implicit keep" is thought to be executed at the end of
the script, after the headers have been modified. (However, the script, after the headers have been modified. (However,
a canceled "implicit keep" remains canceled.) a canceled "implicit keep" remains canceled.)
7. IANA Considerations 8. IANA Considerations
The following template specifies the IANA registration of the Sieve The following template specifies the IANA registration of the Sieve
extension specified in this document: extension specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
Capability name: editheader Capability name: editheader
Description: adds actions 'addheader' and 'deleteheader' Description: Adds actions 'addheader' and 'deleteheader'
that modify the header of the message being that modify the header of the message being
processed processed
RFC number: this RFC RFC number: this RFC
Contact Address: Jutta Degener <jutta@pobox.com> Contact Address: Jutta Degener <jutta@pobox.com>
This information should be added to the list of sieve extensions This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
8. Security Considerations 9. Security Considerations
Someone with write access to a user's script storage may use this Someone with write access to a user's script storage may use this
extension to generate headers that a user would otherwise be extension to generate headers that a user would otherwise be
shielded from (e.g., by a gateway MTA that removes them). shielded from (e.g., by a gateway MTA that removes them).
A sieve filter that removes header fields may unwisely destroy A sieve filter that removes header fields may unwisely destroy
evidence about the path a message has taken. evidence about the path a message has taken.
While this specification overrides the requirement that redirected
messages have more "Received" header fields than the message as
received, doing so removes an important mechanisms for detecting
loops and MUST NOT be permitted by implementations without due
consideration, such as requiring administrative action to enable
it.
Any change in a message content may interfere with digital Any change in a message content may interfere with digital
signature mechanisms that include the header in the signed signature mechanisms that include the header in the signed
material. Since normal message delivery adds "Received" material. Since normal message delivery adds "Received"
header fields and other trace fields to the beginning of a header fields and other trace fields to the beginning of a
message, many such schemas are impervious to headers prefixed message, many such schemas are impervious to headers prefixed
to a message, and will work with "addheader" unless :last is to a message, and will work with "addheader" unless :last is
used. used.
Any decision mechanism in a user's filter that is based Any decision mechanism in a user's filter that is based
on headers is vulnerable to header spoofing. For example, on headers is vulnerable to header spoofing. For example,
if the user adds an APPROVED header or tag, a malicious sender if the user adds an APPROVED header or tag, a malicious sender
may add that tag or header themselves. One way to guard against may add that tag or header themselves. One way to guard against
this is to delete or rename any such headers or stamps prior this is to delete or rename any such headers or stamps prior
to processing the message. to processing the message.
9. Acknowledgments 10. Acknowledgments
Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed,
Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson,
Will Lee, William Leibzon, Mark E. Mallett, Chris Markle, Will Lee, William Leibzon, Mark E. Mallett, Chris Markle,
Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson, Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson,
and Rand Wacker for extensive corrections and suggestions. and Rand Wacker for extensive corrections and suggestions.
10. Authors' Addresses 11. Authors' Addresses
Jutta Degener Jutta Degener
5245 College Ave, Suite #127 5245 College Ave, Suite #127
Oakland, CA 94618 Oakland, CA 94618
Email: jutta@pobox.com Email: jutta@pobox.com
Philip Guenther Philip Guenther
Sendmail, Inc. Sendmail, Inc.
6475 Christie Ave., Ste 350 6475 Christie Ave., Ste 350
Emeryville, CA 94608 Emeryville, CA 94608
Email: guenther@sendmail.com Email: guenther@sendmail.com
11. Discussion 12. Discussion
This section will be removed when this document leaves the This section will be removed when this document leaves the
Internet-Draft stage. Internet-Draft stage.
This draft is intended as an extension to the Sieve mail filtering This draft is intended as an extension to the Sieve mail filtering
language. Sieve extensions are discussed on the MTA Filters mailing language. Sieve extensions are discussed on the MTA Filters mailing
list at <ietf-mta-filters@imc.org>. Subscription requests can list at <ietf-mta-filters@imc.org>. Subscription requests can
be sent to <ietf-mta-filters-request@imc.org> (send an email be sent to <ietf-mta-filters-request@imc.org> (send an email
message with the word "subscribe" in the body). message with the word "subscribe" in the body).
More information on the mailing list along with a WWW archive of More information on the mailing list along with a WWW archive of
back messages is available at <http://www.imc.org/ietf-mta-filters/>. back messages is available at <http://www.imc.org/ietf-mta-filters/>.
11.2 Changes from draft-ietf-sieve-editheader-09.txt 12.1 Changes from draft-ietf-sieve-editheader-10.txt
Update the deleteheader example to not violate the spec.
Remove the security consideration about deleting "Received" headers.
Add a "Capability Identifier" section to match existing RFCs.
Make the normative and information references subsections of a
"References" section to match existing RFCs.
12.2 Changes from draft-ietf-sieve-editheader-09.txt
Add section 5, completely banning <<deleteheader "Received">> Add section 5, completely banning <<deleteheader "Received">>
but requiring that "Subject" changes be permitted. but requiring that "Subject" changes be permitted.
Since deletion of "Received" headers is now banned, this spec Since deletion of "Received" headers is now banned, this spec
no longer updates the base-spec. no longer updates the base-spec.
Updated references to Sieves specs that have been published. Updated references to Sieves specs that have been published.
11.3 Changes from draft-ietf-sieve-editheader-08.txt 12.3 Changes from draft-ietf-sieve-editheader-08.txt
Tighten up the permissible behaviors involving redirect and Tighten up the permissible behaviors involving redirect and
deleteheader "Recieved". deleteheader "Recieved".
Consistently quote the names of header fields, but not actions. Consistently quote the names of header fields, but not actions.
For deleteheader, :last without :index is an error. On the other For deleteheader, :last without :index is an error. On the other
hand, the match-type and comparator are ignored if there are no hand, the match-type and comparator are ignored if there are no
value-patterns. value-patterns.
Clarify that addheader and deleteheader operate on the 'current' Clarify that addheader and deleteheader operate on the 'current'
set of header fields and give examples demonstrating this. set of header fields and give examples demonstrating this.
11.4 Changes from draft-ietf-sieve-editheader-07.txt 12.4 Changes from draft-ietf-sieve-editheader-07.txt
Let implementations permit redirected messages to have fewer Let implementations permit redirected messages to have fewer
"Received" header fields, but warn about the consequences. "Received" header fields, but warn about the consequences.
Updated boilerplate to match RFC 4748. Updated boilerplate to match RFC 4748.
Added "Intended-Status: Standards Track" and Added "Intended-Status: Standards Track" and
"Updates: draft-ietf-sieve-3028bis-12" "Updates: draft-ietf-sieve-3028bis-12"
Change the references from appendices to sections. Change the references from appendices to sections.
Update [SIEVE], [BODY], [DSN], and [MDN] references. Update [SIEVE], [BODY], [DSN], and [MDN] references.
11.5 Changes from draft-ietf-sieve-editheader-06.txt 12.5 Changes from draft-ietf-sieve-editheader-06.txt
Make deleteheader match addheader on the description of invalid Make deleteheader match addheader on the description of invalid
field-names. field-names.
Update copyright boilerplate Update copyright boilerplate
Update references Update references
11.6 Changes from draft-ietf-sieve-editheader-05.txt 12.6 Changes from draft-ietf-sieve-editheader-05.txt
MDN and DSN references are merely informative MDN and DSN references are merely informative
11.7 Changes from draft-ietf-sieve-editheader-04.txt 12.7 Changes from draft-ietf-sieve-editheader-04.txt
Ignore leading and trailing whitespace when matching header field Ignore leading and trailing whitespace when matching header field
values. values.
Header modifications are ignored when continuing after an error Header modifications are ignored when continuing after an error
or generating MDNs or DSNs or generating MDNs or DSNs
Added references for MDN and DSN Added references for MDN and DSN
Update IANA registration to match 3028bis Update IANA registration to match 3028bis
skipping to change at page 9, line 4 skipping to change at page 9, line 26
values. values.
Header modifications are ignored when continuing after an error Header modifications are ignored when continuing after an error
or generating MDNs or DSNs or generating MDNs or DSNs
Added references for MDN and DSN Added references for MDN and DSN
Update IANA registration to match 3028bis Update IANA registration to match 3028bis
Added [KEYWORDS] boilerplate text Added [KEYWORDS] boilerplate text
Describe an invalid field-name to addheader as an error (might Describe an invalid field-name to addheader as an error (might
be detected at runtime) be detected at runtime)
11.8 Changes from draft-ietf-sieve-editheader-03.txt 12.8 Changes from draft-ietf-sieve-editheader-03.txt
Change "Syntax:" to "Usage:". Change "Syntax:" to "Usage:".
Updated references. Updated references.
11.9 Changes from draft-ietf-sieve-editheader-02.txt 12.9 Changes from draft-ietf-sieve-editheader-02.txt
Clarify that value-patterns restrict which occurrences are deleted. Clarify that value-patterns restrict which occurrences are deleted.
Add informative reference to [BODY]. Add informative reference to [BODY].
11.10 Changes from draft-ietf-sieve-editheader-01.txt 12.10 Changes from draft-ietf-sieve-editheader-01.txt
Whitespace and line length tweaks noted by ID-nits. Whitespace and line length tweaks noted by ID-nits.
Clarified what is being counted by :index. Clarified what is being counted by :index.
Update the [SIEVE] reference to the I-D of the revision. Update the [SIEVE] reference to the I-D of the revision.
11.11 Changes from draft-ietf-sieve-editheader-00.txt 12.11 Changes from draft-ietf-sieve-editheader-00.txt
Updated IPR boilerplate to RFC 3978/3979. Updated IPR boilerplate to RFC 3978/3979.
Many corrections in response to WGLC comments. Of particular note: Many corrections in response to WGLC comments. Of particular note:
- correct a number of spelling and grammar errors - correct a number of spelling and grammar errors
- document that neither addheader nor deleteheader affects the - document that neither addheader nor deleteheader affects the
implicit keep implicit keep
- add normative references to RFC 2047 and RFC 2231 - add normative references to RFC 2047 and RFC 2231
- it is not an error for deleteheader to affect nothing - it is not an error for deleteheader to affect nothing
- change "foo.tld" to "foo.example.com" - change "foo.tld" to "foo.example.com"
- add an informative reference to [VACATION], citing it as an - add an informative reference to [VACATION], citing it as an
example of an action that examines header fields example of an action that examines header fields
- add weasel words about changes to fields that have secondary - add weasel words about changes to fields that have secondary
effects effects
- add security consideration for combination of header changes - add security consideration for combination of header changes
and "reject" and "reject"
11.12 Changes from draft-degener-sieve-editheader-03.txt 12.12 Changes from draft-degener-sieve-editheader-03.txt
Renamed to draft-ietf-sieve-editheader-00.txt; Renamed to draft-ietf-sieve-editheader-00.txt;
tweaked the title and abstract. tweaked the title and abstract.
Added Philip Guenther as co-author. Added Philip Guenther as co-author.
Updated IPR boilerplate. Updated IPR boilerplate.
11.13 Changes from draft-degener-sieve-editheader-02.txt 12.13 Changes from draft-degener-sieve-editheader-02.txt
Changed the duplicate restrictions from "messages with different Changed the duplicate restrictions from "messages with different
headers MUST be considered different" to their direct opposite, headers MUST be considered different" to their direct opposite,
"messages with different headers MUST be considered the same," "messages with different headers MUST be considered the same,"
as requested by workgroup members on the mailing list. as requested by workgroup members on the mailing list.
Expanded mention of header signature schemes to Security Expanded mention of header signature schemes to Security
Considerations. Considerations.
Added IANA Considerations section. Added IANA Considerations section.
12. Normative References 13. References
13.1 Normative References
[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April
2001. 2001.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996. Non-ASCII Text", RFC 2047, November 1996.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages, and Encoded Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997. Continuations", RFC 2231, November 1997.
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
13. Informative References 13.2. Informative References
[BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering:
Body Extension", draft-ietf-sieve-body-07, June 2008. Body Extension", draft-ietf-sieve-body-09, March 2008.
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January for Delivery Status Notifications", RFC 3464, January
2003. 2003.
[MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition [MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition
Notification", RFC 3798, May 2004. Notification", RFC 3798, May 2004.
[VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering:
Vacation Extension", RFC 5230, January 2008. Vacation Extension", RFC 5230, January 2008.
 End of changes. 35 change blocks. 
39 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/