DKIM Working Group                                             E. Allman
Internet-Draft                                            Sendmail, Inc.
Intended status:  Standards Track                              M. Delany
Expires:  March 20,  August 4, 2008                                     Yahoo! Inc.
                                                               J. Fenton
                                                     Cisco Systems, Inc.
                                                      September 17, 2007
                                                        February 1, 2008

                     DKIM Sender Signing Practices
                         draft-ietf-dkim-ssp-01
                         draft-ietf-dkim-ssp-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 March 20, August 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).

Abstract

   DomainKeys Identified Mail (DKIM) defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology to permit verification of the source and
   contents of messages by either Mail Transport Agents (MTAs) or Mail
   User Agents (MUAs).  The primary DKIM protocol is described in
   [RFC4871].

   This document describes the records that senders may authors' domains can use to
   advertise
   how they sign their practices regarding signing their outgoing mail, and
   how verifiers should access other hosts can access, parse and interpret those results. records.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

(Unresolved Issues/To Be Done)

   o  Need to consider handling of multiple responses to a DNS query for
      the SSP record.

   o  Security Considerations needs a detailed examination.

   o  IANA Considerations should be formalized (e.g., as in 4871).

   o  Check over the references.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Language and Terminology . . . . . . . . . . . . . . . . . . .  5  4
     2.1.  Terms Imported from DKIM Signatures Specification  . . . .  5
     2.2.  Valid Signature  Evaluator  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Originator Address  SSP Checker  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4.  Originator Domain  Valid Signature  . . . . . . . . . . . . . . . . . . . .  6 .  5
     2.5.  Alleged Signer Author . . . . . . . . . . . . . . . . . . . . . .  6  5
     2.6.  Alleged Originator  Author Address . . . . . . . . . . . . . . . . . . . . . .  6
     2.7.  Sender Signing Practices  Author Domain  . . . . . . . . . . . . . . . . . . . . . .  6
     2.8.  Originator  Author Signature . . . . . . . . . . . . . . . . . . . . .  6
     2.9.  Suspicious  Sender Signing Practices Record  . . . . . . . . . . . . .  6
   3.  Operational Description  . . . . . . . . . . .  6
     2.10. Third-Party Signature . . . . . . . .  6
     3.1.  Publication of SSP Records . . . . . . . . . .  7
     2.11. Verifier Acceptable Third-Party Signature . . . . . .  6
     3.2.  Lookup of SSP Records  . .  7
   3.  Operation Overview . . . . . . . . . . . . . . . .  8
     3.3.  SSP Record Syntax  . . . . . .  7
   4.  Detailed Description . . . . . . . . . . . . . .  9
   4.  IANA Considerations  . . . . . . .  8
     4.1.  DNS Representation . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . .  8
     4.2.  Publication of SSP Records . . . . . . . . . . . . . 11
     5.1.  DNS Attacks  . . .  9
     4.3.  Record Syntax . . . . . . . . . . . . . . . . . . . . 11
     5.2.  DNS Wildcards  . . 10
     4.4.  Sender Signing Practices Check Procedure . . . . . . . . . 12
   5.  IANA Considerations . . . . . . . . . . . 11
   6.  References . . . . . . . . . . 13
   6.  Security Considerations . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . 13
     6.1.  Fraudulent Sender Address . . . . . . . . . . . . . . . . 14 12
     6.2.  DNS Attacks  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Usage Examples (INFORMATIVE)  . . . . . 14
   7.  References . . . . . . . 13
     A.1.  Single Location Domains  . . . . . . . . . . . . . . . . . 13
     A.2.  Bulk Mailing Domains . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . 13
     A.3.  Bulk Mailing Domains with Discardable Mail . . . . . . . . 14
     7.2.  Informative References
     A.4.  Third Party Senders  . . . . . . . . . . . . . . . . . . 15 . 14
   Appendix A. B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 15 14
   Appendix B. C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 14
     C.1.  Changes since -ietf-dkim-ssp-01  . . . . . . . . . . . . . 15
     B.1.
     C.2.  Changes since -ietf-dkim-ssp-00  . . . . . . . . . . . . . 15
     B.2. 16
     C.3.  Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
     B.3.
     C.4.  Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16
     B.4.
     C.5.  Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18 19

