idnits 2.17.1 draft-ietf-sieve-rfc3598bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 279. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3598, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 15, 2006) is 6522 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-06 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group K. Murchison 3 Internet-Draft Carnegie Mellon University 4 Obsoletes: 3598 (if approved) June 15, 2006 5 Expires: December 17, 2006 7 Sieve Email Filtering -- Subaddress Extension 8 draft-ietf-sieve-rfc3598bis-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 17, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 On email systems that allow for 'subaddressing' or 'detailed 42 addressing' (e.g., "ken+sieve@example.org"), it is sometimes 43 desirable to make comparisons against these sub-parts of addresses. 44 This document defines an extension to the Sieve mail filtering 45 language that allows users to compare against the user and detail 46 sub-parts of an address. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions used in this document . . . . . . . . . . . . . . 4 52 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 5 53 4. Subaddress Comparisons . . . . . . . . . . . . . . . . . . . . 6 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 56 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 57 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 58 Appendix B. Changes since RFC3598 . . . . . . . . . . . . . . . . 11 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 Intellectual Property and Copyright Statements . . . . . . . . . . 13 62 1. Introduction 64 Subaddressing is the practice of augmenting the local-part of an 65 [RFC2822] address with some 'detail' information in order to give 66 some extra meaning to that address. One common way of encoding 67 'detail' information into the local-part is to add a 'separator 68 character sequence', such as "+", to form a boundary between the 69 'user' (original local-part) and 'detail' sub-parts of the address, 70 much like the "@" character forms the boundary between the local-part 71 and domain. 73 Typical uses of subaddressing might be: 75 o A message addressed to "ken+sieve@example.org" is delivered into a 76 mailbox called "sieve" belonging to the user "ken". 78 o A message addressed to "5551212#123@example.com" is delivered to 79 the voice mailbox number "123" at phone number "5551212". 81 This document describes an extension to the Sieve language defined by 82 [I-D.ietf-sieve-3028bis] for comparing against the 'user' and 83 'detail' sub-parts of an address. 85 2. Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Capability Identifier 93 The capability string associated with the extension defined in this 94 document is "subaddress". 96 4. Subaddress Comparisons 98 Test commands that act exclusively on addresses may take the optional 99 tagged arguments ":user" and ":detail" to specify what sub-part of 100 the local-part of the address will be acted upon. 102 NOTE: In most cases, the envelope "to" address is the preferred 103 address to examine for subaddress information when the desire is 104 to sort messages based on how they were addressed so as to get to 105 a specific recipient. The envelope address is, after all, the 106 reason a given message is being processed by a given sieve script 107 for a given user. This is particularly true when mailing lists, 108 aliases, and 'virtual domains' are involved since the envelope may 109 be the only source of detail information for the specific 110 recipient. 112 NOTE: Because the encoding of detailed addresses are site and/or 113 implementation specific, using the subaddress extension on foreign 114 addresses (such as the envelope "from" address or originator 115 header fields) may lead to inconsistent or incorrect results. 117 The ":user" argument specifies the user sub-part of the local-part of 118 an address. If the address is not encoded to contain a detail sub- 119 part, then ":user" specifies the entire left-side of the address 120 (equivalent to ":localpart"). 122 The ":detail" argument specifies the detail sub-part of the local- 123 part of an address. If the address is not encoded to contain a 124 detail sub-part, then the test evaluates to false. If a zero-length 125 string is encoded as the detail sub-part, then ":detail" resolves to 126 the empty value (""). 128 NOTE: If the encoding method used for detailed addresses utilizes 129 a separator character sequence, and the separator character 130 sequence occurs more than once in the local-part, then the logic 131 used to split the address is implementation defined, and is 132 usually dependent on the format used by the encompassing mail 133 system. 135 Implementations MUST make sure that the encoding method used for 136 detailed addresses matches that which is used and/or allowed by the 137 encompassing mail system, otherwise unexpected results might occur. 138 Note that the mechanisms used to define and/or query the encoding 139 method used by the mail system are outside the scope of this 140 document. 142 The ":user" and ":detail" address parts are subject to the same rules 143 and restrictions as the standard address parts defined in [I-D.ietf- 144 sieve-3028bis] Section 2.7.4. 146 For convenience, the "ADDRESS-PART" syntax element defined in 147 [I-D.ietf-sieve-3028bis] Section 2.7.4 is augmented here as follows: 149 ADDRESS-PART =/ ":user" / ":detail" 151 A diagram showing the ADDRESS-PARTs of a email address where the 152 detail information follows a separator character sequence of "+" is 153 shown below: 155 :user "+" :detail "@" :domain 156 \-----------------/ 157 :local-part 159 A diagram showing the ADDRESS-PARTs of a email address where the 160 detail information precedes a separator character sequence of "--" is 161 shown below: 163 :detail "--" :user "@" :domain 164 \------------------/ 165 :local-part 167 Example (where the detail information follows "+"): 169 require ["subaddress", "fileinto"]; 171 # In this example the same user account receives mail for both 172 # "ken@example.com" and "postmaster@example.com" 174 # File all messages to postmaster into a single mailbox, 175 # ignoring the :detail part. 176 if envelope :user "to" "postmaster" { 177 fileinto "inbox.postmaster"; 178 stop; 179 } 181 # File mailing list messages (subscribed as "ken+mta-filters"). 182 if envelope :detail "to" "mta-filters" { 183 fileinto "inbox.ietf-mta-filters"; 184 } 186 # Redirect all mail sent to "ken+foo". 187 if envelope :detail "to" "foo" { 188 redirect "ken@example.net"; 189 } 191 5. IANA Considerations 193 This document requests that the IANA update the entry for the 194 "subaddress" Sieve extension to point at this document and to update 195 the contact information with the author's address. 197 6. Security Considerations 199 Security considerations are discussed in [I-D.ietf-sieve-3028bis]. 200 It is believed that this extension does not introduce any additional 201 security concerns. 203 7. Normative References 205 [I-D.ietf-sieve-3028bis] 206 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 207 Language", draft-ietf-sieve-3028bis-06 (work in progress), 208 March 2006. 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, March 1997. 213 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 214 April 2001. 216 Appendix A. Acknowledgments 218 Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall 219 Gellens, Philip Guenther, Jutta Degener, Michael Haardt, Ned Freed, 220 Mark Mallett, and Barry Leiba for their help with this document. 222 Appendix B. Changes since RFC3598 224 o Discussion of how the user and detail information is encoded now 225 uses generic language. 227 o Added note detailing that this extension is most useful when used 228 on the envelope "to" address. 230 o Added note detailing that this extension isn't very useful on 231 foreign addresses (envelope "from" or originator header fields). 233 o Fixed envelope test example to only use "to" address. 235 o Replaced ":user" example with one that doesn't produce unexpected 236 behavior. 238 o Refer to the zero-length string ("") as "empty" instead of "null" 239 (per draft-ietf-sieve-3028bis) 241 o Use only RFC 2606 domains in examples. 243 o Miscellaneous editorial changes. 245 Author's Address 247 Kenneth Murchison 248 Carnegie Mellon University 249 5000 Forbes Avenue 250 Cyert Hall 285 251 Pittsburgh, PA 15213 252 US 254 Phone: +1 412 268 2638 255 Email: murch@andrew.cmu.edu 257 Intellectual Property Statement 259 The IETF takes no position regarding the validity or scope of any 260 Intellectual Property Rights or other rights that might be claimed to 261 pertain to the implementation or use of the technology described in 262 this document or the extent to which any license under such rights 263 might or might not be available; nor does it represent that it has 264 made any independent effort to identify any such rights. Information 265 on the procedures with respect to rights in RFC documents can be 266 found in BCP 78 and BCP 79. 268 Copies of IPR disclosures made to the IETF Secretariat and any 269 assurances of licenses to be made available, or the result of an 270 attempt made to obtain a general license or permission for the use of 271 such proprietary rights by implementers or users of this 272 specification can be obtained from the IETF on-line IPR repository at 273 http://www.ietf.org/ipr. 275 The IETF invites any interested party to bring to its attention any 276 copyrights, patents or patent applications, or other proprietary 277 rights that may cover technology that may be required to implement 278 this standard. Please address the information to the IETF at 279 ietf-ipr@ietf.org. 281 Disclaimer of Validity 283 This document and the information contained herein are provided on an 284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 286 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 287 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 288 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 291 Copyright Statement 293 Copyright (C) The Internet Society (2006). This document is subject 294 to the rights, licenses and restrictions contained in BCP 78, and 295 except as set forth therein, the authors retain all their rights. 297 Acknowledgment 299 Funding for the RFC Editor function is currently provided by the 300 Internet Society.