idnits 2.17.1 draft-freed-sieve-notary-01.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 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 295. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (July 31, 2008) is 5747 days in the past. Is this intentional? 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 157, but not defined == Missing Reference: 'RET' is mentioned on line 157, but not defined -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 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: February 1, 2009 July 31, 2008 6 Sieve Email Filtering: Notary Extension 7 draft-freed-sieve-notary-01 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 February 1, 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 1. Introduction 60 Sieve [RFC5228] is a language for filtering email messages at or 61 around the time of final delivery. It is designed to be 62 implementable on either a mail client or mail server. It is suitable 63 for running on a mail server where users may not be allowed to 64 execute arbitrary programs, such as on black box Internet Message 65 Access Protocol [RFC3501] servers, as it has no user-controlled loops 66 or the ability to run external programs. 68 The base sieve specification defines the envelope extension and test 69 to access information in the message envelope. Only information 70 available in regular SMTP is provided; additional information added 71 to the SMTP envelope by SMTP extensions cannot be accessed. The 72 "dsn-envelope" extension extends the envelope test to allow access to 73 the additional envelope fields defined by the SMTP extension for 74 delivery status notification specified in RFC 3461 [RFC3461]. 76 The base sieve specification also defines the redirect action which 77 sends the message to a different address. Redirect only allows 78 specification of the new recipient address. The "dsn-redirect" 79 extension extends redirect to allow specification of some fields 80 defined by the delivery status notification SMTP extension. 82 2. Conventions used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in BCP 14 [RFC2119]. 88 The terms used to describe the various components of the Sieve 89 language are taken from Section 1.1 of [RFC5228]. 91 This document uses the ABNF notation specified in [RFC5234] and 92 refers to the ABNF production notify-esmtp-value defined in Section 93 4.1 of [RFC3461]. 95 3. Capability Identifier 97 The capability strings associated with the extensions defined in this 98 document are "dsn-envelope" and "dsn-redirect". 100 4. Dsn-envelope extension 102 The "dsn-envelope" extension does not define any new tests or 103 actions, rather, it adds four values to the list of possible (case- 104 insensitive) envelope-part strings defined in Section 5.4 of 105 [RFC5228]: 107 notify Match the list of notification conditions, or NOTIFY values, 108 associated with TO address used in the SMTP RCPT TO command that 109 resulted in this message getting delivered to this user. More 110 than one notification condition can be in effect at once; each 111 condition that is in effect is tested separately and any match 112 causes the text to succeed. The syntax and semantics of the 113 NOTIFY parameter are defined in RFC 3461 [RFC3461] section 4.1. 114 Currently the possible notification condition values are "NEVER", 115 "SUCCESS", "FAILURE" and "DELAY". Note that the value "NEVER" 116 cannot be combined with any other value. 118 orcpt Match the original recipient, or ORCPT, value in decoded form 119 associated with the TO address used in the SMTP RCPT TO command 120 that resulted in this message getting delivered to this user. The 121 syntax and semantics of the ORCPT parameter are defined in Section 122 2.2 of RFC 3461 [RFC3461]. 124 ret Match the return of content, or RET, value given in the SMTP 125 MAIL FROM command. The syntax and semantics of the RET parameter 126 are defined in RFC 3461 [RFC3461] section 4.3. Currently the 127 possible return of content values are "FULL" and "HDRS". 129 envid Match the envelope identifier, or ENVID, value in decoded form 130 given in the SMTP MAIL FROM command. The syntax and semantics of 131 the ENVID parameter are defined in Section 4.4 of RFC 3461 132 [RFC3461]. 134 All of these tests fail unconditionally if the specified envelope 135 parameter does not exist for the current message or recipient. 137 The envelope test's ADDRESS-PART argument assumes the string being 138 tested has the syntax of an email address. None of the new envelope 139 parts defined here have address syntax, accordingly, it is an error 140 to specify an ADDRESS-PART argument in conjunction with these new 141 envelope parts. 143 The "relational" extension [RFC5231] adds a match type called 144 ":count". The count of an envelope test of with an envelope-part of 145 "orcpt", "ret", and "envid" is 1 if the corresponding SMTP parameter 146 is present and 0 otherwise. The count of an envelope test with an 147 envelope-part of "notify" is equal to the number of notification 148 conditions specified and 0 if the NOTIFY parameter is not present. 150 5. Dsn-redirect extension 152 The "dsn-redirect" extension does not define any new tests or 153 actions, rather, it adds two new arguments, NOTIFY and RET, to the 154 redirect action defined in Section 4.2 of [RFC5228]. This updates 155 the usage description for redirect to: 157 Usage: redirect [NOTIFY] [RET] 159 The syntax for the NOTIFY and RET arguments are: 161 NOTIFY = ":notify" notify-value 162 notify-value = DQUOTE notify-esmtp-value DQUOTE 164 RET = ":ret" ret-value 165 ret-value = DQUOTE ("FULL" / "HDRS") DQUOTE 167 The notify-esmtp-value production is defined in Section 4.1 of 168 [RFC3461]. 170 When these arguments are specified, they set the corresponding NOTIFY 171 ESMTP RCPT TO and RET ESMTP MAIL FROM parameters, respectively. 172 These parameters are only available when the delivery status 173 notification (DSN) ESMTP extension is available; they are simply 174 ignored and MUST NOT cause an error if the DSN extension is 175 unavailable. 177 6. Security Considerations 179 The dsn-envelope extension provides access to additional message 180 envelope information. This is not believed to raise any additional 181 security issues beyond those for the Sieve "envelope" test. 183 The dsn-redirect extension allows specification of the delivery 184 status notification's NOTIFY parameter which can cause the generation 185 of notification messages that might otherwise not be generated, 186 especially if notification in the event of successful delivery is 187 required. Sites which limit the ability to request success 188 notifications will also need to restrict the ability to request then 189 using the dsn-redirect extension. 191 All of the security considerations given in the base Sieve 192 specification also apply to this extension. 194 7. IANA Considerations 196 The following template specifies the IANA registration of the Sieve 197 extension specified in this document: 199 To: iana@iana.org 200 Subject: Registration of new Sieve extensions 202 Capability name: dsn-envelope 203 Description: The "dsn-envelope" extension extends the envelope 204 test to allow checking of information associated 205 with the DSN ESMTP extension defined in RFC 3461. 206 RFC number: RFC XXXX 207 Contact address: Sieve discussion list 209 Capability name: dsn-envelope 210 Description: The "dsn-redirect" extension extends the redirect 211 action to allow specification of the NOTIFY and 212 RET ESMTP parameters associated with the DSN SMTP 213 extension defined in RFC 3461. 214 RFC number: RFC XXXX 215 Contact address: Sieve discussion list 217 This information should be added to the list of sieve extensions 218 given on http://www.iana.org/assignments/sieve-extensions. 220 8. References 222 8.1. Normative references 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 228 Extension for Delivery Status Notifications (DSNs)", 229 RFC 3461, January 2003. 231 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 232 Language", RFC 5228, January 2008. 234 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 236 Relational Extension", RFC 5231, January 2008. 238 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 239 Specifications: ABNF", STD 68, RFC 5234, January 2008. 241 8.2. Informative references 243 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 244 4rev1", RFC 3501, March 2003. 246 Author's Address 248 Ned Freed 249 Sun Microsystems 250 800 Royal Oaks 251 Monrovia, CA 91016-6347 252 USA 254 Phone: +1 909 457 4293 255 Email: ned.freed@mrochek.com 257 Full Copyright Statement 259 Copyright (C) The IETF Trust (2008). 261 This document is subject to the rights, licenses and restrictions 262 contained in BCP 78, and except as set forth therein, the authors 263 retain all their rights. 265 This document and the information contained herein are provided on an 266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 268 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 269 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 270 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 273 Intellectual Property 275 The IETF takes no position regarding the validity or scope of any 276 Intellectual Property Rights or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; nor does it represent that it has 280 made any independent effort to identify any such rights. Information 281 on the procedures with respect to rights in RFC documents can be 282 found in BCP 78 and BCP 79. 284 Copies of IPR disclosures made to the IETF Secretariat and any 285 assurances of licenses to be made available, or the result of an 286 attempt made to obtain a general license or permission for the use of 287 such proprietary rights by implementers or users of this 288 specification can be obtained from the IETF on-line IPR repository at 289 http://www.ietf.org/ipr. 291 The IETF invites any interested party to bring to its attention any 292 copyrights, patents or patent applications, or other proprietary 293 rights that may cover technology that may be required to implement 294 this standard. Please address the information to the IETF at 295 ietf-ipr@ietf.org.