idnits 2.17.1 draft-ietf-sieve-rfc3598bis-02.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 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 291. ** 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 directly say this. It does mention RFC3598 though, so this could be OK. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 15, 2006) is 6638 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-05 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 4 errors (**), 0 flaws (~~), 4 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) February 15, 2006 5 Expires: August 19, 2006 7 Sieve Email Filtering -- Subaddress Extension 8 draft-ietf-sieve-rfc3598bis-02.txt 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 August 19, 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 parts of an address. 48 Meta-information on this document 49 This information is intended to facilitate discussion. It will be 50 removed when this document leaves the Internet-Draft stage. 52 This document is intended to be an update to the existing 53 "subaddress" extension to the Sieve mail filtering language, 54 available from the RFC repository as 55 and 56 57 respectively. 59 This document and the Sieve language itself are being discussed on 60 the MTA Filters mailing list at . 61 Subscription requests can be sent to 62 (send an 63 email message with the word "subscribe" in the body). More 64 information on the mailing list along with an archive of back 65 messages is available at . 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 5 71 3. Subaddress Comparisons . . . . . . . . . . . . . . . . . . . . 6 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 76 Appendix B. Changes since RFC3598 . . . . . . . . . . . . . . . . 12 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 Intellectual Property and Copyright Statements . . . . . . . . . . 14 80 1. Introduction 82 Subaddressing is the practice of augmenting (usually with a suffix) 83 the local-part of an [RFC2822] address with some "detail" information 84 to indicate that the message should be delivered to the mailbox 85 specified by the "detail" information. A "separator character 86 sequence" (typically "+"), forms the boundary between the "user" 87 (original local-part) and "detail" sub-parts of the address, much 88 like the "@" character forms the boundary between the local-part and 89 domain. 91 Typical uses of subaddressing might be: 93 o A message addressed to "ken+sieve@example.org" is delivered into a 94 mailbox called "sieve" belonging to the user "ken". 96 o A message addressed to "5551212#123@example.org" is delivered to 97 the voice mailbox number "123" at phone number "5551212". 99 This document describes an extension to the Sieve language defined by 100 [I-D.ietf-sieve-3028bis] for comparing against the "user" and 101 "detail" sub-parts of an address. 103 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 104 1.1, including use of [RFC2119]. 106 2. Capability Identifier 108 The capability string associated with the extension defined in this 109 document is "subaddress". 111 3. Subaddress Comparisons 113 Commands that act exclusively on addresses may take the optional 114 tagged arguments ":user" and ":detail" to specify what sub-part of 115 the local-part of the address will be acted upon. 117 NOTE: In most cases, the envelope "to" address is the preferred 118 address to examine for subaddress information when the desire is 119 to sort messages based on how they were addressed so as to get to 120 a specific recipient. The envelope address is, after all, the 121 reason a given message is being processed by a given sieve script 122 for a given user. This is particularly true when mailing lists, 123 aliases, and "virtual domains" are involved since the envelope may 124 be the only source of detail information for the specific 125 recipient. 127 NOTE: Because the construction of detailed addresses can be site 128 and/or implementation specific, using the subaddress extension on 129 foreign addresses (such as the envelope "from" address or 130 originator header fields) may lead to inconsistent or incorrect 131 results. 133 The ":user" argument specifies the user sub-part of the local-part of 134 an address. The positioning of the user sub-part with respect to the 135 separator character sequence is dependent on the encompassing mail 136 system. If no separator character sequence exists, then ":user" 137 specifies the entire left-side of the address (equivalent to 138 ":localpart"). 140 The ":detail" argument specifies the detail sub-part of the local- 141 part of an address. The positioning of the detail sub-part with 142 respect to the separator character sequence is dependent on the 143 encompassing mail system. If no separator character sequence exists, 144 the test evaluates to false. If the separator character sequence 145 exists, but no detail information is provided, then ":detail" ":is" 146 the empty key (""). Otherwise, the ":detail" sub-part ":contains" 147 the empty key. 149 NOTE: If the separator character sequence occurs more than once in 150 the local-part, then the logic used to split the address is 151 implementation defined, and is usually dependent on the format 152 used by the encompassing mail system. 154 Implementations MUST make sure that the separator character sequence 155 and the ordering of the user and detail sub-parts match those that 156 are used and/or allowed by the encompassing mail system, otherwise 157 unexpected results might occur. Implementations SHOULD allow the 158 separator character sequence and sub-part ordering to be configurable 159 so that they may be used with a variety of mail systems. Note that 160 the mechanisms used to define and/or query the separator character 161 sequence and sub-part ordering used by the mail system are outside 162 the scope of this document. 164 The ":user" and ":detail" address parts are subject to the same rules 165 and restrictions as the standard address parts defined in [I-D.ietf- 166 sieve-3028bis]. 168 For convenience, the "ADDRESS-PART" syntax element defined in 169 [I-D.ietf-sieve-3028bis] is augmented here as follows: 171 ADDRESS-PART =/ ":user" / ":detail" 173 A diagram showing the ADDRESS-PARTs of a email address where the 174 detail information follows a separator character sequence of "+" is 175 shown below: 177 :user "+" :detail "@" :domain 178 `-----------------' 179 :local-part 181 A diagram showing the ADDRESS-PARTs of a email address where the 182 detail information precedes a separator character sequence of "--" is 183 shown below: 185 :detail "--" :user "@" :domain 186 `------------------' 187 :local-part 189 Example (where the detail information follows "+"): 191 require "subaddress"; 193 # File mailing list messages (subscribed as "ken+mta-filters"). 194 if envelope :detail "to" "mta-filters" { 195 fileinto "inbox.ietf-mta-filters"; 196 } 198 # If a message is not directly to me (ignoring +detail), junk it. 199 if not allof (address :user ["to", "cc"] "ken", 200 address :domain ["to", "cc"] "example.org") { 201 discard; 202 } 204 # Redirect all mail sent to +foo. 205 if envelope :detail "to" "foo" { 206 redirect "ken@example.edu"; 207 } 209 4. IANA Considerations 211 This document requests that the IANA update the entry for the 212 "subaddress" Sieve extension to point at this document. 214 5. Security Considerations 216 Security considerations are discussed in [I-D.ietf-sieve-3028bis]. 217 It is believed that this extension does not introduce any additional 218 security concerns. 220 6. Normative References 222 [I-D.ietf-sieve-3028bis] 223 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 224 Language", draft-ietf-sieve-3028bis-05 (work in progress), 225 November 2005. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 231 April 2001. 233 Appendix A. Acknowledgments 235 Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall 236 Gellens, Philip Guenther and Jutta Degener for their help with this 237 document. 239 Appendix B. Changes since RFC3598 241 o Allow detail information to be either or prefix or suffix to the 242 user. 244 o Allow boundary between user and detail parts to be multiple 245 characters. 247 o Added note regarding processing of local-part with multiple 248 separator character sequences. 250 o Fixed envelope test example to only use "to" address. 252 o Refer to the zero-length string ("") as "empty" instead of "null" 253 (per draft-ietf-sieve-3028bis) 255 o Miscellaneous editorial changes. 257 Author's Address 259 Kenneth Murchison 260 Carnegie Mellon University 261 5000 Forbes Avenue 262 Cyert Hall 285 263 Pittsburgh, PA 15213 264 US 266 Phone: +1 412 268 2638 267 Email: murch@andrew.cmu.edu 269 Intellectual Property Statement 271 The IETF takes no position regarding the validity or scope of any 272 Intellectual Property Rights or other rights that might be claimed to 273 pertain to the implementation or use of the technology described in 274 this document or the extent to which any license under such rights 275 might or might not be available; nor does it represent that it has 276 made any independent effort to identify any such rights. Information 277 on the procedures with respect to rights in RFC documents can be 278 found in BCP 78 and BCP 79. 280 Copies of IPR disclosures made to the IETF Secretariat and any 281 assurances of licenses to be made available, or the result of an 282 attempt made to obtain a general license or permission for the use of 283 such proprietary rights by implementers or users of this 284 specification can be obtained from the IETF on-line IPR repository at 285 http://www.ietf.org/ipr. 287 The IETF invites any interested party to bring to its attention any 288 copyrights, patents or patent applications, or other proprietary 289 rights that may cover technology that may be required to implement 290 this standard. Please address the information to the IETF at 291 ietf-ipr@ietf.org. 293 Disclaimer of Validity 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 298 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 299 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 300 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Copyright Statement 305 Copyright (C) The Internet Society (2006). This document is subject 306 to the rights, licenses and restrictions contained in BCP 78, and 307 except as set forth therein, the authors retain all their rights. 309 Acknowledgment 311 Funding for the RFC Editor function is currently provided by the 312 Internet Society.