idnits 2.17.1 draft-ietf-marid-csv-csa-02.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 20, 2005) is 7005 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0791' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'RFC0822' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC2671' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC2822' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC3207' is defined on line 496, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3008 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 marid D. Otis 2 Internet-Draft Mail Abuse Prevention System 3 Expires: August 21, 2005 D. Crocker 4 Brandenburg InternetWorking 5 J. Leslie 6 JLC.net 7 February 20, 2005 9 Client SMTP Authorization (CSA) 10 draft-ietf-marid-csv-csa-02 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 21, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 Internet operation has typically required no public mechanism for 46 announcing restriction or permission of particular hosts to operate 47 clients or servers for particular services on behalf of particular 48 domains. What is missing is an open, interoperable means by which a 49 trusted agency can announce authorization for a host to operate a 50 service. The current specification supports this capability for 51 sending SMTP clients. Specifically, is a sending SMTP client 52 permitted to act as a client MTA? Has a separate authority given it 53 permission to perform this service? Client SMTP Authorization (CSA) 54 specifies a DNS-based record that states whether an associated host 55 has permission to operate as a client MTA. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Client SMTP Authorization SRV Record . . . . . . . . . . . . 5 64 6. Publishing CSA Records . . . . . . . . . . . . . . . . . . . 8 65 7. Using CSA Records . . . . . . . . . . . . . . . . . . . . . 9 66 8. Security Considerations . . . . . . . . . . . . . . . . . . 10 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 68 10. Working Group Evaluation . . . . . . . . . . . . . . . . . . 10 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 11.1 References - Normative . . . . . . . . . . . . . . . . . . 11 71 11.2 References - Informative . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 73 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . 14 76 1. Introduction 78 Internet mail suffers from the operation of hosts acting as mail 79 transfer agents (MTA) without any meaningful cross-net 80 accountability. This makes it impossible to vet MTAs or find 81 recourse when their operations cause problems. Many of these hosts 82 have been compromised and turned into unwilling participants in large 83 networks of hostile MTAs that send spam and worms, and contribute to 84 denial of service attacks. Enhancing the Internet mail transfer 85 service to deal with these issues requires identification, 86 authentication, authorization and accreditation capabilities about 87 the sending SMTP client, as per [ID-CSV]. The current specification 88 addresses the requirement for explicit authorization. 90 It is important to distinguish this security function from 91 authentication. Authentication establishes that a name is being used 92 legitimately. Authorization establishes that the name is permitted 93 to perform a particular service. The relationship between these two 94 functions is that once a client of an exchange is authenticated, then 95 it is possible to query the permission of that client to perform 96 specific services. 98 This specification defines a mechanism to permit session-time 99 verification that a connecting SMTP client is authorized to request 100 service as a mail transfer client. The mechanism uses a DNS SRV 101 [RFC2782] record as a basis for verifying that the associated domain 102 name is authorized to act as an SMTP client. The mechanism is small, 103 simple and useful. Separate mechanisms provide the means of 104 authenticating that the domain name is associated with the connecting 105 host, and accrediting the agency that is authorizing the sending 106 host's operation as an SMTP client. 108 Use of the mechanism specified here MAY also satisfy the 109 authentication requirement. This can occur as a side-effect of the 110 DNS server response optimization that returns IP Address mappings in 111 the Additional Information portion of a response. 113 Terminology: Terminology conforms to [ID-email-arch]. 115 2. Definitions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Model 123 The SMTP [RFC2821], [RFC0821] protocol permits a client to declare 124 its affiliation, by asserting a domain name in the HELO or EHLO 125 announcement. 127 The current proposal has a receiving SMTP server take the domain name 128 associated with an SMTP client and do a forward query of the DNS. 129 The returned DNS information indicates whether that domain name is 130 authorized by the domain administrator to be an SMTP client. 132 For efficiency, the DNS response MAY also return authentication 133 information, as per [ID-CSV]. However the authentication 134 functionality is outside the scope of this specification. 136 4. Mechanism 138 The receiving SMTP server's authorization procedure is: 140 1. Obtain a domain name that is associated with the sending SMTP 141 client. 143 2. Perform a DNS lookup of: 144 QNAME = _client._smtp. 145 QCLASS = IN 146 QTYPE = SRV 147 where is associated with the host attempting to obtain 148 service as an SMTP client. 150 3. If there is no SRV RR matching this QNAME, the CSA information is 151 Unknown; otherwise at least one CSA record exists. 153 4. If there is a matching QNAME: 155 Target addresses MAY be returned in the Additional Data 156 section, or a query for address records of the target name may 157 be needed to determine the associated address(es). This MAY 158 be used to satisfy the authentication function specified in 159 Certified Server Validation [ID-CSV]. 161 Examine Priority, Weight, and Port, to assess whether the 162 client address is authorized as an SMTP client. 164 Weight equal to 2 indicates that any client with a valid claim to 165 that EHLO string is authorized to send email. When Weight equals 2, 166 the receiving SMTP server SHOULD check whether the source IP address 167 of the connection is contained in a response (whether returned as 168 Additional Info by the SRV query or returned by a separate address 169 lookup). If it is not, then the sending SMTP client is NOT 170 authorized when failing the address check. 172 When Weight equals 1, the sending SMTP client is NOT authorized, 173 regardless of whether its IP address is included in the response. 175 When Weight equals 3, the sending SMTP client may or may not be 176 authorized, whether or not its IP address is included in the response 177 (but the EHLO name is authorized, if the receiving SMTP server can 178 find some other way to authenticate its right to use that EHLO name). 180 If the sending SMTP client[ID-CSV] is both authenticated and 181 authorized (with Weight equal 2 and the IP address matching), CSA 182 processing is successful, and the receiving SMTP server can treat 183 messages arriving in this SMTP session as authorized by the EHLO 184 domain administrator. 186 Otherwise, caution is required. The receiving SMTP server might: 188 - Generate an SMTP session error, as suggested below. 190 - Mark the message, to indicate that it failed validation. 192 - Place the message into a special queue, for separate handling. 194 For the Unknown case, in which there is no SRV RR, the receiving SMTP 195 server's local policy MAY test whether the domain name, from the 196 HELO/EHLO announcement, is part of a domain that makes an EXPLICIT 197 assertion, as described in Section 5. 199 When a CSV related session error is generated, a 550 error code 200 SHOULD be used and enough information SHOULD be provided in the reply 201 text to facilitate debugging of the sending system. 203 5. Client SMTP Authorization SRV Record 205 The SRV CSA Record has the following contents: 207 _Service._Proto.Name:TTL:Class:SRV:Priority:Weight:Port:Target 209 Service: 210 _client 212 Protocol: 213 _smtp 215 Name: 216 Domain name asserted in SMTP EHLO announcements. 218 (These first three fields become the QNAME _client._smtp.Name.) 220 TTL: 221 Standard DNS meaning [RFC1035]. 223 Class: 224 Standard DNS meaning [RFC1035]. SRV-CSA records are only defined 225 for the IN Class. 227 Priority: 228 The intended use of [RFC2782] SRV records was to aid discovery and 229 selection of servers by prospective clients. Implementing this 230 client authentication mechanism for the server, the Priority, 231 Weight, and Port fields are no longer used for either discovery or 232 selection. Thus only one SRV-CSA record is needed and these three 233 fields are assigned different meanings. Priority defines the 234 revision level of this mechanism starting at 1. 236 Weight: 237 Weight is a group of bit-fields, as follows: 239 +--------------+----------------------------------------------------+ 240 | Bit Value | Meaning | 241 +--------------+----------------------------------------------------+ 242 | 1 | Ignore Target: The domain name in the Target field | 243 | | is a placeholder, and any IP addresses it resolves | 244 | | to MUST NOT be used for authentication. | 245 | 2 | Authorized: Any host with a valid claim to this | 246 | | name is authorized to send mail. | 247 | - | Other bit values are reserved for expansion and | 248 | | must be set to zero. | 249 +--------------+----------------------------------------------------+ 251 The resulting unsigned integer values for weight are: 253 +--------------+----------------------------------------------------+ 254 | Summed Value | Meaning | 255 +--------------+----------------------------------------------------+ 256 | 0 | Should not be used, but MAY be interpreted as the | 257 | | summed value 1. | 258 | 1 | No mail should be coming from clients with this | 259 | | name. | 260 | 2 | Clients with this name are authorized to send | 261 | | mail. | 262 | 3 | Clients with this name are authorized to send | 263 | | mail, but IP addresses associated with the Target | 264 | | field MUST NOT be used for authentication. | 265 +--------------+----------------------------------------------------+ 267 Port: 268 This field allows the domain administrator to declare assertions 269 which apply to all names within the domain, including those names 270 not present in the DNS. At present, only one assertion in the 271 Port field is defined, as follows: 273 +--------------+----------------------------------------------------+ 274 | Assertion | Meaning | 275 | Bit Value | | 276 +--------------+----------------------------------------------------+ 277 | 1 | Explicit: All authorized names have specific | 278 | | CSV-CSA records. | 279 | - | Other bit values are reserved for expansion and | 280 | | must be set to zero. This range of values should | 281 | | be ignored by the recipient when their function is | 282 | | unknown. | 283 +--------------+----------------------------------------------------+ 285 Domain administrators MAY assert the "Explicit" bit when they have 286 identified all authorized sending SMTP clients within their domain 287 and published specific CSA SRV records for them; that is, all 288 positive authorizations within the domain are explicitly 289 advertised in DNS. 291 This enables receiving SMTP servers to reject SMTP sessions with 292 no specific CSV-CSA record if the HELO string is within a domain 293 that asserts explicit authorization. 295 This assertion greatly simplifies the task of specifying a large 296 class of subdomains which will never legitimately be used as EHLO 297 strings, and makes it practical for large organizations to 298 indicate that individuals should not be using the subdomains 299 assigned to them as EHLO strings. It also deals with invalid EHLO 300 strings that do not appear in the DNS. 302 Target: 303 A domain name (typically the same as the EHLO domain) that 304 resolves to the correct list of IP addresses. If this record is 305 defined with the "Ignore Target" bit value, this field should be 306 set to the Name portion of the QNAME, rather than the "." 307 mentioned in [RFC2782], as a means to prevent excessive traffic on 308 root DNS servers by errant implementations. 310 6. Publishing CSA Records 312 If a domain administrator declares an assertion about all names 313 within a domain, the appropriate bit MUST be set in the Port field of 314 the CSV-CSA record at the root of the domain for which the assertion 315 applies, and MAY be repeated at subdomains of that domain. The 316 Explicit bit applies to a domain and all its subdomains. If it is 317 repeated in a subdomain it has no effect on the semantics, but it 318 might cause a search to stop sooner. 320 Domain administrators SHOULD publish records with such assertions in 321 the port field at a level no deeper than sixth-level domains, such as 323 "_client._smtp.sixth.fifth.fourth.third.second.com" 325 since receivers are expected to search no deeper than that, and will 326 most likely not find records published for seventh-level or deeper. 327 (Receivers will, of course, still query for the weight field at the 328 exact level of the EHLO string.) 330 Although a conceptual framework might list the accreditation step as 331 logically following the authorization step, these steps MAY run in 332 parallel. Thus, those responsible for maintaining CSV DNS records 333 should make allowance for the fact that the response of the 334 accreditation service (which depends only on the EHLO string or the 335 client address) is likely to arrive at the receiving MTA before the 336 response to the DNS SRV query detailed here. As a result, the 337 receiving SMTP server may not follow-up partial or truncated UDP 338 responses for expediency. Regardless of what is specified, this 339 receiving SMTP server may decide to refuse the client if their chosen 340 accreditation service returns "Unknown". The following 341 recommendations explain how to ensure that the complete list of IP 342 addresses reaches the receiving SMTP server in the response to its 343 SRV query. 345 Currently UDP has a limit of 512 octets. Replies requiring more than 346 512 octets may create UDP fragmentation and, depending upon the 347 connection and handling, in addition to a higher rate of packet loss, 348 may also cause truncated or partial replies. Furthermore, delivery 349 and resolver handling of truncated and partial responses varies, 350 leading to additional delays and queries. Domain administrators are 351 strongly advised to keep DNS replies below 512 octets for these 352 reasons. 354 In some cases, domains advertising SRV records will benefit by 355 reassigning some EHLO strings so as to limit the number of IP 356 addresses to be reported in SRV responses. Owing to the efficient 357 nature of the SRV record, the mechanism discussed here calls for a 358 single DNS query per SMTP session (not counting an out-of-band 359 accreditation query), which is substantially less network traffic 360 than per-message methods. 362 To help ensure complete answers are obtained from cached records, TTL 363 values of the SRV-CSA and related address records should be the same. 364 Beware some DNS server implementations consider the SOA TTL as a 365 default rather than a minimum. 367 7. Using CSA Records 369 A receiving SMTP server MAY discover domain assertion information 370 (after finding no record for the specific domain in the EHLO string) 371 by searching for CSV-CSA records in parent nodes of the EHLO string, 372 within the DNS hierarchy. Such a search MUST NOT query a top-level 373 domain (such as COM, NET, or UK), and SHOULD NOT query deeper than a 374 sixth-level domain. Receiving SMTP servers SHOULD ensure that they 375 query a server which caches negative results to avoid useless traffic 376 to the root servers. 378 Receiving SMTP servers MAY maintain and/or query a database which 379 saves domain-names for which a record has been found with the 380 "Explicit" bit set, and MAY reject or otherwise flag sessions for 381 which the "Explicit" assertion applies but no specific CSV-CSA record 382 is found. 384 With a complete response to an SRV-CSA query, SMTP server is able to 385 employ Right Hand Side Black List (RHSBL) services based upon the 386 domain name rather than address alone and as well as the 387 accreditation services detailed in [ID-CSVDNA]. These domain-based 388 services will not suffer from the same outdated-record problems as 389 the IP-Address-based services widely used at the time of this 390 writing. Also, of course, domain-based services will be able to 391 accredit those domains which must periodically change their IP 392 address. Reliance on the HELO/EHLO response allows isolation of 393 domains which may share common address space as with virtual hosting 394 or allow detection of domains for which there is insufficient history 395 which may invoke a go-slow approach as example. 397 8. Security Considerations 399 This proposal pertains to security, namely authentication and 400 authorization of peer MTAs. 402 The proposal also relies on security of the underlying IP network and 403 on the integrity of DNS data. It performs a basic authentication of 404 the peer MTA, based on domain name registration of the peer's IP 405 Address. As such, the mechanism provides a basic building block to a 406 larger repertoire of email security services. 408 There is no way a site can keep its hosts from being referenced as 409 servers. This could lead to denial of service. 411 With SRV, DNS spoofers can supply false addresses. Because this 412 vulnerability exists already with names and addresses, this is not a 413 new vulnerability, merely a slightly extended one. However, as 414 SRV-CSA records are used in an authorization context, the DNS servers 415 can be protected by DNSSEC [RFC3008] should this vulnerability become 416 intractable. 418 9. IANA Considerations 420 The tokens "_client" as _Service and "_smtp" as _Proto labels needs 421 to be registered as used with DNS SRV records [RFC2782]. 423 10. Working Group Evaluation 425 This section contains responses to the issues put forward by the 426 MARID working group chairs. 428 1. Amount of change in software components 429 DNS administration, servers and clients MUST support SRV queries. 430 Client MTA's MUST put their registered domain name in EHLO 431 announcements. 432 Server MTA's MUST implement the validation procedure described in 433 this specification. 435 2. Configuration complexity 436 Requires registering each IP Address of an authorized Client MTA, 437 whenever the set of Addresses changes. No other configuration is 438 required. 440 3. Current use cases that will no longer be viable 441 All current use cases will still be viable. This mechanism is 442 only enabled by the explicit presence of the defined SRV record 443 for the domain name in the EHLO announcement. 445 4. Needed infrastructure changes 446 Explicit registration of Client MTAs. 447 Considerations for use in both IPv4 and IPv6 448 Validation mechanism is based on IP Addresses and requires the 449 usual query and handling of address types that will be 450 encountered from the IP module and the DNS. 452 11. References 454 11.1 References - Normative 456 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 457 1981. 459 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 460 821, August 1982. 462 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 463 text messages", STD 11, RFC 822, August 1982. 465 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 466 RFC 1034, November 1987. 468 [RFC1035] Mockapetris, P., "Domain names - implementation and 469 specification", STD 13, RFC 1035, November 1987. 471 [RFC1122] Braden, R., "Requirements for Internet Hosts - 472 Communication Layers", STD 3, RFC 1122, October 1989. 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, March 1997. 477 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 478 Specification", RFC 2181, July 1997. 480 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 481 2671, August 1999. 483 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 484 specifying the location of services (DNS SRV)", RFC 2782, 485 February 2000. 487 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 488 April 2001. 490 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 491 2001. 493 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) 494 Signing Authority", RFC 3008, November 2000. 496 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 497 Transport Layer Security", RFC 3207, February 2002. 499 11.2 References - Informative 501 [ID-CSV] Crocker, D., Otis, D. and J. Leslie, "Certified Server 502 Validation (CSV)", February 2005. 504 [ID-CSVDNA] 505 Leslie, J., Crocker, D. and D. Otis, "Domain Name 506 Accreditation (DNA)", February 2005. 508 [ID-email-arch] 509 Crocker, D., "Internet Mail Architecture", July 2004. 511 Authors' Addresses 513 Douglas Otis 514 Mail Abuse Prevention System 515 1737 North First Street, Suite 680 516 San Jose, CA 94043 517 USA 519 Phone: +1.408.453.6277 520 EMail: dotis@mail-abuse.org 522 Dave Crocker 523 Brandenburg InternetWorking 524 675 Spruce Drive 525 Sunnyvale, CA 94086 526 USA 528 Phone: +1.408.246.8253 529 EMail: dcrocker@brandenburg.com 530 John Leslie 531 JLC.net 532 10 Souhegan Street 533 Milford, NH 03055 534 USA 536 Phone: +1.603.673.6132 537 EMail: john@jlc.net 539 Appendix A. Acknowledgements 541 John Levine, Tony Finch, and Sam Silberman provided helpful comments. 543 Intellectual Property Statement 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed to 547 pertain to the implementation or use of the technology described in 548 this document or the extent to which any license under such rights 549 might or might not be available; nor does it represent that it has 550 made any independent effort to identify any such rights. Information 551 on the procedures with respect to rights in RFC documents can be 552 found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use of 557 such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository at 559 http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention any 562 copyrights, patents or patent applications, or other proprietary 563 rights that may cover technology that may be required to implement 564 this standard. Please address the information to the IETF at 565 ietf-ipr@ietf.org. 567 Disclaimer of Validity 569 This document and the information contained herein are provided on an 570 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 571 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 572 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 573 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 574 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 575 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 577 Copyright Statement 579 Copyright (C) The Internet Society (2005). This document is subject 580 to the rights, licenses and restrictions contained in BCP 78, and 581 except as set forth therein, the authors retain all their rights. 583 Acknowledgment 585 Funding for the RFC Editor function is currently provided by the 586 Internet Society.