[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02

MARID                                                         D. Crocker
Internet-Draft                               Brandenburg InternetWorking
Expires: December 16, 2004                                     J. Leslie
                                                                 JLC.net
                                                                 D. Otis
                                            Mail Abuse Prevention System
                                                           June 17, 2004


                      Client SMTP Validation (CSV)
                     draft-ietf-marid-csv-intro-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 16, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Internet mail relies on exchanges between systems that have made no
   prior arrangement with each other.  The current service fails to
   provied an adequate level of accountability for participating hosts.
   Client SMTP Validation (CSV) provides an economical service that
   permits an SMTP server to decide whether messages sent by the client
   SMTP are likely to be well-behaved, or at least to decide whether the



Crocker, et al.        Expires December 16, 2004                [Page 1]


Internet-Draft                  Mail-CSV                       June 2004


   client is sufficiently accountable for its actions.  CSV provides a
   small, simple and useful improvement to Internet mail service
   accountability.  It builds upon the existing practise of service
   providers that accredit the networks from which sending systems are
   connecting.

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1   Identification . . . . . . . . . . . . . . . . . . . . . .  6
     4.2   Authentication . . . . . . . . . . . . . . . . . . . . . .  6
     4.3   Authorization  . . . . . . . . . . . . . . . . . . . . . .  7
     4.4   Accreditation  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Client SMTP Validation Details . . . . . . . . . . . . . . . .  7
     5.1   Identification . . . . . . . . . . . . . . . . . . . . . .  8
     5.2   Authentication . . . . . . . . . . . . . . . . . . . . . .  8
     5.3   Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
     5.4   Accreditation  . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.1   References - Normative . . . . . . . . . . . . . . . . . . .  9
   7.2   References - Informative . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   B.  Host Name Authentication . . . . . . . . . . . . . . . . . . . 11
     B.1   DNS-based Mapping  . . . . . . . . . . . . . . . . . . . . 11
     B.2   Reverse DNS  . . . . . . . . . . . . . . . . . . . . . . . 12
     B.3   Forward DNS Lookup . . . . . . . . . . . . . . . . . . . . 12
     B.4   Encryption-Based Authentication  . . . . . . . . . . . . . 13
       B.4.1   StartTLS . . . . . . . . . . . . . . . . . . . . . . . 13
       B.4.2   SMTP Auth  . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14
















Crocker, et al.        Expires December 16, 2004                [Page 2]


Internet-Draft                  Mail-CSV                       June 2004


1.  Overview

   To validate an SMTP session from an unknown sending SMTP client using
   CSV, the receiving SMTP server SHOULD:

   1.  Obtain the source IP address of the TCP connection

   2.  Extract the EHLO domain name

   3.  Query a chosen Accreditation Service for the EHLO domain name
       (see Domain Name Accreditation (DNA) [ID-Marid-CSVDNA])

   4.  Query DNS for a SRV record under the EHLO domain name (see Client
       SMTP Authorization (CSA) [ID-Marid-CSVCSA])

   5.  Check the flags returned and check for a match in the list of
       returned IP addresses

   6.  Based on the results of (3) and (5), determine the level of trust
       to give to the sending SMTP client.

   If the level of trust is high enough, process all email from that
   session in the traditional manner, delivering or forwarding without
   the need for further validation.

   If the level of trust is too low, return an error showing the reason
   for not trusting the sending SMTP client.

   If the level of trust is in between, document the result in a header
   in each email delivered or forwarded, and/or perform additional
   checks

2.  Background

   Internet mail suffers from the operation of hosts acting as mail
   transfer agents (MTA) without any meaningful cross-net
   accountability.  This makes it impossible to vet MTAs or find
   recourse when their operations cause problems.  Many of these hosts
   have been compromised and have been turned into unwilling
   participants in large networks of hostile MTAs that send spam and
   worms, and contribute to denial of service attacks.

   When a server MTA receives a connection, it must decide whether to
   accept the message traffic that is being sent to it, trusting that
   its delivery will not be problematic to the operation of the provider
   or their users.  How can it do this, when operating in the open
   Internet? Client SMTP Validation (CSV) defines a service that permits
   the receiving SMTP server to decide whether messages sent by the



Crocker, et al.        Expires December 16, 2004                [Page 3]


Internet-Draft                  Mail-CSV                       June 2004


   sending SMTP client are likely to be well-behaved, or at least to
   decide whether the client is sufficiently accountable for its
   actions.

   The process of deciding on this trust of the client requires
   performing a series of conceptually discrete steps:

   Identification:
      What is the "name" of the client to be trusted? How is it
      referenced?

      CSV uses the domain name supplied by a client in the SMTP HELO/
      EHLO.

   Authentication:
      Is the client MTA legitimately associated with that name? Can we
      prove that the client is who it purports to be?

      CSV documents a range of existing techniques that are appropriate
      for use with CSV.

   Authorization:
      Is the sending SMTP client permitted to act as a client MTA? Has a
      separate authority given it permission to perform this service?

      CSV specifies a DNS-based record that states whether an associated
      host has permission to operate as a client MTA.

   Accreditation:
      What is the trust that is to be extended to the entity that
      authorized the client MTA? Does the server MTA have a basis for
      deciding that the entity providing authorization for the client
      MTA can, itself, be trusted to make valid authorizations?

      CSV discusses existing techniques for accrediting authorizing
      systems.  It also defines a DNS record that permits such systems
      to announce the accreditation services in which they are listed.
      It defines another DNS record that permits accreditation services
      to publish their assessments of client MTAs.

   A proposal or its implementation well might combine these steps.
   However it is important to consider them independently, in order to
   ensure that the proposal specifies that they are performed in a valid
   manner, or at least that the constraints of the proposal are clear
   for each of these conceptual functions.  This specification
   distinguishes each of these logical steps and defines their operation
   separately.  It is based on validation of the EHLO domain name.  The
   proposed mechanism is small, simple and useful.  In particular it



Crocker, et al.        Expires December 16, 2004                [Page 4]


Internet-Draft                  Mail-CSV                       June 2004


   permits detecting machines that are prohibited from acting as Client
   MTAs and those that are permitted.  The mechanism is designed to be
   useful between peer MTAs and only requires use of well-established
   mechanisms.

   Address-based Authentication:
      Currently, service providers often maintain lists of remote
      networks that are known to be trustworthy or untrustworthy as
      sending SMTP clients.  Typically, these lists are based on the use
      of IP Addresses of the clients.  The IP Addresses serve as
      identifiers.  The list specifies positive or negative
      authorization, and the source of the list is an organization the
      service provider deems worthy to assess other sites.

      When used in this way, IP Addresses are authenticated by relying
      on their use in the IP routing infrastructure.  Packets are routed
      to the specified IP Address, over the open Internet.  A repeated
      exchange using that IP Address is therefore presumed to be an
      interaction with the host legitimately associated with that IP
      Address.

      Increased topological, transfer and access complexities on the
      Internet are making IP Addresses increasingly problematic for use
      as persistent identifiers.  Instead they are viewed as appropriate
      only for the most transient task of delivering individual packets.

   CSV builds upon this popular model.  Besides the considerable benefit
   of having operational practice, the model can be extremely efficient.
   It permits the service provider to assess the source of an entire
   message stream, rather than having to evaluate each message.  Also,
   CSV makes its assessment before messages cross the Internet, thereby
   saving bandwidth and reducing the impact of a distributed denial of
   service attack.

3.  Design Goals

   CSV will verify that a host is authorized to act as an SMTP client
   and that the client is likely to be operated acceptably.  CSV will
   enhance current practice with:

   o  Identification by persistent domain name rather than transient IP
      Address

   o  Alternative authentication techniques

   o  Explicit listing of client service authorization

   o  A standardized method of referencing accreditation services



Crocker, et al.        Expires December 16, 2004                [Page 5]


Internet-Draft                  Mail-CSV                       June 2004


   o  A standardized method of querying an accreditation service.

   Terminology: Terminology conforms to [ID-email-arch].

   Discussion: The venue for discussing this proposal is the
      <http://ietf.org/html.charters/marid-charter.html>.

   NOTE: The current draft makes reference to quite a few underlying
      services that need citations (ed.)


4.  Requirements

4.1  Identification

   The means of identifying a remote host or service requires uniqueness
   and is aided by persistence.  The identifier must not be ambiguous
   and its use is made far more efficient if it is stable over time.
   The two usual choices are IP Addresses and Domain Names.

   An IP Address typically refers to a single host and can change
   relatively frequently, as the host's connection to the Internet
   changes.  IP Addresses are reported by the Internet infrastructure
   and for simple security requirements, transactional use of an IP
   Address through the Internet's routing fabric is taken as validation
   of the Address.  Domain Names are longer-lived but require new
   administrative effort.  They can be used to refer to multiple hosts
   simultaneously.  The administrator of a Domain Name may list any IP
   Address they wish to associate with the name, independent of the
   administrator and the Domain Name having a valid relationship to that
   Address.  Therefore, authentication of a domain name's reference to a
   particular IP Address requires an explicit authentication step.

4.2  Authentication

   If the sending SMTP client of an connection can be authenticated,
   then it is possible to develop an accountability mechanism based on
   that authentication.  MUA-MSA exchanges have a substantial number of
   useful authentication mechanisms available.  These are often very
   strong, and involve significant prior arrangement.  The same holds
   true for MDA-MUA exchanges, and often for MSA-MTA and MTA-MDA
   exchanges, such as within an organizations local network.

   What is missing is a useful means of authenticating MTA-MTA exchanges
   over the open Internet.  Prior arrangement between such a pair of
   MTAs is antithetical to the history and operation of Internet mail.
   Spontaneous communications are at the core of Internet design and
   operation.  So the challenge is to develop an authentication



Crocker, et al.        Expires December 16, 2004                [Page 6]


Internet-Draft                  Mail-CSV                       June 2004


   mechanism that permits the necessary amount of accountability,
   without imposing undue overhead or restrictions.

4.3  Authorization

   Internet operation has typically required no public mechanism for
   restricting or permitting particular hosts to operate clients or
   servers for particular services on behalf of particular domains.  The
   DNS MX record states where to route mail that is destined for a
   specific domain; this implies a degree of authorization for the host
   referenced in the MX.  However the record is really for routing and
   there is no equivalent means of specifying prohibition of other hosts
   that might act as intermediaries.  Similarly there is no means for
   checking the authorization of World Wide Web servers, DNS servers,
   telnet clients or other Internet applications.

   What is missing is an open, interoperable means by which a trusted
   agency can announce its authorization of a particular host to operate
   a particular service.

4.4  Accreditation

   In non-Internet environments the basis for deciding that an
   authorizing agency is, itself, to be trusted, is highly varied and
   often is not well-understood.  It is expected that this portion of an
   Internet mail validation service will therefore need to support be a
   variety of accreditation service styles.

   What is needed is a means of announcing performance of accreditation
   and a means of querying a service to obtain information about the
   host it is accrediting.

5.  Client SMTP Validation Details

   CSV defines a mechanism for session-time, domain-based validation of
   a sending SMTP client.  It is useful across the open Internet,
   between MTAs that have made no prior arrangement with each other.
   Validation establishes that the operation of the MTA is authorized by
   an accredited administrator of the declared domain name.

   The validation requirements are modest, because the system does not
   seek to provide long-term vetting of the client host, nor does it
   assess the actual content being exchanged.  Techniques that would be
   wholly inadequate for classic, strong authentication and validation
   can be entirely sufficient for CSV's needs.






Crocker, et al.        Expires December 16, 2004                [Page 7]


Internet-Draft                  Mail-CSV                       June 2004


5.1  Identification

   The sending SMTP client host is identified by a Domain Name, supplied
   by that host as the parameter to an opening SMTP HELO or EHLO.  The
   domain name serves as a unique, topologically-independent, persistent
   identifier that is registered in the Domain Name Service.

   For CSV, a sending SMTP client places the domain name into the
   <Domain> field specified for a SMTP HELO or EHLO [RFC2821].  The
   domain name is any name under which it is claiming authorization to
   act as a sending SMTP client.  A receiving SMTP server will extract
   this name and use it as the identification for the client seeking to
   send email.

5.2  Authentication

   There is no universal method to authenticate that a host is correctly
   identifying itself.  For most email purposes, it will be sufficient
   to show that the EHLO domain name forward-resolves to the IP address.

   CSV usually returns the list of IP addresses in the reply to the SRV
   query.  The Host Name Authentication appendix gives advice on how to
   proceed if no list is returned.

   If the list is returned and the actual IP address is in it, the
   receiving SMTP server SHOULD consider the EHLO domain name to be
   authenticated.  Conversely, if the list is returned and the actual IP
   address is not in it, the assertion of the EHLO domain name SHOULD be
   considered incorrect, and an error returned.

5.3  Authorization

   The purpose of authorization, in CSV, is to establish that an
   accountable authority has given permission for the sending SMTP
   client host to operate in that role.

   CSV participants SHOULD use the method defined in Client SMTP
   Authorization (CSA) [ID-Marid-CSVCSA].  It specifies a DNS record
   that is associated with the domain name offered by the sending SMTP
   client host.

5.4  Accreditation

   The utility of any service like CSV is entirely dependent upon the
   relevance, reliability and accuracy of the service that accredits the
   authorizing agent.  It is expected that there will be numerous
   services that provide accreditation.  CSV is intended to support use
   of any service that gains credibility among operators of SMTP



Crocker, et al.        Expires December 16, 2004                [Page 8]


Internet-Draft                  Mail-CSV                       June 2004


   servers.

   An initial set of capabilities for specifying CSV-related
   accreditation services is specified in Domain Name Accreditation
   [ID-Marid-CSVDNA].  CSV participants SHOULD use the methods defined
   there.

6.  Security Considerations

   This entire proposal pertains to security, namely authentication and
   authorization of peer MTAs.

   The proposal relies on the integrity and authenticity of DNS data.

7.  References

7.1  References - Normative

   [ID-Marid-CSVCSA]
              Otis, D., Crocker, D. and J. Leslie, "sending SMTP client
              Authorization (CSA)", June 2004.

   [ID-Marid-CSVDNA]
              Leslie, J., Crocker, D. and D. Otis, "Domain Name
              Accreditation (DNA)", June 2004.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
              821, August 1982.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
              RFC 2554, March 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.




Crocker, et al.        Expires December 16, 2004                [Page 9]


Internet-Draft                  Mail-CSV                       June 2004


   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

7.2  References - Informative

   [ID-brand-drip]
              Brand, R. and L. Sherzer, "Designated Relays Inquiry
              Protocol (DRIP)", draft-brand-drip-02 (work in progress),
              October 2003.

   [ID-email-arch]
              Crocker, D., "Internet Mail Architecture", May 2004.


Authors' Addresses

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086
   USA

   Phone: +1.408.246.8253
   EMail: dcrocker@brandenburg.com


   John Leslie
   JLC.net
   10 Souhegan Street
   Milford, NH  03055
   USA

   Phone: +1.603.673.6132
   EMail: john@jlc.net











Crocker, et al.        Expires December 16, 2004               [Page 10]


Internet-Draft                  Mail-CSV                       June 2004


   Douglas Otis
   Mail Abuse Prevention System
   1737 North First Street, Suite 680
   San Jose, CA  94043
   USA

   Phone: +1.408.453.6277
   EMail: dotis@mail-abuse.org

Appendix A.  Acknowledgements

   This proposal is similar to DRIP [ID-brand-drip], however it uses a
   different DNS [RFC1035] record.

Appendix B.  Host Name Authentication

   The routing infrastructure of the Internet distinguishes hosts by
   their topological attachment, noted as its IP Address.  Because IP
   Addresses change periodically and users prefer references that can be
   mnemonic, hosts on the Internet generally have one or more Domain
   Names (DNS) [RFC1035] assigned to them.  Domain Name are globally
   unique.  The core function of the DNS is to map from a name supplied
   by the user, to an IP Address associated with that name.  Internet
   protocols often permit a host to identify itself with its domain
   name.

   But what if a host is programmed incorrectly, or even maliciously.
   We need a way to authenticate that a host is reporting its name
   correctly.  Establishing this authentication is separate from
   determining its authorization to perform any particular service.
   Until the relationship is authenticated, we cannot apply policies
   associated with the name.

   This appendix lists a number of methods for authenticating the
   relationship between the host and its reported name.  Other equally
   valid methods are possible.  The purpose of this document is simply
   to demonstrate that more than one valid technique is already in
   common use.

B.1  DNS-based Mapping

   The Domain Name System has a common mapping mechanism that can be
   used in a variety of ways, based on the schema for assigning names
   and the types of data listed under those names.  The two most popular
   schemas are forward mapping and Reverse-DNS.  Forward looks up a
   "regular" domain name and receive information about it, such as a
   list of IP Addresses associated with that name.  Reverse DNS starts
   with an IP Address and maps it to a pointer to a "regular" domain



Crocker, et al.        Expires December 16, 2004               [Page 11]


Internet-Draft                  Mail-CSV                       June 2004


   name.

   Often when contacted by a remote host, a host uses a reverse-DNS
   query to get the name of the remote host.  This can be followed by a
   forward-DNS query to see if the name reported by the reverse-DNS
   query matches an IP address reported by the forward-DNS query.  If
   so, this is generally considered authentication of the relationship
   of the name to the host.  This method is often used by receiving SMTP
   servers to decide whether to trust the sending SMTP client.

   Closing the circle in this manner permits verifying both that the
   domain assigning the name and the service provider assigning IP
   addresses agree that this is the appropriate name for that remote
   host.  Although this process has known limitations, it is considered
   sufficient for many basic uses.

   Use of an IP Address returned by the DNS is sufficient for
   CSV-related authentication requirements of this service.  However it
   MUST NOT be considered a strong form of authentication as to allow
   otherwise privileged access.  The use of this mechanism is to aid
   selection of accreditation services, such as whether to query using
   the domain name or the client address.  Other measures may be taken
   intended to limit exposure to unknown clients but are beyond the
   scope of this specification.

B.2  Reverse DNS

   Reverse DNS can be used by itself to associate a domain name with an
   IP address.  It indicates that the entity responsible for allocating
   that block of IP addresses has designated an IP address to be used by
   the domain name.  Unfortunately, the reverse-IP branch of the DNS has
   a long history of being poorly maintained, and often does not match
   the forward-DNS information even when the relationship of host to
   name is genuine.

   Reverse DNS by itself should not be considered sufficient
   authentication.

B.3  Forward DNS Lookup

   It is possible that an isolated forward lookup will be sufficient for
   simple sending SMTP client authentication, if an IP Address returned
   for that name matches the IP Address reported by the underlying IP
   service for that remote host.  This indicates that the domain in
   question currently designates that IP Address as an IP address
   entitled to respond for that domain name.





Crocker, et al.        Expires December 16, 2004               [Page 12]


Internet-Draft                  Mail-CSV                       June 2004


B.4  Encryption-Based Authentication

   The use of encryption-based authentication supports a process that is
   entirely independent of the underlying data delivery service.  For
   example, it does not use the IP Address.

B.4.1  StartTLS

   A common certificate method as used with StartTLS [RFC3207] can
   authenticate an unknown server after an investment in signed periodic
   digital certificates, encryption capabilities, and services of a
   Certificate Authority.  This investment creates a barrier for
   large-scale use over the open Internet.  Reliance on the certificate
   signature also adds a need to vet Certificate Authorities in addition
   to the confirmed domains.

   Spontaneous communications are at the core of Internet design and
   operation.  So omission of a Certificate Authority is typically
   allowed of clients.  When this is allowed, StartTLS loses any ability
   to authenticate the relationship of the client to its claimed domain
   name

B.4.2  SMTP Auth

   Another technique is SMTP Auth [RFC2554].  StartTLS invokes a
   TLS-based security mechanisms for the entire life of the connection.
   SMTP Auth provides an additional authentication command to an
   otherwise normal SMTP session, where the client must respond
   correctly to a challenge by the server.  Thus, it it generally useful
   only for clients and servers which have a pre-existing trust
   relationship.




















Crocker, et al.        Expires December 16, 2004               [Page 13]


Internet-Draft                  Mail-CSV                       June 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Crocker, et al.        Expires December 16, 2004               [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/