draft-ietf-sieve-rfc3598bis-05.txt   rfc5233.txt 
Sieve Working Group K. Murchison Network Working Group K. Murchison
Internet-Draft Carnegie Mellon University Request for Comments: 5233 Carnegie Mellon University
Obsoletes: 3598 (if approved) June 15, 2006 Obsoletes: 3598 January 2008
Expires: December 17, 2006 Category: Standards Track
Sieve Email Filtering -- Subaddress Extension
draft-ietf-sieve-rfc3598bis-05
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2006. Sieve Email Filtering: Subaddress Extension
Copyright Notice Status of This Memo
Copyright (C) The Internet Society (2006). 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
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 Email 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document ...............................2
3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 5 3. Capability Identifier ...........................................2
4. Subaddress Comparisons . . . . . . . . . . . . . . . . . . . . 6 4. Subaddress Comparisons ..........................................2
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations .............................................5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations .........................................5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References ............................................5
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments ........................................6
Appendix B. Changes since RFC3598 . . . . . . . . . . . . . . . . 11 Appendix B. Changes since RFC 3598 .................................6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
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
skipping to change at page 3, line 25 skipping to change at page 2, line 25
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 [RFC5228] for comparing against the 'user' and 'detail' sub-parts of
'detail' sub-parts of an address. an address.
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 [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".
skipping to change at page 6, line 28 skipping to change at page 3, line 15
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 address fails to match any of the specified
string is encoded as the detail sub-part, then ":detail" resolves to keys. If a zero-length string is encoded as the detail sub-part,
the empty value (""). then ":detail" resolves to 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
usually dependent on the format used by the encompassing mail 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
encompassing mail system, otherwise unexpected results might occur. encompassing mail system, otherwise unexpected results might occur.
Note that the mechanisms used to define and/or query the encoding Note that the mechanisms used to define and/or query the encoding
method used by the mail system are outside the scope of this method used by the mail system are outside the scope of this
document. document.
The ":user" and ":detail" address parts are subject to the same rules The ":user" and ":detail" address parts are subject to the same rules
and restrictions as the standard address parts defined in [I-D.ietf- and restrictions as the standard address parts defined in [RFC5228],
sieve-3028bis] Section 2.7.4. Section 2.7.4.
For convenience, the "ADDRESS-PART" syntax element defined in For convenience, the "ADDRESS-PART" syntax element defined in
[I-D.ietf-sieve-3028bis] Section 2.7.4 is augmented here as follows: [RFC5228], Section 2.7.4, is augmented here as follows:
ADDRESS-PART =/ ":user" / ":detail" ADDRESS-PART =/ ":user" / ":detail"
A diagram showing the ADDRESS-PARTs of a email address where the A diagram showing the ADDRESS-PARTs of an email address where the
detail information follows a separator character sequence of "+" is detail information follows a separator character sequence of "+" is
shown below: shown below:
:user "+" :detail "@" :domain :user "+" :detail "@" :domain
\-----------------/ \-----------------/
:local-part :local-part
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", "fileinto"]; require ["envelope", "subaddress", "fileinto"];
# In this example the same user account receives mail for both # In this example the same user account receives mail for both
# "ken@example.com" and "postmaster@example.com" # "ken@example.com" and "postmaster@example.com"
# File all messages to postmaster into a single mailbox, # File all messages to postmaster into a single mailbox,
# ignoring the :detail part. # ignoring the :detail part.
if envelope :user "to" "postmaster" { if envelope :user "to" "postmaster" {
fileinto "inbox.postmaster"; fileinto "inbox.postmaster";
stop; stop;
} }
skipping to change at page 8, line 7 skipping to change at page 5, line 7
fileinto "inbox.ietf-mta-filters"; fileinto "inbox.ietf-mta-filters";
} }
# Redirect all mail sent to "ken+foo". # Redirect all mail sent to "ken+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 The following template specifies the IANA registration of the
"subaddress" Sieve extension to point at this document and to update subaddress Sieve extension specified in this document. This
the contact information with the author's address. registration replaces that from RFC 3598:
To: iana@iana.org
Subject: Registration of new Sieve extension
Capability name: subaddress
Description: Adds the ':user' and ':detail' address parts
for use with the address and envelope tests
RFC number: RFC 5233
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
This information has been added to the list of Sieve extensions given
on http://www.iana.org/assignments/sieve-extensions.
6. Security Considerations 6. Security Considerations
Security considerations are discussed in [I-D.ietf-sieve-3028bis]. Security considerations are discussed in [RFC5228]. It is believed
It is believed that this extension does not introduce any additional that this extension does not introduce any additional security
security concerns. concerns.
7. Normative References 7. Normative References
[I-D.ietf-sieve-3028bis]
Showalter, T. and P. Guenther, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-06 (work in progress),
March 2006.
[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
April 2001. 2001.
[RFC5228] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, January 2008.
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,
Mark Mallett, and Barry Leiba 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
skipping to change at page 11, line 22 skipping to change at page 6, line 28
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 o Replaced ":user" example with one that doesn't produce unexpected
behavior. 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 RFC 5228).
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
Carnegie Mellon University Carnegie Mellon University
5000 Forbes Avenue 5000 Forbes Avenue
Cyert Hall 285 Cyert Hall 285
Pittsburgh, PA 15213 Pittsburgh, PA 15213
US USA
Phone: +1 412 268 2638 Phone: +1 412 268 2638
Email: murch@andrew.cmu.edu EMail: murch@andrew.cmu.edu
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
skipping to change at page 13, line 28 skipping to change at line 281
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 24 change blocks. 
78 lines changed or deleted 79 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/