idnits 2.17.1 draft-elvey-refuse-sieve-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-elvey-refuse-sieve', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-elvey-refuse-sieve', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-elvey-refuse-sieve', but the file name used is 'draft-elvey-refuse-sieve-02' == 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 371 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 (June 2004) is 7227 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 182, but not defined == Unused Reference: 'LMTP' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'DSN' is defined on line 255, 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: 7 errors (**), 1 flaw (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Elvey 2 Document: draft-elvey-refuse-sieve The Elvey Partnership, LLC 3 Expires: December 2004 A. Melnikov 4 Isode Ltd 5 June 2004 7 The SIEVE mail filtering language - refuse extension 8 draft-elvey-refuse-sieve-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memo defines the SIEVE mail filtering language [SIEVE] 34 "refuse" extension. 35 A Joe-job is a spam run forged to appear as though it came from an 36 innocent party, who is then generally flooded by the bounces, MDNs 37 and messages with complaints. With the Sieve "reject" action, MDNs 38 contribute to the flood of Joe-job spam to victims of Joe-jobs; 39 SMTP level refusals usually don't. With "refuse", Sieve gains the 40 ability to simply not accept an email during the SMTP transaction 41 (instead of accepting it and then sending an MDN [MDN] back to the 42 alleged sender using "reject"). 44 Table of Contents 46 1. Discussion 2 47 2. Conventions Used in this Document 3 48 3. Introduction and Overview 3 49 4. SIEVE Extension 4 50 4.1 Action refuse 4 51 4.2 "refuse" compatibility with other actions 5 52 4.3 Explicit accomodation for servers that support Enhanced 53 Error Codes [ENHANCED-CODES] 5 54 5. Security Considerations 5 55 6. IANA Considerations 6 56 6.1 refuse extension registration 6 57 7. References 6 58 7.1 Normative References 6 59 7.2 Informative References 7 60 8. Acknowledgments 7 61 9. Author's Addresses 7 62 10. Intellectual Property Rights Statement 7 63 11. Full Copyright Statement 8 64 12. Change Log 8 66 1. Discussion 68 The SIEVE mail filtering language [SIEVE] "refuse" extension, if 69 supported, permits users to handle unwanted email in a way that is 70 sometimes preferable to the existing 'discard' and 'reject' 71 capabilities. When a spam-detection system suspects a message is 72 spam, but isn't certain, discarding the email is considered too 73 risky for some users, for example, those who receive sales leads by 74 email. They are willing to use the reject command. Users are 75 willing to reject but not discard because the sender of an email 76 incorrectly marked as spam will receive a notification that the 77 email was refused, and will likely try again to contact the 78 intended recipient, perhaps via another method of communication. 79 Unfortunately, this usage is problematic, because in the usual 80 case, the email is indeed spam, and the alleged sender to whom the 81 MDN caused by the reject will be sent will often be an innocent Joe- 82 job victim. "Refuse" is intended to be superior to "reject" 83 because it will be less likely to result in email to an innocent 84 victim. "Refuse" refuses to accept an email for delivery instead 85 of accepting it and then sending an MDN. Much spam is sent through 86 open proxies, so "refuse" reduces Joe-job bounces resulting from 87 usage of reject. "Refuse" will also reduce Joe-jobs caused by virus 88 self-propagation via emails with false sender information. 89 "Refuse" may conserve bandwidth, by reducing the number of MDNs 90 sent. Further discussion highlighting the risks of "reject" and the 91 benefits of "refuse" can be found in [Joe-DoS]. 93 2. Conventions Used in this Document 95 Conventions for notations are as in [SIEVE] section 1.1, including 96 use of [KEYWORDS]. 98 This document does not attempt to define what exactly constitutes a 99 spam or virus containing email or how it should be identified, or 100 what actions should be taken when detected. 102 3. Introduction and Overview 104 The "refuse" action MUST refuse to accept an email for delivery at 105 the SMTP/LMTP level by returning a 5XX reply code, instead of 106 sending an MDN as required by the "reject" action, other than for 107 the two exceptions specified below. A SIEVE implementation that 108 cannot do so MUST NOT claim to support the refuse extension. 110 There is an exception when a message has multiple valid recipients, 111 and at least one but not all of them are refusing delivery (whether 112 the refusal is caused by execution of a Sieve "refuse" or for 113 another reason). In this case, the server MUST accept the message 114 and generate DSNs for all recipients that are refusing it. Note 115 that this exception only applies to SMTP, as LMTP is able to reject 116 messages on a per-recipient basis. 118 If a "refuse" implementation performs a return-path verification 119 and it clearly indicates that the message has a forged return-path, 120 the implementation need not refuse to accept the mail, but rather 121 MAY accept and discard it. 123 4. SIEVE Extension 125 This section defines the "refuse" action. 127 4.1 Action refuse 129 Syntax: refuse 131 The "refuse" action refuses delivery of a message by sending back 132 the 550 SMTP response code to an SMTP client. 134 This extension can be only supported by a Sieve implementation 135 running in a MTA. 137 Note that SMTP [SMTP] doesn't allow for non-ASCII characters in 138 SMTP response text. It is an error for non-ASCII characters to 139 appear in the "reason" string (unless the client and the server use 140 an SMTP extension that allows for transmission of non-ASCII reply 141 text; such an extension is not known to the authors). 143 If the "reason" string is multiline, than the reason text MUST be 144 returned as a multiline SMTP/LMTP response, per [SMTP], section 145 4.2.1. 147 In the following script (which assumes support for the spamtest 148 extension), messages that test highly positive for spam are 149 refused. 151 Example: 152 require ["refuse", "spamtest"] 154 if spamtest :value "ge" :comparator "i;ascii-numeric" "6" { 155 refuse text: 156 SpamAssassin thinks the message is spam. 157 It is therefore being refused. 158 Please call 1-900-PAY-US if you want to reach us. 159 . 160 ; 161 elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" { 162 fileinto "Suspect"; 163 } 165 The following excerpt from an SMTP session shows it in action. 166 . 167 C: DATA 168 S: 354 Send message, ending in CRLF.CRLF. 169 ... 170 C: . 171 S: 550-SpamAssassin thinks the message is spam. 172 S: 550-It is therefore being refused. 173 S: 550 Please call 1-900-PAY-US if you want to reach us. 175 SIEVE implementations that implement the "refuse" action must use 176 the "refuse" capability string. 178 4.2 "refuse" compatibility with other actions 180 "Refuse" cancels the implicit keep, and is incompatible with 181 "reject" and "discard". "Refuse" is also incompatible with 182 "vacation" extension [VACATION]. (It should be compatible and 183 incompatible with the same actions as "reject", but [SIEVE] states 184 "Implementations SHOULD prohibit reject when used with other 185 actions." However we feel that "refuse" should be permitted when 186 used with other actions such as "fileinto" and "redirect". This 187 could be useful for analyzing, tracking or reporting spam. Also, 188 users can use tricks (such as multiple redirects back to their own 189 email addresses) to get around such a prohibition anyway.) 191 4.3 Explicit accomodation for servers that support Enhanced Error 192 Codes [ENHANCED-CODES] 194 This section only concerns implementations that support Enhanced 195 Error Codes. 197 If the server supports RFC 2034 [ENHANCED-CODES] it MUST select an 198 appropriate Enhanced Error Code (e.g. 5.7.1 or a more generic 199 5.7.0) and prepend it to the "reason" text. I.e. on such an 200 implementation, the example in section 4.1 would show up in SMTP 201 as: 203 550-5.7.1 SpamAssassin thinks the message is spam. 204 550-5.7.1 It is therefore being refused. 205 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 207 if the server selected "5.7.1" as appropriate. 209 5. Security Considerations 211 The "refuse" extension does not raise any security considerations 212 that are not present in the base [SIEVE] protocol, and these issues 213 are discussed in [SIEVE]. 215 6. IANA Considerations 217 The following section provides the IANA registration for the Sieve 218 extensions specified in this document: 220 6.1 refuse extension registration 222 To: iana@iana.org 223 Subject: Registration of new Sieve extension 225 Capability name: refuse 226 Capability keyword: refuse 227 Capability arguments: N/A 228 Standards Track/IESG-approved experimental RFC number: this RFC 229 Person and email address to contact for further information: 231 Matthew Elvey 232 The Elvey Partnership, LLC 233 3042 Sacramento-ietf St Ste 04 234 San Francisco, CA 235 U.S.A. 237 239 7. References 241 7.1 Normative References 243 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", RFC 2119, March 1997. 246 [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, 247 January 2001. 249 [SMTP] Klensin, J. (Editor), "Simple Mail Transfer Protocol", AT&T 250 Laboratories, RFC 2821, April 2001. 252 [LMTP] Myers, J., "Local Mail Transfer Protocol", Carnegie-Mellon 253 University, RFC 2033, October 1996. 255 [DSN] Moore , K., Vaudreuil, G., "An Extensible Message Format for 256 Delivery Status Notifications", University of Tennessee, Lucent 257 Technologies, RFC 3464, January 2003. 259 [MDN] Fajman, R., "An Extensible Message Format for Message 260 Disposition Notifications", National Institutes of Health, RFC 261 2298, March 1998. 263 [ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning 264 Enhanced Error Codes", Innosoft, RFC 2034, October 1996. 266 7.2 Informative References 268 [Joe-DoS] Stefan Frei, Ivo Silvestri, Gunter Ollmann, "Mail Non 269 Delivery Message DDoS Attacks", 5 April 2004; 270 http://www.techzoom.net/paper-mailbomb.asp 272 8. Acknowledgments 274 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen and Mark E. 275 Mallett for comments and corrections. 277 9. Author's Addresses 279 Matthew Elvey 280 The Elvey Partnership, LLC 281 3042 Sacramento-ietf St Ste 04 282 San Francisco, CA 283 U.S.A. 285 Email: sieve3@matthew.elvey.com 287 Alexey Melnikov 288 Isode Limited 289 5 Castle Business Village 290 36 Station Road 291 Hampton, Middlesex, TW12 2BX 292 UK 294 Email: Alexey.Melnikov@isode.com 296 10. Intellectual Property Rights Statement 298 This document is an Internet-Draft and is subject to all provisions 299 of Section 10 of RFC2026. 301 The IETF takes no position regarding the validity or scope of any 302 intellectual property or other rights that might be claimed to 303 pertain to the implementation or use of the technology described in 304 this document or the extent to which any license under such rights 305 might or might not be available; neither does it represent that it 306 has made any effort to identify any such rights. Information on 307 the IETF's procedures with respect to rights in standards-track and 308 standards-related documentation can be found in BCP-11. Copies of 309 claims of rights made available for publication and any assurances 310 of licenses to be made available, or the result of an attempt made 311 to obtain a general license or permission for the use of such 312 proprietary rights by implementors or users of this specification 313 can be obtained from the IETF Secretariat. 315 11. Full Copyright Statement 317 Copyright (C) The Internet Society 2004. All Rights Reserved. 319 This document and translations of it may be copied and furnished to 320 others, and derivative works that comment on or otherwise explain 321 it or assist in its implementation may be prepared, copied, 322 published and distributed, in whole or in part, without restriction 323 of any kind, provided that the above copyright notice and this 324 paragraph are included on all such copies and derivative works. 325 However, this document itself may not be modified in any way, such 326 as by removing the copyright notice or references to the Internet 327 Society or other Internet organizations, except as needed for the 328 purpose of developing Internet standards in which case the 329 procedures for copyrights defined in the Internet Standards process 330 must be followed, or as required to translate it into languages 331 other than English. 333 The limited permissions granted above are perpetual and will not be 334 revoked by the Internet Society or its successors or assigns. 336 This document and the information contained herein is provided on 337 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 338 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 339 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 340 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 341 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 343 12. Change Log 345 00 First formal draft. 346 01 Explicit RFC 2034 support, disallow "refuse" in MUAs, typos 347 corrected, clarifications, etc. 348 02 Many insubstantial editorial changes (mostly rewording text for 349 readability). Added text regarding non-ASCII characters in the 350 refuse "reason" string. Added an exception allowing return-path 351 forgery to justify discarding a message.