idnits 2.17.1 draft-ietf-sieve-refuse-reject-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 564. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 669 lines 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (October 4, 2007) is 6046 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 454, 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 3798 (ref. 'MDN') (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 3462 (ref. 'REPORT') (Obsoleted by RFC 6522) -- 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? -- No information found for draft-melnikov-smtp-lang-XX - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Aaron Stone 2 Document: draft-ietf-sieve-refuse-reject-05 libSieve Project 3 Intended status: Standards Track Matthew Elvey 4 Expires: April 7, 2008 The Elvey Partnership, 5 LLC 6 Alexey Melnikov 7 Isode, Ltd 8 October 4, 2007 10 Sieve Email Filtering: Reject Extension 11 draft-ietf-sieve-refuse-reject-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 A revised version of this draft document will be submitted to the 37 RFC editor as a Proposed Standard for the Internet Community. 38 Discussion and suggestions for improvement are requested. 39 Distribution of this draft is unlimited. 41 Abstract 43 This memo updates the definition of the Sieve mail filtering language 44 (RFC draft-ietf-sieve-3028bis-XX.txt) "reject" extension, originally 45 defined in RFC 3028. 47 A "Joe-job" is a spam run forged to appear as though it came from an 48 innocent party, who is then generally flooded by automated bounces, 49 Message Disposition Notifications (MDNs), and personal messages with 50 complaints. The original Sieve "reject" action defined in RFC 3028 51 required use of MDNs for rejecting messages, thus contributing to the 52 flood of Joe-job spam to victims of Joe-jobs. 54 This memo updates the definition of the "reject" action to allow 55 messages to be refused during the SMTP transaction, and defines the 56 "ereject" action to require messages to be refused during the SMTP 57 transaction. 59 The "ereject" action is intended to replace the "reject" action 60 wherever possible. 62 Table of Contents 64 1. Introduction 2 65 2. Conventions Used in this Document 3 66 3. Sieve "reject" and "ereject" extensions X 67 3.1 Action ereject 68 3.1.1 Rejecting a message at the SMTP/LMTP protocol level 69 3.1.2 Rejecting a message by sending a DSN 70 3.2 Action reject 71 3.3 "ereject"/"reject" compatibility with other actions 72 3.4 How "reject"/"ereject" should generate MDNs 73 3.5 How "reject"/"ereject" should perform protocol level refusal 74 4. Security Considerations X 75 5. IANA Considerations X 76 5.1 reject extension registration X 77 5.2 refuse extension registration X 78 6. References X 79 6.1 Normative References X 80 6.2 Informative References X 81 7. Acknowledgments X 82 8. Author's Addresses X 83 9. Intellectual Property Rights Statement X 84 10. Full Copyright Statement X 85 11. Changes from RFC 3028 X 86 12. Change Log X 88 1. Introduction 90 The Sieve mail filtering language [SIEVE] defined in RFC 3028 91 specifies that "reject" action shall discard a message and send a 92 Message Disposition Notification [MDN] to the envelope sender along 93 with an explanatory message. 95 This document updates the definition of the "reject" action to permit 96 refusal of the message during the SMTP transaction, if possible, and 97 defines a new "ereject" action to require refusal of the message 98 during the SMTP transaction. 100 Implementations are further encouraged to use spam-detection systems 101 to determine the level of risk associated with sending an MDN, 102 allowing implementations to silently drop the MDN if the rejected 103 message is deemed to be likely spam. 105 Further discussion highlighting the risks of generating MDNs and the 106 benefits of protocol-level refusal can be found in [Joe-DoS]. 108 2. Conventions Used in this Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119. 114 Conventions for notations are as in [SIEVE] Section 1.1. 116 This document does not attempt to define spam or how it should be 117 identified, nor to define an email virus or how it should be 118 detected. Implementations are advised to follow best practices 119 and keep abreast of current research in these fields. 121 3. Sieve "reject" and "ereject" extensions 123 3.1 Action ereject 125 Usage: ereject 127 Sieve implementations that implement the "ereject" action must use 128 the "ereject" capability string. 130 The "ereject" action cancels the implicit keep and refuses delivery 131 of a message. The reason string is a UTF-8 [UTF-8] string 132 specifying the reason for refusal. How a message is refused depends 133 on the capabilities of the mail component (MDA or MTA) executing the 134 Sieve script. The Sieve interpreter MUST carry out one of the 135 following actions (listed in order from most to least preferred), 136 SHOULD carry out the most preferable action, and SHOULD fall back to 137 lesser actions if a preferred action fails. 139 1. Refuse message delivery by sending a 5XX response code 140 over SMTP [SMTP] or LMTP [LMTP]. See Section 3.1.1 for more 141 details. 143 2. Discard the message if a return-path verification clearly 144 indicates that the message has a forged return-path. 146 3. Send a non-delivery report to the envelope sender 147 ([REPORT] [DSN]). See Section 3.1.2 for more details. 149 The ereject action MUST NOT be available in environments that do 150 not support protocol level rejection, e.g. an MUA. 152 3.1.1 Rejecting a message at the SMTP/LMTP protocol level 154 Sieve implementations that are able to reject messages at the 155 SMTP/LMTP level MUST do so and SHOULD use the 550 response code. Note 156 that if a message is arriving over SMTP and has multiple recipients, 157 some of whom have accepted the message, Section 3.1.2 defines how to 158 reject such a message. 160 Note that SMTP [SMTP] doesn't allow for non-ASCII characters in the 161 SMTP response text. If non-ASCII characters appear in the "reason" 162 string, they can be sent at the protocol level if and only if the 163 client and the server use an SMTP extension that allows for 164 transmission of non-ASCII reply text. (One example of such an SMTP 165 extension is described in [UTF8-RESP].) In the absence of such an 166 SMTP extension, the Sieve engine MUST replace any reason string 167 being sent at the protocol level and containing non-ASCII 168 characters with an implementation-defined ASCII-only string. 169 Implementations SHOULD notify the user that such replacement took 170 place. Users that don't like this behavior should consider using 171 the "reject" action described in Section 3.2, if available. 173 See Section 3.5 for the detailed instructions about performing 174 protocol level rejection. 176 3.1.2 Rejecting a message by sending a DSN 178 An implementation may receive a message via SMTP that has more 179 than one RCPT TO that has been accepted by the server, and at least 180 one but not all of them are refusing delivery (whether the refusal 181 is caused by a Sieve "ereject" action or for some other reason). 182 In this case, the server MUST accept the message and generate DSNs 183 for all recipients that are refusing it. Note that this exception 184 does not apply to LMTP, as LMTP is able to reject messages on a per- 185 recipient basis. 187 Note that according to [DSN], Delivery Status Notifications MUST NOT 188 be generated if the MAIL FROM (or Return-Path) is empty. 190 The DSN message MUST follow the requirements of [DSN] and [REPORT]. 191 The action-value field defined in [DSN], Section 2.3.3, MUST contain 192 the value "failed". The human-readable portion of the non-delivery 193 report MUST contain the reason string from the "ereject" action and 194 SHOULD contain additional text alerting the apparent original sender 195 that the message was refused by an email filter. This part of the 196 report might appear as follows: 198 ------------------------------------------------------------ 199 Your message was refused by the recipient's mail filtering program. 200 The reason given was as follows: 202 I am not taking mail from you, and I don't want your birdseed, 203 either! 204 ------------------------------------------------------------ 206 3.2 Action reject 208 This section updates the definition of the reject action in Section 209 4.1 of RFC 3028 and is an optional extension to [SIEVE]. 211 Usage: reject 213 Sieve implementations that implement the "reject" action must use 214 the "reject" capability string. 216 The "reject" action cancels the implicit keep and refuses delivery 217 of a message. The reason string is a UTF-8 [UTF-8] string 218 specifying the reason for refusal. Unlike the "ereject" action 219 described above, this action would always favor preserving the exact 220 text of the refusal reason. Typically the "reject" action refuses 221 delivery of a message by sending back an [MDN] to the alleged sender 222 (see Section 3.4). However implementations MAY refuse delivery over 223 protocol (as detailed in Section 3.5), if and only if all of the 224 following conditions are true: 226 1) The reason string consists of only US-ASCII characters 227 or 228 The reason string contains non-US-ASCII and both client and server 229 support and negotiate use of an SMTP/LMTP extension for sending 230 UTF-8 responses. 231 2) LMTP protocol is used 232 or 233 SMTP protocol is used and the message contains a single recipient 234 or SMTP protocol is used, the message contains multiple recipients 235 and all of them refused message delivery (whether using Sieve or 236 not). 238 Script generators SHOULD ensure that a rejection action being 239 executed as a result of an anti-spam/anti-virus positive test 240 be done using the ereject action, as it is more suitable for such 241 rejections. 243 Script generators MAY automatically upgrade scripts that previously 244 used the reject action for anti-spam/anti-virus related rejections. 245 Note that such generators MUST make sure that the target environment 246 can support the ereject action. 248 Example: 249 require ["reject"]; 251 if size :over 100K { 252 reject text: 253 Your message is to big. If you want to send me a big attachment, 254 put it on a public web site and send me an URL. 255 . 256 ; 257 } 259 (Pretend that the reason string above contains some non-ASCII text) 261 3.3 "ereject"/"reject" compatibility with other actions 263 This section applies equally to "reject" and "ereject" actions. 264 All references to the "reject" action in this section can be replaced 265 with the "ereject" action. 267 A "reject" action cancels the implicit keep. 269 Implementations MUST prohibit the execution of more than one reject 270 in a Sieve script. 272 "Reject" MUST be incompatible with the "vacation" [VACATION] 273 action. It is NOT RECOMMENDED that implementations permit the use of 274 "reject" with actions that cause mail delivery, such as "keep", 275 "fileinto", "redirect". 276 Making "reject" compatible with actions that cause mail delivery 277 violates the RFC 2821 principle that a message is either delivered or 278 bounced back to the sender. So bouncing a message back (rejecting) 279 and delivering it will make the sender believe that the message was 280 not delivered. 281 However, there are existing laws requiring certain organizations to 282 archive all received messages, even the rejected ones. Also, it can 283 be quite useful to save copies of rejected messages for later 284 analysis. 286 Any action that would modify the message body will not have an effect 287 on the body of any message refused by "reject" using an SMTP response 288 code and MUST NOT have any effect on the content of generated 289 DSN/MDNs. 291 3.4 Rejecting a message by sending an MDN 293 The reject action resends the received message to the envelope sender 294 specified by the MAIL FROM (or Return-Path) address, wrapping it in 295 a "reject" form, explaining that it was rejected by the recipient. 297 Note that according to [MDN], Message Disposition Notifications MUST 298 NOT be generated if the MAIL FROM (or Return-Path) is empty. 300 A reject message MUST take the form of a failure MDN as specified 301 by [MDN]. The human-readable portion of the message, the first 302 component of the MDN, contains the human readable message 303 describing the error, and it SHOULD contain additional text 304 alerting the apparent original sender that mail was refused by an 305 email filter. 307 The MDN disposition-field as defined in the MDN specification MUST 308 be "deleted" and MUST have the "MDN-sent-automatically" and 309 "automatic-action" modes set (see Section 3.2.6 of [MDN]). 311 In the following script, a message is rejected and returned to the 312 alleged sender. 314 Example: 315 require ["reject"]; 317 if header :contains "from" "coyote@desert.example.org" { 318 reject text: 319 I am not taking mail from you, and I don't 320 want your birdseed, either!" 321 . 322 ; 323 } 325 For this script, the first part of the MDN might appear as follows: 327 ------------------------------------------------------------ 328 The message was refused by the recipient's mail filtering program. 329 The reason given was as follows: 331 I am not taking mail from you, and I don't want your birdseed, 332 either! 333 ------------------------------------------------------------ 335 3.5 How "reject"/"ereject" should perform protocol level refusal 337 If the "reason" string consists of multiple CRLF separated lines, 338 then the reason text MUST be returned as a multiline SMTP/LMTP 339 response, per [SMTP], Section 4.2.1. Any line MUST NOT exceed the 340 SMTP limit on the maximal line length. To make the reason string 341 conform to any such limits the server MAY insert CRLFs and turn the 342 response into a multiline response. 344 In the following script (which assumes support for the spamtest 345 [SPAMTEST] and fileinto extensions), messages that test highly 346 positive for spam are refused. 348 Example: 349 require ["ereject", "spamtest", "fileinto", 350 "comparator-i;ascii-numeric"]; 352 if spamtest :value "ge" 353 :comparator "i;ascii-numeric" "6" { 354 ereject text: 355 AntiSpam engine thinks your message is spam. 356 It is therefore being refused. 357 Please call 1-900-PAY-US if you want to reach us. 358 . 359 ; 360 } elsif spamtest :value "ge" 361 :comparator "i;ascii-numeric" "4" { 362 fileinto "Suspect"; 363 } 365 The following excerpt from an SMTP session shows it in action. 366 ... 367 C: DATA 368 S: 354 Send message, ending in CRLF.CRLF. 369 ... 370 C: . 371 S: 550-AntiSpam engine thinks your message is spam. 372 S: 550-It is therefore being refused. 373 S: 550 Please call 1-900-PAY-US if you want to reach us. 375 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES] it MUST 376 prepend an appropriate Enhanced Error Code to the "reason" text. 377 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. 378 With an Enhanced Error Code, the response to DATA command in the SMTP 379 example below will look like: 381 S: 550-5.7.1 AntiSpam engine thinks your message is spam. 382 S: 550-5.7.1 It is therefore being refused. 383 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 385 if the server selected "5.7.1" as appropriate. 387 If a Sieve implementation that supports "ereject" doesn't wish to 388 immediately disclose the reason for rejection (for example that it 389 detected spam), it may delay immediately sending of the 550 error 390 code by sending a 4XX error code on the first attempt to receive 391 the message. 393 4. Security Considerations 395 The Introduction to this document discusses why rejecting messages 396 before delivery is better than accepting and bouncing them. 398 Security issues associated with email auto-responders are fully 399 discussed in the Security Considerations section of [RFC3834]. This 400 document is not believed to introduce any additional security 401 considerations in this general area. 403 The "ereject" extension does not raise any other security 404 considerations that are not already present in the base [SIEVE] 405 specification, and these issues are discussed in [SIEVE]. 407 5. IANA Considerations 409 The following section provides the IANA registrations for the Sieve 410 extensions specified in this document: 412 5.1 reject extension registration 414 IANA is requested to update the registration for the Sieve "reject" 415 extension as detailed below: 417 Capability name: reject 418 Description: adds the 'reject' action for refusing delivery 419 of a message. The exact reason for refusal is 420 conveyed back to the client. 421 RFC number: this RFC 422 Contact address: The Sieve discussion list 424 5.2 ereject extension registration 426 IANA is requested to replace the preliminary registration of the 427 Sieve refuse extension with the following registration: 429 << Issue of replace / obsolete the draft refuse extension: 431 Matthew: Would it be better to have it obsolete it, rather 432 than replace it? I think so, to prevent inadvertent reuse, 433 especially since there are 'refuse' implementations. 435 Alexey: I agree with obsoleting it, if you think there are 436 implementations. But I thought there were no implementations 437 of refuse. 439 >> 441 Capability name: ereject 442 Description: adds the 'ereject' action for refusing delivery 443 of a message. The refusal should happen as early 444 as possible (e.g. at the protocol level) and might 445 not preserve the exact reason for refusal if it 446 contains non-US-ASCII text. 447 RFC number: this RFC 448 Contact address: The Sieve discussion list 450 6. References 452 6.1 Normative References 454 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", RFC 2119, March 1997. 456 << NIT: KEYWORDS is never cited >> 458 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 459 Language", Work-in-progress, draft-ietf-sieve-3028bis-XX.txt 461 [SMTP] Klensin, J. (Editor), "Simple Mail Transfer Protocol", AT&T 462 Laboratories, RFC 2821, April 2001. 464 [LMTP] Myers, J., "Local Mail Transfer Protocol", Carnegie-Mellon 465 University, RFC 2033, October 1996. 466 << NIT: LMTP is Informative >> 468 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 469 Delivery Status Notifications", University of Tennessee, Lucent 470 Technologies, RFC 3464, January 2003. 472 [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition 473 Notification", RFC 3798, May 2004. 475 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 476 Reporting of Mail System Administrative Messages", RFC 3462, 477 January 2003. 479 [ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning 480 Enhanced Error Codes", Innosoft, RFC 2034, October 1996. 482 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 483 RFC 3629, November 2003. 485 [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: 486 Vacation Extension", work in progress, 487 draft-ietf-sieve-vacation-XX.txt. 489 6.2 Informative References 491 [Joe-DoS] Stefan Frei, Ivo Silvestri, Gunter Ollmann, "Mail Non 492 Delivery Message DDoS Attacks", 5 April 2004", 493 . 495 [SPAMTEST] Daboo, C., "SIEVE Email Filtering: Spamtest and 496 Virustest Extensions", work in progress, draft-ietf-sieve- 497 spamtestbis-XX.txt 499 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 500 Electronic Mail", RFC 3834, August 2004. 502 [UTF8-RESP] A. Melnikov (Ed.), "SMTP Language Extension", 503 work in progress, draft-melnikov-smtp-lang-XX.txt 505 7. Acknowledgments 507 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 508 Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens 509 for comments and corrections. 511 The authors gratefully acknowledge the extensive work of Tim 512 Showalter as the author of the RFC 3028, which originally defined 513 the "reject" action. 515 8. Authors' Addresses 517 Aaron Stone 518 libSieve Project 519 260 El Verano Ave 520 Palo Alto, CA 94306 521 USA 523 Email: aaron@serendipity.palo-alto.ca.us 525 Matthew Elvey 526 The Elvey Partnership, LLC 527 1819 Polk Street, Suite 133 528 San Francisco, CA 94109 529 USA 531 Email: sieve3@matthew.elvey.com 533 Alexey Melnikov 534 Isode Limited 535 5 Castle Business Village 536 36 Station Road 537 Hampton, Middlesex, TW12 2BX 538 UK 540 Email: Alexey.Melnikov@isode.com 542 9. Intellectual Property Rights Statement 544 The IETF takes no position regarding the validity or scope of any 545 Intellectual Property Rights or other rights that might be claimed to 546 pertain to the implementation or use of the technology described in 547 this document or the extent to which any license under such rights 548 might or might not be available; nor does it represent that it has 549 made any independent effort to identify any such rights. Information 550 on the procedures with respect to rights in RFC documents can be 551 found in BCP 78 and BCP 79. 553 Copies of IPR disclosures made to the IETF Secretariat and any 554 assurances of licenses to be made available, or the result of an 555 attempt made to obtain a general license or permission for the use of 556 such proprietary rights by implementers or users of this 557 specification can be obtained from the IETF on-line IPR repository at 558 http://www.ietf.org/ipr. 560 The IETF invites any interested party to bring to its attention any 561 copyrights, patents or patent applications, or other proprietary 562 rights that may cover technology that may be required to implement 563 this standard. Please address the information to the IETF at 564 ietf-ipr@ietf.org. 566 10. Full Copyright Statement 568 Copyright (C) The IETF Trust (2007). 570 This document is subject to the rights, licenses and restrictions 571 contained in BCP 78, and except as set forth therein, the authors 572 retain all their rights. 574 This document and the information contained herein are provided on an 575 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 576 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 577 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 578 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 579 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 580 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 582 Acknowledgement 584 Funding for the RFC Editor function is currently provided by the 585 Internet Society. 587 11. Changes from RFC 3028 589 Clarified that the "reject" action cancels the implicit keep. 590 Extended list of allowable actions on "reject" to include protocol 591 level message rejection. 593 Added the "ereject" action that is similar to "reject", but will 594 always favor protocol level message rejection. 596 12. Change Log 598 <> 601 00 First formal draft. 602 01 Explicit RFC 2034 support, disallow "refuse" in MUAs, typos 603 corrected, clarifications, etc. 604 02 Many insubstantial editorial changes (mostly rewording text for 605 readability). Added text regarding non-ASCII characters in the 606 refuse "reason" string. Added an exception allowing return-path 607 forgery to justify discarding a message. 608 03 (Renamed to be SIEVE WG 00) - Updated boilerplate, added reject 609 action from the base spec, acknowledged Tim as the author of 610 "reject". 611 04 (SIEVE WG 01) Based on WGLC feedback, the refuse and the reject 612 actions were merged into a single action called reject. Text 613 reorganized as the result. Typos and examples corrected. Updated 614 IANA registration and Security Considerations sections. 615 05 (SIEVE WG 02) Copied some security considerations from Vacation 616 draft. Clarified that the "reason" string is in UTF-8. Clarified 617 interaction with "editheader" extension. Added text about sending 618 of 4XX instead of 550. Corrected typos in several examples. 619 06 (SIEVE WG 03) Explicitly list all actions incompatible w/ 620 reject. Added two paragraphs explaining why reject SHOULD (as 621 opposed to MUST/MAY) be incompatible with them. Clarified that if 622 the reason string contains non-ASCII and rejection over protocol 623 is possible, then the reason string MUST be replaced with an 624 implementations defined ASCII-only string. Added :exacttext 625 optional argument that preserves UTF-8 reason string by forcing 626 generation of DSN. 627 07 (SIEVE WG 04) Removed special handling of empty return path. 628 Several editorial changes from Randy Gellens. 629 Clarified :exacttext applicability, removed redundancy. Reverted 630 SHOULD NOT send MDNs back to MUST NOT send MDNs of earlier drafts 631 (section 3.1.3). 632 08 (SIEVE WG 05) 633 Reformatted the text to use no more than 72 characters per line. 634 Reverted back to two actions (reject and ereject), as per 635 consensus at the IETF 67. Major text update/rewrite as the 636 result. Changed the order of actions that can be performed by 637 ereject: protocol level rejection should always be first, 638 followed by "accept and discard" for the case of faked return 639 path. Added more details on how DSN reports should be generated. 640 09 Editorship of this document taken over by Aaron Stone. Many 641 general edits, including clarifications and grammar and spelling 642 corrections. Updated boilerplate to RFC 4748. Nits identified. 643 Republished for the first time in a long time.