draft-ietf-sieve-editheader-07.txt   draft-ietf-sieve-editheader-08.txt 
Network Working Group Jutta Degener Network Working Group Jutta Degener
Internet Draft Philip Guenther Internet Draft Philip Guenther
Expires: May 2007 Sendmail, Inc. Intended status: Standards Track Sendmail, Inc.
November 2006
Updates: RFC-ietf-sieve-3028bis-12
Sieve Email Filtering: Editheader Extension Sieve Email Filtering: Editheader Extension
draft-ietf-sieve-editheader-07.txt draft-ietf-sieve-editheader-08.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 37 skipping to change at page 1, line 38
"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 (2006). Copyright (C) The IETF Trust (2007).
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 3, line 19 skipping to change at page 3, line 19
<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.
The field-name is mandatory and always matched as a case-insensitive The field-name is mandatory and always matched as a case-insensitive
US-ASCII string. If the field-name is not a valid 7-bit header US-ASCII string. If the field-name is not a valid 7-bit 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 value-patterns, if specified, restrict which occurrences of The value-patterns, if specified, restrict which occurrences of
the header field are deleted to those whose values match any of the header field are deleted to those whose values match any of
the specified value-patterns, the matching being according to the specified value-patterns, the matching being according to
the match-type and comparator and performed as if by the "header" the match-type and comparator and performed as if by the "header"
test. In particular, leading and trailing whitespace in the test. In particular, leading and trailing whitespace in the
field values is ignored. field values is 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 2 :contains "Received" "via carrier-pigeon"
deletes the second "Received:" header field if it contains deletes the second "Received" header field if it contains
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.
If an script uses the deleteheader action to remove "Received"
header fields and then performs a "redirect" action, the
implementation SHOULD NOT send the outgoing message with fewer
Received header fields than the original message. If the
implementation does not permit that for the involved script, it
is implementation defined what Received header fields are present
in such an outgoing message. The above overrides the requirement
on Received header fields in RFC-ietf-sieve-3028bis-12 section
4.2.
5. Interaction with Other Sieve Extensions 5. 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.
All other actions that store or send the message MUST do so with With the exception of the special handling of "redirect" and
the current set of header fields. "Received" header fields described above, all other actions that
store or send the message MUST do so with the current set of
header fields.
Tests and actions such as "exists", "header", or "vacation" Tests and actions such as "exists", "header", or "vacation"
[VACATION] that examine header fields MUST examine the current [VACATION] that examine header fields MUST examine the current
state of a header as modified by any actions that have taken state of a header as modified by any actions that have taken
place so far. place so far.
As an example, the "header" test in the following fragment will As an example, the "header" test in the following fragment will
always evaluate to true, regardless of whether the incoming always evaluate to true, regardless of whether the incoming
message contained an "X-Hello" header field or not: message contained an "X-Hello" header field or not:
skipping to change at page 5, line 32 skipping to change at page 5, line 39
7. Security Considerations 7. 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 therefore should 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 to the beginning of a message, many such schemas header fields to the beginning of a message, many such schemas
are impervious to headers prefixed to a message, and will are impervious to headers prefixed to a message, and will
work with "addheader" unless :last is used. work with "addheader" unless :last is 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
skipping to change at page 6, line 34 skipping to change at page 7, line 5
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-06.txt 10.1 Changes from draft-ietf-sieve-editheader-07.txt
Let implementations permit redirected messages to have fewer
Received header fields, but warn about the consequences.
Updated boilerplate to match RFC 4748.
Added "Intended-Status: Standards Track" and
"Updates: draft-ietf-sieve-3028bis-12"
Change the references from appendices to sections.
Update [SIEVE], [BODY], [DSN], and [MDN] references.
10.2 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.2 Changes from draft-ietf-sieve-editheader-05.txt 10.3 Changes from draft-ietf-sieve-editheader-05.txt
MDN and DSN references are merely informative MDN and DSN references are merely informative
10.3 Changes from draft-ietf-sieve-editheader-04.txt 10.4 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
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.4 Changes from draft-ietf-sieve-editheader-03.txt 10.5 Changes from draft-ietf-sieve-editheader-03.txt
Change "Syntax:" to "Usage:". Change "Syntax:" to "Usage:".
Updated references. Updated references.
10.5 Changes from draft-ietf-sieve-editheader-02.txt 10.6 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.6 Changes from draft-ietf-sieve-editheader-01.txt 10.7 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.7 Changes from draft-ietf-sieve-editheader-00.txt 10.8 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.8 Changes from draft-degener-sieve-editheader-03.txt 10.9 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.9 Changes from draft-degener-sieve-editheader-02.txt 10.10 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.
Appendices 11. Normative References
Appendix A. 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: A Mail Filtering
Language", draft-ietf-sieve-3028bis-10, November 2006. Language", draft-ietf-sieve-3028bis-12, February 2007.
Appendix B. Informative References 12. 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-05, November 2006. Body Extension", draft-ietf-sieve-body-06, February 2007.
[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 1894, January for Delivery Status Notifications", RFC 3464, January
1996. 2003.
[MDN] Fajman, R., "An Extensible Message Format for Message [MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition
Disposition Notifications", RFC 2298, March 1998. 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", draft-ietf-sieve-vacation-06,
February 2006. February 2006.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
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 This document and the information contained herein are provided on an
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OR FITNESS FOR A PARTICULAR PURPOSE
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
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 specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention any
any copyrights, patents or patent applications, or other copyrights, patents or patent applications, or other proprietary
proprietary rights that may cover technology that may be required rights that may cover technology that may be required to implement
to implement this standard. Please address the information to the this standard. Please address the information to the IETF at
IETF at ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by Funding for the RFC Editor function is currently provided by the IETF
the Internet Society. Administrative Support Activity (IASA).
 End of changes. 28 change blocks. 
46 lines changed or deleted 76 lines changed or added

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