1.  Introduction

   DomainKeys Identified Mail (DKIM) defines a mechanism by which email
   messages can be cryptographically signed, permitting a signing domain
   to claim responsibility for the introduction of a message into the
   mail stream.  Message recipients can verify the signature by querying
   the signer's domain directly to retrieve the appropriate public key,
   and thereby confirm that the message was attested to by a party in
   possession of the private key for the signing domain.

   However, the legacy of the Internet is such that not all messages
   will be signed, and signed.  Therefore, the absence of a signature on a message is not an a
   priori indication of forgery.  In fact, during early phases of DKIM
   deployment it must be expected that most messages will remain
   unsigned.  However,  Nevertheless, some domains may choose find it highly desirable to
   advertise that they sign all of their outgoing mail, for example, mail making the
   absence of a valid signature a potential indication of forgery.
   Without a mechanism to protect their brand name.  It is
   highly desirable for such domains do so, the benefits of DKIM are limited to be able to advertise that fact
   to verifiers, and that messages claiming to be from them that do not
   have
   cases in which a valid signature are likely to exists and cannot be forgeries.  This is the topic
   for sender signing practices.

   In the absence of a valid DKIM signature on behalf of the "From"
   address [RFC2822], message verifiers implementing this specification
   MUST determine whether messages from that sender are expected extended to be
   signed, and what
   cases in which signatures are acceptable.  In particular, whether a
   domain signs all outbound email must be made available to the
   verifier.  Without missing or are invalid.  Defining such
   a mechanism, mechanism is the benefit purpose of message signing
   techniques such as DKIM is limited since unsigned messages will
   always need to be considered to be potentially legitimate.  This
   determination is referred to as a Sender Signing Practices check.

   Conceivably, such expressions might be imagined to be extended in the
   future to include information about what hashing algorithms a domain
   uses, what kind of messages might be sent (e.g., bulk vs. personal
   vs. transactional), etc.  Such concerns are out of scope of this
   standard, because they can be expressed in the key record
   ("Selector") with which the signature is verified.  In contrast, this (SSP).

   This specification focuses on information which is relevant in the
   absence of a valid an acceptable signature.  Expressions of signing practice
   which require outside auditing are similarly out of scope for this
   specification because they fall under the purview of reputation and
   accreditation.  Sender Signing Practices can be extended in the
   future to include additional information that a receiver might use as
   input to a processing decision.

   More specifically, this specification defines the SSP Checker, a
   module that retrieves the SSP information for a given domain, and the
   format of the data returned.  An module called the Evaluator combines
   information from DKIM signatures, SSP Checker results, and any other
   data sources it cares to use in order to make a decision regarding
   how the message should be processed.  The Evaluator is explicitly out
   of scope of this document, and is described herein in order to make
   the limits of this specification clear.

   The detailed requirements for Sender Signing Practices are given in
   [I-D.ietf-dkim-ssp-requirements],
   [RFC5016], which the protocol described in this document attempts to
   satisfy.  This document refers extensively to [RFC4871], which should
   be read as a prerequisite to this document.

2.  Language and Terminology

2.1.  Terms Imported from DKIM Signatures Specification

   Some terminology used herein is derived directly from [RFC4871].
   Briefly,

   o  A "Signer" is the agent that signs a message.  In many cases it
      will correspond closely with the original author of the message or
      an agent working on the author's behalf.

   o  A "Verifier" is  "Selectors" describe the agent that verifies a message keys published by checking the
      actual signature a signing domain.
      Signing domains may have multiple Selectors.  Selectors subdivide
      the address space to allow a single sending domain to publish
      multiple keys.

   o  A "Verifier" is the agent that verifies a message by checking
      actual signature(s) in the message header against the message
      itself and using the public key published in the Selector referenced
      by a given signature.

2.2.  Evaluator

   The "Evaluator" is the Alleged Signer. module that makes the ultimate decision on how
   an incoming message should be processed at a given site.  In some
   cases it may be colocated with the Verifier.  The Verifier also looks up Evaluator combines
   information from the
      Sender Signing Practices published by DKIM signature(s) (if any), the domain output of the Originator
      Address if
   SSP Checker, and any other information it cares to consult in order
   to make a processing decision about the message message.  The specification
   of the Evaluator is not correctly signed by out of scope of this document.

2.3.  SSP Checker

   The "SSP Checker" module performs the Alleged
      Originator.

   o  A "Selector" specifies which SSP queries on behalf of the keys published by a signing
      domain should be queried.
   Evaluator.  It is essentially a way of subdividing the address space to allow a single sending domain primary module defined by this document.  The
   input to publish
      multiple keys.

2.2. the SSP Checker is an address extracted from the From header
   field of the message being evaluated; the output is either the Sender
   Signing Practices associated with that domain, or an error code.

2.4.  Valid Signature

   A "Valid Signature" is any signature on a message which correctly
   verifies using the procedure described in section 6.1 of [RFC4871].

2.3.  Originator

2.5.  Alleged Author

   An "Alleged Author" is the Author Address of a message received by an
   Evaluator; it is "alleged" because it has not yet been verified.

2.6.  Author Address

   The "Originator "Author Address" is the an email address in the From header field of
   a message [RFC2822], or if and only if [RFC2822].  If the From header field contains multiple
   addresses, the first address in the From header
   field.

      NON-NORMATIVE RATIONALE:  The alternative option when there are message has multiple addresses in Author Addresses, which may
   potentially cause the From header field Evaluator to perform multiple SSP Checks for a
   given message.

2.7.  Author Domain

   The "Author Domain" is everything to use the value of
      the Sender header field.  This would be closer to the semantics
      indicated in [RFC2822] than using the first address in the From
      header field.  However, the large number of deployed Mail User
      Agents that do not display the Sender header field value argues
      against that.  Multiple addresses in the From header field are
      rare in real life.

      Even when there is only one address in the From header field, this
      address is chosen as the reference address for SSP lookups because
      it represents the author of the message and is more widely
      displayed by Mail User Agents as a result.  The Sender header
      field frequently has other meanings.

2.4.  Originator Domain

   The "Originator Domain" is everything to the right right of the "@" in the
   Originator
   Author Address (excluding the "@" itself).

2.5.  Alleged Signer

2.8.  Author Signature

   An "Alleged Signer" "Author Signature" is any Valid Signature where the identity of
   the signer claimed in a DKIM-
   Signature header field in a user or agent on behalf of which the message received by a Verifier; it is
   "alleged" because it has not yet been verified.

2.6.  Alleged Originator

   An "Alleged Originator" is signed (listed in
   the "i=" tag or its default value from the Originator "d=" tag) matches an
   Author Address of a message
   received by a Verifier; it is "alleged" because it has not yet been
   verified.

2.7. in the message.

