idnits 2.17.1 draft-ietf-sieve-refuse-reject-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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 472 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SIEVE], [MDN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (May 2005) is 6914 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: 'VACATION' is mentioned on line 256, but not defined == Unused Reference: 'LMTP' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'DSN' is defined on line 337, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Downref: Normative reference to an Informational RFC: RFC 2033 (ref. 'LMTP') ** Obsolete normative reference: RFC 2298 (ref. 'MDN') (Obsoleted by RFC 3798) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Elvey 2 Document: draft-ietf-sieve-refuse-reject-00 The Elvey Partnership,LLC 3 Expires: November 2005 A. Melnikov 4 Isode Ltd 5 May 2005 7 The SIEVE mail filtering language - reject and refuse extensions 8 draft-ietf-sieve-refuse-reject 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 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 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 A revised version of this draft document will be submitted to the 34 RFC editor as a Proposed Standard for the Internet Community. 35 Discussion and suggestions for improvement are requested. 36 Distribution of this draft is unlimited. 38 Abstract 40 This memo defines the SIEVE mail filtering language [SIEVE] 41 "reject" and "refuse" extensions. 43 A Joe-job is a spam run forged to appear as though it came from an 44 innocent party, who is then generally flooded by the bounces, MDNs 45 and messages with complaints. With the Sieve "reject" action, MDNs 46 contribute to the flood of Joe-job spam to victims of Joe-jobs; 47 SMTP level refusals usually don't. With "refuse", Sieve gains the 48 ability to simply not accept an email during the SMTP transaction 49 (instead of accepting it and then sending an MDN [MDN] back to the 50 alleged sender using "reject"). 52 Table of Contents 54 1. Introduction 4 55 2. Conventions Used in this Document 4 56 3. Discussion of finer points 4 57 4. SIEVE "reject" extension 5 58 4.1 Action reject 5 59 4.2 "reject" compatibility with other actions 6 60 5. SIEVE "refuse" extension 6 61 5.1 Action refuse 6 62 5.2 "refuse" compatibility with other actions 7 63 5.3 Explicit accomodation for servers that support Enhanced 64 Error Codes [ENHANCED-CODES] 7 65 6. Security Considerations 8 66 7. IANA Considerations 8 67 7.1 reject extension registration 8 68 7.2 refuse extension registration 8 69 8. References 9 70 8.1 Normative References 9 71 8.2 Informative References 9 72 9. Acknowledgments 9 73 10. Author's Addresses 10 74 11. Intellectual Property Rights Statement 10 75 12. Full Copyright Statement 11 76 13. Changes from RFC 3028 11 77 14. Change Log 11 79 1. Introduction 81 The SIEVE mail filtering language [SIEVE] "reject" action allows 82 users to refuse delivery of a message by sending an [MDN]. This 83 action was originally defined in RFC 3028 [SIEVE]. 85 The "refuse" extension, if supported, permits users to handle 86 unwanted email in a way that is sometimes preferable to the 87 existing 'discard' and 'reject' capabilities. When a spam- 88 detection system suspects a message is spam, but isn't certain, 89 discarding the email is considered too risky for some users, for 90 example, those who receive sales leads by email. They are willing 91 to use the reject command. Users are willing to reject but not 92 discard because the sender of an email incorrectly marked as spam 93 will receive a notification that the email was refused, and will 94 likely try again to contact the intended recipient, perhaps via 95 another method of communication. Unfortunately, this usage is 96 problematic, because in the usual case, the email is indeed spam, 97 and the alleged sender to whom the MDN caused by the reject will be 98 sent will often be an innocent Joe-job victim. "Refuse" is 99 intended to be superior to "reject" because it will be less likely 100 to result in email to an innocent victim. "Refuse" refuses to 101 accept an email for delivery instead of accepting it and then 102 sending an MDN. Much spam is sent through open proxies, so 103 "refuse" reduces Joe-job bounces resulting from usage of reject. 104 "Refuse" will also reduce Joe-jobs caused by virus self-propagation 105 via emails with false sender information. "Refuse" may conserve 106 bandwidth, by reducing the number of MDNs sent. Further discussion 107 highlighting the risks of "reject" and the benefits of "refuse" can 108 be found in [Joe-DoS]. 110 2. Conventions Used in this Document 112 Conventions for notations are as in [SIEVE] section 1.1, including 113 use of [KEYWORDS]. 115 This document does not attempt to define what exactly constitutes a 116 spam or virus containing email or how it should be identified, or 117 what actions should be taken when detected. 119 3. Discussion of finer points 121 The "refuse" action MUST refuse to accept an email for delivery at 122 the SMTP/LMTP level by returning a 5XX reply code, instead of 123 sending an MDN as required by the "reject" action, other than for 124 the two exceptions specified below. A SIEVE implementation that 125 cannot do so MUST NOT claim to support the refuse extension. 127 There is an exception when a message has multiple valid recipients, 128 and at least one but not all of them are refusing delivery (whether 129 the refusal is caused by execution of a Sieve "refuse" or for 130 another reason). In this case, the server MUST accept the message 131 and generate DSNs for all recipients that are refusing it. Note 132 that this exception only applies to SMTP, as LMTP is able to reject 133 messages on a per-recipient basis. 135 If a "refuse" implementation performs a return-path verification 136 and it clearly indicates that the message has a forged return-path, 137 the implementation need not refuse to accept the mail, but rather 138 MAY accept and discard it. 140 The "reject" action is defined so that it can be used by 141 implementations unable to implement "refuse" (i.e. by MUAs) or for 142 backwards compatibility with scripts based on RFC3028. 144 4. SIEVE "reject" extension 146 SIEVE implementations that implement the "reject" action must use 147 the "reject" capability string. 149 4.1 Action reject 151 Syntax: reject 153 The "reject" action refuses delivery of a message by sending back 154 an [MDN] to the sender. The "reject" action also cancels the 155 implicit keep. It resends the message to the sender, wrapping it 156 in a "reject" form, noting that it was rejected by the recipient. 157 In the following script, a message is rejected and returned to the 158 sender. 160 Example: 161 require ["reject"] 163 if header :contains "from" "coyote@desert.example.org" { 164 reject "I am not taking mail from you, and I don't 165 want your birdseed, either!"; 166 } 168 A reject message MUST take the form of a failure MDN as specified 169 by [MDN]. The human-readable portion of the message, the 170 first component of the MDN, contains the human readable message 171 describing the error, and it SHOULD contain additional text 172 alerting the original sender that mail was refused by a filter. 173 This part of the MDN might appear as follows: 175 ------------------------------------------------------------ 176 The message was refused by the recipient's mail filtering program. 177 The reason 178 given was as follows: 180 I am not taking mail from you, and I don't want your birdseed, 181 either! 182 ------------------------------------------------------------ 184 The MDN action-value field as defined in the MDN specification MUST 185 be "deleted" and MUST have the MDN-sent-automatically and automatic- 186 action modes set. 188 4.2 "reject" compatibility with other actions 190 A "reject" action cancels the implicit keep. 192 Implementations MUST prohibit more than one reject in a SIEVE 193 script. "Reject" is also incompatible with the "refuse" and 194 "vacation" [VACATION] extensions. 196 Implementations SHOULD prohibit reject when used with other 197 actions. 199 5. SIEVE "refuse" extension 201 SIEVE implementations that implement the "refuse" action must use 202 the "refuse" capability string. 204 5.1 Action refuse 206 Syntax: refuse 208 The "refuse" action refuses delivery of a message by sending back 209 the 550 SMTP response code to an SMTP client. 211 This extension can be only supported by a Sieve implementation 212 running in an MTA. 214 Note that SMTP [SMTP] doesn't allow for non-ASCII characters in 215 SMTP response text. It is an error for non-ASCII characters to 216 appear in the "reason" string (unless the client and the server use 217 an SMTP extension that allows for transmission of non-ASCII reply 218 text; such an extension is not known to the authors). 220 If the "reason" string is multiline, than the reason text MUST be 221 returned as a multiline SMTP/LMTP response, per [SMTP], section 222 4.2.1. 224 In the following script (which assumes support for the spamtest 225 extension), messages that test highly positive for spam are 226 refused. 228 Example: 229 require ["refuse", "spamtest"] 231 if spamtest :value "ge" :comparator "i;ascii-numeric" "6" { 232 refuse text: 233 SpamAssassin thinks the message is spam. 234 It is therefore being refused. 235 Please call 1-900-PAY-US if you want to reach us. 236 . 237 ; 238 elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" { 239 fileinto "Suspect"; 240 } 242 The following excerpt from an SMTP session shows it in action. 244 C: DATA 245 S: 354 Send message, ending in CRLF.CRLF. 246 ... 247 C: . 248 S: 550-SpamAssassin thinks the message is spam. 249 S: 550-It is therefore being refused. 250 S: 550 Please call 1-900-PAY-US if you want to reach us. 252 5.2 "refuse" compatibility with other actions 254 "Refuse" cancels the implicit keep, and is incompatible with 255 "reject" and "discard". "Refuse" is also incompatible with the 256 "vacation" [VACATION] action. Any action that would modify the 257 message body will necessarily have no effect on the body of any 258 message refused by "refuse" using the 550 SMTP response code. 259 If a script attempts to "refuse" the same message more than once, 260 the implementation may ignore the later attempts or consider it 261 an error." 263 5.3 Explicit accomodation for servers that support Enhanced Error 264 Codes [ENHANCED-CODES] 266 This section only concerns implementations that support Enhanced 267 Error Codes. 269 If the server supports RFC 2034 [ENHANCED-CODES] it MUST select an 270 appropriate Enhanced Error Code (e.g. 5.7.1 or a more generic 271 5.7.0) and prepend it to the "reason" text. I.e. on such an 272 implementation, the example in section 4.1 would show up in SMTP 273 as: 275 550-5.7.1 SpamAssassin thinks the message is spam. 276 550-5.7.1 It is therefore being refused. 277 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 279 if the server selected "5.7.1" as appropriate. 281 6. Security Considerations 283 The "refuse" extension does not raise any security considerations 284 that are not present in the base [SIEVE] protocol, and these issues 285 are discussed in [SIEVE]. 287 7. IANA Considerations 289 The following section provides the IANA registrations for the Sieve 290 extensions specified in this document: 292 7.1 reject extension registration 294 IANA is requested to update the registration for the SIEVE "reject" 295 and "refuse" extensions to point to this document. 297 <> 299 7.2 refuse extension registration 301 To: iana@iana.org 302 Subject: Registration of new Sieve extension 304 Capability name: refuse 305 Capability keyword: refuse 306 Capability arguments: N/A 307 Standards Track/IESG-approved experimental RFC number: this RFC 308 Person and email address to contact for further information: 310 Matthew Elvey 311 The Elvey Partnership, LLC 312 3042 Sacramento-ietf St Ste 04 313 San Francisco, CA 314 U.S.A. 316 318 8. References 320 8.1 Normative References 322 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", RFC 2119, March 1997. 325 [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, 326 January 2001. 328 Guenther, P., "Sieve: An Email Filtering Language", Work-in- 329 progress, draft-ietf-sieve-3028bis-XX.txt 331 [SMTP] Klensin, J. (Editor), "Simple Mail Transfer Protocol", AT&T 332 Laboratories, RFC 2821, April 2001. 334 [LMTP] Myers, J., "Local Mail Transfer Protocol", Carnegie-Mellon 335 University, RFC 2033, October 1996. 337 [DSN] Moore , K., Vaudreuil, G., "An Extensible Message Format for 338 Delivery Status Notifications", University of Tennessee, Lucent 339 Technologies, RFC 3464, January 2003. 341 [MDN] Fajman, R., "An Extensible Message Format for Message 342 Disposition Notifications", National Institutes of Health, RFC 343 2298, March 1998. 345 [ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning 346 Enhanced Error Codes", Innosoft, RFC 2034, October 1996. 348 8.2 Informative References 350 [Joe-DoS] Stefan Frei, Ivo Silvestri, Gunter Ollmann, "Mail Non 351 Delivery Message DDoS Attacks", 5 April 2004", 352 . 354 9. Acknowledgments 356 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 357 Mark E. Mallett and Philip Guenther for comments and corrections. 359 The authors gratefully acknowledge the extensive work of Tim 360 Showalter as the author of the RFC 3028, which originally defined 361 "reject". 363 10. Author's Addresses 365 Matthew Elvey 366 The Elvey Partnership, LLC 367 3042 Sacramento-ietf St Ste 04 368 San Francisco, CA 369 U.S.A. 371 Email: sieve3@matthew.elvey.com 373 Alexey Melnikov 374 Isode Limited 375 5 Castle Business Village 376 36 Station Road 377 Hampton, Middlesex, TW12 2BX 378 UK 380 Email: Alexey.Melnikov@isode.com 382 11. Intellectual Property Rights Statement 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed 386 to pertain to the implementation or use of the technology described 387 in this document or the extent to which any license under such 388 rights might or might not be available; nor does it represent that 389 it has made any independent effort to identify any such rights. 390 Information on the procedures with respect to rights in RFC 391 documents can be found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use 396 of such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository 398 at http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at ietf- 404 ipr@ietf.org. 406 12. Full Copyright Statement 408 Copyright (C) The Internet Society (2005). 410 This document is subject to the rights, licenses and restrictions 411 contained in BCP 78, and except as set forth therein, the authors 412 retain all their rights. 414 This document and the information contained herein are provided on 415 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 416 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 417 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 418 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 419 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 420 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 421 PARTICULAR PURPOSE. 423 Acknowledgement 425 Funding for the RFC Editor function is currently provided by the 426 Internet Society. 428 13. Changes from RFC 3028 430 Clarified that the "reject" action cancels the implicit keep. 432 14. Change Log 434 <> 436 00 First formal draft. 437 01 Explicit RFC 2034 support, disallow "refuse" in MUAs, typos 438 corrected, clarifications, etc. 439 02 Many insubstantial editorial changes (mostly rewording text for 440 readability). Added text regarding non-ASCII characters in the 441 refuse "reason" string. Added an exception allowing return-path 442 forgery to justify discarding a message. 443 03 (Renamed to be SIEVE WG 00) - Updated boilerplate, added reject 444 action from the base spec, acknowledged Tim as the author of 445 "reject".