draft-ietf-sieve-editheader-11.txt   rfc5293.txt 
Network Working Group Jutta Degener Network Working Group J. Degener
Internet Draft Philip Guenther Request for Comments: 5293 P. Guenther
Intended status: Standards Track Sendmail, Inc. Category: Standards Track Sendmail, Inc.
August 2008
Sieve Email Filtering: Editheader Extension Sieve Email Filtering: Editheader Extension
draft-ietf-sieve-editheader-11.txt
Status of this memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The IETF Trust (2008). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document defines two new actions for the "Sieve" email This document defines two new actions for the "Sieve" email filtering
filtering language that add and delete email header fields. 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
of communication between email processors. communication between email processors. This extension enables sieve
This extension enables sieve scripts to interact with other scripts to interact with other components that consume or produce
components that consume or produce header fields by allowing header fields by allowing the script to delete and add header fields.
the script to delete and add header fields.
2. Conventions Used in This Document 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 Section 1.1 of [SIEVE], 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
logical line of an email message header. line of an email message header.
3. Capability Identifier 3. Capability Identifier
The capability string associated with the extension defined in The capability string associated with the extension defined in this
this document is "editheader". document is "editheader".
4. 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
field name as described by the [IMAIL] "field-name" nonterminal name, as described by the [IMAIL] "field-name" nonterminal syntax
syntax element, the implementation MUST flag an error. The element, the implementation MUST flag an error. The addheader action
addheader action does not affect Sieve's implicit keep. 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 [IMAIL]
"unstructured" nonterminal syntax element or exceeds a length "unstructured" nonterminal syntax element or exceeds a length limit
limit set by the implementation, the implementation MUST either set by the implementation, the implementation MUST either flag an
flag an error or encode the field using folding white space and error or encode the field using folding white space and the encodings
the encodings described in [RFC2047] or [RFC2231] to be compliant described in [MIME3] or [MIMEPARAM] to be compliant with [IMAIL].
with RFC 2822.
An implementation MAY impose a length limit onto the size of An implementation MAY impose a length limit onto the size of the
the encoded header field; such a limit MUST NOT be less encoded header field; such a limit MUST NOT be less than 998
than 998 characters, not including the terminating CRLF characters, not including the terminating CRLF supplied by the
supplied by the implementation. implementation.
By default, the header field is inserted at the beginning of the By default, the header field is inserted at the beginning of the
existing message header. If the optional flag ":last" is existing message header. If the optional flag ":last" is specified,
specified, it is appended at the end. it is appended at the end.
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";
} }
5. Action deleteheader 5. Action deleteheader
skipping to change at page 3, line 21 skipping to change at page 2, line 47
redirect "kim@home.example.com"; redirect "kim@home.example.com";
} }
5. 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
the named header field. The deleteheader action does not affect named header field. The deleteheader action does not affect Sieve's
Sieve's implicit keep. 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
field name as described by the [IMAIL] "field-name" nonterminal name as described by the [IMAIL] "field-name" nonterminal syntax
syntax element, the implementation MUST flag an error. 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
the header field are deleted to those whose values match any of header field are deleted to those whose values match any of the
the specified value-patterns, the matching being according to specified value-patterns, the matching being according to the match-
the match-type and comparator and performed as if by the "header" type and comparator and performed as if by the "header" test. In
test. In particular, leading and trailing whitespace in the particular, leading and trailing whitespace in the field values is
field values is ignored. If no value-patterns are specified ignored. If no value-patterns are specified, then the comparator and
then the comparator and match-type options are silently ignored. 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
are limited to the <fieldno> occurrence of the named header limited to the <fieldno> occurrence of the named header field,
field, beginning at 1, the first named header field. If :last beginning at 1, the first named header field. If :last is specified,
is specified, the count is backwards; 1 denotes the last named the count is backwards; 1 denotes the last named header field, 2 the
header field, 2 the second to last, and so on. The counting second to last, and so on. The counting happens before the <value-
happens before the <value-patterns> match, if any. For example: patterns> match, if any. For example:
deleteheader :index 1 :contains "Delivered-To" deleteheader :index 1 :contains "Delivered-To"
"bob@example.com"; "bob@example.com";
deletes the first "Delivered-To" header field if it contains the deletes the first "Delivered-To" header field if it contains the
string "bob@example.com" (not the first "Delivered-To" field string "bob@example.com" (not the first "Delivered-To" field that
that contains "bob@example.com"). 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
the deleteheader action or if the :index argument is greater deleteheader action or if the :index argument is greater than the
than the number of named header fields. 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
without also specifying :index. also specifying :index.
6. 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
header fields may be deleted and which header fields may be fields may be deleted and which header fields may be added. However,
added. However, implementations MUST NOT permit attempts to implementations MUST NOT permit attempts to delete "Received" and
delete "Received" header fields and MUST permit both addition "Auto-Submitted" header fields and MUST permit both addition and
and deletion of the "Subject" header field. 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
attempt MUST be silently ignored. MUST be silently ignored.
7. 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
messages MUST do so using the original, unmodified message header. MUST do so using the original, unmodified message header. Similarly,
Similarly, if an error terminates processing of the script, the if an error terminates processing of the script, the original message
original message header MUST be used when doing the implicit header MUST be used when doing the implicit keep required by Section
keep required by [SIEVE] section 2.10.6. 2.10.6 of [SIEVE].
With the exception of the special handling of redirect and All other actions that store, send, or alter the message MUST do so
"Received" header fields described above, all other actions that with the current set of header fields. This includes the addheader
store, send, or alter the message MUST do so with the current set and deleteheader actions themselves. For example, the following
of header fields. This includes the addheader and deleteheader leaves the message unchanged:
actions themselves. For example, the following leaves the message
unchanged:
addheader "X-Hello" "World"; addheader "X-Hello" "World";
deleteheader :index 1 "X-Hello"; deleteheader :index 1 "X-Hello";
Similarly, given a message with three or more "X-Hello" header Similarly, given a message with three or more "X-Hello" header
fields, the following example deletes the first and third of fields, the following example deletes the first and third of them,
them, not the first and second: not the first and second:
deleteheader :index 1 "X-Hello"; deleteheader :index 1 "X-Hello";
deleteheader :index 2 "X-Hello"; deleteheader :index 2 "X-Hello";
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
state of a header as modified by any actions that have taken 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 or not the incoming
message contained an "X-Hello" header field or not: message contained an "X-Hello" header field:
addheader "X-Hello" "World"; addheader "X-Hello" "World";
if header :contains "X-Hello" "World" if header :contains "X-Hello" "World"
{ {
fileinto "international"; fileinto "international";
} }
However, if the presence or value of a header field affects how However, if the presence or value of a header field affects how the
the implementation parses or decodes other parts of the message, implementation parses or decodes other parts of the message, then,
then for the purposes of that parsing or decoding the implementation for the purposes of that parsing or decoding, the implementation MAY
MAY ignore some or all changes made to those header fields. For ignore some or all changes made to those header fields. For example,
example, in an implementation that supports the [BODY] extension, in an implementation that supports the [BODY] extension, "body" tests
"body" tests may be unaffected by deleting or adding "Content-Type" may be unaffected by deleting or adding "Content-Type" or "Content-
or "Content-Transfer-Encoding" header fields. This does not rescind Transfer-Encoding" header fields. This does not rescind the
the requirement that changes to those header fields affect direct requirement that changes to those header fields affect direct tests;
tests; only the semantic side effects of changes to the fields only the semantic side effects of changes to the fields may be
may be ignored. ignored.
For the purpose of weeding out duplicates, a message modified For the purpose of weeding out duplicates, a message modified by
by addheader or deleteheader MUST be considered the same as addheader or deleteheader MUST be considered the same as the original
the original message. For example, in an implementation that message. For example, in an implementation that obeys the constraint
obeys the constraint in [SIEVE] section 2.10.3 and does not deliver in Section 2.10.3 of [SIEVE] and does not deliver the same message to
the same message to a folder more than once, the following a folder more than once, the following code fragment
code fragment
keep; keep;
addheader "X-Flavor" "vanilla"; addheader "X-Flavor" "vanilla";
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
to pick which of the redundant "fileinto" or "keep" actions is which of the redundant "fileinto" or "keep" actions is executed, and
executed, and which ones are ignored. 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
the script, after the headers have been modified. (However, script, after the headers have been modified. (However, a canceled
a canceled "implicit keep" remains canceled.) "implicit keep" remains canceled.)
8. 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
that modify the header of the message being modify the header of the message being processed
processed RFC number: RFC 5293
RFC number: this RFC Contact Address: The Sieve discussion list <ietf-mta-filters&imc.org>
Contact Address: Jutta Degener <jutta@pobox.com>
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
9. 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
shielded from (e.g., by a gateway MTA that removes them). from (e.g., by a gateway Mail Transport Agent (MTA) that removes
them).
This is the first Sieve extension to be standardized that allows
alteration of messages being processed by Sieve engines. A Sieve
script that uses Sieve tests defined in [SIEVE], the editheader
extension, and the redirect action back to the same user can keep
some state between different invocations of the same script for the
same message. But note that it would not be possible to introduce an
infinite loop using any such script, because each iteration adds a
new Received header field, so email loop prevention described in
[SMTP] will eventually non deliver the message, and because the
editheader extension is explicitly prohibited to alter or delete
Received header fields (i.e., it can't interfere with loop
prevention).
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.
Any change in a message content may interfere with digital Any change in message content may interfere with digital signature
signature mechanisms that include the header in the signed mechanisms that include the header in the signed material. For
material. Since normal message delivery adds "Received" example, changes to (or deletion/addition of) header fields included
header fields and other trace fields to the beginning of a in the "SHOULD be included in the signature" list in Section 5.5 of
message, many such schemas are impervious to headers prefixed [DKIM] can invalidate DKIM signatures. This also includes DKIM
to a message, and will work with "addheader" unless :last is signatures that guarantee a header field absence.
used.
Any decision mechanism in a user's filter that is based
on headers is vulnerable to header spoofing. For example,
if the user adds an APPROVED header or tag, a malicious sender
may add that tag or header themselves. One way to guard against
this is to delete or rename any such headers or stamps prior
to processing the message.
10. Acknowledgments
Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed,
Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson,
Will Lee, William Leibzon, Mark E. Mallett, Chris Markle,
Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson,
and Rand Wacker for extensive corrections and suggestions.
11. Authors' Addresses
Jutta Degener
5245 College Ave, Suite #127
Oakland, CA 94618
Email: jutta@pobox.com
Philip Guenther
Sendmail, Inc.
6475 Christie Ave., Ste 350
Emeryville, CA 94608
Email: guenther@sendmail.com
12. Discussion
This section will be removed when this document leaves the
Internet-Draft stage.
This draft is intended as an extension to the Sieve mail filtering
language. Sieve extensions are discussed on the MTA Filters mailing
list at <ietf-mta-filters@imc.org>. Subscription requests can
be sent to <ietf-mta-filters-request@imc.org> (send an email
message with the word "subscribe" in the body).
More information on the mailing list along with a WWW archive of
back messages is available at <http://www.imc.org/ietf-mta-filters/>.
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">>
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.
12.3 Changes from draft-ietf-sieve-editheader-08.txt
Tighten up the permissible behaviors involving redirect and
deleteheader "Recieved".
Consistently quote the names of header fields, but not actions.
For deleteheader, :last without :index is an error. On the other
hand, the match-type and comparator are ignored if there are no
value-patterns.
Clarify that addheader and deleteheader operate on the 'current'
set of header fields and give examples demonstrating this.
12.4 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.
12.5 Changes from draft-ietf-sieve-editheader-06.txt
Make deleteheader match addheader on the description of invalid
field-names.
Update copyright boilerplate
Update references
12.6 Changes from draft-ietf-sieve-editheader-05.txt
MDN and DSN references are merely informative
12.7 Changes from draft-ietf-sieve-editheader-04.txt
Ignore leading and trailing whitespace when matching header field
values.
Header modifications are ignored when continuing after an error
or generating MDNs or DSNs
Added references for MDN and DSN
Update IANA registration to match 3028bis
Added [KEYWORDS] boilerplate text
Describe an invalid field-name to addheader as an error (might
be detected at runtime)
12.8 Changes from draft-ietf-sieve-editheader-03.txt
Change "Syntax:" to "Usage:".
Updated references.
12.9 Changes from draft-ietf-sieve-editheader-02.txt
Clarify that value-patterns restrict which occurrences are deleted.
Add informative reference to [BODY].
12.10 Changes from draft-ietf-sieve-editheader-01.txt
Whitespace and line length tweaks noted by ID-nits. The editheader extension doesn't directly affect [IMAIL] header field
signatures generated using [SMIME] or [OPENPGP], because these
signature schemes include a separate copy of the header fields inside
the signed message/rfc822 body part. However, software written to
detect differences between the inner (signed) copy of header fields
and the outer (modified by editheader) header fields might be
affected by changes made by editheader.
Clarified what is being counted by :index. Since normal message delivery adds "Received" header fields and other
trace fields to the beginning of a message, many such digital
signature mechanisms are impervious to headers prefixed to a message,
and will work with "addheader" unless :last is used.
Update the [SIEVE] reference to the I-D of the revision. Any decision mechanism in a user's filter that is based on headers is
vulnerable to header spoofing. For example, if the user adds an
APPROVED header or tag, a malicious sender may add that tag or header
themselves. One way to guard against this is to delete or rename any
such headers or stamps prior to processing the message.
12.11 Changes from draft-ietf-sieve-editheader-00.txt 10. Acknowledgments
Updated IPR boilerplate to RFC 3978/3979. Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Arnt
Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Will Lee, William
Leibzon, Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall
Schwartz, Aaron Stone, Nigel Swinson, and Rand Wacker for extensive
corrections and suggestions.
Many corrections in response to WGLC comments. Of particular note: 11. References
- correct a number of spelling and grammar errors
- document that neither addheader nor deleteheader affects the
implicit keep
- add normative references to RFC 2047 and RFC 2231
- it is not an error for deleteheader to affect nothing
- change "foo.tld" to "foo.example.com"
- add an informative reference to [VACATION], citing it as an
example of an action that examines header fields
- add weasel words about changes to fields that have secondary
effects
- add security consideration for combination of header changes
and "reject"
12.12 Changes from draft-degener-sieve-editheader-03.txt 11.1. Normative References
Renamed to draft-ietf-sieve-editheader-00.txt; [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822,
tweaked the title and abstract. April 2001.
Added Philip Guenther as co-author. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Updated IPR boilerplate. [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, November 1996.
12.13 Changes from draft-degener-sieve-editheader-02.txt [MIMEPARAM] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
Changed the duplicate restrictions from "messages with different [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
headers MUST be considered different" to their direct opposite, Email Filtering Language", RFC 5228, January 2008.
"messages with different headers MUST be considered the same,"
as requested by workgroup members on the mailing list.
Expanded mention of header signature schemes to Security 11.2. Informative References
Considerations.
Added IANA Considerations section. [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering:
Body Extension", RFC 5173, April 2008.
13. References [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
13.1 Normative References [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April [MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message
2001. Disposition Notification", RFC 3798, May 2004.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [OPENPGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
Requirement Levels", RFC 2119, March 1997. "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail [SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for Extensions (S/MIME) Version 3.1 Message Specification",
Non-ASCII Text", RFC 2047, November 1996. RFC 3851, July 2004.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
Encoded Word Extensions: Character Sets, Languages, and 2821, April 2001.
Continuations", RFC 2231, November 1997.
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering [VACATION] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering:
Language", RFC 5228, January 2008. Vacation Extension", RFC 5230, January 2008.
13.2. Informative References Authors' Addresses
[BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: Jutta Degener
Body Extension", draft-ietf-sieve-body-09, March 2008. 5245 College Ave, Suite #127
Oakland, CA 94618
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format EMail: jutta@pobox.com
for Delivery Status Notifications", RFC 3464, January
2003.
[MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition Philip Guenther
Notification", RFC 3798, May 2004. Sendmail, Inc.
6475 Christie Ave., Ste 350
Emeryville, CA 94608
[VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: EMail: guenther@sendmail.com
Vacation Extension", RFC 5230, January 2008.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). 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
 End of changes. 61 change blocks. 
339 lines changed or deleted 198 lines changed or added

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