2.9.  Sender Signing Practices Record

   A "Sender Signing Practices" (or just "practices") consist Practices Record" consists of a machine-readable
   record published by the domain of the an Alleged
   Originator Author which includes
   information about on whether or not that domain signs all of their email, and whether signatures from third
   parties are sanctioned by the Alleged Originator.

2.8.  Originator Signature

   An "Originator Signature"
   related information.  That record is any Valid Signature where the signing
   address (listed defined in the "i=" tag if present, otherwise its default
   value, consisting detail in section
   Section 3.3.

3.  Operational Description

   The use of the null address, representing an unknown user,
   followed Sender Signing Practices consists of two parts:

      Publication of SSP records by "@", followed author domains wishing to do so

      Lookup of SSP records by an SSP Checker under the value direction of an
      Evaluator.

3.1.  Publication of SSP Records

3.1.1.  DNS Representation

   Sender Signing Practices Records are published using the "d=" tag) matches the
   Originator Address.  If the signing address does not include a local-
   part, then only DNS "TXT"
   resource record type.

      *[[DRAFT DISCUSSION, TO BE DELETED BEFORE PUBLICATION*:  There has
      been considerable discussion on the domains must match; otherwise, DKIM WG mailing list regarding
      the two addresses
   must be identical.

2.9.  Suspicious

   Messages that do not contain relative advantages of TXT and a valid Originator Signature new resource record (RR)
      type.  Many DNS server and which resolver implementations are inconsistent with incapable
      of quickly and easily supporting new resource record types.  For
      this reason, support of TXT records is required whether a Sender Signing Practices check (e.g., are
   received new RR
      type is defined or not.  However, without a Valid Signature and the sender's signing practices
   indicate all messages from the domain are signed) are referred "flag day" on which
      SSP TXT record support is to as
   "Suspicious".  The handling of be withdrawn, such messages support is at the discretion of
   the Verifier or final recipient.  "Suspicious" applies only likely
      to the
   DKIM evaluation of the message; continue indefinitely.  As a Verifier may decide the message
   should be accepted on the basis of other information beyond the scope
   of result, this document.  Conversely, messages not deemed Suspicious may be
   rejected specification defines
      no new RR type for other reasons.

2.10.  Third-Party Signature

   A "Third-Party Signature" SSP.

      Another alternative proposed by P. Hallam-Baker is the publication
      of both a Valid Signature which is not an
   Originator Signature.

2.11.  Verifier Acceptable Third-Party Signature

   A Verifier Acceptable Third-Party Signature is TXT record and, when implementations permit, a Third-Party
   Signature that the Verifier is willing new RR,
      referred to accept as meaningful for XPTR, which gives the message under consideration.  The Verifier may use any criteria
   it deems appropriate for making this determination.

3.  Operation Overview

   Sender Signing Practices checks MUST location from which SSP and
      other policy information relating to a give domain can be based on
      retrieved.  This has the Originator
   Address.  If the message contains advantage of supporting a valid Originator Signature, no
   Sender Signing Practices check need be performed:  the Verifier
   SHOULD NOT look up variety of
      policies in a scalable manner, with better handling of wildcards
      and centralized publication of policy records, with caching
      advantages.  However, the Sender Signing Practices above implementation issues also apply
      to XPTR, and an additional lookup is required to retrieve SSP via
      the message MUST
   NOT be considered Suspicious.

   Verifiers checking messages that do not have at least one valid
   Originator Signature MUST perform a Sender Signing Practices check on XPTR method.  At the domain specified by time of publication of this draft,
      consensus on this proposal was unclear.*]]*

   The RDATA for SSP resource records is textual in format, with
   specific syntax and semantics relating to their role in describing
   sender signing practices.  SSP records follow the Originator Address as tag-list syntax
   described in
   Section 4.4.

   A Sender Signing Practices check produces one section 3.2 of four possible
   results:

   1.  Some messages from this domain are not signed; [RFC4871], including the message MUST
       NOT be considered Suspicious, even in restriction on
   duplicate tags, the absence use of a valid
       signature.  This is the default.

   2.  All messages from this domain are signed.  Messages containing a
       Verifier Acceptable Third-Party Signature white space, and case sensitivity.
   Records not in overall compliance with that syntax MUST NOT be considered
       Suspicious.

          NON-NORMATIVE RATIONALE:  Third-party signatures, since they
          can potentially represent any domain, are considered more
          likely to be abused by attackers seeking ignored
   (considered equivalent to spoof a specific
          address.  It may therefore "NODATA" result), although they MAY cause
   the logging of warning messages via an appropriate system logging
   mechanism.  All syntactically valid tags MUST be desirable for verifiers made available to apply
          other criteria outside
   the scope Evaluator.

3.1.2.  Location of this specification in
          deciding to accept a given third-party signature.  For
          example, SSP Records

   SSP records for a list of known mailing list domains used by
          addresses served by the verifier might be specifically
          considered acceptable third-party signers.

   3.  All valid messages from this domain are signed; published at a location in the domain of domain's
   DNS hierarchy prefixed by "_ssp._domainkey"; e.g., the
       Alleged Originator requests that only messages with valid
       Originator Signatures be considered not Suspicious; Third-Party
       Signatures are irrelevant.  This practice SSP record for
   "example.com" would typically be used
       by domains which send only transactional email (i.e., do not use
       mailing lists and such a "TXT" record that is published at
   "_ssp._domainkey.example.com".

   Sender Signing Practices are likely intended to break signatures) and
       which wish apply to emphasize security over deliverability all mail sent from
   the domain of their
       messages. an Alleged Author.  In order to ensure that SSP applies
   to any hosts within that domain (e.g., www.example.com,
   ftp.example.com, etc.) the absence of a valid Originator Signature, SSP lookup algorithm looks up one level in
   the
       message MUST be considered Suspicious.

   4.  The domain does not exist; the message MUST tree.  For example, mail signed by www.example.com may
   optionally be considered
       Suspicious.

   If covered by the Sender Signing Practices SSP record for the domain does not exist
   but the domain does exist, Verifier systems MUST assume that some
   messages example.com.  This
   prevents administrators from this having to include an SSP record for
   every name within a given domain.

   Normally, a domain are not signed and the message MUST NOT be
   considered Suspicious.

