idnits 2.17.1 draft-ietf-sieve-refuse-reject-09.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 651. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3028, but the abstract doesn't seem to directly say this. It does mention RFC3028 though, so this could be OK. -- The draft header indicates that this document updates RFC5228, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC5228, updated by this document, for RFC5378 checks: 2005-05-09) -- 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 (November 17, 2008) is 5611 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) ** 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) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-11 -- Obsolete informational reference (is this intentional?): RFC 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Stone, Ed. 3 Internet-Draft Serendipity 4 Obsoletes: 3028 (if approved) 5 Updates: 5228 (if approved) November 17, 2008 6 Intended status: Standards Track 7 Expires: May 21, 2009 9 Sieve Email Filtering: Reject and Extended Reject Extensions 10 draft-ietf-sieve-refuse-reject-09 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 21, 2009. 37 Abstract 39 This memo updates the definition of the Sieve mail filtering language 40 "reject" extension, originally defined in RFC 3028. 42 A "Joe-job" is a spam run forged to appear as though it came from an 43 innocent party, who is then generally flooded by automated bounces, 44 Message Disposition Notifications (MDNs), and personal messages with 45 complaints. The original Sieve "reject" action defined in RFC 3028 46 required use of MDNs for rejecting messages, thus contributing to the 47 flood of Joe-job spam to victims of Joe-jobs. 49 This memo updates the definition of the "reject" action to allow 50 messages to be refused during the SMTP transaction, and defines the 51 "ereject" action to require messages to be refused during the SMTP 52 transaction, if possible. 54 The "ereject" action is intended to replace the "reject" action 55 wherever possible. The "ereject" action is similar to "reject", but 56 will always favor protocol level message rejection. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 62 2. Sieve 'reject' and 'ereject' Extentions . . . . . . . . . . . 4 63 2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.1. Rejecting a message at the SMTP/LMTP protocol level . 5 65 2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 5 66 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6 67 2.2.1. Rejecting a message by sending an MDN . . . . . . . . 7 68 2.3. Silent upgrade from reject to ereject . . . . . . . . . . 8 69 2.4. Compatibility with other actions . . . . . . . . . . . . . 8 70 2.5. Details of protocol level refusal . . . . . . . . . . . . 9 71 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. reject extension registration . . . . . . . . . . . . . . 11 75 5.2. ereject extension registration . . . . . . . . . . . . . . 12 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . . . 15 83 1. Introduction 85 The Sieve mail filtering language, as originally defined in RFC 3028 86 [SIEVE], specified that the "reject" action shall discard a message 87 and send a Message Disposition Notification [MDN] to the envelope 88 sender along with an explanatory message. The Sieve mail filtering 89 language, as updated in RFC 5228 [SIEVEBIS], does not define any 90 reject action, hence the purpose of this document. 92 This document updates the definition of the "reject" action to permit 93 refusal of the message during the SMTP transaction, if possible, and 94 defines a new "ereject" action to require refusal of the message 95 during the SMTP transaction, if possible. 97 An important goal of this document is to reduce the risk of Sieve 98 scripts being used to perpetrate "Joe-job" spam runs, where the MDN 99 sent notifying the sender of a message of its non-delivery is in fact 100 sent to an innocent third-party. The original Sieve "reject" action 101 defined in RFC 3028 required use of MDNs for rejecting messages, thus 102 contributing to the flood of Joe-job spam to victims of Joe-jobs. By 103 rejecting the message at the protocol level, it is less likely that 104 an MDN will be needed, and so less likely that an MDN will be 105 misdirected at an innocent third-party. 107 Implementations are further encouraged to use spam-detection systems 108 to determine the level of risk associated with sending an MDN, and 109 this document allows implementations to silently drop the MDN if the 110 rejected message is deemed to be likely spam. 112 This document also describes how to use reject/ereject at varying 113 points in the email stack: Mail Transfer Agent (MTA), Mail Delivery 114 Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a 115 comprehensive discussion of these environments. 117 In general, an MDN is generated by an MUA, and can be used to 118 indicate the status of a message with respect to its recipient, while 119 a DSN [DSN] is generated by an MTA, and can be used to indicate 120 whether or not a message was received and delivered by the mail 121 system. 123 Further discussion highlighting the risks of generating MDNs and the 124 benefits of protocol-level refusal can be found in [Joe-DoS]. 126 1.1. Conventions Used in This Document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [KEYWORDS]. 132 Conventions for notations are as in RFC 5228 [SIEVEBIS] Section 1.1. 134 This document does not attempt to define spam or how it should be 135 identified, nor to define an email virus or how it should be 136 detected. Implementors are advised to follow best practices and keep 137 abreast of current research in these fields. 139 2. Sieve 'reject' and 'ereject' Extentions 141 2.1. Action ereject 143 Usage: ereject 145 Sieve implementations that implement the "ereject" action must use 146 the "ereject" capability string. 148 The "ereject" action cancels the implicit keep and refuses delivery 149 of a message. The reason string is a UTF-8 [UTF-8] string specifying 150 the reason for refusal. How a message is refused depends on the 151 capabilities of the mail component (MDA or MTA) executing the Sieve 152 script. The Sieve interpreter MUST carry out one of the following 153 actions (listed in order from most to least preferred), MUST carry 154 out the most preferable action possible, and MUST fall back to lesser 155 actions if a preferred action fails. 157 1. Refuse message delivery by sending a 5XX response code over SMTP 158 [SMTP] or LMTP [LMTP]. See Section 2.1.1 for more details. 160 2. Send a non-delivery report to the envelope sender ([REPORT] 161 [DSN]), unless the envelope sender address is determined to be a 162 forged or otherwise invalid address. 164 Note that determination of whether or not an envelope sender is a 165 forgery may be performed by site-specific and implementation-specific 166 heuristic techniques, such as "return-path verification", details of 167 which are outside the scope of this document. Implementations SHOULD 168 log instances when a non-delivery report is not sent and the reason 169 for not sending the report (e.g. content was spam, return-path 170 invalid, etc.). 172 The ereject action MUST NOT be available in environments that do not 173 support protocol level rejection, e.g. an MUA, and MUST be available 174 in all other environments that support the reject action. 176 Example: 177 require ["ereject"]; 179 if address "from" "someone@example.com" { 180 ereject "I no longer accept mail from this address"; 181 } 183 2.1.1. Rejecting a message at the SMTP/LMTP protocol level 185 Sieve implementations that are able to reject messages at the SMTP/ 186 LMTP level MUST do so and SHOULD use the 550 response code. Note 187 that if a message is arriving over SMTP and has multiple recipients, 188 some of whom have accepted the message, Section 2.1.2 defines how to 189 reject such a message. 191 The risk that these actions will generate blowback spam are minimized 192 but cannot be eliminated completely even in the case of ereject, so 193 caution is advised when using these actions to deal with messages 194 determined to be spam. 196 Note that SMTP [SMTP] does not allow non-ASCII characters in the SMTP 197 response text. If non-ASCII characters appear in the "reason" 198 string, they can be sent at the protocol level if and only if the 199 client and the server use an SMTP extension that allows for 200 transmission of non-ASCII reply text. (One example of such an SMTP 201 extension is described in [UTF8-RESP].) In the absence of such an 202 SMTP extension, the Sieve engine MUST replace any reason string being 203 sent at the protocol level and containing non-ASCII characters with 204 an implementation-defined ASCII-only string. 206 Users who don't like this behavior should consider using the "reject" 207 action described in Section 2.2, if available. 209 See Section 2.5 for the detailed instructions about performing 210 protocol level rejection. 212 2.1.2. Rejecting a message by sending a DSN 214 An implementation may receive a message via SMTP that has more than 215 one RCPT TO that has been accepted by the server, and at least one 216 but not all of them are refusing delivery (whether the refusal is 217 caused by a Sieve "ereject" action or for some other reason). In 218 this case, the server MUST accept the message and generate DSNs for 219 all recipients that are refusing it. Note that this exception does 220 not apply to LMTP, as LMTP is able to reject messages on a per- 221 recipient basis. (However, the LMTP client may then have no choice 222 but to generate a DSN to report the error, which may result in 223 blowback spam.) 224 Note that according to [DSN], Delivery Status Notifications MUST NOT 225 be generated if the MAIL FROM (or Return-Path) is empty. 227 The DSN message MUST follow the requirements of [DSN] and [REPORT] 228 The action-value field defined in [DSN], Section 2.3.3, MUST contain 229 the value "failed". The human-readable portion of the non-delivery 230 report MUST contain the reason string from the "ereject" action and 231 SHOULD contain additional text alerting the apparent original sender 232 that the message was refused by an email filter. This part of the 233 report might appear as follows: 235 ------------------------------------------------------------ 236 Your message was refused by the recipient's mail filtering program. 237 The reason given was as follows: 239 I am not taking mail from you, and I don't want your birdseed, 240 either! 241 ------------------------------------------------------------ 243 2.2. Action reject 245 This section updates the definition of the reject action in Section 246 4.1 of RFC 3028 and is an optional extension to [SIEVEBIS]. 248 Usage: reject 250 Sieve implementations that implement the "reject" action must use the 251 "reject" capability string. 253 The "reject" action cancels the implicit keep and refuses delivery of 254 a message. The reason string is a UTF-8 [UTF-8] string specifying 255 the reason for refusal. Unlike the "ereject" action described above, 256 this action would always favor preserving the exact text of the 257 refusal reason. Typically the "reject" action refuses delivery of a 258 message by sending back an MDN to the sender (see Section 2.2.1). 259 However implementations MAY refuse delivery over SMTP/LMTP protocol 260 (as detailed in Section 2.5), if and only if all of the following 261 conditions are true: 263 1. The reason string consists of only US-ASCII characters 264 or 265 The reason string contains non-US-ASCII and both client and 266 server support and negotiate use of an SMTP/LMTP extension for 267 sending UTF-8 responses. 269 2. LMTP protocol is used 270 or 271 SMTP protocol is used and the message has a single recipient 272 or 273 SMTP protocol is used, the message has multiple recipients, and 274 all of them refused message delivery (whether using Sieve or 275 not). 277 Example: 278 require ["reject"]; 280 if size :over 100K { 281 reject text: 282 Your message is too big. If you want to send me a big attachment, 283 put it on a public web site and send me an URL. 284 . 285 ; 286 } 288 (Pretend that the reason string above contains some non-ASCII text.) 290 Implementations may use techniques as described in Section 2.1 to 291 determine if a non-delivery report should not be sent to a forged 292 sender. Implementations SHOULD log instances when a non-delivery 293 report is not sent and the reason for not sending the report. 295 2.2.1. Rejecting a message by sending an MDN 297 The reject action resends the received message to the envelope sender 298 specified by the MAIL FROM (or Return-Path) address, wrapping it in a 299 "reject" form, explaining that it was rejected by the recipient. 301 Note that according to [MDN], Message Disposition Notifications MUST 302 NOT be generated if the MAIL FROM (or Return-Path) is empty. 304 A reject message MUST take the form of a failure MDN as specified by 305 [MDN]. The human-readable portion of the message, the first 306 component of the MDN, contains the human readable message describing 307 the error, and it SHOULD contain additional text alerting the 308 apparent original sender that mail was refused by an email filter. 310 The MDN disposition-field as defined in the MDN specification MUST be 311 "deleted" and MUST have the "MDN-sent-automatically" and "automatic- 312 action" modes set (see Section 3.2.6 of [MDN]). 314 In the following script, a message is rejected and returned to the 315 sender. 317 Example: 318 require ["reject"]; 320 if header :contains "from" "coyote@desert.example.org" { 321 reject text: 322 I am not taking mail from you, and I don't 323 want your birdseed, either!" 324 . 325 ; 326 } 328 For this script, the first part of the MDN might appear as follows: 330 ------------------------------------------------------------ 331 The message was refused by the recipient's mail filtering program. 332 The reason given was as follows: 334 I am not taking mail from you, and I don't want your birdseed, 335 either! 336 ------------------------------------------------------------ 338 2.3. Silent upgrade from reject to ereject 340 Implementations MUST NOT silently upgrade reject actions to ereject 341 actions in a Sieve script, because this might lead to unpleasant 342 changes of behavior not expected by the script owner. 344 User interfaces that present a generic rejection option, and generate 345 Sieve script output, MAY switch from generating reject to ereject 346 actions, so long as doing so does not create a confusing change for 347 the script owner. 349 Script generators SHOULD ensure that a rejection action being 350 executed as a result of an anti-spam/anti-virus positive test be done 351 using the ereject action, as it is more suitable for such rejections. 353 Script generators MAY automatically upgrade scripts that previously 354 used the reject action for anti-spam/anti-virus related rejections. 355 Note that such generators MUST make sure that the target environment 356 can support the ereject action. 358 2.4. Compatibility with other actions 360 This section applies equally to "reject" and "ereject" actions. All 361 references to the "reject" action in this section can be replaced 362 with the "ereject" action. 364 A "reject" action cancels the implicit keep. 366 Implementations MUST prohibit the execution of more than one reject 367 in a Sieve script. 369 "Reject" MUST be incompatible with the "vacation" [VACATION] action. 370 It is NOT RECOMMENDED that implementations permit the use of "reject" 371 with actions that cause mail delivery, such as "keep", "fileinto", 372 "redirect". 374 Making "reject" compatible with actions that cause mail delivery 375 violates the RFC 2821 [SMTP] principle that a message is either 376 delivered or bounced back to the sender. So bouncing a message back 377 (rejecting) and delivering it will make the sender believe that the 378 message was not delivered. 380 However, there are existing laws requiring certain organizations to 381 archive all received messages, even the rejected ones. Also, it can 382 be quite useful to save copies of rejected messages for later 383 analysis. 385 Any action that would modify the message body will not have an effect 386 on the body of any message refused by "reject" using an SMTP response 387 code and MUST NOT have any effect on the content of generated DSN/ 388 MDNs. 390 2.5. Details of protocol level refusal 392 If the "reason" string consists of multiple CRLF separated lines, 393 then the reason text MUST be returned as a multiline SMTP/LMTP 394 response, per [SMTP], Section 4.2.1. Any line MUST NOT exceed the 395 SMTP limit on the maximal line length. To make the reason string 396 conform to any such limits the server MAY insert CRLFs and turn the 397 response into a multiline response. 399 In the following script (which assumes support for the spamtest 400 [SPAMTEST] and fileinto extensions), messages that test highly 401 positive for spam are refused. 403 Example: 404 require ["ereject", "spamtest", "fileinto", 405 "comparator-i;ascii-numeric"]; 407 if spamtest :value "ge" 408 :comparator "i;ascii-numeric" "6" { 409 ereject text: 410 AntiSpam engine thinks your message is spam. 411 It is therefore being refused. 412 Please call 1-900-PAY-US if you want to reach us. 413 . 414 ; 415 } elsif spamtest :value "ge" 416 :comparator "i;ascii-numeric" "4" { 417 fileinto "Suspect"; 418 } 420 The following excerpt from an SMTP session shows it in action. 422 ... 423 C: DATA 424 S: 354 Send message, ending in CRLF.CRLF. 425 ... 426 C: . 427 S: 550-AntiSpam engine thinks your message is spam. 428 S: 550-It is therefore being refused. 429 S: 550 Please call 1-900-PAY-US if you want to reach us. 431 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES] it MUST 432 prepend an appropriate Enhanced Error Code to the "reason" text. 433 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. 434 With an Enhanced Error Code, the response to DATA command in the SMTP 435 example below will look like: 437 S: 550-5.7.1 AntiSpam engine thinks your message is spam. 438 S: 550-5.7.1 It is therefore being refused. 439 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 441 if the server selected "5.7.1" as appropriate. 443 If a Sieve implementation that supports "ereject" does not wish to 444 immediately disclose the reason for rejection (for example, that it 445 detected spam), it may delay immediately sending of the 550 error 446 code by sending a 4XX error code on the first attempt to receive the 447 message. 449 3. Changes from RFC 3028 451 Clarified that the "reject" action cancels the implicit keep. 452 Extended the list of allowable actions on "reject" to include 453 protocol level message rejection. 455 Added the "ereject" action that is similar to "reject", but will 456 always favor protocol level message rejection. 458 4. Security Considerations 460 The Introduction to this document discusses why rejecting messages 461 before delivery is better than accepting and bouncing them. 463 While the details of techniques that can be used to determine when to 464 silently drop a non-delivery report are outside the scope of this 465 document, the explicit permission this document gives to take such 466 action may enable denial of service situations. Techniques such as 467 spam-checking, return-path verification, and others, can and do have 468 false-positives. Care should be exercised to prevent the loss of 469 legitimate messages by failing to notify the sender of non-delivery. 471 Security issues associated with email auto-responders are fully 472 discussed in the Security Considerations section of [RFC3834]. This 473 document is not believed to introduce any additional security 474 considerations in this general area. 476 The "ereject" extension does not raise any other security 477 considerations that are not already present in the base [SIEVE] 478 specification, and these issues are discussed in [SIEVE]. 480 5. IANA Considerations 482 The following section provides the IANA registrations for the Sieve 483 extensions specified in this document: 485 5.1. reject extension registration 487 IANA is requested to update the registration for the Sieve "reject" 488 extension as detailed below: 490 Capability name: reject 491 Description: adds the "reject" action for refusing delivery 492 of a message. The exact reason for refusal is 493 conveyed back to the client. 494 RFC number: this RFC 495 Contact address: the Sieve discussion list 497 5.2. ereject extension registration 499 IANA is requested to replace the preliminary registration of the 500 Sieve refuse extension with the following registration: 502 Capability name: ereject 503 Description: adds the 'ereject' action for refusing delivery 504 of a message. The refusal should happen as early 505 as possible (e.g. at the protocol level) and might 506 not preserve the exact reason for refusal if it 507 contains non-US-ASCII text. 508 RFC number: this RFC 509 Contact address: the Sieve discussion list 511 6. References 513 6.1. Normative References 515 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 516 for Delivery Status Notifications", RFC 3464, 517 January 2003. 519 [ENHANCED-CODES] 520 Freed, N., "SMTP Service Extension for Returning Enhanced 521 Error Codes", RFC 2034, October 1996. 523 [KEYWORDS] 524 Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 528 October 1996. 530 [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition 531 Notification", RFC 3798, May 2004. 533 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 534 Reporting of Mail System Administrative Messages", 535 RFC 3462, January 2003. 537 [SIEVEBIS] 538 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 539 Language", RFC 5228, January 2008. 541 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 542 April 2001. 544 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 545 10646", STD 63, RFC 3629, November 2003. 547 [VACATION] 548 Showalter, T. and N. Freed, "Sieve Email Filtering: 549 Vacation Extension", RFC 5230, January 2008. 551 6.2. Informative References 553 [EMAIL-ARCH] 554 Crocker, D., "Internet Mail Architecture", 555 draft-crocker-email-arch-11 (work in progress), 556 October 2008. 558 [Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-Delivery 559 Notice Attacks", April 2004, . 562 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 563 Electronic Mail", RFC 3834, August 2004. 565 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", 566 RFC 3028, January 2001. 568 [SPAMTEST] 569 Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 570 Extensions", RFC 5235, January 2008. 572 [UTF8-RESP] 573 Melnikov, A., "SMTP Language Extension", 574 draft-melnikov-smtp-lang-07 (work in progress), June 2007. 576 Appendix A. Acknowledgements 578 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 579 Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens 580 for comments and corrections. 582 The authors gratefully acknowledge the extensive work of Tim 583 Showalter as the author of the RFC 3028, which originally defined the 584 "reject" action. 586 Authors' Addresses 588 Aaron Stone (editor) 589 Serendipity 590 260 El Verano Ave 591 Palo Alto, CA 94306 592 USA 594 Email: aaron@serendipity.palo-alto.ca.us 596 Matthew Elvey 597 The Elvey Partnership, LLC 598 1819 Polk Street, Suite 133 599 San Francisco, CA 94109 600 USA 602 Email: sieve3@matthew.elvey.com 604 Alexey Melnikov 605 Isode Limited 606 5 Castle Business Village 607 36 Station Road 608 Hampton, Middlesex TW12 2BX 609 UK 611 Email: Alexey.Melnikov@isode.com 613 Full Copyright Statement 615 Copyright (C) The IETF Trust (2008). 617 This document is subject to the rights, licenses and restrictions 618 contained in BCP 78, and except as set forth therein, the authors 619 retain all their rights. 621 This document and the information contained herein are provided on an 622 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 623 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 624 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 625 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 626 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 627 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 629 Intellectual Property 631 The IETF takes no position regarding the validity or scope of any 632 Intellectual Property Rights or other rights that might be claimed to 633 pertain to the implementation or use of the technology described in 634 this document or the extent to which any license under such rights 635 might or might not be available; nor does it represent that it has 636 made any independent effort to identify any such rights. Information 637 on the procedures with respect to rights in RFC documents can be 638 found in BCP 78 and BCP 79. 640 Copies of IPR disclosures made to the IETF Secretariat and any 641 assurances of licenses to be made available, or the result of an 642 attempt made to obtain a general license or permission for the use of 643 such proprietary rights by implementers or users of this 644 specification can be obtained from the IETF on-line IPR repository at 645 http://www.ietf.org/ipr. 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 this standard. Please address the information to the IETF at 651 ietf-ipr@ietf.org.