idnits 2.17.1 draft-freed-sieve-notary-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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 348. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 17, 2008) is 5629 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) == Missing Reference: 'NOTIFY' is mentioned on line 205, but not defined == Missing Reference: 'RET' is mentioned on line 205, but not defined -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Freed 3 Internet-Draft Sun Microsystems 4 Expires: May 21, 2009 November 17, 2008 6 Sieve Email Filtering: Delivery Status Notifications Extension 7 draft-freed-sieve-notary-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 21, 2009. 34 Abstract 36 This document describes the "dsn-envelope" and "dsn-redirect" 37 extensions to the Sieve email filtering language. The "dsn-envelope" 38 extension provides access to additional envelope information provided 39 by the delivery status notification extension to SMTP defined in RFC 40 3461. The "dsn-redirect" extension extends Sieve's redirect action 41 to provide control over delivery status notification parameters. 43 Change History (to be removed prior to publication as an RFC 45 Fixed several typos. 47 Changed name of extension from notary to dsn-envelope. 49 Added the dsn-redirect extension. 51 Updated references. 53 Added a note about the use of ADDRESS-PART arguments with the new 54 envelope-part strings defined by the dsn-envelope extension. 56 Fleshed out the dsn-redirect extension. 58 Changed document title to agree with new extension names. 60 Added some examples. 62 Fixed more typos. 64 1. Introduction 66 Sieve [RFC5228] is a language for filtering email messages at or 67 around the time of final delivery. It is designed to be 68 implementable on either a mail client or mail server. It is suitable 69 for running on a mail server where users may not be allowed to 70 execute arbitrary programs, such as on black box Internet Message 71 Access Protocol [RFC3501] servers, as it has no user-controlled loops 72 or the ability to run external programs. 74 The base sieve specification defines the envelope extension and test 75 to access information in the message envelope. Only information 76 available in regular SMTP is provided; additional information added 77 to the SMTP envelope by SMTP extensions cannot be accessed. The 78 "dsn-envelope" extension extends the envelope test to allow access to 79 the additional envelope fields defined by the SMTP extension for 80 delivery status notification specified in RFC 3461 [RFC3461]. 82 The base sieve specification also defines the redirect action which 83 sends the message to a different address. Redirect only allows 84 specification of the new recipient address. The "dsn-redirect" 85 extension extends redirect to allow specification of some fields 86 defined by the delivery status notification SMTP extension. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 The terms used to describe the various components of the Sieve 95 language are taken from Section 1.1 of [RFC5228]. 97 This document uses the ABNF notation specified in [RFC5234] and 98 refers to the ABNF production notify-esmtp-value defined in Section 99 4.1 of [RFC3461]. 101 3. Capability Identifier 103 The capability strings associated with the extensions defined in this 104 document are "dsn-envelope" and "dsn-redirect". 106 4. Dsn-envelope extension 108 The "dsn-envelope" extension does not define any new tests or 109 actions, rather, it adds four values to the list of possible (case- 110 insensitive) envelope-part strings defined in Section 5.4 of 111 [RFC5228]: 113 notify Match the list of notification conditions, or NOTIFY values, 114 associated with TO address used in the SMTP RCPT TO command that 115 resulted in this message getting delivered to this user. More 116 than one notification condition can be in effect at once; each 117 condition that is in effect is tested separately and any match 118 causes the text to succeed. The syntax and semantics of the 119 NOTIFY parameter are defined in RFC 3461 [RFC3461] section 4.1. 120 Currently the possible notification condition values are "NEVER", 121 "SUCCESS", "FAILURE" and "DELAY". Note that the value "NEVER" 122 cannot be combined with any other value. 124 orcpt Match the original recipient, or ORCPT, value in decoded form 125 associated with the TO address used in the SMTP RCPT TO command 126 that resulted in this message getting delivered to this user. The 127 syntax and semantics of the ORCPT parameter are defined in Section 128 2.2 of RFC 3461 [RFC3461]. 130 ret Match the return of content, or RET, value given in the SMTP 131 MAIL FROM command. The syntax and semantics of the RET parameter 132 are defined in RFC 3461 [RFC3461] section 4.3. Currently the 133 possible return of content values are "FULL" and "HDRS". 135 envid Match the envelope identifier, or ENVID, value in decoded form 136 given in the SMTP MAIL FROM command. The syntax and semantics of 137 the ENVID parameter are defined in Section 4.4 of RFC 3461 138 [RFC3461]. 140 All of these tests fail unconditionally if the specified envelope 141 parameter does not exist for the current message or recipient. 143 The envelope test's ADDRESS-PART argument assumes the string being 144 tested has the syntax of an email address. None of the new envelope 145 parts defined here have address syntax, accordingly, it is an error 146 to specify an ADDRESS-PART argument in conjunction with these new 147 envelope parts. 149 The "relational" extension [RFC5231] adds a match type called 150 ":count". The count of an envelope test of with an envelope-part of 151 "orcpt", "ret", and "envid" is 1 if the corresponding SMTP parameter 152 is present and 0 otherwise. The count of an envelope test with an 153 envelope-part of "notify" is equal to the number of notification 154 conditions specified and 0 if the NOTIFY parameter is not present. 156 4.1. Examples 158 The fact that the notify envelope-part operates on a list of values 159 makes it easy to check to see if a given value is present without 160 havingt to worry about other values: 162 require ["envelope", "dsn-envelope"]; 164 # Check whether SUCCESS notifications were requested, 165 # irrespective of any other requests that were made 166 if envelope "notify" "SUCCESS" 167 { 168 # do whatever 169 } 171 Checking to see if a given request is the only one present is a 172 little trickier, however: 174 require ["envelope", "dsn-envelope", "relational", 175 "comparator-i;ascii-numeric"]; 177 # Check whether only FAILURE notifications were requested 178 if allof ( envelope "notify" "FAILURE", 179 envelope :comparator "i;ascii-numeric" 180 :count "eq" "notify" "1" 181 ) 182 { 183 # do whatever 184 } 186 The orcpt envelope-part contains an address type indicator in 187 addition to an address, which must be taken into account: 189 require ["envelope", "dsn-envelope"]; 191 # See if the orcpt is an RFC822 address in the example.com 192 # domain 193 if envelope :matches "orcpt" "rfc822;*@example.com" 194 { 195 # do whatever 196 } 198 5. Dsn-redirect extension 200 The "dsn-redirect" extension does not define any new tests or 201 actions, rather, it adds two new arguments, NOTIFY and RET, to the 202 redirect action defined in Section 4.2 of [RFC5228]. This updates 203 the usage description for redirect to: 205 Usage: redirect [NOTIFY] [RET] 207 The syntax for the NOTIFY and RET arguments are: 209 NOTIFY = ":notify" notify-value 210 notify-value = DQUOTE notify-esmtp-value DQUOTE 212 RET = ":ret" ret-value 213 ret-value = DQUOTE ("FULL" / "HDRS") DQUOTE 215 The notify-esmtp-value production is defined in Section 4.1 of 216 [RFC3461]. 218 When these arguments are specified, they set the corresponding NOTIFY 219 ESMTP RCPT TO and RET ESMTP MAIL FROM parameters, respectively. 220 These parameters are only available when the delivery status 221 notification (DSN) ESMTP extension is available; they are simply 222 ignored and MUST NOT cause an error if the DSN extension is 223 unavailable. 225 6. Security Considerations 227 The dsn-envelope extension provides access to additional message 228 envelope information. This is not believed to raise any additional 229 security issues beyond those for the Sieve "envelope" test. 231 The dsn-redirect extension allows specification of the delivery 232 status notification's NOTIFY parameter which can cause the generation 233 of notification messages that might otherwise not be generated, 234 especially if notification in the event of successful delivery is 235 required. Sites which limit the ability to request success 236 notifications will also need to restrict the ability to request them 237 using the dsn-redirect extension. 239 All of the security considerations given in the base Sieve 240 specification also apply to this extension. 242 7. IANA Considerations 244 The following template specifies the IANA registration of the Sieve 245 extension specified in this document: 247 To: iana@iana.org 248 Subject: Registration of new Sieve extensions 250 Capability name: dsn-envelope 251 Description: The "dsn-envelope" extension extends the envelope 252 test to allow checking of information associated 253 with the DSN ESMTP extension defined in RFC 3461. 254 RFC number: RFC XXXX 255 Contact address: Sieve discussion list 257 Capability name: dsn-redirect 258 Description: The "dsn-redirect" extension extends the redirect 259 action to allow specification of the NOTIFY and 260 RET ESMTP parameters associated with the DSN SMTP 261 extension defined in RFC 3461. 262 RFC number: RFC XXXX 263 Contact address: Sieve discussion list 265 This information should be added to the list of sieve extensions 266 given on http://www.iana.org/assignments/sieve-extensions. 268 8. References 270 8.1. Normative references 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 276 Extension for Delivery Status Notifications (DSNs)", 277 RFC 3461, January 2003. 279 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 280 Language", RFC 5228, January 2008. 282 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 283 Relational Extension", RFC 5231, January 2008. 285 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 286 Specifications: ABNF", STD 68, RFC 5234, January 2008. 288 8.2. Informative references 290 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 291 4rev1", RFC 3501, March 2003. 293 Appendix A. Acknowledgements 295 Cyrus Daboo, Derek Diget, Philip Guenther, Arnt Gulbrandsen, Alexey 296 Melnikov, and Alexandros Vellis provided helpful suggestions and 297 corrections. 299 Author's Address 301 Ned Freed 302 Sun Microsystems 303 800 Royal Oaks 304 Monrovia, CA 91016-6347 305 USA 307 Phone: +1 909 457 4293 308 Email: ned.freed@mrochek.com 310 Full Copyright Statement 312 Copyright (C) The IETF Trust (2008). 314 This document is subject to the rights, licenses and restrictions 315 contained in BCP 78, and except as set forth therein, the authors 316 retain all their rights. 318 This document and the information contained herein are provided on an 319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 321 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 322 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 323 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 326 Intellectual Property 328 The IETF takes no position regarding the validity or scope of any 329 Intellectual Property Rights or other rights that might be claimed to 330 pertain to the implementation or use of the technology described in 331 this document or the extent to which any license under such rights 332 might or might not be available; nor does it represent that it has 333 made any independent effort to identify any such rights. Information 334 on the procedures with respect to rights in RFC documents can be 335 found in BCP 78 and BCP 79. 337 Copies of IPR disclosures made to the IETF Secretariat and any 338 assurances of licenses to be made available, or the result of an 339 attempt made to obtain a general license or permission for the use of 340 such proprietary rights by implementers or users of this 341 specification can be obtained from the IETF on-line IPR repository at 342 http://www.ietf.org/ipr. 344 The IETF invites any interested party to bring to its attention any 345 copyrights, patents or patent applications, or other proprietary 346 rights that may cover technology that may be required to implement 347 this standard. Please address the information to the IETF at 348 ietf-ipr@ietf.org.