4.  Detailed Description

4.1.  DNS Representation expressing Sender Signing Practices will want to
   do so for both itself and all of its "descendents" (child domains at
   all lower levels).  Domains wishing to do so MUST publish SSP records are published using the DNS TXT
   resource record type.

      NON-NORMATIVE DISCUSSION:  There has been considerable discussion
      on the DKIM WG mailing list regarding
   for the relative advantages of
      TXT domain itself and a new resource record (RR) type.  Many DNS server and
      resolver implementations are incapable of quickly and easily
      supporting new resource record types.  For this reason, support of
      TXT any subdomains.

   Wildcards within a domain publishing SSP records is required whether pose a new RR type particular
   problem.  This is defined or not.
      However, without a "flag day" on which discussed in more detail in Section 5.2.

3.2.  Lookup of SSP TXT record support is
      to be withdrawn, such support is likely to continue indefinitely.
      As a result, this specification defines no new RR type for SSP.

      Another alternative proposed by P. Hallam-Baker Records

   NON-NORMATIVE NOTE:  While the operation of the Evaluator is outside
   the publication scope of both a TXT record and, when implementations permit, a new RR,
      referred this specification, it is generally not worthwhile for
   an Evaluator to as XPTR, which gives the location from which request an SSP and
      other policy information relating to a give domain can be
      retrieved.  This has check when the advantage results of supporting a variety that check
   will not affect the disposition of
      policies the message.  Since the
   information provided by SSP is only relevant in a scalable manner, with better handling of wildcards
      and centralized publication of policy records, with caching
      advantages.  However, the above implementation issues also apply absence of valid
   Author Signature(s), there is little to XPTR, and be gained by performing an additional lookup is required
   SSP check on domains corresponding to retrieve valid Author Signatures.  SSP via
   checks may also be unnecessary when the XPTR method.  At Evaluator has some other
   basis for deciding to process the time of publication message "normally", including, but
   not limited to, the presence of this draft,
      consensus on this proposal was unclear.

   The RDATA a DKIM signature that the Evaluator
   has some basis to trust sufficiently for this purpose.

3.2.1.  SSP resource records is textual in format, with
   specific syntax and semantics relating to their role in describing
   sender signing practices. Checker Results

   A Sender Signing Practices check produces one of four possible
   results for use by the Evaluator:

   1.  The "Tag=Value List" syntax described domain does not exist in
   section 3.2 of [RFC4871] DNS.

   2.  The domain does exist, but no SSP Record is used.  Records present.

   3.  The SSP Record exists, and that value is also returned.

   4.  The DNS information could not in compliance with be determined due to a transient
       error such as "SERVFAIL".

3.2.2.  SSP Lookup Algorithm

   SSP Checkers doing an SSP lookup MUST produce a result that syntax or is
   semantically equivalent to applying the syntax of individual tags described following steps in Section 4.3
   MUST the order
   listed below.  In practice, several of these steps can be ignored (considered equivalent performed
   in parallel in order to a NODATA result) for
   purposes of message disposition, although they MAY cause improve performance.  However,
   implementations SHOULD avoid doing unnecessary DNS lookups.  For the logging
   purposes of warning messages via an appropriate system logging mechanism. this section a "valid SSP records record" is one that is both
   syntactically and semantically correct; in particular, it must match
   the ABNF for a domain are published at "tag-list" and must include a location in the domain's
   DNS hierarchy prefixed by _ssp._domainkey; e.g., the defined "dkim=" tag.

   1.  _Fetch Named SSP record Record._ The SSP Checker MUST query DNS for
   example.com would be a
       TXT record that is published at
   _ssp._domainkey.example.com.

