idnits 2.17.1 draft-ietf-sieve-rfc3598bis-03.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 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 293. ** 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 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 (April 18, 2006) is 6583 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) April 18, 2006 5 Expires: October 20, 2006 7 Sieve Email Filtering -- Subaddress Extension 8 draft-ietf-sieve-rfc3598bis-03 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 October 20, 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 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. Conventions used in this document . . . . . . . . . . . . . . 5 71 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 6 72 4. Subaddress Comparisons . . . . . . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 77 Appendix B. Changes since RFC3598 . . . . . . . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Intellectual Property and Copyright Statements . . . . . . . . . . 14 81 1. Introduction 83 Subaddressing is the practice of augmenting the local-part of an 84 [RFC2822] address with some "detail" information to indicate that the 85 message should be delivered to the mailbox specified by the "detail" 86 information. One common way of encoding "detail" information into 87 the local-part is to add a "separator character sequence", such as 88 "+", to form a boundary between the "user" (original local-part) and 89 "detail" sub-parts of the address, much like the "@" character forms 90 the boundary between the local-part and domain. 92 Typical uses of subaddressing might be: 94 o A message addressed to "ken+sieve@example.org" is delivered into a 95 mailbox called "sieve" belonging to the user "ken". 97 o A message addressed to "5551212#123@example.com" is delivered to 98 the voice mailbox number "123" at phone number "5551212". 100 This document describes an extension to the Sieve language defined by 101 [I-D.ietf-sieve-3028bis] for comparing against the "user" and 102 "detail" sub-parts of an address. 104 2. Conventions used in this document 106 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 107 1.1. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Capability Identifier 115 The capability string associated with the extension defined in this 116 document is "subaddress". 118 4. Subaddress Comparisons 120 Test commands that act exclusively on addresses may take the optional 121 tagged arguments ":user" and ":detail" to specify what sub-part of 122 the local-part of the address will be acted upon. 124 NOTE: In most cases, the envelope "to" address is the preferred 125 address to examine for subaddress information when the desire is 126 to sort messages based on how they were addressed so as to get to 127 a specific recipient. The envelope address is, after all, the 128 reason a given message is being processed by a given sieve script 129 for a given user. This is particularly true when mailing lists, 130 aliases, and "virtual domains" are involved since the envelope may 131 be the only source of detail information for the specific 132 recipient. 134 NOTE: Because the encoding of detailed addresses are site and/or 135 implementation specific, using the subaddress extension on foreign 136 addresses (such as the envelope "from" address or originator 137 header fields) may lead to inconsistent or incorrect results. 139 The ":user" argument specifies the user sub-part of the local-part of 140 an address. If the address is not encoded to contain a detail sub- 141 part, then ":user" specifies the entire left-side of the address 142 (equivalent to ":localpart"). 144 The ":detail" argument specifies the detail sub-part of the local- 145 part of an address. If the address is not encoded to contain a 146 detail sub-part, then the test evaluates to false. If a zero-length 147 string is encoded as the detail sub-part, then ":detail" ":is" the 148 empty key (""). 150 NOTE: If the encoding method used for detailed addresses utilizes 151 a separator character sequence, and the separator character 152 sequence occurs more than once in the local-part, then the logic 153 used to split the address is implementation defined, and is 154 usually dependent on the format used by the encompassing mail 155 system. 157 Implementations MUST make sure that the encoding method used for 158 detailed addresses matches that which is used and/or allowed by the 159 encompassing mail system, otherwise unexpected results might occur. 160 Note that the mechanisms used to define and/or query the encoding 161 method used by the mail system are outside the scope of this 162 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] Section 2.7.4. 168 For convenience, the "ADDRESS-PART" syntax element defined in 169 [I-D.ietf-sieve-3028bis] Section 2.7.4 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.net"; 207 } 209 5. IANA Considerations 211 This document requests that the IANA update the entry for the 212 "subaddress" Sieve extension to point at this document. 214 6. 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 7. Normative References 222 [I-D.ietf-sieve-3028bis] 223 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 224 Language", draft-ietf-sieve-3028bis-06 (work in progress), 225 March 2006. 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, Jutta Degener, Michael Haardt, and Ned 237 Freed for their help with this document. 239 Appendix B. Changes since RFC3598 241 o Discussion of how the user and detail information is encoded now 242 uses generic language. 244 o Added note detailing that this extension is most useful when used 245 on the envelope "to" address. 247 o Added note detailing that this extension isn't very useful on 248 foreign addresses (envelope "from" or originator header fields). 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 Use only RFC 2606 domains in examples. 257 o Miscellaneous editorial changes. 259 Author's Address 261 Kenneth Murchison 262 Carnegie Mellon University 263 5000 Forbes Avenue 264 Cyert Hall 285 265 Pittsburgh, PA 15213 266 US 268 Phone: +1 412 268 2638 269 Email: murch@andrew.cmu.edu 271 Intellectual Property Statement 273 The IETF takes no position regarding the validity or scope of any 274 Intellectual Property Rights or other rights that might be claimed to 275 pertain to the implementation or use of the technology described in 276 this document or the extent to which any license under such rights 277 might or might not be available; nor does it represent that it has 278 made any independent effort to identify any such rights. Information 279 on the procedures with respect to rights in RFC documents can be 280 found in BCP 78 and BCP 79. 282 Copies of IPR disclosures made to the IETF Secretariat and any 283 assurances of licenses to be made available, or the result of an 284 attempt made to obtain a general license or permission for the use of 285 such proprietary rights by implementers or users of this 286 specification can be obtained from the IETF on-line IPR repository at 287 http://www.ietf.org/ipr. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights that may cover technology that may be required to implement 292 this standard. Please address the information to the IETF at 293 ietf-ipr@ietf.org. 295 Disclaimer of Validity 297 This document and the information contained herein are provided on an 298 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 299 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 300 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 301 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 302 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 305 Copyright Statement 307 Copyright (C) The Internet Society (2006). This document is subject 308 to the rights, licenses and restrictions contained in BCP 78, and 309 except as set forth therein, the authors retain all their rights. 311 Acknowledgment 313 Funding for the RFC Editor function is currently provided by the 314 Internet Society.