draft-ietf-sieve-editheader-09.txt   draft-ietf-sieve-editheader-10.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
Updates: RFC-ietf-sieve-3028bis-12
Sieve Email Filtering: Editheader Extension Sieve Email Filtering: Editheader Extension
draft-ietf-sieve-editheader-09.txt draft-ietf-sieve-editheader-10.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 1, line 38 skipping to change at page 1, line 36
"work in progress." "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines two new actions for the "Sieve" email This document defines two new actions for the "Sieve" email
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.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
the string "via carrier-pigeon" (not the second "Received" field the string "via carrier-pigeon" (not the second "Received" field
that contains "via carrier-pigeon"). that contains "via carrier-pigeon").
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.
If an script uses the deleteheader action to remove "Received" 5. Implementation Limitations on Changes
header fields and then performs a redirect action, then the
implementation MUST either:
A) silently ignore all of the deleteheader actions that removed
"Received" header fields when generating the outgoing message,
B) silently ignore just enough of the deleteheader actions that
removed "Received" header fields when generating the outgoing
message, such that it has more "Received" header fields than
the message as recieved by the implementation, or
C) obey all the deleteheader actions, possibly sending out a
message with no more "Received" header fields than where in
the message as received. This overrides the requirement on
"Received" header fields in RFC-ietf-sieve-3028bis-12
section 4.2.
Implementations MUST NOT do choice (C) without due consideration, As a matter of local policy, implementations MAY limit which
such as requiring explicit administrative action to enable it. header fields may be deleted and which header fields may be
added. However, implementations MUST NOT permit attempts to
delete "Received" header fields and MUST permit both addition
and deletion of the "Subject" header field.
5. Interaction with Other Sieve Extensions If a script tries to make a change that isn't permitted, the
attempt MUST be silently ignored.
6. 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 6, line 5 skipping to change at page 5, line 34
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.)
6. IANA Considerations 7. 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.
7. Security Considerations 8. 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 While this specification overrides the requirement that redirected
messages have more "Received" header fields than the message as messages have more "Received" header fields than the message as
skipping to change at page 7, line 5 skipping to change at page 6, line 36
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.
8. Acknowledgments 9. 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.
9. Authors' Addresses 10. 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 St., Ste 350 6475 Christie Ave., Ste 350
Emeryville, CA 94608 Emeryville, CA 94608
Email: guenther@sendmail.com Email: guenther@sendmail.com
10. Discussion 11. 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/>.
10.1 Changes from draft-ietf-sieve-editheader-08.txt 11.2 Changes from draft-ietf-sieve-editheader-09.txt
Add section 5, completely banning <<deleteheader "Received">>
but requiring that "Subject" changes be permitted.
Since deletion of "Received" headers is now banned, this spec
no longer updates the base-spec.
Updated references to Sieves specs that have been published.
11.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.
10.2 Changes from draft-ietf-sieve-editheader-07.txt 11.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.
10.3 Changes from draft-ietf-sieve-editheader-06.txt 11.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
10.4 Changes from draft-ietf-sieve-editheader-05.txt 11.6 Changes from draft-ietf-sieve-editheader-05.txt
MDN and DSN references are merely informative MDN and DSN references are merely informative
10.5 Changes from draft-ietf-sieve-editheader-04.txt 11.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 8, line 47 skipping to change at page 9, line 4
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)
10.6 Changes from draft-ietf-sieve-editheader-03.txt 11.8 Changes from draft-ietf-sieve-editheader-03.txt
Change "Syntax:" to "Usage:". Change "Syntax:" to "Usage:".
Updated references. Updated references.
10.7 Changes from draft-ietf-sieve-editheader-02.txt 11.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].
10.8 Changes from draft-ietf-sieve-editheader-01.txt 11.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.
10.9 Changes from draft-ietf-sieve-editheader-00.txt 11.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"
10.10 Changes from draft-degener-sieve-editheader-03.txt 11.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.
10.11 Changes from draft-degener-sieve-editheader-02.txt 11.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.
11. Normative References 12. 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: A Mail Filtering [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-12, February 2007. Language", RFC 5228, January 2008.
12. Informative References 13. 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-06, February 2007. Body Extension", draft-ietf-sieve-body-07, June 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", draft-ietf-sieve-vacation-06, Vacation Extension", RFC 5230, January 2008.
February 2006.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 11, line 44 skipping to change at line 508
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 33 change blocks. 
49 lines changed or deleted 47 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/