4.2.  Publication of SSP Records

   Sender Signing Practices are intended to apply corresponding to all mail sent from the domain of an Alleged Originator, and to Author Domain prefixed by
       ""_ssp._domainkey."" (note the greatest extent
   possible, to all subdomains trailing dot).  If the result of that domain.  There
       this query is a "NOERROR" response with one or more answers which
       are several cases valid SSP records, return that need record for interpretation by
       the Evaluator; otherwise, continue to be considered in that regard:

   o the next step.

   2.  _Verify Domain Exists._ The domain itself

   o  Subdomains which may or may not be used for email

   o  Hostnames which may or may not be used SSP Checker MUST perform a DNS query
       for email

   o  Other named resource records in a record corresponding to the domain

   o  Multi-level examples Author Domain (with no prefix).
       The type of the above, e.g., a.b.example.com

   o  Non-existent cases, i.e., a subdomain or hostname that does not
      actually exist within the domain

   Normally, a domain expressing Sender Signing Practices will want to
   do so for both itself and all query can be of its "descendents" (child domains and
   hosts, at all lower levels).  Domains wishing any type, since this step is only
       to do so MUST publish
   SSP records as follows:

      Publish an SSP record for determine if the domain itself

      Publish an SSP record for any existing subdomain

   Note that since exists in DNS.  This query MAY
       be done in parallel with the lookup algorithm described below references query made in step 2.  If the
   immediate parent result
       of the alleged originating domain, it this query is not
   necessary to publish an "NXDOMAIN" error, the SSP records Checker MUST return
       an appropriate error to the Evaluator and terminate the
       algorithm.

          NON-NORMATIVE DISCUSSION:  Any resource record type could be
          used for every single-level label within this query since the domain.  This has been done to relieve domain administrators existence of
   the burden a resource record
          of publishing any type will prevent an SSP record "NXDOMAIN" error.  "MX" is a
          reasonable choice for every other this purpose is because this record in type
          is thought to be the
   domain, most common for likely domains, and will
          therefore result in a result which would can be otherwise required.

   Wildcards within a domain, including but not limited to wildcard MX
   records, pose more readily cached
          than a particular problem.  While referencing negative result.

   3.  _Try Parent Domain._ The SSP Checker MUST query DNS for a TXT
       record for the immediate parent domain allows domain, prefixed with
       ""_ssp._domainkey.""  If the discovery result of an SSP record corresponding to
   an unintended immediate-child subdomain, wildcard records apply at
   multiple levels.  For example, if there this query is anything
       other than a wildcard MX record for
   example.com, "NOERROR" response with a valid SSP record, the domain foo.bar.example.com can receive mail through
       algorithm terminates returning a result indicating that no SSP
       record was present.  If the named mail exchanger.  Conversely, SSP "t" tag exists in the existence response
       and any of the record
   makes flags is "s" (indicating it impossible should not apply to tell whether foo.bar.example.com is a
   legitimate name since
       subdomain), the SSP Checker MUST also return a query for that name will not "No SSP Record"
       result.  Otherwise, return an
   NXDOMAIN error.  For that reason, SSP coverage record for subdomains interpretation by the
       Evaluator.

   If any of
   domains containing the queries involved in the Sender Signing Practices Check
   result in a wildcard record is incomplete.

      NON-NORMATIVE NOTE:  Complete "SERVFAIL" error response, the SSP Checker MUST return
   that information to the Evaluator; possible actions include queuing
   the message or returning an SMTP error indicating a temporary
   failure.

3.3.  SSP coverage of domains containing
      (or where any parent contains) wildcards generally cannot be
      guaranteed.

4.3. Record Syntax

   SSP records follow Records MUST match the "tag=value" "tag-list" syntax described defined in section 3.2 of [RFC4871].
   The SSP record syntax is a tag-list as defined in that
   section, including the restriction on duplicate tags, the use of
   white space, and case sensitivity.

   Tags specific tags used in SSP records are as follows. described below.
   Unrecognized tags MUST be ignored.  In the ABNF below, the FWS token is inherited from
   [RFC2822] with the exclusion of obs-FWS.  The ALPHA and DIGIT tokens
   are imported from [RFC4234].

   dkim=  Outbound signing practices for the domain (plain-text;
      REQUIRED).  Possible values are as follows:

      unknown  The domain may sign some none, some, or all email.

      all  All mail from the domain is signed; unsigned email MUST be
         considered Suspicious.  The domain may send messages through
         agents that may modify and re-sign messages, so email signed with a Verifier Acceptable Third-Party Signature SHOULD NOT be
         considered Suspicious.

      strict an Author Signature.

      discardable  All mail from the domain is signed; messages lacking signed with an Author
         Signature.  Furthermore, if a message arrives without a valid Originator
         Author Signature MUST be considered Suspicious.  The due to modification in transit, submission via
         a path without access to a signing key, or other reason, the
         domain does not expect encourages the recipient(s) to send messages through agents that may
         modify and re-sign messages. discard it.

         NON-NORMATIVE RATIONALE:  Strict DISCUSSION:  Sender signing practices may of
         "discardable" would be used by
            entities which send usually inappropriate for domains of end
         users, because of the potential for mailing lists and similar
         agents to modify messages in such a way as to render the
         signature invalid.  Domains sending mail that is expected to
         pass with no significant modification to the recipient, such as
         domains sending only transactional email to individual
            addresses and which messages, are willing appropriate
         places to accept consider the consequence publication of
            having some mail which is re-signed appear suspicious in
            return a "discardable" practice.
         See [RFC5016] section 5.3 and Appendix A for additional control over their addresses.  Strict
            practices may also be used by entities which do not send
            (and therefore do not sign) any email. further
         discussion.

      ABNF:

   ssp-dkim-tag   = "dkim" [FWS] *WSP "=" [FWS] *WSP ("unknown" /
                     "all" / "strict")

   handling=  Non-compliant message handling request for the domain
      (plain-text; OPTIONAL).  Possible values are "discardable")

   t= Flags, represented as follows:

      process  Messages which a colon-separated list of names (plain-text;
      OPTIONAL, default is that no flags are Suspicious from this domain SHOULD be
         processed by the verifier, although set).  Flag values are:

      s  The signing practices apply only to the SSP failure MAY named domain, and not
         to subdomains.

      ABNF:

   ssp-t-tag       = %x75 *WSP "=" *WSP ssp-t-tag-flag
                     0*( *WSP ":" *WSP ssp-t-tag-flag )
   ssp-t-tag-flag  = "s" / hyphenated-word
                           ; for future extension
   hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
                     (ALPHA / DIGIT) ]
      Unrecognized flags MUST be
         considered included in subsequent evaluation of the message.  This result that is provided
      to the default value.

      deny  Messages which are Suspicious from this domain MAY be
         rejected, bounced, or otherwise not delivered at the option of
         the verifier.

            NON-NORMATIVE EXPLANATION:  The "deny" practice Evaluator.

