idnits 2.17.1 draft-ietf-sieve-refuse-reject-08.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 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 635. 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 5640 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'VACATION' == 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 (==), 11 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-08 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 . . . . . . . . . . . . . . 11 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 specifies the use of a Delivery Status 113 Notification [DSN] instead of an MDN when appropriate. In general, 114 an MDN is generated by [[[arnt's text]]] while a DSN is generated by 115 [[[arnt's text]]]. 117 This document also describes how to use reject/ereject at varying 118 points in the email stack: Mail Transfer Agent (MTA), Mail Delivery 119 Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a 120 comprehensive discussion of these environments. 122 Further discussion highlighting the risks of generating MDNs and the 123 benefits of protocol-level refusal can be found in [Joe-DoS]. 125 1.1. Conventions Used in This Document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [KEYWORDS]. 131 Conventions for notations are as in RFC 5228 [SIEVEBIS] Section 1.1. 133 This document does not attempt to define spam or how it should be 134 identified, nor to define an email virus or how it should be 135 detected. Implementors are advised to follow best practices and keep 136 abreast of current research in these fields. 138 2. Sieve 'reject' and 'ereject' Extentions 140 2.1. Action ereject 142 Usage: ereject 144 Sieve implementations that implement the "ereject" action must use 145 the "ereject" capability string. 147 The "ereject" action cancels the implicit keep and refuses delivery 148 of a message. The reason string is a UTF-8 [UTF-8] string specifying 149 the reason for refusal. How a message is refused depends on the 150 capabilities of the mail component (MDA or MTA) executing the Sieve 151 script. The Sieve interpreter MUST carry out one of the following 152 actions (listed in order from most to least preferred), MUST carry 153 out the most preferable action possible, and MUST fall back to lesser 154 actions if a preferred action fails. 156 1. Refuse message delivery by sending a 5XX response code over SMTP 157 [SMTP] or LMTP [LMTP]. See Section 2.1.1 for more details. 159 2. Send a non-delivery report to the envelope sender ([REPORT] 160 [DSN]), unless the envelope sender address is determined to be a 161 forged or otherwise invalid address. 163 Note that determination of whether or not an envelope sender is a 164 forgery may be performed by site-specific and implementation-specific 165 heuristic techniques, such as "return-path verification", details of 166 which are outside the scope of this document. Implementations SHOULD 167 log instances when a non-delivery report is not sent and the reason 168 for not sending the report (e.g. content was spam, return-path 169 invalid, etc.). 171 The ereject action MUST NOT be available in environments that do not 172 support protocol level rejection, e.g. an MUA, and MUST be available 173 in all other environments that support the reject action. 175 Example: 176 require ["ereject"]; 178 if address "from" "someone@example.com" { 179 ereject "I no longer accept mail from this address"; 180 } 182 2.1.1. Rejecting a message at the SMTP/LMTP protocol level 184 Sieve implementations that are able to reject messages at the SMTP/ 185 LMTP level MUST do so and SHOULD use the 550 response code. Note 186 that if a message is arriving over SMTP and has multiple recipients, 187 some of whom have accepted the message, Section 2.1.2 defines how to 188 reject such a message. 190 The risk that these actions will generate blowback spam are minimized 191 but cannot be eliminated completely even in the case of ereject, so 192 caution is advised when using these actions to deal with messages 193 determined to be spam. 195 Note that SMTP [SMTP] does not allow non-ASCII characters in the SMTP 196 response text. If non-ASCII characters appear in the "reason" 197 string, they can be sent at the protocol level if and only if the 198 client and the server use an SMTP extension that allows for 199 transmission of non-ASCII reply text. (One example of such an SMTP 200 extension is described in [UTF8-RESP].) In the absence of such an 201 SMTP extension, the Sieve engine MUST replace any reason string being 202 sent at the protocol level and containing non-ASCII characters with 203 an implementation-defined ASCII-only string. 205 Users who don't like this behavior should consider using the "reject" 206 action described in Section 2.2, if available. 208 See Section 2.5 for the detailed instructions about performing 209 protocol level rejection. 211 2.1.2. Rejecting a message by sending a DSN 213 An implementation may receive a message via SMTP that has more than 214 one RCPT TO that has been accepted by the server, and at least one 215 but not all of them are refusing delivery (whether the refusal is 216 caused by a Sieve "ereject" action or for some other reason). In 217 this case, the server MUST accept the message and generate DSNs for 218 all recipients that are refusing it. Note that this exception does 219 not apply to LMTP, as LMTP is able to reject messages on a per- 220 recipient basis. (However, the LMTP client may then have no choice 221 but to generate a DSN to report the error, which may result in 222 blowback spam.) 223 Note that according to [DSN], Delivery Status Notifications MUST NOT 224 be generated if the MAIL FROM (or Return-Path) is empty. 226 The DSN message MUST follow the requirements of [DSN] and [REPORT] 227 The action-value field defined in [DSN], Section 2.3.3, MUST contain 228 the value "failed". The human-readable portion of the non-delivery 229 report MUST contain the reason string from the "ereject" action and 230 SHOULD contain additional text alerting the apparent original sender 231 that the message was refused by an email filter. This part of the 232 report might appear as follows: 234 ------------------------------------------------------------ 235 Your message was refused by the recipient's mail filtering program. 236 The reason given was as follows: 238 I am not taking mail from you, and I don't want your birdseed, 239 either! 240 ------------------------------------------------------------ 242 2.2. Action reject 244 This section updates the definition of the reject action in Section 245 4.1 of RFC 3028 and is an optional extension to [SIEVEBIS]. 247 Usage: reject 249 Sieve implementations that implement the "reject" action must use the 250 "reject" capability string. 252 The "reject" action cancels the implicit keep and refuses delivery of 253 a message. The reason string is a UTF-8 [UTF-8] string specifying 254 the reason for refusal. Unlike the "ereject" action described above, 255 this action would always favor preserving the exact text of the 256 refusal reason. Typically the "reject" action refuses delivery of a 257 message by sending back an MDN to the alleged sender (see 258 Section 2.2.1). However implementations MAY refuse delivery over 259 SMTP/LMTP protocol (as detailed in Section 2.5), if and only if all 260 of the following conditions are true: 262 1. The reason string consists of only US-ASCII characters 263 or 264 The reason string contains non-US-ASCII and both client and 265 server support and negotiate use of an SMTP/LMTP extension for 266 sending UTF-8 responses. 268 2. LMTP protocol is used 269 or 270 SMTP protocol is used and the message has a single recipient 271 or 272 SMTP protocol is used, the message has multiple recipients, and 273 all of them refused message delivery (whether using Sieve or 274 not). 276 Example: 277 require ["reject"]; 279 if size :over 100K { 280 reject text: 281 Your message is too big. If you want to send me a big attachment, 282 put it on a public web site and send me an URL. 283 . 284 ; 285 } 287 (Pretend that the reason string above contains some non-ASCII text.) 289 2.2.1. Rejecting a message by sending an MDN 291 The reject action resends the received message to the envelope sender 292 specified by the MAIL FROM (or Return-Path) address, wrapping it in a 293 "reject" form, explaining that it was rejected by the recipient. 295 Note that according to [MDN], Message Disposition Notifications MUST 296 NOT be generated if the MAIL FROM (or Return-Path) is empty. 298 A reject message MUST take the form of a failure MDN as specified by 299 [MDN]. The human-readable portion of the message, the first 300 component of the MDN, contains the human readable message describing 301 the error, and it SHOULD contain additional text alerting the 302 apparent original sender that mail was refused by an email filter. 304 The MDN disposition-field as defined in the MDN specification MUST be 305 "deleted" and MUST have the "MDN-sent-automatically" and "automatic- 306 action" modes set (see Section 3.2.6 of [MDN]). 308 In the following script, a message is rejected and returned to the 309 alleged sender. 311 Example: 312 require ["reject"]; 314 if header :contains "from" "coyote@desert.example.org" { 315 reject text: 316 I am not taking mail from you, and I don't 317 want your birdseed, either!" 318 . 319 ; 320 } 322 For this script, the first part of the MDN might appear as follows: 324 ------------------------------------------------------------ 325 The message was refused by the recipient's mail filtering program. 326 The reason given was as follows: 328 I am not taking mail from you, and I don't want your birdseed, 329 either! 330 ------------------------------------------------------------ 332 2.3. Silent upgrade from reject to ereject 334 Implementations MUST NOT silently upgrade reject actions to ereject 335 actions, however user interfaces may change the specific action 336 underlying a descriptive representation, thereby effecting a silent 337 upgrade of sorts. 339 Script generators SHOULD ensure that a rejection action being 340 executed as a result of an anti-spam/anti-virus positive test be done 341 using the ereject action, as it is more suitable for such rejections. 343 Script generators MAY automatically upgrade scripts that previously 344 used the reject action for anti-spam/anti-virus related rejections. 345 Note that such generators MUST make sure that the target environment 346 can support the ereject action. 348 2.4. Compatibility with other actions 350 This section applies equally to "reject" and "ereject" actions. All 351 references to the "reject" action in this section can be replaced 352 with the "ereject" action. 354 A "reject" action cancels the implicit keep. 356 Implementations MUST prohibit the execution of more than one reject 357 in a Sieve script. 359 "Reject" MUST be incompatible with the "vacation" [VACATION] action. 360 It is NOT RECOMMENDED that implementations permit the use of "reject" 361 with actions that cause mail delivery, such as "keep", "fileinto", 362 "redirect". 364 Making "reject" compatible with actions that cause mail delivery 365 violates the RFC 2821 [SMTP] principle that a message is either 366 delivered or bounced back to the sender. So bouncing a message back 367 (rejecting) and delivering it will make the sender believe that the 368 message was not delivered. 370 However, there are existing laws requiring certain organizations to 371 archive all received messages, even the rejected ones. Also, it can 372 be quite useful to save copies of rejected messages for later 373 analysis. 375 Any action that would modify the message body will not have an effect 376 on the body of any message refused by "reject" using an SMTP response 377 code and MUST NOT have any effect on the content of generated DSN/ 378 MDNs. 380 2.5. Details of protocol level refusal 382 If the "reason" string consists of multiple CRLF separated lines, 383 then the reason text MUST be returned as a multiline SMTP/LMTP 384 response, per [SMTP], Section 4.2.1. Any line MUST NOT exceed the 385 SMTP limit on the maximal line length. To make the reason string 386 conform to any such limits the server MAY insert CRLFs and turn the 387 response into a multiline response. 389 In the following script (which assumes support for the spamtest 390 [SPAMTEST] and fileinto extensions), messages that test highly 391 positive for spam are refused. 393 Example: 394 require ["ereject", "spamtest", "fileinto", 395 "comparator-i;ascii-numeric"]; 397 if spamtest :value "ge" 398 :comparator "i;ascii-numeric" "6" { 399 ereject text: 400 AntiSpam engine thinks your message is spam. 401 It is therefore being refused. 402 Please call 1-900-PAY-US if you want to reach us. 403 . 404 ; 405 } elsif spamtest :value "ge" 406 :comparator "i;ascii-numeric" "4" { 407 fileinto "Suspect"; 408 } 410 The following excerpt from an SMTP session shows it in action. 412 ... 413 C: DATA 414 S: 354 Send message, ending in CRLF.CRLF. 415 ... 416 C: . 417 S: 550-AntiSpam engine thinks your message is spam. 418 S: 550-It is therefore being refused. 419 S: 550 Please call 1-900-PAY-US if you want to reach us. 421 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES] it MUST 422 prepend an appropriate Enhanced Error Code to the "reason" text. 423 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. 424 With an Enhanced Error Code, the response to DATA command in the SMTP 425 example below will look like: 427 S: 550-5.7.1 AntiSpam engine thinks your message is spam. 428 S: 550-5.7.1 It is therefore being refused. 429 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 431 if the server selected "5.7.1" as appropriate. 433 If a Sieve implementation that supports "ereject" does not wish to 434 immediately disclose the reason for rejection (for example, that it 435 detected spam), it may delay immediately sending of the 550 error 436 code by sending a 4XX error code on the first attempt to receive the 437 message. 439 3. Changes from RFC 3028 441 Clarified that the "reject" action cancels the implicit keep. 442 Extended the list of allowable actions on "reject" to include 443 protocol level message rejection. 445 Added the "ereject" action that is similar to "reject", but will 446 always favor protocol level message rejection. 448 4. Security Considerations 450 The Introduction to this document discusses why rejecting messages 451 before delivery is better than accepting and bouncing them. 453 Security issues associated with email auto-responders are fully 454 discussed in the Security Considerations section of [RFC3834]. This 455 document is not believed to introduce any additional security 456 considerations in this general area. 458 The "ereject" extension does not raise any other security 459 considerations that are not already present in the base [SIEVE] 460 specification, and these issues are discussed in [SIEVE]. 462 5. IANA Considerations 464 The following section provides the IANA registrations for the Sieve 465 extensions specified in this document: 467 5.1. reject extension registration 469 IANA is requested to update the registration for the Sieve "reject" 470 extension as detailed below: 472 Capability name: reject 473 Description: adds the "reject" action for refusing delivery 474 of a message. The exact reason for refusal is 475 conveyed back to the client. 476 RFC number: this RFC 477 Contact address: the Sieve discussion list 479 5.2. ereject extension registration 481 IANA is requested to replace the preliminary registration of the 482 Sieve refuse extension with the following registration: 484 Capability name: ereject 485 Description: adds the 'ereject' action for refusing delivery 486 of a message. The refusal should happen as early 487 as possible (e.g. at the protocol level) and might 488 not preserve the exact reason for refusal if it 489 contains non-US-ASCII text. 490 RFC number: this RFC 491 Contact address: the Sieve discussion list 493 6. References 495 6.1. Normative References 497 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 498 for Delivery Status Notifications", RFC 3464, 499 January 2003. 501 [ENHANCED-CODES] 502 Freed, N., "SMTP Service Extension for Returning Enhanced 503 Error Codes", RFC 2034, October 1996. 505 [KEYWORDS] 506 Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 510 October 1996. 512 [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition 513 Notification", RFC 3798, May 2004. 515 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 516 Reporting of Mail System Administrative Messages", 517 RFC 3462, January 2003. 519 [SIEVEBIS] 520 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 521 Language", RFC 5228, January 2008. 523 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 524 April 2001. 526 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 527 10646", STD 63, RFC 3629, November 2003. 529 [VACATION] 530 Showalter, T. and N. Freed, "Sieve Email Filtering: 532 Vacation Extension", RFC 5230, January 2008. 534 6.2. Informative References 536 [EMAIL-ARCH] 537 Crocker, D., "Internet Mail Architecture", 538 draft-crocker-email-arch-11 (work in progress), 539 October 2008. 541 [Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-Delivery 542 Message DDoS Attacks", April 2004, . 546 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 547 Electronic Mail", RFC 3834, August 2004. 549 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", 550 RFC 3028, January 2001. 552 [SPAMTEST] 553 Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 554 Extensions", RFC 5235, January 2008. 556 [UTF8-RESP] 557 Melnikov, A., "SMTP Language Extension", 558 draft-melnikov-smtp-lang-07 (work in progress), June 2007. 560 Appendix A. Acknowledgements 562 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 563 Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens 564 for comments and corrections. 566 The authors gratefully acknowledge the extensive work of Tim 567 Showalter as the author of the RFC 3028, which originally defined the 568 "reject" action. 570 Authors' Addresses 572 Aaron Stone (editor) 573 Serendipity 574 260 El Verano Ave 575 Palo Alto, CA 94306 576 USA 578 Email: aaron@serendipity.palo-alto.ca.us 580 Matthew Elvey 581 The Elvey Partnership, LLC 582 1819 Polk Street, Suite 133 583 San Francisco, CA 94109 584 USA 586 Email: sieve3@matthew.elvey.com 588 Alexey Melnikov 589 Isode Limited 590 5 Castle Business Village 591 36 Station Road 592 Hampton, Middlesex TW12 2BX 593 UK 595 Email: Alexey.Melnikov@isode.com 597 Full Copyright Statement 599 Copyright (C) The IETF Trust (2008). 601 This document is subject to the rights, licenses and restrictions 602 contained in BCP 78, and except as set forth therein, the authors 603 retain all their rights. 605 This document and the information contained herein are provided on an 606 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 607 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 608 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 609 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 610 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 611 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 613 Intellectual Property 615 The IETF takes no position regarding the validity or scope of any 616 Intellectual Property Rights or other rights that might be claimed to 617 pertain to the implementation or use of the technology described in 618 this document or the extent to which any license under such rights 619 might or might not be available; nor does it represent that it has 620 made any independent effort to identify any such rights. Information 621 on the procedures with respect to rights in RFC documents can be 622 found in BCP 78 and BCP 79. 624 Copies of IPR disclosures made to the IETF Secretariat and any 625 assurances of licenses to be made available, or the result of an 626 attempt made to obtain a general license or permission for the use of 627 such proprietary rights by implementers or users of this 628 specification can be obtained from the IETF on-line IPR repository at 629 http://www.ietf.org/ipr. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights that may cover technology that may be required to implement 634 this standard. Please address the information to the IETF at 635 ietf-ipr@ietf.org.