idnits 2.17.1 draft-ietf-sieve-refuse-reject-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. ** 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 503 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (June 2006) is 6522 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) == Unused Reference: 'KEYWORDS' is defined on line 333, but no explicit reference was found in the text -- No information found for draft-ietf-sieve-3028bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SIEVE' ** 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) -- No information found for draft-ietf-sieve-vacation-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VACATION' -- No information found for draft-ietf-sieve-spamtestbis-XX - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 12 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-02 The Elvey Partnership, 3 LLC 4 Expires: December 2006 A. Melnikov 5 Isode Ltd 6 June 2006 8 The SIEVE mail filtering language - reject extension 9 draft-ietf-sieve-refuse-reject 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 A revised version of this draft document will be submitted to the 35 RFC editor as a Proposed Standard for the Internet Community. 36 Discussion and suggestions for improvement are requested. 37 Distribution of this draft is unlimited. 39 Abstract 41 This memo defines the SIEVE mail filtering language (RFC 42 <<3028bis>>) "reject" extension. 44 A Joe-job is a spam run forged to appear as though it came from an 45 innocent party, who is then generally flooded by the bounces, 46 Message Disposition Notifications (MDNs) and messages with 47 complaints. The original Sieve "reject" action defined in RFC 3028 48 required use of MDNs for rejecting messages, thus contributing to 49 the flood of Joe-job spam to victims of Joe-jobs. This document 50 updates definition of "reject" to require rejecting messages during 51 the SMTP transaction (instead of accepting them and then sending 52 MDNs back to the alleged sender) wherever possible, thereby 53 reducing the problem. 55 Table of Contents 57 1. Introduction 2 58 2. Conventions Used in this Document 3 59 3. SIEVE "reject" extension 3 60 3.1 Action reject 3 61 3.2 "reject" compatibility with other actions 7 62 4. Security Considerations 7 63 5. IANA Considerations 7 64 5.1 reject extension registration 7 65 5.2 refuse extension registration 8 66 6. References 8 67 6.1 Normative References 8 68 6.2 Informative References 8 69 7. Acknowledgments 9 70 8. Author's Addresses 9 71 9. Intellectual Property Rights Statement 9 72 10. Full Copyright Statement 10 73 11. Changes from RFC 3028 11 74 12. Change Log 11 76 1. Introduction 78 The SIEVE mail filtering language [SIEVE] "reject" action defined 79 in RFC 3028 only allowed users to refuse delivery of a message by 80 sending an [MDN]. 82 This document updates definition of the "reject" action to permit 83 users to handle unwanted email in a way that is sometimes 84 preferable to the existing 'discard' and the original 'reject' 85 capabilities. When a spam-detection system suspects a message is 86 spam, but isn't certain, discarding the email is considered too 87 risky for some users, for example, those who receive sales leads by 88 email. They are willing to use the reject command. Users are 89 willing to reject but not discard because the sender of an email 90 incorrectly marked as spam will receive a notification that the 91 email was refused, and will likely try again to contact the 92 intended recipient, perhaps via another method of communication. 93 Unfortunately, this usage is problematic, because in the usual 94 case, the email is indeed spam, and the alleged sender to whom an 95 MDN caused by the reject will be sent will often be an innocent Joe- 96 job victim. The updated "reject" is less likely to result in email 97 to an innocent victim, because it requires that an implemention 98 refuse to accept an email for delivery instead of accepting it and 99 then sending an MDN wherever possible. Much spam is sent through 100 open proxies, so SMTP level refusal reduces Joe-job bounces (AKA 101 backscatter) resulting from usage of MDNs. The updated "reject" 102 will also reduce Joe-jobs caused by virus self-propagation via 103 emails with false sender information. SMTP level refusal helps to 104 prevent the blacklisting of sources of backscatter and conserve 105 bandwidth, by reducing the number of MDNs sent. Further discussion 106 highlighting the risks of generating MDNs and the benefits of 107 protocol level refusal can be found in [Joe-DoS]. 109 2. Conventions Used in this Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 113 this document are to be interpreted as described in RFC 2119. 115 Conventions for notations are as in [SIEVE] section 1.1. 117 This document does not attempt to define what exactly constitutes a 118 spam or virus containing email or how it should be identified. 120 3. SIEVE "reject" extension 122 SIEVE implementations that implement the "reject" action must use 123 the "reject" capability string. 125 3.1 Action reject 127 Usage: reject 129 The "reject" action cancels the implicit keep and refuses delivery 130 of a message. The reason string is a UTF-8 [UTF-8] string 131 specifying the reason for refusal. How message is refused depends 132 on capabilities of mail component (MUA, MDA or MTA) executing the 133 Sieve script. The Sieve interpreter must do one of the following 134 actions, as detailed by the following priority table (items listed 135 earlier take precedence). Note that if action can not be taken or 136 fails, the interpreter should try the next item in the list: 138 1. If message return-path (MAIL FROM) is empty the message SHOULD be 139 accepted and discarded. 140 2. If a "reject" implementation performs a return-path verification 141 and it clearly indicates that the message has a forged return-path, 142 the implementation need not refuse mail delivery, but rather MAY 143 accept and discard it. 144 3. Message delivery is refused by sending 5XX response code over 145 SMTP [SMTP] or LMTP [LMTP]. See section 3.1.1 for more details. 146 4. Message delivery is refused by sending a non delivery report 147 (DSN [DSN]). See section 3.1.2 for more details. 148 5. Message delivery is refused by sending a message disposition 149 notification report (MDN). See section 3.1.3 for more details. 151 3.1.1 Rejecting messages at SMTP/LMTP protocol level 153 Sieve implementations that are able to reject messages at SMTP/LMTP 154 level SHOULD use the 550 response code. Note that if a message is 155 arriving over SMTP and has multiple recipients, some of which have 156 accepted the message, or the Sieve implementation is part of an 157 MUA, section 3.1.2 and section 3.1.3 define how to reject such a 158 message. 160 <> 163 Note that SMTP [SMTP] doesn't allow for non-ASCII characters in 164 SMTP response text. If non-ASCII characters appear in the "reason" 165 string, they may be sent if and only if the client and the server 166 use an SMTP extension that allows for transmission of non-ASCII 167 reply text. Otherwise, the implementation should either consider it 168 an error, or accept the message and generate DSN as described in 169 section 3.1.2. 171 If the "reason" string is multiline, than the reason text MUST be 172 returned as a multiline SMTP/LMTP response, per [SMTP], section 173 4.2.1. Any line MUST NOT exceed the SMTP limit on the maximal line 174 length. To make the reason string conform to any such limits the 175 server MAY insert CRLFs and turn the response into a multiline 176 response. 178 In the following script (which assumes support for the spamtest 179 [SPAMTEST] and fileinto extensions), messages that test highly 180 positive for spam are refused. 182 Example: 183 require ["reject", "spamtest", 184 "comparator-i;ascii-numeric", "fileinto"]; 186 if spamtest :value "ge" :comparator "i;ascii-numeric" "6" { 187 refuse text: 188 AntiSpam engine thinks your message is spam. 189 It is therefore being refused. 190 Please call 1-900-PAY-US if you want to reach us. 191 . 192 ; 193 } elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" { 194 fileinto "Suspect"; 195 } 197 The following excerpt from an SMTP session shows it in action. 198 ... 199 C: DATA 200 S: 354 Send message, ending in CRLF.CRLF. 201 ... 202 C: . 203 S: 550-AntiSpam engine thinks your message is spam. 204 S: 550-It is therefore being refused. 205 S: 550 Please call 1-900-PAY-US if you want to reach us. 207 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES] it MUST 208 prepend an appropriate Enhanced Error Code to the "reason" text. 209 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. 210 With Enhanced Error Code the response to DATA command in the SMTP 211 example below will look like: 213 S: 550-5.7.1 AntiSpam engine thinks your message is spam. 214 S: 550-5.7.1 It is therefore being refused. 215 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 217 if the server selected "5.7.1" as appropriate. 219 If a Sieve implementation that supports "reject" doesn't wish to 220 immediately disclose the reason for rejection (for example that it 221 detected spam), it may delay immediate sending the 550 error code 222 by sending a 4XX error code on the first attempt to receive the 223 message. 225 3.1.2 Rejecting message by sending DSN 227 If the implementation receives a message via SMTP that has more 228 than one RCPT TO that has been accepted by the server, and at least 229 one but not all of them are refusing delivery (whether the refusal 230 is caused by execution of a Sieve "reject" or for another reason). 231 In this case, the server MUST accept the message and generate DSNs 232 for all recipients that are refusing it. Note that this exception 233 does not apply to LMTP, as LMTP is able to reject messages on a per- 234 recipient basis. 236 3.1.3 Rejecting message by sending MDN 238 When Sieve engine is running inside MUA it has no ability to reject 239 the message before it was delivered, as the message is already 240 delivered. In this case the client should send a Message 241 Disposition Notification [MDN] back to the sender. It resends the 242 message to the sender as specified in the Return-Path header field, 243 wrapping it in a "reject" form, noting that it was rejected by the 244 recipient. 245 MTAs and MDAs SHOULD NOT implement "reject" by sending MDNs, they 246 SHOULD reject at protocol level as described in section 3.1.1. 247 In the following script, a message is rejected and returned to the 248 sender. 250 Example: 251 require ["reject"]; 253 if header :contains "from" "coyote@desert.example.org" 254 { 255 reject text: 256 I am not taking mail from you, and I don't 257 want your birdseed, either!" 258 . 259 ; 260 } 262 A reject message MUST take the form of a failure MDN as specified 263 by [MDN]. The human-readable portion of the message, the first 264 component of the MDN, contains the human readable message 265 describing the error, and it SHOULD contain additional text 266 alerting the original sender that mail was refused by a filter. 267 This part of the MDN might appear as follows: 269 ------------------------------------------------------------ 270 The message was refused by the recipient's mail filtering program. 271 The reason 272 given was as follows: 274 I am not taking mail from you, and I don't want your birdseed, 275 either! 276 ------------------------------------------------------------ 278 The MDN action-value field as defined in the MDN specification MUST 279 be "deleted" and MUST have the MDN-sent-automatically and automatic- 280 action modes set. 282 3.2 "reject" compatibility with other actions 284 A "reject" action cancels the implicit keep. 286 Implementations MUST prohibit the execution of more than one reject 287 in a SIEVE script. "Reject" is also incompatible with the 288 "vacation" [VACATION] extensions. Implementations SHOULD prohibit 289 reject when used with other actions, in particular "reject" SHOULD 290 be incompatible with keep, fileinto, redirect and discard. 292 Any action that would modify the message body will not have effect 293 on the body of any message refused by "reject" using the 550 SMTP 294 response code and MUST NOT have any effect on context of generated 295 DSN/MDNs. 297 4. Security Considerations 299 The Introduction section talks about why rejecting messages before 300 delivery is better then accepting and bouncing them. 302 Security issues associated with mail auto-responders are fully 303 discussed in the security consideration section of [RFC3834]. This 304 document is believed not to introduce any additional security 305 considerations in this general area. 307 The "reject" extension does not raise any other security 308 considerations that are not already present in the base [SIEVE] 309 protocol, and these issues are discussed in [SIEVE]. 311 5. IANA Considerations 313 The following section provides the IANA registrations for the Sieve 314 extensions specified in this document: 316 5.1 reject extension registration 318 IANA is requested to update the registration for the SIEVE "reject" 319 extension to point to this document. 320 IANA is also requested to update Tim Showalter's email address to 321 be 322 tjs@psaux.com 324 5.2 refuse extension registration 326 IANA is requested to remove registration of the refuse extension. 327 <> 329 6. References 331 6.1 Normative References 333 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", RFC 2119, March 1997. 336 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 337 Language", Work-in-progress, draft-ietf-sieve-3028bis-XX.txt 339 [SMTP] Klensin, J. (Editor), "Simple Mail Transfer Protocol", AT&T 340 Laboratories, RFC 2821, April 2001. 342 [LMTP] Myers, J., "Local Mail Transfer Protocol", Carnegie-Mellon 343 University, RFC 2033, October 1996. 345 [DSN] Moore , K., Vaudreuil, G., "An Extensible Message Format for 346 Delivery Status Notifications", University of Tennessee, Lucent 347 Technologies, RFC 3464, January 2003. 349 [MDN] Fajman, R., "An Extensible Message Format for Message 350 Disposition Notifications", National Institutes of Health, RFC 351 2298, March 1998. 353 [ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning 354 Enhanced Error Codes", Innosoft, RFC 2034, October 1996. 356 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 357 RFC 3629, November 2003. 359 [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: 360 Vacation Extension", work in progress, draft-ietf-sieve-vacation-XX.txt. 362 6.2 Informative References 364 [Joe-DoS] Stefan Frei, Ivo Silvestri, Gunter Ollmann, "Mail Non 365 Delivery Message DDoS Attacks", 5 April 2004", 366 . 368 [SPAMTEST] Daboo, C., "SIEVE Email Filtering: Spamtest and 369 Virustest Extensions", work in progress, draft-ietf-sieve- 370 spamtestbis-XX.txt 371 <> 374 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 375 Electronic Mail", RFC 3834, August 2004. 377 7. Acknowledgments 379 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 380 Mark E. Mallett, Philip Guenther and Michael Haardt for comments 381 and corrections. 383 The authors gratefully acknowledge the extensive work of Tim 384 Showalter as the author of the RFC 3028, which originally defined 385 the "reject" action. 387 8. Author's Addresses 389 Matthew Elvey 390 The Elvey Partnership, LLC 391 3042 Sacramento-ietf St Ste 04 392 San Francisco, CA 393 U.S.A. 395 Email: sieve3@matthew.elvey.com 397 Alexey Melnikov 398 Isode Limited 399 5 Castle Business Village 400 36 Station Road 401 Hampton, Middlesex, TW12 2BX 402 UK 404 Email: Alexey.Melnikov@isode.com 406 9. Intellectual Property Rights Statement 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed 410 to pertain to the implementation or use of the technology described 411 in this document or the extent to which any license under such 412 rights might or might not be available; nor does it represent that 413 it has made any independent effort to identify any such rights. 414 Information on the procedures with respect to rights in RFC 415 documents can be found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use 420 of such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository 422 at http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights that may cover technology that may be required to implement 427 this standard. Please address the information to the IETF at ietf- 428 ipr@ietf.org. 430 10. Full Copyright Statement 432 Copyright (C) The Internet Society (2006). 434 This document is subject to the rights, licenses and restrictions 435 contained in BCP 78, and except as set forth therein, the authors 436 retain all their rights. 438 This document and the information contained herein are provided on 439 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 440 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 441 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 442 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 443 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 444 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 445 PARTICULAR PURPOSE. 447 Acknowledgement 449 Funding for the RFC Editor function is currently provided by the 450 Internet Society. 452 11. Changes from RFC 3028 454 Clarified that the "reject" action cancels the implicit keep. 455 Extended list of allowable actions on reject to include protocol 456 level message rejection and generation of DSNs. 458 12. Change Log 460 <> 463 00 First formal draft. 464 01 Explicit RFC 2034 support, disallow "refuse" in MUAs, typos 465 corrected, clarifications, etc. 466 02 Many insubstantial editorial changes (mostly rewording text for 467 readability). Added text regarding non-ASCII characters in the refuse 468 "reason" string. Added an exception allowing return-path forgery to 469 justify discarding a message. 470 03 (Renamed to be SIEVE WG 00) - Updated boilerplate, added reject 471 action from the base spec, acknowledged Tim as the author of "reject". 472 04 (SIEVE WG 01) Based on WGLC feedback, the refuse and the reject 473 actions were merged into a single action called reject. Text 474 reorganized as the result. Typos and examples corrected. Updated IANA 475 registration and Security Considerations sections. 476 05 (SIEVE WG 02) Copied some security considerations from Vacation 477 draft. Clarified that the "reason" string is in UTF-8. Clarified 478 interaction with "editheader" extension. Added text about sending of 479 4XX instead of 550. Corrected typos in several examples.