4.  IANA Considerations

   IANA is intended
            for use by domains that value security over deliverability.
            For example, a domain used by a financial institution to
            send transactional email, which signs all of its messages,
            might consider their concern about phishing messages
            purporting to come from their domain to be higher than their
            concern about some some legitimate messages not being
            delivered.  The "handling=deny" practice allows them requested to
            express that concern in a way that can be acted upon by
            verifiers, if they so choose.

      ABNF:

        ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" /
                               "deny")

   t= Flags, represented as create a colon-separated list of names (plain-text;
      OPTIONAL, default is that no flags are set).  Flag values are:

      y  The domain is testing signing practices, "DKIM selector name" registry and the Verifier
         SHOULD NOT consider a message suspicious based on the record.

      s  The signing practices apply only to
   reserve the named domain, selector name ""_ssp"" to avoid confusion between DKIM
   key records and not SSP records.

   *<<< Needs to subdomains.

      ABNF:

        ssp-t-tag     = %x75 [FWS] "=" [FWS] ssp-t-tag-flag
                           0*( [FWS] ":" [FWS] ssp-t-tag-flag )
        ssp-t-tag-flag = "y" / "s" / hyphenated-word
                           ; for future extension
        hyphenated-word =  ALPHA [ *(ALPHA / DIGIT / "-")
                                (ALPHA / DIGIT) ]

      Unrecognized flags MUST be ignored.

4.4. updated to be more complete; see 4871 for examples
   >>>*

5.  Security Considerations

   Security considerations in the Sender Signing Practices Check Procedure

   Verifiers MUST produce a result that is semantically equivalent are mostly
   related to
   applying attempts on the following steps part of malicious senders to represent
   themselves as other authors, often in an attempt to defraud either
   the order listed.  In practice,
   several of these steps can recipient or an Alleged Author.

   Additional security considerations regarding Sender Signing Practices
   may be performed in parallel found in order to
   improve performance.

   1.   If a valid Originator Signature exists, the message is not
        Suspicious, and DKIM threat analysis [RFC4686].

      *<<<THIS SECTION IS NOT COMPLETE.>>>*

5.1.  DNS Attacks

   An attacker might attack the algorithm terminates.

   2.   The Verifier MUST query DNS for a TXT record corresponding infrastructure in an attempt to
        the Originator Domain prefixed by "_ssp._domainkey.".  If the
        result of this query
   impersonate SSP records.  However, such an attacker is a NOERROR response with one or more
        answers which are syntactically-valid SSP responses, proceed likely to
        step 7.

   3.   The Verifier MUST query DNS for an MX
   attack at a higher level, e.g., redirecting "A" or "MX" record corresponding
   lookups in order to capture traffic that was legitimately intended
   for the Originator Domain (with no prefix).  This query is made only
        to check target domain.  Domains concerned about this should use
   DNSSEC [RFC4033].

   Because SSP operates within the existence framework of the domain name and MAY be done in
        parallel with legacy e-mail
   system, the query made default result in step 2.  If the result absence of this
        query is an NXDOMAIN error, the message is Suspicious and the
        algorithm terminates.

           NON-NORMATIVE DISCUSSION:  Any resource SSP record type could be
           used for this query since is that
   the existence of a resource record
           of any type will prevent an NXDOMAIN error.  The choice domain does not sign all of MX
           for this purpose is because this record type its messages.  It is thought to be
           the most common for likely domains, and will therefore result
           in
   important that the SSP Checker distinguish a result which DNS failure such as
   SERVFAIL from other DNS errors so that appropriate actions can be more readily cached than
   taken.

5.2.  DNS Wildcards

   Wildcards within a negative
           result.

   4.   If domain publishing SSP records, including but not
   limited to wildcard "MX" records, pose a particular problem.  While
   referencing the immediate parent of the Originator Domain is a top-level domain (a domain consisting allows the discovery of a single element such as "com",
        "us", or "jp"), then the message is not Suspicious (because no an
   SSP record was found) and the algorithm terminates.  The
        verifier MAY also compare the parent domain against a locally-
        maintained list of known address suffixes (e.g., .co.uk) and
        terminate the algorithm with a not Suspicious result if the
        parent domain matches corresponding to an entry on the list.

   5.   The Verifier MUST query DNS for unintended immediate-child subdomain,
   wildcard records apply at multiple levels.  For example, if there is
   a TXT wildcard "MX" record for "example.com", the immediate
        parent domain, prefixed with "_ssp._domainkey."  If the result
        of this query is a NOERROR response with one or more answers
        which are syntactically-valid SSP responses, proceed to step 6.
        Otherwise, the message is not Suspicious and the algorithm
        terminates.

   6.   If domain
   "foo.bar.example.com" can receive mail through the SSP "t" tag exists in named mail
   exchanger.  Conversely, the response and any existence of the flags
        is "s" (indicating record makes it should not apply
   impossible to a subdomain), the
        message tell whether "foo.bar.example.com" is a legitimate name
   since a query for that name will not Suspicious and the algorithm terminates.

   7.   If the return an "NXDOMAIN" error.  For
   that reason, SSP "t" tag exists in the response and any coverage for subdomains of the flags
        is "y" (indicating testing), the message domains containing a
   wildcard record is not Suspicious and
        the algorithm terminates.

   8.   If the value of the incomplete.

      NON-NORMATIVE NOTE:  Complete SSP "dkim" tag is "unknown", the message is
        not Suspicious and the algorithm terminates.

   9.   If the value coverage of the SSP "dkim" tag is "all", and one or more
        Verifier Acceptable Third-Party Signatures are present on the
        message, the message is not Suspicious and the algorithm
        terminates.

   10.  The message is Suspicious and the algorithm terminates.

   If domains containing
      (or where any of the queries involved in the Sender Signing Practices Check
   result parent contains) wildcards generally cannot be
      guaranteed.

