MARID J. Leslie
Internet-Draft JLC.net
Expires: January 16, 2005 D. Crocker
Brandenburg InternetWorking
D. Otis
Mail Abuse Prevention System
July 18, 2004
Domain Name Accreditation (DNA)
draft-ietf-marid-csv-dna-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 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Increased diversity and abuse of access, across the open Internet,
mandates additional accountability for sending SMTP clients, in the
absence of prior, direct arrangement with receiving SMTP servers. One
means for enabling this is by registration with third-party services
that vouch for the policies and accountability of SMTP clients
accessing SMTP servers. This specification defines a means for an
SMTP client to list third-party services that are prepared to vouch
Leslie, et al. Expires January 16, 2005 [Page 1]
Internet-Draft CSV-DNA July 2004
for it, and a means for an SMTP server, or its intermediary, to query
vouching services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Accreditation Services . . . . . . . . . . . . . . . . . . . 4
4. Listing Pointer Service Record Template . . . . . . . . . . 5
5. Accreditation Procedure . . . . . . . . . . . . . . . . . . 5
6. Accreditation Report Record Template . . . . . . . . . . . . 6
7. Discussion of DNS record types . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . 8
9. References - Normative . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . 10
Leslie, et al. Expires January 16, 2005 [Page 2]
Internet-Draft CSV-DNA July 2004
1. Introduction
The Internet mail system, based on SMTP [RFC2821], is designed to
allow any client to contact any server. Where prior arrangement is
appropriate and may be verified during the session, the client and
server can use classic authentication techniques. Increased diversity
and abuse of access mandates additional accountability and validation
for sessions that do not have the benefit of prior, direct
arrangement. One means for enabling this is by having the sending
SMTP client registered with a third-party accreditation service that
can provide an independent path to information about the policies and
performance quality of that client's operator.
This specification defines a mechanism for obtaining such
information. It can be operated directly, between the receiving SMTP
server and individual direct accreditation services, or it can be
used with an indirect/proxy accreditation server working on behalf of
the SMTP server, fielding queries to other accreditation services.
The Domain Name Service [RFC1035] provides a common registration
environment, so that sending SMTP clients can specify third-party
services in which they are listed. The DNS also provides a convenient
venue for listing the accreditation information reported by those
services.
2. Background
Should a sending SMTP client host (or network) be trusted to be
transmit genuine email, rather than problematic messages, such as
spam and worms? There are many third-party services that publish
their assessments of such hosts and networks. For example, The
MAPS-RBL Realtime Blackhole List was established in 1996, listing IP
addresses of SMTP clients which sent large amounts of unsolicited
email. Another well-known service was ORBS, which listed SMTP clients
verified to act as open relays, thereby forwarding mail without any
attempt at validation of the sender.
Less well-known are various "whitelist" services, which list SMTP
clients assessed to be sending little or no spam. One examples is
bondedsender.com; it lists IP addresses of SMTP clients whose owners
have posted a bond with bondedsender.com. Each time a recipient of an
email passing through one of the bonded SMTP clients complains that
the email actually was spam, a portion of that bond is forfeit to a
non-profit organization. Another example is Habeas.com, authorizing
senders to include a copyrighted text string, to show certification.
Leslie, et al. Expires January 16, 2005 [Page 3]
Internet-Draft CSV-DNA July 2004
3. Accreditation Services
Third-party services can list sending SMTP clients that guard against
sending unsolicited bulk email or they can list those that are known
to be a problem. This provides a mechanism for establishing trust
between clients and servers that have had no prior contact. This
specification does not deal with the internal operation of such
third-party services.
Accreditation services must, themselves, be assessed for the criteria
they use. Some will have trivial criteria, offering no serious
quality assurance. Others will be so strict as to have very narrow
utility. Still others may use criteria that go wildly astray from a
sender's care in obtaining and using recipient addresses. For example
the accreditation service might base their assessment on the listee's
political views. Hence it is the responsibility of the host querying
the accreditation service to evaluate the operation of the
accreditation service, itself, and treat the weightings they offer
accordingly.
Finding Appropriate Accreditation Services With millions of domains
and hundreds of expected accreditation services, a core challenge
is to find the particular direct accreditation services that
evaluate a particular sending SMTP client. For that reason,
sending SMTP clients SHOULD advertise lists in which they appear.
This is intended as a convenience for receiving SMTP servers, and
those servers MAY consult any accreditation services they wish.
A sending SMTP client SHOULD register accreditation services in
which it is listed by including DNS records with domain-names of
the accreditation services. The client SHOULD place such records
at each sub-domain level that receiving SMTP servers will need to
validate. In cases where the domain management wishes to advertise
the same list for any subdomain name, wildcard DNS records MAY be
used.
(Note that the existence of these DNS records does not certify
that a sending SMTP client has a valid claim to the name it places
in the EHLO command; this requires a separate mechanism, to ensure
that the client is authorized to use that name.
Clients SHOULD list more than one accreditation service, so that
it is likely at least one service will be acceptable to a
receiving SMTP server that is making the query. Indeed, it is
likely that some direct accreditation services will develop a
reputation for being "spam-friendly" and be considered worthless
for reputation purposes. In other cases, the receiving SMTP server
or its proxy may have no way to rate a particular direct
Leslie, et al. Expires January 16, 2005 [Page 4]
Internet-Draft CSV-DNA July 2004
accreditation service the sending SMTP client uses, and it will be
ignored.
In order to facilitate resolution of problematic listings, a
receiving SMTP server that refuses access to a sending SMTP client,
due to an unfavorable recommendation, SHOULD return an error message
that cites the accreditation service(s) providing the basis for the
rejection.
4. Listing Pointer Service Record Template
A domain may list services that provide accreditation information
about the operations associated with that name. The DNS records they
SHOULD list are in the form:
1. Name: The domain name that will be checked
2. Type: PTR
3. Class: IN
4. TTL: Standard DNS meaning
5. Target: QNAME string (starting with "_VOUCH._SMTP.") for a DNS
SRV query to return the preferred access method for
human-readable queries to a suggested accreditation service.
Concatenating (with a single dot between them) the domain name of a
sender recommending this service with this target domain name
(without the "_VOUCH._SMTP.") and doing a DNS query for a TXT record
SHOULD return a string giving a report on the trustworthiness of the
client domain.
5. Accreditation Procedure
A receiving SMTP server MAY validate a sending SMTP client by:
1. Obtaining the domain name of the client.
2. Determining that the name is being used by an authorized party.
3. Creating a list of accreditation services to query, both those
the client has registered and those obtained by the server
through other means -- such as those that perform block-listing
-- to query.
4. Querying those services for assessments of the host associated
with that name.
Leslie, et al. Expires January 16, 2005 [Page 5]
Internet-Draft CSV-DNA July 2004
5. Synthesize a single assessment using the responses from the
multiple services; this is done according to whatever weightings
and other methods local policy may dictate.
6. Returning the recommendation -- with a value of "unknown" if no
records were found or if none of the recommended accreditation
services are known.
Alternatively, the receiving SMTP server MAY query any trusted
accreditation service which itself performs steps 3 through 6 and
reports a single recommendation.
In the event that the query procedure is unable to produce a useful
assessment, the decision on how much trust to place in the client is
outside the scope of this document.
If the final report is "not recommended", the server SHOULD return an
error including the name of an accreditation service that reported
Not-Recommended. We suggest using "550 Access Denied based on
<accreditation-service-domain-name> report."
6. Accreditation Report Record Template
A direct accreditation service MUST publish its listings using the
following record and format:
1. Name: <domain being checked>.<Accreditation Service>.
2. Type: TXT
3. Class: IN
4. TTL: Standard DNS meaning
5. Target: Accreditation Report string.
The Accreditation Report string MUST contain a report for a
particular service, encoded as:
1. service accredited
2. comma
3. level accredited for (service-specific, may be empty)
4. comma
5. recommendation, specified as:
Leslie, et al. Expires January 16, 2005 [Page 6]
Internet-Draft CSV-DNA July 2004
1. 'A' for Strongly Recommended
2. 'B' for Recommended
3. 'C' for Unknown
4. 'D' for Not Recommended
5. 'E' for Strongly Not Recommended
6. semicolon (or end-of-string)
7. optional info (format is local to each accreditation service).
Strings which do not match this format MAY have meaning outside the
scope of this specification and MUST be ignored by DNA parsers
unaware of such meaning.
For MARID-CSV, the "service accredited" MUST be "MARID" and the
"level accredited" currently MUST be "1".
The "Accreditation Service" string portion of the Query Name above
should match the RDATA string of the Suggested Service Record
published by the domain being checked, with the "_VOUCH._SMTP."
substring removed.
7. Discussion of DNS record types
For the DNS records listing recommended accreditation services, we
have chosen to use the existing PTR record type. It is perfectly
suited to our needs, yielding a domain-name as the answer and having
no known competing uses at the subdomain levels matching likely EHLO
strings. Conflicts with possible future uses are prevented by
prefixing the substring "_VOUCH._SMTP." so as to point to a SRV query
string. Any CSV queries MUST discard any PTR records returned which
do not contain that prefix.
For the DNS records giving accreditation reports, we have chosen the
existing TXT records. We believe that accreditation services should
be given the full flexibility of free-format text in addition to the
limited formatted text we specify here. There should be no future
conflicts except for accreditation relating to other services, for
which we specify that each TXT record should start with the name of
the service being accredited. Since all these records are at
subdomains generated by concatenating two different domain names,
naming conflicts for the query string cannot arise unless the
accreditation service chooses subdomain (host) names which overlap
top-level domain names.
Leslie, et al. Expires January 16, 2005 [Page 7]
Internet-Draft CSV-DNA July 2004
For both record types, wildcards will work. Domain management can
specify the same accreditation service(s) for all possible subdomains
with wildcard PTR record(s). Accreditation services can specify the
same accreditation report for all possible subdomains with a single
TXT record.
8. Security Considerations
This entire proposal pertains to security, namely authorization and
verification of clients seeking services.
It specifies a way for client domains to advertise the names of
accreditation services in DNS. Various well-known attacks on DNS
services may result in failure to respond to queries or in the
receipt of out-of-date information. However, servers need not use
this information directly, and are more likely to use out-of-band
methods to query their preferred accreditation service.
9 References - Normative
[ID-Marid-CSV]
Crocker, D., Otis, D. and J. Leslie, "Client SMTP
Validation (CSV))", July 2004.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
Authors' Addresses
John Leslie
JLC.net
10 Souhegan Street
Milford, NH 03055
USA
Phone: +1.603.673.6132
EMail: john@jlc.net
Leslie, et al. Expires January 16, 2005 [Page 8]
Internet-Draft CSV-DNA July 2004
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253
EMail: dcrocker@brandenburg.com
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
Leslie, et al. Expires January 16, 2005 [Page 9]
Internet-Draft CSV-DNA 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.
Leslie, et al. Expires January 16, 2005 [Page 10]