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

Versions: 00 01 02

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

                    Domain Name Accreditation (DNA)

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 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

   The list of Internet-Draft Shadow Directories can be accessed at

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

Copyright Notice

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


   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

Leslie, et al.         Expires December 17, 2004                [Page 1]

Internet-Draft                  CSV-DNA                        June 2004

   for an SMTP client to list third-party services that are prepared to
   vouch 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 December 17, 2004                [Page 2]

Internet-Draft                  CSV-DNA                        June 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 accreditation services, or it can be used with
   an 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 offered 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

Leslie, et al.         Expires December 17, 2004                [Page 3]

Internet-Draft                  CSV-DNA                        June 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

   Query Assistance by Listee With millions of domains and hundreds of
      expected accreditation services, a core challenge is to find the
      particular, trusted accreditation services that list a particular
      sending SMTP client.  For that reason, sending SMTP clients SHOULD
      advertise the lists in which they appear.  This is intended as a
      convenience for receiving SMTP servers, and those servers MUST
      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 client has a valid claim to the name it is using; this
      requires a separate mechanism, to ensure that the client is
      authorized to use that name.  See [ID-Marid-HNA].)

      Clients SHOULD list more than one accreditation service, since
      other accreditation services will assuredly assign differing
      weights to recommendations from other accreditation services.
      Indeed, it is likely that some accreditation services will develop
      a reputation for being "spam-friendly" and be assigned negative
      weighting by many other accreditation services.  In other cases,
      the actual accreditation service used by the server may have no

Leslie, et al.         Expires December 17, 2004                [Page 4]

Internet-Draft                  CSV-DNA                        June 2004

      experience with a particular accreditation service the client
      uses, and will almost certainly assign a zero weighting to its

   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

4.  Listing Pointer Service Record Template

   A domain name may map to 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 validates 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

Leslie, et al.         Expires December 17, 2004                [Page 5]

Internet-Draft                  CSV-DNA                        June 2004

       with that name.

   5.  Normalizing the assessment from the accumulated weights,
       according to policies.

   6.  Returning the recommendation -- with a value of "unknown" if no
       records were found or if none of the recommended accreditation
       services are known.

   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

6.  Accreditation Report Record Template

   An accreditation service SHOULD 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:

       1.  'A' for Strongly Recommended

       2.  'B' for Recommended

Leslie, et al.         Expires December 17, 2004                [Page 6]

Internet-Draft                  CSV-DNA                        June 2004

       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 MARID 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.

   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

Leslie, et al.         Expires December 17, 2004                [Page 7]

Internet-Draft                  CSV-DNA                        June 2004

   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

              Crocker, D., Otis, D. and J. Leslie, "Host Name
              Authentication (HNA)", June 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
   10 Souhegan Street
   Milford, NH  03055

   Phone: +1.603.673.6132
   EMail: john@jlc.net

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086

   Phone: +1.408.246.8253
   EMail: dcrocker@brandenburg.com

Leslie, et al.         Expires December 17, 2004                [Page 8]

Internet-Draft                  CSV-DNA                        June 2004

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

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

Leslie, et al.         Expires December 17, 2004                [Page 9]

Internet-Draft                  CSV-DNA                        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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


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

Leslie, et al.         Expires December 17, 2004               [Page 10]

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