idnits 2.17.1 draft-ietf-sieve-refuse-reject-06.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 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. 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 (December 14, 2007) is 5978 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 Aaron Stone, Ed. 3 Internet-Draft Hydric Acid 4 Updates: 3028 (if approved) 5 Intended status: Standards Track December 14, 2007 6 Expires: June 5, 2008 8 Sieve Email Filtering: Extensions for Rejecting Messages 9 draft-ietf-sieve-refuse-reject-06 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 June 5, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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. 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 . . . . . . . . . 4 68 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2.1. Rejecting a message by sending an MDN . . . . . . . . 6 70 2.3. Compatibility with other actions . . . . . . . . . . . . . 7 71 2.4. Details of protocol level refusal . . . . . . . . . . . . 8 72 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. reject extension registration . . . . . . . . . . . . . . 10 76 5.2. ereject extension registration . . . . . . . . . . . . . . 10 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 Intellectual Property and Copyright Statements . . . . . . . . . . 13 84 1. Introduction 86 The Sieve mail filtering language [SIEVEBIS], as originally defined 87 in RFC 3028 [SIEVE], specified that the "reject" action shall discard 88 a message and send a Message Disposition Notification [MDN] to the 89 envelope sender along with an explanatory message. 91 This document updates the definition of the "reject" action to permit 92 refusal of the message during the SMTP transaction, if possible, and 93 defines a new "ereject" action to require refusal of the message 94 during the SMTP transaction. 96 Implementations are further encouraged to use spam-detection systems 97 to determine the level of risk associated with sending an MDN, and 98 this document allows implementations to silently drop the MDN if the 99 rejected message is deemed to be likely spam. 101 Further discussion highlighting the risks of generating MDNs and the 102 benefits of protocol-level refusal can be found in [Joe-DoS]. 104 1.1. Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [KEYWORDS]. 110 Conventions for notations are as in RFC 3028 [SIEVE] Section 1.1. 112 This document does not attempt to define spam or how it should be 113 identified, nor to define an email virus or how it should be 114 detected. Implementations are advised to follow best practices and 115 keep abreast of current research in these fields. 117 2. Sieve 'reject' and 'ereject' Extentions 119 2.1. Action ereject 121 Usage: ereject 123 Sieve implementations that implement the "ereject" action must use 124 the "ereject" capability string. 126 The "ereject" action cancels the implicit keep and refuses delivery 127 of a message. The reason string is a UTF-8 [UTF-8] string specifying 128 the reason for refusal. How a message is refused depends on the 129 capabilities of the mail component (MDA or MTA) executing the Sieve 130 script. The Sieve interpreter MUST carry out one of the following 131 actions (listed in order from most to least preferred), SHOULD carry 132 out the most preferable action, and SHOULD fall back to lesser 133 actions if a preferred action fails. 135 1. Refuse message delivery by sending a 5XX response code over SMTP 136 [SMTP] or LMTP [LMTP]. See Section 2.1.1 for more details. 138 2. Discard the message if a return-path verification clearly 139 indicates that the message has a forged return-path. 141 3. Send a non-delivery report to the envelope sender ([REPORT] 142 [DSN]). See Section 2.1.2 for more details. 144 The ereject action MUST NOT be available in environments that do not 145 support protocol level rejection, e.g. an MUA. 147 2.1.1. Rejecting a message at the SMTP/LMTP protocol level 149 Sieve implementations that are able to reject messages at the SMTP/ 150 LMTP level MUST do so and SHOULD use the 550 response code. Note 151 that if a message is arriving over SMTP and has multiple recipients, 152 some of whom have accepted the message, Section 2.1.2 defines how to 153 reject such a message. 155 Note that SMTP [SMTP] does not allow non-ASCII characters in the SMTP 156 response text. If non-ASCII characters appear in the "reason" 157 string, they can be sent at the protocol level if and only if the 158 client and the server use an SMTP extension that allows for 159 transmission of non-ASCII reply text. (One example of such an SMTP 160 extension is described in [UTF8-RESP].) In the absence of such an 161 SMTP extension, the Sieve engine MUST replace any reason string being 162 sent at the protocol level and containing non-ASCII characters with 163 an implementation-defined ASCII-only string. 165 Users who don't like this behavior should consider using the "reject" 166 action described in Section 2.2, if available. 168 See Section 2.4 for the detailed instructions about performing 169 protocol level rejection. 171 2.1.2. Rejecting a message by sending a DSN 173 An implementation may receive a message via SMTP that has more than 174 one RCPT TO that has been accepted by the server, and at least one 175 but not all of them are refusing delivery (whether the refusal is 176 caused by a Sieve "ereject" action or for some other reason). In 177 this case, the server MUST accept the message and generate DSNs for 178 all recipients that are refusing it. Note that this exception does 179 not apply to LMTP, as LMTP is able to reject messages on a per- 180 recipient basis. 182 Note that according to [DSN], Delivery Status Notifications MUST NOT 183 be generated if the MAIL FROM (or Return-Path) is empty. 185 The DSN message MUST follow the requirements of [DSN] and [REPORT] 186 The action-value field defined in [DSN], Section 2.3.3, MUST contain 187 the value "failed". The human-readable portion of the non-delivery 188 report MUST contain the reason string from the "ereject" action and 189 SHOULD contain additional text alerting the apparent original sender 190 that the message was refused by an email filter. This part of the 191 report might appear as follows: 193 ------------------------------------------------------------ 194 Your message was refused by the recipient's mail filtering program. 195 The reason given was as follows: 197 I am not taking mail from you, and I don't want your birdseed, 198 either! 199 ------------------------------------------------------------ 201 2.2. Action reject 203 This section updates the definition of the reject action in Section 204 4.1 of RFC 3028 and is an optional extension to [SIEVEBIS]. 206 Usage: reject 208 Sieve implementations that implement the "reject" action must use the 209 "reject" capability string. 211 The "reject" action cancels the implicit keep and refuses delivery of 212 a message. The reason string is a UTF-8 [UTF-8] string specifying 213 the reason for refusal. Unlike the "ereject" action described above, 214 this action would always favor preserving the exact text of the 215 refusal reason. Typically the "reject" action refuses delivery of a 216 message by sending back an MDN to the alleged sender (see 217 Section 2.2.1). However implementations MAY refuse delivery over 218 protocol (as detailed in Section 2.4), if and only if all of the 219 following conditions are true: 221 1. The reason string consists of only US-ASCII characters 222 or 223 The reason string contains non-US-ASCII and both client and 224 server support and negotiate use of an SMTP/LMTP extension for 225 sending UTF-8 responses. 227 2. LMTP protocol is used 228 or 229 SMTP protocol is used and the message contains a single recipient 230 or 231 SMTP protocol is used, the message contains multiple recipients 232 and all of them refused message delivery (whether using Sieve or 233 not). 235 Script generators SHOULD ensure that a rejection action being 236 executed as a result of an anti-spam/anti-virus positive test be done 237 using the ereject action, as it is more suitable for such rejections. 239 Script generators MAY automatically upgrade scripts that previously 240 used the reject action for anti-spam/anti-virus related rejections. 241 Note that such generators MUST make sure that the target environment 242 can support the ereject action. 244 Example: 245 require ["reject"]; 247 if size :over 100K { 248 reject text: 249 Your message is to big. If you want to send me a big attachment, 250 put it on a public web site and send me an URL. 251 . 252 ; 253 } 255 (Pretend that the reason string above contains some non-ASCII text) 257 2.2.1. Rejecting a message by sending an MDN 259 The reject action resends the received message to the envelope sender 260 specified by the MAIL FROM (or Return-Path) address, wrapping it in a 261 "reject" form, explaining that it was rejected by the recipient. 263 Note that according to [MDN], Message Disposition Notifications MUST 264 NOT be generated if the MAIL FROM (or Return-Path) is empty. 266 A reject message MUST take the form of a failure MDN as specified by 267 [MDN]. The human-readable portion of the message, the first 268 component of the MDN, contains the human readable message describing 269 the error, and it SHOULD contain additional text alerting the 270 apparent original sender that mail was refused by an email filter. 272 The MDN disposition-field as defined in the MDN specification MUST be 273 "deleted" and MUST have the "MDN-sent-automatically" and "automatic- 274 action" modes set (see Section 3.2.6 of [MDN]). 276 In the following script, a message is rejected and returned to the 277 alleged sender. 279 Example: 280 require ["reject"]; 282 if header :contains "from" "coyote@desert.example.org" { 283 reject text: 284 I am not taking mail from you, and I don't 285 want your birdseed, either!" 286 . 287 ; 288 } 290 For this script, the first part of the MDN might appear as follows: 292 ------------------------------------------------------------ 293 The message was refused by the recipient's mail filtering program. 294 The reason given was as follows: 296 I am not taking mail from you, and I don't want your birdseed, 297 either! 298 ------------------------------------------------------------ 300 2.3. Compatibility with other actions 302 This section applies equally to "reject" and "ereject" actions. All 303 references to the "reject" action in this section can be replaced 304 with the "ereject" action. 306 A "reject" action cancels the implicit keep. 308 Implementations MUST prohibit the execution of more than one reject 309 in a Sieve script. 311 "Reject" MUST be incompatible with the "vacation" [VACATION] action. 312 It is NOT RECOMMENDED that implementations permit the use of "reject" 313 with actions that cause mail delivery, such as "keep", "fileinto", 314 "redirect". 316 Making "reject" compatible with actions that cause mail delivery 317 violates the RFC 2821 [SMTP] principle that a message is either 318 delivered or bounced back to the sender. So bouncing a message back 319 (rejecting) and delivering it will make the sender believe that the 320 message was not delivered. 322 However, there are existing laws requiring certain organizations to 323 archive all received messages, even the rejected ones. Also, it can 324 be quite useful to save copies of rejected messages for later 325 analysis. 327 Any action that would modify the message body will not have an effect 328 on the body of any message refused by "reject" using an SMTP response 329 code and MUST NOT have any effect on the content of generated DSN/ 330 MDNs. 332 2.4. Details of protocol level refusal 334 If the "reason" string consists of multiple CRLF separated lines, 335 then the reason text MUST be returned as a multiline SMTP/LMTP 336 response, per [SMTP], Section 4.2.1. Any line MUST NOT exceed the 337 SMTP limit on the maximal line length. To make the reason string 338 conform to any such limits the server MAY insert CRLFs and turn the 339 response into a multiline response. 341 In the following script (which assumes support for the spamtest 342 [SPAMTEST] and fileinto extensions), messages that test highly 343 positive for spam are refused. 345 Example: 346 require ["ereject", "spamtest", "fileinto", 347 "comparator-i;ascii-numeric"]; 349 if spamtest :value "ge" 350 :comparator "i;ascii-numeric" "6" { 351 ereject text: 352 AntiSpam engine thinks your message is spam. 353 It is therefore being refused. 354 Please call 1-900-PAY-US if you want to reach us. 355 . 356 ; 357 } elsif spamtest :value "ge" 358 :comparator "i;ascii-numeric" "4" { 359 fileinto "Suspect"; 360 } 362 The following excerpt from an SMTP session shows it in action. 364 ... 365 C: DATA 366 S: 354 Send message, ending in CRLF.CRLF. 367 ... 368 C: . 369 S: 550-AntiSpam engine thinks your message is spam. 370 S: 550-It is therefore being refused. 371 S: 550 Please call 1-900-PAY-US if you want to reach us. 373 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES] it MUST 374 prepend an appropriate Enhanced Error Code to the "reason" text. 375 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. 376 With an Enhanced Error Code, the response to DATA command in the SMTP 377 example below will look like: 379 S: 550-5.7.1 AntiSpam engine thinks your message is spam. 380 S: 550-5.7.1 It is therefore being refused. 381 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 383 if the server selected "5.7.1" as appropriate. 385 If a Sieve implementation that supports "ereject" does not wish to 386 immediately disclose the reason for rejection (for example, that it 387 detected spam), it may delay immediately sending of the 550 error 388 code by sending a 4XX error code on the first attempt to receive the 389 message. 391 3. Changes from RFC 3028 393 Clarified that the "reject" action cancels the implicit keep. 394 Extended the list of allowable actions on "reject" to include 395 protocol level message rejection. 397 Added the "ereject" action that is similar to "reject", but will 398 always favor protocol level message rejection. 400 4. Security Considerations 402 The Introduction to this document discusses why rejecting messages 403 before delivery is better than accepting and bouncing them. 405 Security issues associated with email auto-responders are fully 406 discussed in the Security Considerations section of [RFC3834]. This 407 document is not believed to introduce any additional security 408 considerations in this general area. 410 The "ereject" extension does not raise any other security 411 considerations that are not already present in the base [SIEVE] 412 specification, and these issues are discussed in [SIEVE]. 414 5. IANA Considerations 416 The following section provides the IANA registrations for the Sieve 417 extensions specified in this document: 419 5.1. reject extension registration 421 IANA is requested to update the registration for the Sieve "reject" 422 extension as detailed below: 424 Capability name: reject 425 Description: adds the "reject" action for refusing delivery 426 of a message. The exact reason for refusal is 427 conveyed back to the client. 428 RFC number: this RFC 429 Contact address: the Sieve discussion list 431 5.2. ereject extension registration 433 IANA is requested to replace the preliminary registration of the 434 Sieve refuse extension with the following registration: 436 Capability name: ereject 437 Description: adds the 'ereject' action for refusing delivery 438 of a message. The refusal should happen as early 439 as possible (e.g. at the protocol level) and might 440 not preserve the exact reason for refusal if it 441 contains non-US-ASCII text. 442 RFC number: this RFC 443 Contact address: the Sieve discussion list 445 6. References 447 6.1. Normative References 449 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 450 for Delivery Status Notifications", RFC 3464, 451 January 2003. 453 [ENHANCED-CODES] 454 Freed, N., "SMTP Service Extension for Returning Enhanced 455 Error Codes", RFC 2034, October 1996. 457 [KEYWORDS] 458 Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 [LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 462 October 1996. 464 [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition 465 Notification", RFC 3798, May 2004. 467 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 468 Reporting of Mail System Administrative Messages", 469 RFC 3462, January 2003. 471 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", 472 RFC 3028, January 2001. 474 [SIEVEBIS] 475 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 476 Language", draft-ietf-sieve-3028bis-13 (work in progress), 477 October 2007. 479 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 480 April 2001. 482 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 483 10646", STD 63, RFC 3629, November 2003. 485 [VACATION] 486 Showalter, T. and N. Freed, "Sieve Email Filtering: 487 Vacation Extension", draft-ietf-sieve-vacation-07 (work in 488 progress), March 2007. 490 6.2. Informative References 492 [Joe-DoS] "Mail Non-Delivery Message DDoS Attacks", 4 2004. 494 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 495 Electronic Mail", RFC 3834, August 2004. 497 [SPAMTEST] 498 Daboo, C., "SIEVE Email Filtering: Spamtest and Virustest 499 Extensions", draft-ietf-sieve-spamtestbis-05 (work in 500 progress), July 2006. 502 [UTF8-RESP] 503 Melnikov, A., "SMTP Language Extension", 504 draft-melnikov-smtp-lang-07 (work in progress), June 2007. 506 Appendix A. Acknowledgements 508 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 509 Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens 510 for comments and corrections. 512 The authors gratefully acknowledge the extensive work of Tim 513 Showalter as the author of the RFC 3028, which originally defined the 514 "reject" action. 516 Authors' Addresses 518 Aaron Stone (editor) 519 Hydric Acid 520 260 El Verano Ave 521 Palo Alto, CA 94306 522 USA 524 Email: aaron@serendipity.palo-alto.ca.us 526 Matthew Elvey 527 The Elvey Partnership, LLC 528 1819 Polk Street, Suite 133 529 San Francisco, CA 94109 530 USA 532 Email: sieve3@matthew.elvey.com 534 Alexey Melnikov 535 Isode Limited 536 5 Castle Business Village 537 36 Station Road 538 Hampton, Middlesex TW12 2BX 539 UK 541 Email: Alexey.Melnikov@isode.com 543 Full Copyright Statement 545 Copyright (C) The IETF Trust (2007). 547 This document is subject to the rights, licenses and restrictions 548 contained in BCP 78, and except as set forth therein, the authors 549 retain all their rights. 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Intellectual Property 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Acknowledgment 585 Funding for the RFC Editor function is provided by the IETF 586 Administrative Support Activity (IASA).