7Network Working Group K. Murchison
8Request for Comments: 5233 Carnegie Mellon University
9Obsoletes: 3598 January 2008
10Category: Standards Track
13 Sieve Email Filtering: Subaddress Extension
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 On email systems that allow for 'subaddressing' or 'detailed
26 addressing' (e.g., "ken+sieve@example.org"), it is sometimes
27 desirable to make comparisons against these sub-parts of addresses.
28 This document defines an extension to the Sieve Email Filtering
29 Language that allows users to compare against the user and detail
30 sub-parts of an address.
34 1. Introduction ....................................................2
35 2. Conventions Used in This Document ...............................2
36 3. Capability Identifier ...........................................2
37 4. Subaddress Comparisons ..........................................2
38 5. IANA Considerations .............................................5
39 6. Security Considerations .........................................5
40 7. Normative References ............................................5
41 Appendix A. Acknowledgments ........................................6
42 Appendix B. Changes since RFC 3598 .................................6
58Murchison Standards Track [Page 1]
60RFC 5233 Sieve: Subaddress Extension January 2008
65 Subaddressing is the practice of augmenting the local-part of an
66 [RFC2822] address with some 'detail' information in order to give
67 some extra meaning to that address. One common way of encoding
68 'detail' information into the local-part is to add a 'separator
69 character sequence', such as "+", to form a boundary between the
70 'user' (original local-part) and 'detail' sub-parts of the address,
71 much like the "@" character forms the boundary between the local-part
74 Typical uses of subaddressing might be:
76 o A message addressed to "ken+sieve@example.org" is delivered into a
77 mailbox called "sieve" belonging to the user "ken".
79 o A message addressed to "5551212#123@example.com" 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 [RFC5228] for comparing against the 'user' and 'detail' sub-parts of
862. Conventions Used in This Document
88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
90 document are to be interpreted as described in [RFC2119].
923. Capability Identifier
94 The capability string associated with the extension defined in this
95 document is "subaddress".
974. Subaddress Comparisons
99 Test commands that act exclusively on addresses may take the optional
100 tagged arguments ":user" and ":detail" to specify what sub-part of
101 the local-part of the address will be acted upon.
103 NOTE: In most cases, the envelope "to" address is the preferred
104 address to examine for subaddress information when the desire is
105 to sort messages based on how they were addressed so as to get to
106 a specific recipient. The envelope address is, after all, the
107 reason a given message is being processed by a given sieve script
108 for a given user. This is particularly true when mailing lists,
114Murchison Standards Track [Page 2]
116RFC 5233 Sieve: Subaddress Extension January 2008
119 aliases, and 'virtual domains' are involved since the envelope may
120 be the only source of detail information for the specific
123 NOTE: Because the encoding of detailed addresses are site and/or
124 implementation specific, using the subaddress extension on foreign
125 addresses (such as the envelope "from" address or originator
126 header fields) may lead to inconsistent or incorrect results.
128 The ":user" argument specifies the user sub-part of the local-part of
129 an address. If the address is not encoded to contain a detail sub-
130 part, then ":user" specifies the entire left side of the address
131 (equivalent to ":localpart").
133 The ":detail" argument specifies the detail sub-part of the local-
134 part of an address. If the address is not encoded to contain a
135 detail sub-part, then the address fails to match any of the specified
136 keys. If a zero-length string is encoded as the detail sub-part,
137 then ":detail" resolves to the empty value ("").
139 NOTE: If the encoding method used for detailed addresses utilizes
140 a separator character sequence, and the separator character
141 sequence occurs more than once in the local-part, then the logic
142 used to split the address is implementation-defined and is usually
143 dependent on the format used by the encompassing mail system.
145 Implementations MUST make sure that the encoding method used for
146 detailed addresses matches that which is used and/or allowed by the
147 encompassing mail system, otherwise unexpected results might occur.
148 Note that the mechanisms used to define and/or query the encoding
149 method used by the mail system are outside the scope of this
152 The ":user" and ":detail" address parts are subject to the same rules
153 and restrictions as the standard address parts defined in [RFC5228],
156 For convenience, the "ADDRESS-PART" syntax element defined in
157 [RFC5228], Section 2.7.4, is augmented here as follows:
159 ADDRESS-PART =/ ":user" / ":detail"
161 A diagram showing the ADDRESS-PARTs of an email address where the
162 detail information follows a separator character sequence of "+" is
170Murchison Standards Track [Page 3]
172RFC 5233 Sieve: Subaddress Extension January 2008
175 :user "+" :detail "@" :domain
179 A diagram showing the ADDRESS-PARTs of a email address where the
180 detail information precedes a separator character sequence of "--" is
183 :detail "--" :user "@" :domain
187 Example (where the detail information follows "+"):
189 require ["envelope", "subaddress", "fileinto"];
191 # In this example the same user account receives mail for both
192 # "ken@example.com" and "postmaster@example.com"
194 # File all messages to postmaster into a single mailbox,
195 # ignoring the :detail part.
196 if envelope :user "to" "postmaster" {
197 fileinto "inbox.postmaster";
201 # File mailing list messages (subscribed as "ken+mta-filters").
202 if envelope :detail "to" "mta-filters" {
203 fileinto "inbox.ietf-mta-filters";
206 # Redirect all mail sent to "ken+foo".
207 if envelope :detail "to" "foo" {
208 redirect "ken@example.net";
226Murchison Standards Track [Page 4]
228RFC 5233 Sieve: Subaddress Extension January 2008
2315. IANA Considerations
233 The following template specifies the IANA registration of the
234 subaddress Sieve extension specified in this document. This
235 registration replaces that from RFC 3598:
238 Subject: Registration of new Sieve extension
240 Capability name: subaddress
241 Description: Adds the ':user' and ':detail' address parts
242 for use with the address and envelope tests
244 Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
246 This information has been added to the list of Sieve extensions given
247 on http://www.iana.org/assignments/sieve-extensions.
2496. Security Considerations
251 Security considerations are discussed in [RFC5228]. It is believed
252 that this extension does not introduce any additional security
2557. Normative References
257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
258 Requirement Levels", BCP 14, RFC 2119, March 1997.
260 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
263 [RFC5228] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email
264 Filtering Language", RFC 5228, January 2008.
282Murchison Standards Track [Page 5]
284RFC 5233 Sieve: Subaddress Extension January 2008
287Appendix A. Acknowledgments
289 Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall
290 Gellens, Philip Guenther, Jutta Degener, Michael Haardt, Ned Freed,
291 Mark Mallett, and Barry Leiba for their help with this document.
293Appendix B. Changes since RFC 3598
295 o Discussion of how the user and detail information is encoded now
296 uses generic language.
298 o Added note detailing that this extension is most useful when used
299 on the envelope "to" address.
301 o Added note detailing that this extension isn't very useful on
302 foreign addresses (envelope "from" or originator header fields).
304 o Fixed envelope test example to only use "to" address.
306 o Replaced ":user" example with one that doesn't produce unexpected
309 o Refer to the zero-length string ("") as "empty" instead of "null"
312 o Use only RFC 2606 domains in examples.
314 o Miscellaneous editorial changes.
319 Carnegie Mellon University
325 Phone: +1 412 268 2638
326 EMail: murch@andrew.cmu.edu
338Murchison Standards Track [Page 6]
340RFC 5233 Sieve: Subaddress Extension January 2008
343Full Copyright Statement
345 Copyright (C) The IETF Trust (2008).
347 This document is subject to the rights, licenses and restrictions
348 contained in BCP 78, and except as set forth therein, the authors
349 retain all their rights.
351 This document and the information contained herein are provided on an
352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
361 The IETF takes no position regarding the validity or scope of any
362 Intellectual Property Rights or other rights that might be claimed to
363 pertain to the implementation or use of the technology described in
364 this document or the extent to which any license under such rights
365 might or might not be available; nor does it represent that it has
366 made any independent effort to identify any such rights. Information
367 on the procedures with respect to rights in RFC documents can be
368 found in BCP 78 and BCP 79.
370 Copies of IPR disclosures made to the IETF Secretariat and any
371 assurances of licenses to be made available, or the result of an
372 attempt made to obtain a general license or permission for the use of
373 such proprietary rights by implementers or users of this
374 specification can be obtained from the IETF on-line IPR repository at
375 http://www.ietf.org/ipr.
377 The IETF invites any interested party to bring to its attention any
378 copyrights, patents or patent applications, or other proprietary
379 rights that may cover technology that may be required to implement
380 this standard. Please address the information to the IETF at
394Murchison Standards Track [Page 7]