|Network Working Group||D. Crocker|
|INTERNET DRAFT||Brandenburg InternetWorking|
|Category: Standards Track||JLC.net|
|Expires: January 2005||D. Otis|
|Mail Abuse Prevention System|
Client SMTP Validation (CSV)
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 in January 2005.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Internet mail relies on exchanges between systems that have made no prior arrangement with each other. Widespread abuse of the email system has led operators to demand accountability for the email their receiving SMTP servers are being asked to process. Client SMTP Validation (CSV) provides an economical service that permits a receiving SMTP server to decide whether a sending SMTP client is likely to produce well-behaved traffic, or at least to decide whether the 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 practice of service providers that accredit the networks from which sending systems are connecting.
3 Service Goal
4.1 Assessing Authorization
4.2 Assessing Accreditation
5 Client SMTP Validation Details
5.1 Assessing Authorization
5.2 Assessing Accreditation
6 Security Considerations
§ Normative References
§ Informative References
§ Author's Addresses
B Host Name Authentication
B.1 DNS-based Mapping
B.2 Reverse DNS
B.3 Forward DNS Lookup
§ Intellectual Property and Copyright Statements
CSV considers two questions at the start of each SMTP session:
To validate an SMTP session from an unknown sending SMTP client using CSV, the receiving SMTP server:
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.
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 decides whether to accept the message traffic that is being sent to it, trusting that delivery of that traffic's messages 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 transmitted by the 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:
An implementation well might combine some of these steps. However it is important to consider them independently, in order to ensure that they are specified in a valid manner, or at least that the constraints of the proposal are clear for each of these conceptual functions. This specification is based on validation of the EHLO domain name. The mechanism is small, simple and useful. In particular it 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.
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.
CSV verifies that a host is authorized to act as an SMTP client and that the client is likely to be operated acceptably. CSV enhances current practice with:
For a receiving SMTP server to determine whether a host has authorization to act as a sending SMTP client, it is necessary to identify the host and verify its association with that identity. Given that, a DNS query on the name can return an explicit authorization.
This portion of CSV determines accreditations for the sending SMTP client or for the administration under which it operates. The basis for deciding that an authorizing agency is, itself, to be trusted can be highly varied. Often, well-established practices are not that well-understood. This makes it difficult to predict what methods of accreditation will be most appropriate and successful for Internet mail. 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 standard means for:
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.
Validation has two separate phases: assessing authorization and assessing accreditation. The first is performed between the receiving SMTP server and the sending SMTP client. The second is performed between the receiving SMTP server and one or more accrediting services.
This phase provides a means for a network administrator to publicly state what hosts are authorized by it to act as client MTAs. Absent such a statement of authority, it is possible that the client is a rogue or compromised host.
The assessment requires three steps:
The CSV authorization phase provides a basis for trusting that the sending SMTP client is under the control of a domain's management; but this says nothing about the policies and practices of that management. Separate accreditation services are needed for that. It is expected that there will be numerous services that provide accreditation. CSV is intended to support use of any accreditation service that gains credibility among operators of SMTP servers.
An initial set of capabilities for specifying CSV-related accreditation services is specified in Domain Name Accreditation (DNA) [ID-CSVDNA]. Sending SMTP clients SHOULD publish CSV records referring to accreditation services in which they are listed. Accreditation services MUST publish DNA-conformant records.
CSV defines a security mechanism. The nature of the security requirements for CSV are significantly different from typical, "strong" methods required for most Internet security functions.
The proposal relies on the integrity and authenticity of DNS data.
|[ID-CSVCSA]||Otis, D., Crocker, D. and J. Leslie, "sending SMTP client Authorization (CSA)", June 2004.|
|[ID-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.B., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.|
|[RFC0822]||Crocker, D.H., "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.G., "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.|
|[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.|
|[ID-brand-drip]||Brand, R and L Sherzer, "Designated Relays Inquiry Protocol (DRIP)", Internet-Draft draft-brand-drip-02, October 2003.|
|[ID-mail-arch]||Crocker, D., "Internet Mail Architecture", May 2004.|
|675 Spruce Drive
|Sunnyvale, CA 94086|
|10 Souhegan Street
|Milford, NH 03055|
|Mail Abuse Prevention System|
|1737 North First Street, Suite 680
|San Jose, CA 94043|
This proposal is similar to DRIP [ID-brand-drip], however it uses a different DNS [RFC1035] record.
Review comments and suggestions, on previous versions of CSV, have been made by: Tony Finch, Carl Hutzler, Meng Weng Wong, Greg Connor.
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. A Domain Name is 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.
A number of methods for authenticating the relationship between the host and its reported name might be used. The current CSV specification supports authentication through Domain Name Service mappings between a domain name and an IP Address. Other equally valid methods are possible. However none has yet proved practical for authenticating a client to a server, without prior arrangement between them.
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 receives 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 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 an 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. However it MUST NOT be considered a strong form of authentication for allowing 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.
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.
An isolated forward lookup is 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.
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 IETF's procedures with respect to rights in IETF 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 firstname.lastname@example.org.
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 (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.
Funding for the RFC Editor function is currently provided by the Internet Society.