6.  References

6.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

6.2.  Informative References

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC5016]  Thomas, M., "Requirements for a SERVFAIL error response, the verifier MAY either queue
   the message or return an SMTP error indicating a temporary failure.

5.  IANA Considerations

   IANA is requested DomainKeys Identified Mail
              (DKIM) Signing Practices Protocol", RFC 5016,
              October 2007.

Appendix A.  Usage Examples (INFORMATIVE)

   These examples are intended to create illustrate typical uses of SSP.  They
   are not intended to be exhaustive, nor to apply to every domain or
   mail system's individual situation.

A.1.  Single Location Domains

   A common mail system configuration handles all of a "DKIM selector name" registry domain's users'
   incoming and to
   reserve outgoing mail through a single MTA or cluster of MTAs.
   In that case, the selector name "_ssp" MTA(s) can be configured to avoid confusion between DKIM key
   records and sign outgoing mail with
   an Author Signature.

   In this situation it might be appropriate to publish an SSP records.

6.  Security Considerations

   Security considerations in record
   for the Sender Signing Practices domain containing "all", depending on whether the users also
   send mail through other MTAs that do not apply an Author Signature.
   Such MTAs could include MTAs at hotels or hotspot networks used by
   travelling users, or web sites that provide "mail an article"
   features.

   Domain managers are mostly
   related advised to attempts on consider the part of malicious senders to represent
   themselves as other senders, often ways that mail processing
   can modify messages in ways that will invalidate an attempt to defraud either
   the recipient existing DKIM
   signature, such as mailing lists, courtesy forwarders, and other
   paths that could add or modify headers, or modify the Alleged Originator.

   Additional security considerations regarding Sender Signing Practices
   may be found in message body.
   In that case, if the modifications invalidate the DKIM threat analysis [RFC4686].

6.1.  Fraudulent Sender Address

   [[Assuming 3rd party signature is based on Sender header field]] If signature,
   recipient MTAs will consider the Sender Signing Practices sanction third-party signing, mail not to have an
   attacker can create Author
   Signature, even though the signature was present when the mail was
   originally sent.

A.2.  Bulk Mailing Domains

   Another common configuration uses a message domain solely for bulk or
   broadcast mail, with no individual human users, again typically
   sending all the mail through a From header field single MTA or cluster of MTAs that can
   apply an
   arbitrary sender and a legitimately signed Sender header field

6.2.  DNS Attacks

   An attacker might attack Author Signature.  In this case, the DNS infrastructure domain's management can
   be confident that all of its outgoing mail will be sent through the
   signing MTA.  Lacking individual users, the domain is unlikely to
   participate in an attempt mailing lists, but could still send mail through other
   paths that might invalidate signatures.

   Domain owners often use specialist mailing providers to
   impersonate SSP records.  However, such an attacker is more likely send their
   bulk mail.  In that case, the mailing provider needs access to
   attack at a higher level, e.g., redirecting A or MX record lookups
   suitable signing key in order to capture traffic that was legitimately intended apply an Author Signature.  One
   possible route would be for the
   target domain.  Domains concerned about this should use DNSSEC
   [RFC4033].

   Because SSP operates within domain owner to generate the key and
   give it to the mailing provider.  Another would be for the domain to
   delegate a subdomain to the framework of mailing provider, for example,
   bigbank.example might delegate email.bigbank.example to such a
   provider.  In that case, the legacy e-mail
   system, provider can generate the default result keys and DKIM
   DNS records itself and use the subdomain in the absence of an SSP record is that Author Address in the
   mail.

A.3.  Bulk Mailing Domains with Discardable Mail

   In some cases, a domain does not might sign all of its messages.  Therefore, outgoing mail with an
   Author Signature, but prefers that recipient systems discard mail
   without a DNS
   attack which valid Author Signature to avoid confusion from mail sent
   from sources that do not apply an Author Signature.  (This latter
   kind of mail is successful in suppressing the sometimes loosely called "forgeries".)  In that case,
   it may be appropriate to publish an SSP response record containing
   "discardable".  Note that a domain SHOULD NOT publish a "discardable"
   record if it wishes to maximize the likelihood that mail from the
   verifier
   domain is sufficient to delivered, since it could cause some fraction of the mail
   the verifier domain sends to see unsigned messages
   as non-suspicious, even when that is not intended by be discarded.

   As a special case, if a domain sends no mail at all, it can safely
   publish a "discardable" SSP record, since any mail with an author
   address in the alleged
   originating domain.

7.  References

7.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for domain is a forgery.

A.4.  Third Party Senders

   Another common use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

