idnits 2.17.1 draft-ietf-sieve-rfc3598bis-00.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 254. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 7, 2005) is 7018 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) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3028 (Obsoleted by RFC 5228, RFC 5429) Summary: 7 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 Oceana Matrix Ltd. 4 Obsoletes: 3598 (if approved) February 7, 2005 5 Expires: August 11, 2005 7 Sieve Email Filtering -- Subaddress Extension 8 draft-ietf-sieve-rfc3598bis-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 11, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 On email systems that allow for "subaddressing" or "detailed 44 addressing" (e.g., "ken+sieve@example.org"), it is sometimes 45 desirable to make comparisons against these sub-parts of addresses. 46 This document defines an extension to the Sieve mail filtering 47 language that allows users to compare against the user and detail 48 parts of an address. 50 Meta-information on this document 52 This information is intended to facilitate discussion. It will be 53 removed when this document leaves the Internet-Draft stage. 55 This document is intended to be an update to the existing 56 "subaddress" extension to the Sieve mail filtering language, 57 available from the RFC repository as 58 and 59 respectively. 61 This document and the Sieve language itself are being discussed on 62 the MTA Filters mailing list at . 63 Subscription requests can be sent to 64 (send an 65 email message with the word "subscribe" in the body). More 66 information on the mailing list along with a WWW archive of back 67 messages is available at . 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 5 73 3. Subaddress Comparisons . . . . . . . . . . . . . . . . . . . 6 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 75 5. Security Considerations . . . . . . . . . . . . . . . . . . 9 76 6. Normative References . . . . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 78 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 79 B. Changes since RFC3598 . . . . . . . . . . . . . . . . . . . 11 80 Intellectual Property and Copyright Statements . . . . . . . 12 82 1. Introduction 84 Subaddressing is the practice of appending some "detail" information 85 to the local-part of an [RFC2822] address to indicate that the 86 message should be delivered to the mailbox specified by the "detail" 87 information. The "detail" information is prefixed with a special 88 "separator character" (typically "+") which forms the boundary 89 between the "user" (original local-part) and the "detail" sub-parts 90 of the address, much like the "@" character forms the boundary 91 between the local-part and domain. 93 Typical uses of subaddressing might be: 95 o A message addressed to "ken+sieve@example.org" is delivered into a 96 mailbox called "sieve" belonging to the user "ken". 97 o A message addressed to "5551212#123@example.org" 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 [RFC3028] for comparing against the "user" and "detail" sub-parts of 102 an address. 104 Conventions for notations are as in [RFC3028] section 1.1, including 105 use of [RFC2119]. 107 2. Capability Identifier 109 The capability string associated with the extension defined in this 110 document is "subaddress". 112 3. Subaddress Comparisons 114 Commands that act exclusively on addresses may take the optional 115 tagged arguments ":user" and ":detail" to specify what sub-part of 116 the local-part of the address will be acted upon. 118 NOTE: In most cases, the envelope "to" address is the preferred 119 address to examine for subaddress information when the desire is 120 to sort messages based on how they were addressed so as to get to 121 a specific recipient. The envelope address is, after all, the 122 reason a given message is being processed by a given sieve script 123 for a given user. This is particularly true when mailing lists, 124 aliases, and "virtual domains" are involved since the envelope may 125 be the only source of detail information for the specific 126 recipient. 128 The ":user" argument specifies that sub-part of the local-part which 129 lies to the left of the separator character (e.g., "ken" in 130 "ken+sieve@example.org"). If no separator character exists, then 131 ":user" specifies the entire left-side of the address (equivalent to 132 ":localpart"). 134 The ":detail" argument specifies that sub-part of the local-part 135 which lies to the right of the separator character (e.g., "sieve" in 136 "ken+sieve@example.org"). If no separator character exists, the test 137 evaluates to false. If nothing lies to the right of the separator 138 character, then ":detail" ":is" the null key (""). Otherwise, the 139 ":detail" sub-part contains the null key. 141 NOTE: If the separator character occurs more than once in the 142 local-part, then the address MUST be split at the left-most 143 separator. 145 Implementations MUST make sure that the separator character matches 146 that which is used and/or allowed by the encompassing mail system, 147 otherwise unexpected results might occur. Implementations SHOULD 148 allow the separator character to be configurable so that they may be 149 used with a variety of mail systems. Note that the mechanisms used 150 to define and/or query the separator character used by the mail 151 system are outside the scope of this document. 153 The ":user" and ":detail" address parts are subject to the same rules 154 and restrictions as the standard address parts defined in [RFC3028]. 156 For convenience, the "ADDRESS-PART" syntax element defined in 157 [RFC3028] is augmented here as follows: 159 ADDRESS-PART =/ ":user" / ":detail" 161 A diagram showing the ADDRESS-PARTs of a email address utilizing a 162 separator character of '+' is shown below: 164 :user "+" :detail "@" :domain 165 `-----------------' 166 :local-part 168 Example: 170 require "subaddress"; 172 # File mailing list messages (subscribed as "ken+mta-filters"). 173 if envelope :detail "to" "mta-filters" { 174 fileinto "inbox.ietf-mta-filters"; 175 } 177 # If a message is not to me (ignoring +detail), junk it. 178 if not allof (address :user ["to", "cc", "bcc"] "ken", 179 address :domain ["to", "cc", "bcc"] "example.org") { 180 discard; 182 # Redirect all mail sent to +foo. 183 if envelope :detail "to" "foo" { 184 redirect "ken@example.edu"; 185 } 187 4. IANA Considerations 189 This document requests that the IANA update the entry for the 190 "subaddress" Sieve extension to point at this document. 192 5. Security Considerations 194 Security considerations are discussed in [RFC3028]. It is believed 195 that this extension does not introduce any additional security 196 concerns. 198 6. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, March 1997. 203 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 204 2001. 206 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 207 RFC 3028, January 2001. 209 Author's Address 211 Kenneth Murchison 212 Oceana Matrix Ltd. 213 21 Princeton Place 214 Orchard Park, NY 14127 215 US 217 Phone: +1 716 662 8973 218 Email: ken@oceana.com 220 Appendix A. Acknowledgments 222 Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall 223 Gellens, Philip Guenther and Jutta Degener for their help with this 224 document. 226 Appendix B. Changes since RFC3598 228 o Added note regarding processing of local-part with multiple 229 separator characters. 230 o Fixed envelope test example to only use "to" address. 232 Intellectual Property Statement 234 The IETF takes no position regarding the validity or scope of any 235 Intellectual Property Rights or other rights that might be claimed to 236 pertain to the implementation or use of the technology described in 237 this document or the extent to which any license under such rights 238 might or might not be available; nor does it represent that it has 239 made any independent effort to identify any such rights. Information 240 on the procedures with respect to rights in RFC documents can be 241 found in BCP 78 and BCP 79. 243 Copies of IPR disclosures made to the IETF Secretariat and any 244 assurances of licenses to be made available, or the result of an 245 attempt made to obtain a general license or permission for the use of 246 such proprietary rights by implementers or users of this 247 specification can be obtained from the IETF on-line IPR repository at 248 http://www.ietf.org/ipr. 250 The IETF invites any interested party to bring to its attention any 251 copyrights, patents or patent applications, or other proprietary 252 rights that may cover technology that may be required to implement 253 this standard. Please address the information to the IETF at 254 ietf-ipr@ietf.org. 256 Disclaimer of Validity 258 This document and the information contained herein are provided on an 259 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 260 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 261 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 262 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 263 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 264 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 266 Copyright Statement 268 Copyright (C) The Internet Society (2005). This document is subject 269 to the rights, licenses and restrictions contained in BCP 78, and 270 except as set forth therein, the authors retain all their rights. 272 Acknowledgment 274 Funding for the RFC Editor function is currently provided by the 275 Internet Society.