MARID D. Crocker
Internet-Draft Brandenburg InternetWorking
Expires: January 12, 2005 J. Leslie
JLC.net
D. Otis
Mail Abuse Prevention System
July 14, 2004
Client SMTP Validation (CSV)
draft-ietf-marid-csv-intro-01
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 January 12, 2005.
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. 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
Crocker, et al. Expires January 12, 2005 [Page 1]
Internet-Draft Mail-CSV July 2004
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.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Service Goal . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Assessing Authorization . . . . . . . . . . . . . . . . . 6
4.2 Assessing Accreditation . . . . . . . . . . . . . . . . . 8
5. Client SMTP Validation Details . . . . . . . . . . . . . . . . 8
5.1 Assessing Authorization . . . . . . . . . . . . . . . . . 8
5.2 Assessing Accreditation . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
B. Host Name Authentication . . . . . . . . . . . . . . . . . . . 12
B.1 DNS-based Mapping . . . . . . . . . . . . . . . . . . . . 13
B.2 Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . 13
B.3 Forward DNS Lookup . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Crocker, et al. Expires January 12, 2005 [Page 2]
Internet-Draft Mail-CSV July 2004
1. Overview
CSV considers two questions at the start of each SMTP session:
o Does a domain's management authorize this MTA to be sending email?
o Do independent accreditation services consider that domain's
policies and practices sufficient for controlling email abuse?
To validate an SMTP session from an unknown sending SMTP client using
CSV, the receiving SMTP server:
1. Obtains the remote IP address of the TCP connection.
2. Extracts the domain name from the EHLO command sent by the SMTP
client
3. Queries a chosen Accreditation Service for the EHLO domain name
(see Domain Name Accreditation (DNA) [ID-CSVDNA])
4. Queries DNS for a SRV record under the EHLO domain name (see
Client SMTP Authorization (CSA) [ID-CSVCSA])
5. Checks the SRV reply for flags returned, and checks for a match
in the list of returned IP addresses
6. Determines the level of trust to give to the sending SMTP client,
based on the results of (3) and (5)
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.
Terminology: Terminology conforms to [ID-mail-arch].
Discussion: The venue for discussing this proposal is the IETF MARID
working group[1].
Crocker, et al. Expires January 12, 2005 [Page 3]
Internet-Draft Mail-CSV July 2004
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 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:
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?
By finding the sending SMTP client's actual IP address, in the
list of IP addresses returned by a DNS Address query on the EHLO
domain-name, CSV satisfies the minimal authentication needs of
this task.
Authorization:
Is the remote host permitted to act as a sending SMTP client? Has
the domain management authorized it to perform this function?
CSV specifies a DNS-based record that states whether an associated
host has permission to operate as a client MTA.
Crocker, et al. Expires January 12, 2005 [Page 4]
Internet-Draft Mail-CSV July 2004
Accreditation:
What is the trust that is to be extended to the entity that
authorized the sending SMTP client? Does the receiving SMTP server
have a basis for deciding that the entity providing authorization
for the client MTA can, itself, be trusted to make accountable
authorizations?
CSV defines a DNS record that permits domains to announce the
accreditation services in which they are listed. It also defines a
separate record by which accreditation services publish their
assessments of sending domains.
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.
Address-based Accreditation:
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 that the operator of the receiving SMTP server
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 continuing
TCP session 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,
Crocker, et al. Expires January 12, 2005 [Page 5]
Internet-Draft Mail-CSV July 2004
CSV makes its assessment before messages cross the Internet, thereby
saving bandwidth and reducing the impact of a distributed denial of
service attack.
3. Service Goal
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:
o Identification by persistent domain name rather than transient IP
Address.
o A standardized method of documenting authorization to operate as a
sending SMTP client.
o A standardized method of referencing accreditation services.
o A standardized method of querying an accreditation service.
4. Requirements
4.1 Assessing Authorization
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.
Identification The means of identifying a remote host or service
anchor=""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 DNS administrator for a domain will maintain
record(s) listing one or more IP addresses associated with that
Crocker, et al. Expires January 12, 2005 [Page 6]
Internet-Draft Mail-CSV July 2004
name, even though reverse-DNS records (not controlled by the same
DNS administrator) may give conflicting information. The
forward-DNS is considered the valid authority for CSV purposes.
Therefore, authentication of a domain name's reference to a
particular IP Address requires an explicit authentication step.
Authentication If the sending SMTP client of a 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
organization's 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 mechanism that permits the necessary amount of
accountability, without imposing undue overhead or restrictions.
A number of strong authentication mechanisms are possible, but
none has yet attained widespread adoption among MTAs with no prior
relationship. CSV specifies a weaker authentication scheme that
meets the modest requirements for this service. Stronger methods
can be supported later, if necessary. However they must be tied to
a domain name and must not require any prior relationship.
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 email
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 authorization of other hosts that might act as email
relays. 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
accountable domain management can announce its authorization of a
particular host to operate a particular service. CSV defines such
a mechanism for sending SMTP clients.
Crocker, et al. Expires January 12, 2005 [Page 7]
Internet-Draft Mail-CSV July 2004
4.2 Assessing Accreditation
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:
o referencing different accreditation services, and
o querying a service to obtain information about the domain 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.
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.
5.1 Assessing Authorization
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:
Crocker, et al. Expires January 12, 2005 [Page 8]
Internet-Draft Mail-CSV July 2004
Identification: The sending SMTP client host is identified by a
Domain Name. The domain name serves as a unique,
topologically-independent, persistent identifier that is
registered in the Domain Name Service.
A sending SMTP client MUST supply a published domain name as the
parameter to an SMTP HELO or EHLO. The sending SMTP client MAY
issue multiple EHLO's over the course of a session, such as for
isolating email flows for accreditation, with different domain
names to represent different users on the client system. If an
EHLO is issued, the entire CSV process MUST be restarted without
needing to make a new connection.
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, upon which CSV assessments are then made.
Authentication: There is no universal, strong method to authenticate
that a host is correctly identifying itself. For most email
transport purposes, it will be sufficient to show that the EHLO
domain name forward-resolves to the IP address of the sending SMTP
client.
The response to a CSV authentication query usually includes the
list of associated IP addresses in the Additional Information
section. Formally, this additional information is the same as
would be obtained from additional queries for that information. A
server includes it in the CSV query for efficiency, to avoid
additional DNS queries.
If the list is returned and the actual IP address of the sending
SMTP client 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 result
in an error being returned.
Authorization: In CSV, the purpose of authorization is to establish
that an accountable authority has given permission for the sending
SMTP client host to operate in that role.
CSV participants MUST use the method defined in Client SMTP
Authorization (CSA) [ID-CSVCSA]. It specifies a DNS record that is
associated with the domain name offered by the sending SMTP client
host.
Crocker, et al. Expires January 12, 2005 [Page 9]
Internet-Draft Mail-CSV July 2004
5.2 Assessing Accreditation
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.
6. Security Considerations
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.
7. References
7.1 Normative References
[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., "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.
Crocker, et al. Expires January 12, 2005 [Page 10]
Internet-Draft Mail-CSV July 2004
[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.
[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 Informative References
[ID-brand-drip]
Brand, R. and L. Sherzer, "Designated Relays Inquiry
Protocol (DRIP)", draft-brand-drip-02 (work in progress),
October 2003.
[ID-mail-arch]
Crocker, D., "Internet Mail Architecture", May 2004.
URIs
[1] <http://ietf.org/html.charters/marid-charter.html>
Authors' Addresses
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253
EMail: dcrocker@brandenburg.com
Crocker, et al. Expires January 12, 2005 [Page 11]
Internet-Draft Mail-CSV July 2004
John Leslie
JLC.net
10 Souhegan Street
Milford, NH 03055
USA
Phone: +1.603.673.6132
EMail: john@jlc.net
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.
Review comments and suggestions, on previous versions of CSV, have
been made by: Tony Finch, Carl Hutzler, Meng Weng Wong, Greg Connor.
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. 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
Crocker, et al. Expires January 12, 2005 [Page 12]
Internet-Draft Mail-CSV July 2004
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.
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 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.
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
Crocker, et al. Expires January 12, 2005 [Page 13]
Internet-Draft Mail-CSV July 2004
name is genuine.
Reverse DNS by itself SHOULD NOT be considered sufficient
authentication.
B.3 Forward DNS Lookup
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.
Crocker, et al. Expires January 12, 2005 [Page 14]
Internet-Draft Mail-CSV July 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 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
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 January 12, 2005 [Page 15]