7.2.  Informative References

   [I-D.ietf-dkim-ssp-requirements]
              Thomas, M., "Requirements case is for a DKIM Signing Practices
              Protocol", draft-ietf-dkim-ssp-requirements-05 (work third party to enter into an
   agreement whereby that third party will send bulk or other mail on
   behalf of a designated author domain, using that domain in
              progress), April 2007.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., the
   RFC2822 From:  or other headers.  Due to the many and S.
              Rose, "DNS Security Introduction varied
   complexities of such agreements, third party signing is not addressed
   in this specification.  The authors anticipate that as mail systems
   gain experience with DKIM, it will become possible to codify best
   practices of this and Requirements",
              RFC 4033, March 2005.

   [RFC4686]  Fenton, J., "Analysis other usages of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006. DKIM.

Appendix A. B.  Acknowledgements

   The authors wish to thank many members of the ietf-dkim mailing list,
   in particular Arvel Hathcock and Eliot Lear, list
   for valuable suggestions and constructive criticism of earlier
   versions of this draft.

   This draft incorporates content from a parallel "DKIM Author Signing
   Policies" document edited by John Levine.  The authors appreciate
   this contribution.

Appendix B. C.  Change Log

B.1.

   *NOTE TO RFC EDITOR:  This section may be removed upon publication of
   this document as an RFC.*

C.1.  Changes since -ietf-dkim-ssp-01

   o  Reworded introduction for clarity.

   o  Various definition clarifications.

   o  Changed names of practices to unknown, all, and discardable.

   o  Removed normative language mandating use of SSP in particular
      situations (issue 1538).

   o  Clarified possible confusion over handling of syntax errors.

   o  Removed normative language from Introduction (issue 1538).

   o  Changed "Originator" to "Author" throughout (issue 1529).

   o  Removed all references to Third-Party Signatures (issues 1512,
      1521).

   o  Removed all mention of "Suspicious" (issues 1528, 1530).

   o  Removed "t=y" (testing) flag (issue 1540).

   o  Removed "handling" tag (issue 1513).

   o  Broke up the "Sender Signing Practices Check Procedure" into two
      algorithms:  fetching the SSP record and interpretation thereof
      (issues 1531, 1535; partially addresses issue 1520).
      Interpretation is now the responsibility of the Evaluator.

   o  Document restructuring for better flow and remove redundancies
      (some may address issue 1523, but I'm not sure I understand that
      issue completely; also issues 1532, 1537).

   o  Removed all mention of how this interacts with users, even though
      it makes parts of the document harder to understand (issue 1526).

   o  Introduced the concepts of "SSP Checker" and "Evaluator".

   o  Multiple author case now handled my separate invocations of SSP
      checker by Evaluator (issue 1525).

   o  Removed check to avoid querying top-level domains.

   o  Changed ABNF use of whitespace from [FWS] to *WSP (partially
      addresses issue 1543).

C.2.  Changes since -ietf-dkim-ssp-00

   o  Clarified Operation Overview and eliminated use of Legitimate as
      the counterpart of Suspicious since the words have different
      meanings.

   o  Improved discussion (courtesy of Arvel Hathcock) of the use of TXT
      records in DNS vs. a new RR type.

   o  Clarified publication rules for multilevel names.

   o  Better description of overall record syntax, in particular that
      records with unknown tags are considered syntactically correct.

   o  Clarified Sender Signing Practices Check Procedure, primarily by
      use of new term Originator Author Domain.

   o  Eliminated section "Third-Party Signatures and Mailing Lists" that
      is better included in the DKIM overview document.

   o  Added "handling" tag to express alleged sending domain's
      preference about handling of Suspicious messages.

   o  Clarified handling of SERVFAIL error in SSP check.

   o  Replaced "entity" with "domain", since with the removal of user-
      granularity SSP, the only entities having sender signing policies
      are domains.

B.2.

C.3.  Changes since -allman-ssp-02

   o  Removed user-granularity SSP and u= tag.

   o  Replaced DKIMP resource record with a TXT record.

   o  Changed name of the primary tag from "p" to "dkim".

   o  Replaced lookup algorithm with one which traverses upward at most
      one level.

   o  Added description of records which must be published, and effect
      of wildcard records within the domain, on SSP.

B.3.

C.4.  Changes since -allman-ssp-01

   o  Changed term "Sender Signing Policy" to "Sender Signing
      Practices".

   o  Changed query methodology to use a separate DNS resource record
      type, DKIMP.

   o  Changed tag values from SPF-like symbols to words.

   o  User level policies now default to that of the domain if not
      specified.

   o  Removed the "Compliance" section since we're still not clear on
      what goes here.

   o  Changed the "parent domain" policy to only search up one level
      (assumes that subdomains will publish SSP records if appropriate).

   o  Added detailed description of SSP check procedure.

B.4.

C.5.  Changes since -allman-ssp-00

   From a "diff" perspective, the changes are extensive.  Semantically,
   the changes are:

   o  Added section on "Third-Party Signatures and Mailing Lists"

   o  Added "Compliance" (transferred from -base document).  I'm not
      clear on what needs to be done here.

   o  Extensive restructuring.

Authors' Addresses

   Eric Allman
   Sendmail, Inc.
   6475 Christie Ave, Suite 350
   Emeryville, CA  94608
   USA

   Phone:  +1 510 594 5501
   Email:  eric+dkim@sendmail.org
   URI:

   Mark Delany
   Yahoo! Inc.
   701 First Avenue
   Sunnyvale, CA  94089
   USA

   Phone:  +1 408 349 6831
   Email:  markd+dkim@yahoo-inc.com
   URI:

   Jim Fenton
   Cisco Systems, Inc.
   MS SJ-9/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706
   USA

   Phone:  +1 408 526 5914
   Email:  fenton@cisco.com
   URI:

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).