idnits 2.17.1 draft-ietf-sieve-refuse-reject-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 597. 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 updates RFC3028, but the abstract doesn't seem to directly say this. It does mention RFC3028 though, so this could be OK. 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 RFC3028, updated by this document, for RFC5378 checks: 1997-04-18) -- 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 (May 26, 2008) is 5807 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 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 Hydric Acid 4 Updates: 3028 (if approved) 5 Intended status: Standards Track May 26, 2008 6 Expires: November 27, 2008 8 Sieve Email Filtering: Reject and Extended Reject Extensions 9 draft-ietf-sieve-refuse-reject-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This memo updates the definition of the Sieve mail filtering language 43 "reject" extension, originally defined in RFC 3028. 45 A "Joe-job" is a spam run forged to appear as though it came from an 46 innocent party, who is then generally flooded by automated bounces, 47 Message Disposition Notifications (MDNs), and personal messages with 48 complaints. The original Sieve "reject" action defined in RFC 3028 49 required use of MDNs for rejecting messages, thus contributing to the 50 flood of Joe-job spam to victims of Joe-jobs. 52 This memo updates the definition of the "reject" action to allow 53 messages to be refused during the SMTP transaction, and defines the 54 "ereject" action to require messages to be refused during the SMTP 55 transaction, if possible. 57 The "ereject" action is intended to replace the "reject" action 58 wherever possible. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 64 2. Sieve 'reject' and 'ereject' Extentions . . . . . . . . . . . 3 65 2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1.1. Rejecting a message at the SMTP/LMTP protocol level . 4 67 2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 5 68 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2.1. Rejecting a message by sending an MDN . . . . . . . . 6 70 2.3. Silent upgrade from reject to ereject . . . . . . . . . . 7 71 2.4. Compatibility with other actions . . . . . . . . . . . . . 7 72 2.5. Details of protocol level refusal . . . . . . . . . . . . 8 73 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 10 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 5.1. reject extension registration . . . . . . . . . . . . . . 10 77 5.2. ereject extension registration . . . . . . . . . . . . . . 10 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 Intellectual Property and Copyright Statements . . . . . . . . . . 14 85 1. Introduction 87 The Sieve mail filtering language [SIEVEBIS], as originally defined 88 in RFC 3028 [SIEVE], specified that the "reject" action shall discard 89 a message and send a Message Disposition Notification [MDN] to the 90 envelope sender along with an explanatory message. RFC 5228 91 [SIEVEBIS] does not define any reject action, hence the purpose of 92 this document. 94 This document updates the definition of the "reject" action to permit 95 refusal of the message during the SMTP transaction, if possible, and 96 defines a new "ereject" action to require refusal of the message 97 during the SMTP transaction, if possible. 99 Implementations are further encouraged to use spam-detection systems 100 to determine the level of risk associated with sending an MDN, and 101 this document allows implementations to silently drop the MDN if the 102 rejected message is deemed to be likely spam. 104 Further discussion highlighting the risks of generating MDNs and the 105 benefits of protocol-level refusal can be found in [Joe-DoS]. 107 1.1. Conventions Used in This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [KEYWORDS]. 113 Conventions for notations are as in RFC 3028 [SIEVE] Section 1.1. 115 This document does not attempt to define spam or how it should be 116 identified, nor to define an email virus or how it should be 117 detected. Implementors are advised to follow best practices and keep 118 abreast of current research in these fields. 120 2. Sieve 'reject' and 'ereject' Extentions 122 2.1. Action ereject 124 Usage: ereject 126 Sieve implementations that implement the "ereject" action must use 127 the "ereject" capability string. 129 The "ereject" action cancels the implicit keep and refuses delivery 130 of a message. The reason string is a UTF-8 [UTF-8] string specifying 131 the reason for refusal. How a message is refused depends on the 132 capabilities of the mail component (MDA or MTA) executing the Sieve 133 script. The Sieve interpreter MUST carry out one of the following 134 actions (listed in order from most to least preferred), SHOULD carry 135 out the most preferable action, and SHOULD fall back to lesser 136 actions if a preferred action fails. 138 1. Refuse message delivery by sending a 5XX response code over SMTP 139 [SMTP] or LMTP [LMTP]. See Section 2.1.1 for more details. 141 2. Discard the message if a return-path verification clearly 142 indicates that the message has a forged return-path. 144 3. Send a non-delivery report to the envelope sender ([REPORT] 145 [DSN]). See Section 2.1.2 for more details. 147 The ereject action MUST NOT be available in environments that do not 148 support protocol level rejection, e.g. an MUA, and MUST be available 149 in all other environments that support the reject action. 151 Example: 152 require ["ereject"]; 154 if address "from" "someone@example.com" { 155 ereject "I no longer accept mail from this address"; 156 } 158 2.1.1. Rejecting a message at the SMTP/LMTP protocol level 160 Sieve implementations that are able to reject messages at the SMTP/ 161 LMTP level MUST do so and SHOULD use the 550 response code. Note 162 that if a message is arriving over SMTP and has multiple recipients, 163 some of whom have accepted the message, Section 2.1.2 defines how to 164 reject such a message. 166 Note that SMTP [SMTP] does not allow non-ASCII characters in the SMTP 167 response text. If non-ASCII characters appear in the "reason" 168 string, they can be sent at the protocol level if and only if the 169 client and the server use an SMTP extension that allows for 170 transmission of non-ASCII reply text. (One example of such an SMTP 171 extension is described in [UTF8-RESP].) In the absence of such an 172 SMTP extension, the Sieve engine MUST replace any reason string being 173 sent at the protocol level and containing non-ASCII characters with 174 an implementation-defined ASCII-only string. 176 Users who don't like this behavior should consider using the "reject" 177 action described in Section 2.2, if available. 179 See Section 2.5 for the detailed instructions about performing 180 protocol level rejection. 182 2.1.2. Rejecting a message by sending a DSN 184 An implementation may receive a message via SMTP that has more than 185 one RCPT TO that has been accepted by the server, and at least one 186 but not all of them are refusing delivery (whether the refusal is 187 caused by a Sieve "ereject" action or for some other reason). In 188 this case, the server MUST accept the message and generate DSNs for 189 all recipients that are refusing it. Note that this exception does 190 not apply to LMTP, as LMTP is able to reject messages on a per- 191 recipient basis. (However, the LMTP client may then have no choice 192 but to generate a DSN to report the error, which may result in 193 blowback.) 195 Note that according to [DSN], Delivery Status Notifications MUST NOT 196 be generated if the MAIL FROM (or Return-Path) is empty. 198 The DSN message MUST follow the requirements of [DSN] and [REPORT] 199 The action-value field defined in [DSN], Section 2.3.3, MUST contain 200 the value "failed". The human-readable portion of the non-delivery 201 report MUST contain the reason string from the "ereject" action and 202 SHOULD contain additional text alerting the apparent original sender 203 that the message was refused by an email filter. This part of the 204 report might appear as follows: 206 ------------------------------------------------------------ 207 Your message was refused by the recipient's mail filtering program. 208 The reason given was as follows: 210 I am not taking mail from you, and I don't want your birdseed, 211 either! 212 ------------------------------------------------------------ 214 2.2. Action reject 216 This section updates the definition of the reject action in Section 217 4.1 of RFC 3028 and is an optional extension to [SIEVEBIS]. 219 Usage: reject 221 Sieve implementations that implement the "reject" action must use the 222 "reject" capability string. 224 The "reject" action cancels the implicit keep and refuses delivery of 225 a message. The reason string is a UTF-8 [UTF-8] string specifying 226 the reason for refusal. Unlike the "ereject" action described above, 227 this action would always favor preserving the exact text of the 228 refusal reason. Typically the "reject" action refuses delivery of a 229 message by sending back an MDN to the alleged sender (see 230 Section 2.2.1). However implementations MAY refuse delivery over 231 protocol (as detailed in Section 2.5), if and only if all of the 232 following conditions are true: 234 1. The reason string consists of only US-ASCII characters 235 or 236 The reason string contains non-US-ASCII and both client and 237 server support and negotiate use of an SMTP/LMTP extension for 238 sending UTF-8 responses. 240 2. LMTP protocol is used 241 or 242 SMTP protocol is used and the message has a single recipient 243 or 244 SMTP protocol is used, the message has multiple recipients, and 245 all of them refused message delivery (whether using Sieve or 246 not). 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 2.2.1. Rejecting a message by sending an MDN 263 The reject action resends the received message to the envelope sender 264 specified by the MAIL FROM (or Return-Path) address, wrapping it in a 265 "reject" form, explaining that it was rejected by the recipient. 267 Note that according to [MDN], Message Disposition Notifications MUST 268 NOT be generated if the MAIL FROM (or Return-Path) is empty. 270 A reject message MUST take the form of a failure MDN as specified by 271 [MDN]. The human-readable portion of the message, the first 272 component of the MDN, contains the human readable message describing 273 the error, and it SHOULD contain additional text alerting the 274 apparent original sender that mail was refused by an email filter. 276 The MDN disposition-field as defined in the MDN specification MUST be 277 "deleted" and MUST have the "MDN-sent-automatically" and "automatic- 278 action" modes set (see Section 3.2.6 of [MDN]). 280 In the following script, a message is rejected and returned to the 281 alleged sender. 283 Example: 284 require ["reject"]; 286 if header :contains "from" "coyote@desert.example.org" { 287 reject text: 288 I am not taking mail from you, and I don't 289 want your birdseed, either!" 290 . 291 ; 292 } 294 For this script, the first part of the MDN might appear as follows: 296 ------------------------------------------------------------ 297 The message was refused by the recipient's mail filtering program. 298 The reason given was as follows: 300 I am not taking mail from you, and I don't want your birdseed, 301 either! 302 ------------------------------------------------------------ 304 2.3. Silent upgrade from reject to ereject 306 Implementations MUST NOT silently upgrade reject actions to ereject 307 actions, however user interfaces may change the specific action 308 underlying a descriptive representation, thereby effecting a silent 309 upgrade of sorts. 311 Script generators SHOULD ensure that a rejection action being 312 executed as a result of an anti-spam/anti-virus positive test be done 313 using the ereject action, as it is more suitable for such rejections. 315 Script generators MAY automatically upgrade scripts that previously 316 used the reject action for anti-spam/anti-virus related rejections. 317 Note that such generators MUST make sure that the target environment 318 can support the ereject action. 320 2.4. Compatibility with other actions 322 This section applies equally to "reject" and "ereject" actions. All 323 references to the "reject" action in this section can be replaced 324 with the "ereject" action. 326 A "reject" action cancels the implicit keep. 328 Implementations MUST prohibit the execution of more than one reject 329 in a Sieve script. 331 "Reject" MUST be incompatible with the "vacation" [VACATION] action. 332 It is NOT RECOMMENDED that implementations permit the use of "reject" 333 with actions that cause mail delivery, such as "keep", "fileinto", 334 "redirect". 336 Making "reject" compatible with actions that cause mail delivery 337 violates the RFC 2821 [SMTP] principle that a message is either 338 delivered or bounced back to the sender. So bouncing a message back 339 (rejecting) and delivering it will make the sender believe that the 340 message was not delivered. 342 However, there are existing laws requiring certain organizations to 343 archive all received messages, even the rejected ones. Also, it can 344 be quite useful to save copies of rejected messages for later 345 analysis. 347 Any action that would modify the message body will not have an effect 348 on the body of any message refused by "reject" using an SMTP response 349 code and MUST NOT have any effect on the content of generated DSN/ 350 MDNs. 352 2.5. Details of protocol level refusal 354 If the "reason" string consists of multiple CRLF separated lines, 355 then the reason text MUST be returned as a multiline SMTP/LMTP 356 response, per [SMTP], Section 4.2.1. Any line MUST NOT exceed the 357 SMTP limit on the maximal line length. To make the reason string 358 conform to any such limits the server MAY insert CRLFs and turn the 359 response into a multiline response. 361 In the following script (which assumes support for the spamtest 362 [SPAMTEST] and fileinto extensions), messages that test highly 363 positive for spam are refused. 365 Example: 366 require ["ereject", "spamtest", "fileinto", 367 "comparator-i;ascii-numeric"]; 369 if spamtest :value "ge" 370 :comparator "i;ascii-numeric" "6" { 371 ereject text: 372 AntiSpam engine thinks your message is spam. 373 It is therefore being refused. 374 Please call 1-900-PAY-US if you want to reach us. 375 . 376 ; 377 } elsif spamtest :value "ge" 378 :comparator "i;ascii-numeric" "4" { 379 fileinto "Suspect"; 380 } 382 The following excerpt from an SMTP session shows it in action. 384 ... 385 C: DATA 386 S: 354 Send message, ending in CRLF.CRLF. 387 ... 388 C: . 389 S: 550-AntiSpam engine thinks your message is spam. 390 S: 550-It is therefore being refused. 391 S: 550 Please call 1-900-PAY-US if you want to reach us. 393 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES] it MUST 394 prepend an appropriate Enhanced Error Code to the "reason" text. 395 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. 396 With an Enhanced Error Code, the response to DATA command in the SMTP 397 example below will look like: 399 S: 550-5.7.1 AntiSpam engine thinks your message is spam. 400 S: 550-5.7.1 It is therefore being refused. 401 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 403 if the server selected "5.7.1" as appropriate. 405 If a Sieve implementation that supports "ereject" does not wish to 406 immediately disclose the reason for rejection (for example, that it 407 detected spam), it may delay immediately sending of the 550 error 408 code by sending a 4XX error code on the first attempt to receive the 409 message. 411 3. Changes from RFC 3028 413 Clarified that the "reject" action cancels the implicit keep. 414 Extended the list of allowable actions on "reject" to include 415 protocol level message rejection. 417 Added the "ereject" action that is similar to "reject", but will 418 always favor protocol level message rejection. 420 4. Security Considerations 422 The Introduction to this document discusses why rejecting messages 423 before delivery is better than accepting and bouncing them. 425 Security issues associated with email auto-responders are fully 426 discussed in the Security Considerations section of [RFC3834]. This 427 document is not believed to introduce any additional security 428 considerations in this general area. 430 The "ereject" extension does not raise any other security 431 considerations that are not already present in the base [SIEVE] 432 specification, and these issues are discussed in [SIEVE]. 434 5. IANA Considerations 436 The following section provides the IANA registrations for the Sieve 437 extensions specified in this document: 439 5.1. reject extension registration 441 IANA is requested to update the registration for the Sieve "reject" 442 extension as detailed below: 444 Capability name: reject 445 Description: adds the "reject" action for refusing delivery 446 of a message. The exact reason for refusal is 447 conveyed back to the client. 448 RFC number: this RFC 449 Contact address: the Sieve discussion list 451 5.2. ereject extension registration 453 IANA is requested to replace the preliminary registration of the 454 Sieve refuse extension with the following registration: 456 Capability name: ereject 457 Description: adds the 'ereject' action for refusing delivery 458 of a message. The refusal should happen as early 459 as possible (e.g. at the protocol level) and might 460 not preserve the exact reason for refusal if it 461 contains non-US-ASCII text. 462 RFC number: this RFC 463 Contact address: the Sieve discussion list 465 6. References 467 6.1. Normative References 469 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 470 for Delivery Status Notifications", RFC 3464, 471 January 2003. 473 [ENHANCED-CODES] 474 Freed, N., "SMTP Service Extension for Returning Enhanced 475 Error Codes", RFC 2034, October 1996. 477 [KEYWORDS] 478 Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 482 October 1996. 484 [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition 485 Notification", RFC 3798, May 2004. 487 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 488 Reporting of Mail System Administrative Messages", 489 RFC 3462, January 2003. 491 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", 492 RFC 3028, January 2001. 494 [SIEVEBIS] 495 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 496 Language", RFC 5228, January 2008. 498 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 499 April 2001. 501 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 502 10646", STD 63, RFC 3629, November 2003. 504 [VACATION] 505 Showalter, T. and N. Freed, "Sieve Email Filtering: 506 Vacation Extension", RFC 5230, January 2008. 508 6.2. Informative References 510 [Joe-DoS] "Mail Non-Delivery Message DDoS Attacks", 4 2004. 512 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 513 Electronic Mail", RFC 3834, August 2004. 515 [SPAMTEST] 516 Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 517 Extensions", RFC 5235, January 2008. 519 [UTF8-RESP] 520 Melnikov, A., "SMTP Language Extension", 521 draft-melnikov-smtp-lang-07 (work in progress), June 2007. 523 Appendix A. Acknowledgements 525 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 526 Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens 527 for comments and corrections. 529 The authors gratefully acknowledge the extensive work of Tim 530 Showalter as the author of the RFC 3028, which originally defined the 531 "reject" action. 533 Authors' Addresses 535 Aaron Stone (editor) 536 Hydric Acid 537 260 El Verano Ave 538 Palo Alto, CA 94306 539 USA 541 Email: aaron@serendipity.palo-alto.ca.us 542 Matthew Elvey 543 The Elvey Partnership, LLC 544 1819 Polk Street, Suite 133 545 San Francisco, CA 94109 546 USA 548 Email: sieve3@matthew.elvey.com 550 Alexey Melnikov 551 Isode Limited 552 5 Castle Business Village 553 36 Station Road 554 Hampton, Middlesex TW12 2BX 555 UK 557 Email: Alexey.Melnikov@isode.com 559 Full Copyright Statement 561 Copyright (C) The IETF Trust (2008). 563 This document is subject to the rights, licenses and restrictions 564 contained in BCP 78, and except as set forth therein, the authors 565 retain all their rights. 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 570 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 571 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 572 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Intellectual Property 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at 597 ietf-ipr@ietf.org. 599 Acknowledgment 601 Funding for the RFC Editor function is provided by the IETF 602 Administrative Support Activity (IASA).