draft-ietf-sieve-rfc3598bis-04.txt   draft-ietf-sieve-rfc3598bis-05.txt 
Sieve Working Group K. Murchison Sieve Working Group K. Murchison
Internet-Draft Carnegie Mellon University Internet-Draft Carnegie Mellon University
Obsoletes: 3598 (if approved) April 24, 2006 Obsoletes: 3598 (if approved) June 15, 2006
Expires: October 26, 2006 Expires: December 17, 2006
Sieve Email Filtering -- Subaddress Extension Sieve Email Filtering -- Subaddress Extension
draft-ietf-sieve-rfc3598bis-04 draft-ietf-sieve-rfc3598bis-05
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 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on October 26, 2006. This Internet-Draft will expire on December 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
On email systems that allow for "subaddressing" or "detailed On email systems that allow for 'subaddressing' or 'detailed
addressing" (e.g., "ken+sieve@example.org"), it is sometimes addressing' (e.g., "ken+sieve@example.org"), it is sometimes
desirable to make comparisons against these sub-parts of addresses. desirable to make comparisons against these sub-parts of addresses.
This document defines an extension to the Sieve mail filtering This document defines an extension to the Sieve mail filtering
language that allows users to compare against the user and detail language that allows users to compare against the user and detail
sub-parts of an address. sub-parts of an address.
Meta-information on this document
This information is intended to facilitate discussion. It will be
removed when this document leaves the Internet-Draft stage.
This document is intended to be an update to the existing
"subaddress" extension to the Sieve mail filtering language,
available from the RFC repository as
<ftp://ftp.isi.edu/in-notes/rfc3598.txt> and
<ftp://ftp.isi.edu/internet-drafts/draft-ietf-sieve-3028bis-06.txt>
respectively.
This document and the Sieve language itself are being discussed on
the MTA Filters mailing list at <mailto:ietf-mta-filters@imc.org>.
Subscription requests can be sent to
<mailto:ietf-mta-filters-request@imc.org?body=subscribe> (send an
email message with the word "subscribe" in the body). More
information on the mailing list along with an archive of back
messages is available at <http://www.imc.org/ietf-mta-filters/>.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 6 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 5
4. Subaddress Comparisons . . . . . . . . . . . . . . . . . . . . 7 4. Subaddress Comparisons . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
Appendix B. Changes since RFC3598 . . . . . . . . . . . . . . . . 12 Appendix B. Changes since RFC3598 . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
Subaddressing is the practice of augmenting the local-part of an Subaddressing is the practice of augmenting the local-part of an
[RFC2822] address with some "detail" information in order to give [RFC2822] address with some 'detail' information in order to give
some extra meaning to that address. One common way of encoding some extra meaning to that address. One common way of encoding
"detail" information into the local-part is to add a "separator 'detail' information into the local-part is to add a 'separator
character sequence", such as "+", to form a boundary between the character sequence', such as "+", to form a boundary between the
"user" (original local-part) and "detail" sub-parts of the address, 'user' (original local-part) and 'detail' sub-parts of the address,
much like the "@" character forms the boundary between the local-part much like the "@" character forms the boundary between the local-part
and domain. and domain.
Typical uses of subaddressing might be: Typical uses of subaddressing might be:
o A message addressed to "ken+sieve@example.org" is delivered into a o A message addressed to "ken+sieve@example.org" is delivered into a
mailbox called "sieve" belonging to the user "ken". mailbox called "sieve" belonging to the user "ken".
o A message addressed to "5551212#123@example.com" is delivered to o A message addressed to "5551212#123@example.com" is delivered to
the voice mailbox number "123" at phone number "5551212". the voice mailbox number "123" at phone number "5551212".
This document describes an extension to the Sieve language defined by This document describes an extension to the Sieve language defined by
[I-D.ietf-sieve-3028bis] for comparing against the "user" and [I-D.ietf-sieve-3028bis] for comparing against the 'user' and
"detail" sub-parts of an address. 'detail' sub-parts of an address.
2. Conventions used in this document 2. Conventions used in this document
Conventions for notations are as in [I-D.ietf-sieve-3028bis] section
1.1.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Capability Identifier 3. Capability Identifier
The capability string associated with the extension defined in this The capability string associated with the extension defined in this
document is "subaddress". document is "subaddress".
4. Subaddress Comparisons 4. Subaddress Comparisons
skipping to change at page 7, line 17 skipping to change at page 6, line 17
Test commands that act exclusively on addresses may take the optional Test commands that act exclusively on addresses may take the optional
tagged arguments ":user" and ":detail" to specify what sub-part of tagged arguments ":user" and ":detail" to specify what sub-part of
the local-part of the address will be acted upon. the local-part of the address will be acted upon.
NOTE: In most cases, the envelope "to" address is the preferred NOTE: In most cases, the envelope "to" address is the preferred
address to examine for subaddress information when the desire is address to examine for subaddress information when the desire is
to sort messages based on how they were addressed so as to get to to sort messages based on how they were addressed so as to get to
a specific recipient. The envelope address is, after all, the a specific recipient. The envelope address is, after all, the
reason a given message is being processed by a given sieve script reason a given message is being processed by a given sieve script
for a given user. This is particularly true when mailing lists, for a given user. This is particularly true when mailing lists,
aliases, and "virtual domains" are involved since the envelope may aliases, and 'virtual domains' are involved since the envelope may
be the only source of detail information for the specific be the only source of detail information for the specific
recipient. recipient.
NOTE: Because the encoding of detailed addresses are site and/or NOTE: Because the encoding of detailed addresses are site and/or
implementation specific, using the subaddress extension on foreign implementation specific, using the subaddress extension on foreign
addresses (such as the envelope "from" address or originator addresses (such as the envelope "from" address or originator
header fields) may lead to inconsistent or incorrect results. header fields) may lead to inconsistent or incorrect results.
The ":user" argument specifies the user sub-part of the local-part of The ":user" argument specifies the user sub-part of the local-part of
an address. If the address is not encoded to contain a detail sub- an address. If the address is not encoded to contain a detail sub-
part, then ":user" specifies the entire left-side of the address part, then ":user" specifies the entire left-side of the address
(equivalent to ":localpart"). (equivalent to ":localpart").
The ":detail" argument specifies the detail sub-part of the local- The ":detail" argument specifies the detail sub-part of the local-
part of an address. If the address is not encoded to contain a part of an address. If the address is not encoded to contain a
detail sub-part, then the test evaluates to false. If a zero-length detail sub-part, then the test evaluates to false. If a zero-length
string is encoded as the detail sub-part, then ":detail" ":is" the string is encoded as the detail sub-part, then ":detail" resolves to
empty key (""). the empty value ("").
NOTE: If the encoding method used for detailed addresses utilizes NOTE: If the encoding method used for detailed addresses utilizes
a separator character sequence, and the separator character a separator character sequence, and the separator character
sequence occurs more than once in the local-part, then the logic sequence occurs more than once in the local-part, then the logic
used to split the address is implementation defined, and is used to split the address is implementation defined, and is
usually dependent on the format used by the encompassing mail usually dependent on the format used by the encompassing mail
system. system.
Implementations MUST make sure that the encoding method used for Implementations MUST make sure that the encoding method used for
detailed addresses matches that which is used and/or allowed by the detailed addresses matches that which is used and/or allowed by the
skipping to change at page 8, line 29 skipping to change at page 7, line 29
A diagram showing the ADDRESS-PARTs of a email address where the A diagram showing the ADDRESS-PARTs of a email address where the
detail information precedes a separator character sequence of "--" is detail information precedes a separator character sequence of "--" is
shown below: shown below:
:detail "--" :user "@" :domain :detail "--" :user "@" :domain
\------------------/ \------------------/
:local-part :local-part
Example (where the detail information follows "+"): Example (where the detail information follows "+"):
require "subaddress"; require ["subaddress", "fileinto"];
# In this example the same user account receives mail for both
# "ken@example.com" and "postmaster@example.com"
# File all messages to postmaster into a single mailbox,
# ignoring the :detail part.
if envelope :user "to" "postmaster" {
fileinto "inbox.postmaster";
stop;
}
# File mailing list messages (subscribed as "ken+mta-filters"). # File mailing list messages (subscribed as "ken+mta-filters").
if envelope :detail "to" "mta-filters" { if envelope :detail "to" "mta-filters" {
fileinto "inbox.ietf-mta-filters"; fileinto "inbox.ietf-mta-filters";
} }
# If a message is not directly to me (ignoring +detail), junk it. # Redirect all mail sent to "ken+foo".
if not allof (address :user ["to", "cc"] "ken",
address :domain ["to", "cc"] "example.org") {
discard;
}
# Redirect all mail sent to +foo.
if envelope :detail "to" "foo" { if envelope :detail "to" "foo" {
redirect "ken@example.net"; redirect "ken@example.net";
} }
5. IANA Considerations 5. IANA Considerations
This document requests that the IANA update the entry for the This document requests that the IANA update the entry for the
"subaddress" Sieve extension to point at this document. "subaddress" Sieve extension to point at this document and to update
the contact information with the author's address.
6. Security Considerations 6. Security Considerations
Security considerations are discussed in [I-D.ietf-sieve-3028bis]. Security considerations are discussed in [I-D.ietf-sieve-3028bis].
It is believed that this extension does not introduce any additional It is believed that this extension does not introduce any additional
security concerns. security concerns.
7. Normative References 7. Normative References
[I-D.ietf-sieve-3028bis] [I-D.ietf-sieve-3028bis]
skipping to change at page 11, line 9 skipping to change at page 10, line 9
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall
Gellens, Philip Guenther, Jutta Degener, Michael Haardt, Ned Freed, Gellens, Philip Guenther, Jutta Degener, Michael Haardt, Ned Freed,
and Mark Mallett for their help with this document. Mark Mallett, and Barry Leiba for their help with this document.
Appendix B. Changes since RFC3598 Appendix B. Changes since RFC3598
o Discussion of how the user and detail information is encoded now o Discussion of how the user and detail information is encoded now
uses generic language. uses generic language.
o Added note detailing that this extension is most useful when used o Added note detailing that this extension is most useful when used
on the envelope "to" address. on the envelope "to" address.
o Added note detailing that this extension isn't very useful on o Added note detailing that this extension isn't very useful on
foreign addresses (envelope "from" or originator header fields). foreign addresses (envelope "from" or originator header fields).
o Fixed envelope test example to only use "to" address. o Fixed envelope test example to only use "to" address.
o Replaced ":user" example with one that doesn't produce unexpected
behavior.
o Refer to the zero-length string ("") as "empty" instead of "null" o Refer to the zero-length string ("") as "empty" instead of "null"
(per draft-ietf-sieve-3028bis) (per draft-ietf-sieve-3028bis)
o Use only RFC 2606 domains in examples. o Use only RFC 2606 domains in examples.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
Author's Address Author's Address
Kenneth Murchison Kenneth Murchison
 End of changes. 17 change blocks. 
58 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/