7Network Working Group K. Murchison
8Request for Comments: 3598 Oceana Matrix Ltd.
9Category: Standards Track September 2003
12 Sieve Email Filtering -- Subaddress Extension
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright (C) The Internet Society (2003). All Rights Reserved.
28 On email systems that allow for "subaddressing" or "detailed
29 addressing" (e.g., "ken+sieve@example.org"), it is sometimes
30 desirable to make comparisons against these sub-parts of addresses.
31 This document defines an extension to the Sieve mail filtering
32 language that allows users to compare against the user and detail
37 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
38 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 2
39 3. Subaddress Comparisons. . . . . . . . . . . . . . . . . . . . 2
40 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
41 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
42 6. Normative References. . . . . . . . . . . . . . . . . . . . . 4
43 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
44 8. Intellectual Property Statement . . . . . . . . . . . . . . . 5
45 9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 5
46 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 6
58Murchison Standards Track [Page 1]
60RFC 3598 Sieve Email Filtering September 2003
65 Subaddressing is the practice of appending some "detail" information
66 to the local-part of an [IMAIL] address to indicate that the message
67 should be delivered to the mailbox specified by the "detail"
68 information. The "detail" information is prefixed with a special
69 "separator character" (typically "+") which forms the boundary
70 between the "user" (original local-part) and the "detail" sub-parts
71 of the address, much like the "@" character forms the boundary
72 between the local-part and domain.
74 Typical uses of subaddressing might be:
76 - A message addressed to "ken+sieve@example.org" is delivered into a
77 mailbox called "sieve" belonging to the user "ken".
79 - A message addressed to "5551212#123@example.org" is delivered to
80 the voice mailbox number "123" at phone number "5551212".
82 This document describes an extension to the Sieve language defined by
83 [SIEVE] for comparing against the "user" and "detail" sub-parts of an
86 Conventions for notations are as in [SIEVE] section 1.1, including
892. Capability Identifier
91 The capability string associated with the extension defined in this
92 document is "subaddress".
943. Subaddress Comparisons
96 Commands that act exclusively on addresses may take the optional
97 tagged arguments ":user" and ":detail" to specify what sub-part of
98 the local-part of the address will be acted upon.
100 NOTE: In most cases, the envelope "to" address is the preferred
101 address to examine for subaddress information when the desire is to
102 sort messages based on how they were addressed so as to get to a
103 specific recipient. The envelope address is, after all, the reason a
104 given message is being processed by a given sieve script for a given
105 user. This is particularly true when mailing lists, aliases, and
106 "virtual domains" are involved since the envelope may be the only
107 source of detail information for the specific recipient.
114Murchison Standards Track [Page 2]
116RFC 3598 Sieve Email Filtering September 2003
119 The ":user" argument specifies that sub-part of the local-part which
120 lies to the left of the separator character (e.g., "ken" in
121 "ken+sieve@example.org"). If no separator character exists, then
122 ":user" specifies the entire left-side of the address (equivalent to
125 The ":detail" argument specifies that sub-part of the local-part
126 which lies to the right of the separator character (e.g., "sieve" in
127 "ken+sieve@example.org"). If no separator character exists, the test
128 evaluates to false. If nothing lies to the right of the separator
129 character, then ":detail" ":is" the null key (""). Otherwise, the
130 ":detail" sub-part contains the null key.
132 Implementations MUST make sure that the separator character matches
133 that which is used and/or allowed by the encompassing mail system,
134 otherwise unexpected results might occur. Implementations SHOULD
135 allow the separator character to be configurable so that they may be
136 used with a variety of mail systems. Note that the mechanisms used
137 to define and/or query the separator character used by the mail
138 system are outside the scope of this document.
140 The ":user" and ":detail" address parts are subject to the same rules
141 and restrictions as the standard address parts defined in [SIEVE].
142 For convenience, the "ADDRESS-PART" syntax element defined in [SIEVE]
143 is augmented here as follows:
145 ADDRESS-PART =/ ":user" / ":detail"
147 A diagram showing the ADDRESS-PARTs of a email address utilizing a
148 separator character of '+' is shown below:
150 :user "+" :detail "@" :domain
156 require "subaddress";
158 # File mailing list messages (subscribed as "ken+mta-filters").
159 if envelope :detail "to" "mta-filters" {
160 fileinto "inbox.ietf-mta-filters";
163 # If a message is not to me (ignoring +detail), junk it.
164 if not allof (address :user ["to", "cc", "bcc"] "ken",
165 address :domain ["to", "cc", "bcc"] "example.org") {
170Murchison Standards Track [Page 3]
172RFC 3598 Sieve Email Filtering September 2003
177 # Redirect all mail sent to +foo.
178 if envelope :detail ["to", "cc", "bcc"] "foo" {
179 redirect "ken@example.edu";
1824. Security Considerations
184 Security considerations are discussed in [SIEVE]. It is believed
185 that this extension does not introduce any additional security
1885. IANA Considerations
190 The following template specifies the IANA registration of the Sieve
191 extension specified in this document:
194 Subject: Registration of new Sieve extension
196 Capability name: subaddress
197 Capability keyword: subaddress
198 Capability arguments: N/A
199 Standards Track/RFC 3598
200 Person and email address to contact for further information:
205 This information has been added to the list of sieve extensions given
206 on http://www.iana.org/assignments/sieve-extensions.
2086. Normative References
210 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822,
213 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
214 Requirement Levels", BCP 14, RFC 2119, March 1997.
216 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC
226Murchison Standards Track [Page 4]
228RFC 3598 Sieve Email Filtering September 2003
233 Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall
234 Gellens, Philip Guenther and Jutta Degener for their help with this
2378. Intellectual Property Statement
239 The IETF takes no position regarding the validity or scope of any
240 intellectual property or other rights that might be claimed to
241 pertain to the implementation or use of the technology described in
242 this document or the extent to which any license under such rights
243 might or might not be available; neither does it represent that it
244 has made any effort to identify any such rights. Information on the
245 IETF's procedures with respect to rights in standards-track and
246 standards-related documentation can be found in BCP-11. Copies of
247 claims of rights made available for publication and any assurances of
248 licenses to be made available, or the result of an attempt made to
249 obtain a general license or permission for the use of such
250 proprietary rights by implementors or users of this specification can
251 be obtained from the IETF Secretariat.
253 The IETF invites any interested party to bring to its attention any
254 copyrights, patents or patent applications, or other proprietary
255 rights which may cover technology that may be required to practice
256 this standard. Please address the information to the IETF Executive
264 Orchard Park, NY 14127
266 EMail: ken@oceana.com
282Murchison Standards Track [Page 5]
284RFC 3598 Sieve Email Filtering September 2003
28710. Full Copyright Statement
289 Copyright (C) The Internet Society (2003). All Rights Reserved.
291 This document and translations of it may be copied and furnished to
292 others, and derivative works that comment on or otherwise explain it
293 or assist in its implementation may be prepared, copied, published
294 and distributed, in whole or in part, without restriction of any
295 kind, provided that the above copyright notice and this paragraph are
296 included on all such copies and derivative works. However, this
297 document itself may not be modified in any way, such as by removing
298 the copyright notice or references to the Internet Society or other
299 Internet organizations, except as needed for the purpose of
300 developing Internet standards in which case the procedures for
301 copyrights defined in the Internet Standards process must be
302 followed, or as required to translate it into languages other than
305 The limited permissions granted above are perpetual and will not be
306 revoked by the Internet Society or its successors or assignees.
308 This document and the information contained herein is provided on an
309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
317 Funding for the RFC Editor function is currently provided by the
338Murchison Standards Track [Page 6]