draft-ietf-dkim-ssp-01.txt   draft-ietf-dkim-ssp-02.txt 
DKIM Working Group E. Allman DKIM Working Group E. Allman
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Intended status: Standards Track M. Delany Intended status: Standards Track M. Delany
Expires: March 20, 2008 Yahoo! Inc. Expires: August 4, 2008 Yahoo! Inc.
J. Fenton J. Fenton
Cisco Systems, Inc. Cisco Systems, Inc.
September 17, 2007 February 1, 2008
DKIM Sender Signing Practices DKIM Sender Signing Practices
draft-ietf-dkim-ssp-01 draft-ietf-dkim-ssp-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 20, 2008. This Internet-Draft will expire on August 4, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and key server technology to permit verification of the source and
contents of messages by either Mail Transport Agents (MTAs) or Mail contents of messages by either Mail Transport Agents (MTAs) or Mail
User Agents (MUAs). The primary DKIM protocol is described in User Agents (MUAs). The primary DKIM protocol is described in
[RFC4871]. [RFC4871].
This document describes the records that senders may use to advertise This document describes the records that authors' domains can use to
how they sign their outgoing mail, and how verifiers should access advertise their practices regarding signing their outgoing mail, and
and interpret those results. how other hosts can access, parse and interpret those records.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
(Unresolved Issues/To Be Done) (Unresolved Issues/To Be Done)
Need to consider handling of multiple responses to a DNS query for o Need to consider handling of multiple responses to a DNS query for
the SSP record. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4
2.1. Terms Imported from DKIM Signatures Specification . . . . 5 2.1. Terms Imported from DKIM Signatures Specification . . . . 5
2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5 2.3. SSP Checker . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Originator Domain . . . . . . . . . . . . . . . . . . . . 6 2.4. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5
2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 5
2.6. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6 2.6. Author Address . . . . . . . . . . . . . . . . . . . . . . 6
2.7. Sender Signing Practices . . . . . . . . . . . . . . . . . 6 2.7. Author Domain . . . . . . . . . . . . . . . . . . . . . . 6
2.8. Originator Signature . . . . . . . . . . . . . . . . . . . 6 2.8. Author Signature . . . . . . . . . . . . . . . . . . . . . 6
2.9. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6 2.9. Sender Signing Practices Record . . . . . . . . . . . . . 6
2.10. Third-Party Signature . . . . . . . . . . . . . . . . . . 7 3. Operational Description . . . . . . . . . . . . . . . . . . . 6
2.11. Verifier Acceptable Third-Party Signature . . . . . . . . 7 3.1. Publication of SSP Records . . . . . . . . . . . . . . . . 6
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Lookup of SSP Records . . . . . . . . . . . . . . . . . . 8
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8 3.3. SSP Record Syntax . . . . . . . . . . . . . . . . . . . . 9
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10 5.1. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12 5.2. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.1. Single Location Domains . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 14
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
B.1. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 14
B.2. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16 C.1. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 15
B.3. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16 C.2. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 16
B.4. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16 C.3. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
C.4. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16
C.5. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key, the signer's domain directly to retrieve the appropriate public key,
and thereby confirm that the message was attested to by a party in and thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain. possession of the private key for the signing domain.
However, the legacy of the Internet is such that not all messages However, the legacy of the Internet is such that not all messages
will be signed, and the absence of a signature on a message is not an will be signed. Therefore, the absence of a signature is not an a
a priori indication of forgery. In fact, during early phases of priori indication of forgery. In fact, during early phases of DKIM
deployment it must be expected that most messages will remain deployment it must be expected that most messages will remain
unsigned. However, some domains may choose to sign all of their unsigned. Nevertheless, some domains may find it highly desirable to
outgoing mail, for example, to protect their brand name. It is advertise that they sign all of their outgoing mail making the
highly desirable for such domains to be able to advertise that fact absence of a valid signature a potential indication of forgery.
to verifiers, and that messages claiming to be from them that do not Without a mechanism to do so, the benefits of DKIM are limited to
have a valid signature are likely to be forgeries. This is the topic cases in which a valid signature exists and cannot be extended to
for sender signing practices. cases in which signatures are missing or are invalid. Defining such
a mechanism is the purpose of Sender Signing Practices (SSP).
In the absence of a valid DKIM signature on behalf of the "From" This specification focuses on information which is relevant in the
address [RFC2822], message verifiers implementing this specification absence of an acceptable signature. Expressions of signing practice
MUST determine whether messages from that sender are expected to be which require outside auditing are out of scope for this
signed, and what signatures are acceptable. In particular, whether a specification because they fall under the purview of reputation and
domain signs all outbound email must be made available to the accreditation. Sender Signing Practices can be extended in the
verifier. Without such a mechanism, the benefit of message signing future to include additional information that a receiver might use as
techniques such as DKIM is limited since unsigned messages will input to a processing decision.
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 More specifically, this specification defines the SSP Checker, a
future to include information about what hashing algorithms a domain module that retrieves the SSP information for a given domain, and the
uses, what kind of messages might be sent (e.g., bulk vs. personal format of the data returned. An module called the Evaluator combines
vs. transactional), etc. Such concerns are out of scope of this information from DKIM signatures, SSP Checker results, and any other
standard, because they can be expressed in the key record data sources it cares to use in order to make a decision regarding
("Selector") with which the signature is verified. In contrast, this how the message should be processed. The Evaluator is explicitly out
specification focuses on information which is relevant in the absence of scope of this document, and is described herein in order to make
of a valid signature. Expressions of signing practice which require the limits of this specification clear.
outside auditing are similarly out of scope for this specification
because they fall under the purview of reputation and accreditation.
The detailed requirements for Sender Signing Practices are given in The detailed requirements for Sender Signing Practices are given in
[I-D.ietf-dkim-ssp-requirements], which the protocol described in [RFC5016], which the protocol described in this document attempts to
this document attempts to satisfy. This document refers extensively satisfy. This document refers extensively to [RFC4871], which should
to [RFC4871], which should be read as a prerequisite to this be read as a prerequisite to this document.
document.
2. Language and Terminology 2. Language and Terminology
2.1. Terms Imported from DKIM Signatures Specification 2.1. Terms Imported from DKIM Signatures Specification
Some terminology used herein is derived directly from [RFC4871]. Some terminology used herein is derived directly from [RFC4871].
Briefly, Briefly,
o A "Signer" is the agent that signs a message. In many cases it 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 will correspond closely with the original author of the message or
an agent working on the author's behalf. an agent working on the author's behalf.
o A "Verifier" is the agent that verifies a message by checking the o "Selectors" describe the keys published by a signing domain.
actual signature against the message itself and the public key Signing domains may have multiple Selectors. Selectors subdivide
published by the Alleged Signer. The Verifier also looks up the
Sender Signing Practices published by the domain of the Originator
Address if the message is not correctly signed by the Alleged
Originator.
o A "Selector" specifies which of the keys published by a signing
domain should be queried. It is essentially a way of subdividing
the address space to allow a single sending domain to publish the address space to allow a single sending domain to publish
multiple keys. multiple keys.
2.2. Valid Signature o A "Verifier" is the agent that verifies a message by checking
actual signature(s) in the message header against the message
A "Valid Signature" is any signature on a message which correctly itself using the public key published in the Selector referenced
verifies using the procedure described in section 6.1 of [RFC4871]. by a given signature.
2.3. Originator Address
The "Originator Address" is the email address in the From header
field of a message [RFC2822], or if and only 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
multiple addresses in the From header field is 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 of the "@" in the
Originator Address (excluding the "@" itself).
2.5. Alleged Signer
An "Alleged Signer" is the identity of the signer claimed in a DKIM-
Signature header field in a message received by a Verifier; it is
"alleged" because it has not yet been verified.
2.6. Alleged Originator
An "Alleged Originator" is the Originator Address of a message
received by a Verifier; it is "alleged" because it has not yet been
verified.
2.7. Sender Signing Practices 2.2. Evaluator
"Sender Signing Practices" (or just "practices") consist of a The "Evaluator" is the module that makes the ultimate decision on how
machine-readable record published by the domain of the Alleged an incoming message should be processed at a given site. In some
Originator which includes information about whether or not that cases it may be colocated with the Verifier. The Evaluator combines
domain signs all of their email, and whether signatures from third information from the DKIM signature(s) (if any), the output of the
parties are sanctioned by the Alleged Originator. SSP Checker, and any other information it cares to consult in order
to make a processing decision about the message. The specification
of the Evaluator is out of scope of this document.
2.8. Originator Signature 2.3. SSP Checker
An "Originator Signature" is any Valid Signature where the signing The "SSP Checker" module performs the SSP queries on behalf of the
address (listed in the "i=" tag if present, otherwise its default Evaluator. It is the primary module defined by this document. The
value, consisting of the null address, representing an unknown user, input to the SSP Checker is an address extracted from the From header
followed by "@", followed by the value of the "d=" tag) matches the field of the message being evaluated; the output is either the Sender
Originator Address. If the signing address does not include a local- Signing Practices associated with that domain, or an error code.
part, then only the domains must match; otherwise, the two addresses
must be identical.
2.9. Suspicious 2.4. Valid Signature
Messages that do not contain a valid Originator Signature and which A "Valid Signature" is any signature on a message which correctly
are inconsistent with a Sender Signing Practices check (e.g., are verifies using the procedure described in section 6.1 of [RFC4871].
received without a Valid Signature and the sender's signing practices
indicate all messages from the domain are signed) are referred to as
"Suspicious". The handling of such messages is at the discretion of
the Verifier or final recipient. "Suspicious" applies only to the
DKIM evaluation of the message; a Verifier may decide the message
should be accepted on the basis of other information beyond the scope
of this document. Conversely, messages not deemed Suspicious may be
rejected for other reasons.
2.10. Third-Party Signature 2.5. Alleged Author
A "Third-Party Signature" is a Valid Signature which is not an An "Alleged Author" is the Author Address of a message received by an
Originator Signature. Evaluator; it is "alleged" because it has not yet been verified.
2.11. Verifier Acceptable Third-Party Signature 2.6. Author Address
A Verifier Acceptable Third-Party Signature is a Third-Party The "Author Address" is an email address in the From header field of
Signature that the Verifier is willing to accept as meaningful for a message [RFC2822]. If the From header field contains multiple
the message under consideration. The Verifier may use any criteria addresses, the message has multiple Author Addresses, which may
it deems appropriate for making this determination. potentially cause the Evaluator to perform multiple SSP Checks for a
given message.
3. Operation Overview 2.7. Author Domain
Sender Signing Practices checks MUST be based on the Originator The "Author Domain" is everything to the right of the "@" in the
Address. If the message contains a valid Originator Signature, no Author Address (excluding the "@" itself).
Sender Signing Practices check need be performed: the Verifier
SHOULD NOT look up the Sender Signing Practices and the message MUST
NOT be considered Suspicious.
Verifiers checking messages that do not have at least one valid 2.8. Author Signature
Originator Signature MUST perform a Sender Signing Practices check on
the domain specified by the Originator Address as described in
Section 4.4.
A Sender Signing Practices check produces one of four possible An "Author Signature" is any Valid Signature where the identity of
results: the user or agent on behalf of which the message is signed (listed in
the "i=" tag or its default value from the "d=" tag) matches an
Author Address in the message.
1. Some messages from this domain are not signed; the message MUST 2.9. Sender Signing Practices Record
NOT be considered Suspicious, even in the absence of a valid
signature. This is the default.
2. All messages from this domain are signed. Messages containing a A "Sender Signing Practices Record" consists of a machine-readable
Verifier Acceptable Third-Party Signature MUST NOT be considered record published by the domain of an Alleged Author which includes
Suspicious. information on whether that domain signs all of their email, and
related information. That record is defined in detail in section
Section 3.3.
NON-NORMATIVE RATIONALE: Third-party signatures, since they 3. Operational Description
can potentially represent any domain, are considered more
likely to be abused by attackers seeking to spoof a specific
address. It may therefore be desirable for verifiers to apply
other criteria outside the scope of this specification in
deciding to accept a given third-party signature. For
example, 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; the domain of the The use of Sender Signing Practices consists of two parts:
Alleged Originator requests that only messages with valid
Originator Signatures be considered not Suspicious; Third-Party
Signatures are irrelevant. This practice would typically be used
by domains which send only transactional email (i.e., do not use
mailing lists and such that are likely to break signatures) and
which wish to emphasize security over deliverability of their
messages. In the absence of a valid Originator Signature, the
message MUST be considered Suspicious.
4. The domain does not exist; the message MUST be considered Publication of SSP records by author domains wishing to do so
Suspicious.
If the Sender Signing Practices record for the domain does not exist Lookup of SSP records by an SSP Checker under the direction of an
but the domain does exist, Verifier systems MUST assume that some Evaluator.
messages from this domain are not signed and the message MUST NOT be
considered Suspicious.
4. Detailed Description 3.1. Publication of SSP Records
4.1. DNS Representation 3.1.1. DNS Representation
Sender Signing Practices records are published using the DNS TXT Sender Signing Practices Records are published using the DNS "TXT"
resource record type. resource record type.
NON-NORMATIVE DISCUSSION: There has been considerable discussion *[[DRAFT DISCUSSION, TO BE DELETED BEFORE PUBLICATION*: There has
on the DKIM WG mailing list regarding the relative advantages of been considerable discussion on the DKIM WG mailing list regarding
TXT and a new resource record (RR) type. Many DNS server and the relative advantages of TXT and a new resource record (RR)
resolver implementations are incapable of quickly and easily type. Many DNS server and resolver implementations are incapable
supporting new resource record types. For this reason, support of of quickly and easily supporting new resource record types. For
TXT records is required whether a new RR type is defined or not. this reason, support of TXT records is required whether a new RR
However, without a "flag day" on which SSP TXT record support is type is defined or not. However, without a "flag day" on which
to be withdrawn, such support is likely to continue indefinitely. SSP TXT record support is to be withdrawn, such support is likely
As a result, this specification defines no new RR type for SSP. to continue indefinitely. As a result, this specification defines
no new RR type for SSP.
Another alternative proposed by P. Hallam-Baker is the publication Another alternative proposed by P. Hallam-Baker is the publication
of both a TXT record and, when implementations permit, a new RR, of both a TXT record and, when implementations permit, a new RR,
referred to as XPTR, which gives the location from which SSP and referred to as XPTR, which gives the location from which SSP and
other policy information relating to a give domain can be other policy information relating to a give domain can be
retrieved. This has the advantage of supporting a variety of retrieved. This has the advantage of supporting a variety of
policies in a scalable manner, with better handling of wildcards policies in a scalable manner, with better handling of wildcards
and centralized publication of policy records, with caching and centralized publication of policy records, with caching
advantages. However, the above implementation issues also apply advantages. However, the above implementation issues also apply
to XPTR, and an additional lookup is required to retrieve SSP via to XPTR, and an additional lookup is required to retrieve SSP via
the XPTR method. At the time of publication of this draft, the XPTR method. At the time of publication of this draft,
consensus on this proposal was unclear. consensus on this proposal was unclear.*]]*
The RDATA for SSP resource records is textual in format, with The RDATA for SSP resource records is textual in format, with
specific syntax and semantics relating to their role in describing specific syntax and semantics relating to their role in describing
sender signing practices. The "Tag=Value List" syntax described in sender signing practices. SSP records follow the tag-list syntax
section 3.2 of [RFC4871] is used. Records not in compliance with described in section 3.2 of [RFC4871], including the restriction on
that syntax or the syntax of individual tags described in Section 4.3 duplicate tags, the use of white space, and case sensitivity.
MUST be ignored (considered equivalent to a NODATA result) for Records not in overall compliance with that syntax MUST be ignored
purposes of message disposition, although they MAY cause the logging (considered equivalent to a "NODATA" result), although they MAY cause
of warning messages via an appropriate system logging mechanism. the logging of warning messages via an appropriate system logging
mechanism. All syntactically valid tags MUST be made available to
the Evaluator.
SSP records for a domain are published at a location in the domain's 3.1.2. Location of SSP Records
DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for
example.com would be a TXT record that is published at
_ssp._domainkey.example.com.
4.2. Publication of SSP Records SSP records for a domain are published at a location in the domain's
DNS hierarchy prefixed by "_ssp._domainkey"; e.g., the SSP record for
"example.com" would be a "TXT" record that is published at
"_ssp._domainkey.example.com".
Sender Signing Practices are intended to apply to all mail sent from Sender Signing Practices are intended to apply to all mail sent from
the domain of an Alleged Originator, and to the greatest extent the domain of an Alleged Author. In order to ensure that SSP applies
possible, to all subdomains of that domain. There are several cases to any hosts within that domain (e.g., www.example.com,
that need to be considered in that regard: ftp.example.com, etc.) the SSP lookup algorithm looks up one level in
the domain tree. For example, mail signed by www.example.com may
o The domain itself optionally be covered by the SSP record for example.com. This
prevents administrators from having to include an SSP record for
o Subdomains which may or may not be used for email every name within a given domain.
o Hostnames which may or may not be used for email Normally, a domain 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
for the domain itself and any subdomains.
o Other named resource records in the domain Wildcards within a domain publishing SSP records pose a particular
problem. This is discussed in more detail in Section 5.2.
o Multi-level examples of the above, e.g., a.b.example.com 3.2. Lookup of SSP Records
o Non-existent cases, i.e., a subdomain or hostname that does not NON-NORMATIVE NOTE: While the operation of the Evaluator is outside
actually exist within the domain the scope of this specification, it is generally not worthwhile for
an Evaluator to request an SSP check when the results of that check
will not affect the disposition of the message. Since the
information provided by SSP is only relevant in the absence of valid
Author Signature(s), there is little to be gained by performing an
SSP check on domains corresponding to valid Author Signatures. SSP
checks may also be unnecessary when the Evaluator has some other
basis for deciding to process the message "normally", including, but
not limited to, the presence of a DKIM signature that the Evaluator
has some basis to trust sufficiently for this purpose.
Normally, a domain expressing Sender Signing Practices will want to 3.2.1. SSP Checker Results
do so for both itself and all of its "descendents" (child domains and
hosts, at all lower levels). Domains wishing to do so MUST publish
SSP records as follows:
Publish an SSP record for the domain itself A Sender Signing Practices check produces one of four possible
results for use by the Evaluator:
Publish an SSP record for any existing subdomain 1. The domain does not exist in DNS.
Note that since the lookup algorithm described below references the 2. The domain does exist, but no SSP Record is present.
immediate parent of the alleged originating domain, it is not
necessary to publish SSP records for every single-level label within
the domain. This has been done to relieve domain administrators of
the burden of publishing an SSP record for every other record in the
domain, which would be otherwise required.
Wildcards within a domain, including but not limited to wildcard MX 3. The SSP Record exists, and that value is also returned.
records, pose a particular problem. While referencing the immediate
parent domain allows the discovery of an SSP record corresponding to
an unintended immediate-child subdomain, wildcard records apply at
multiple levels. For example, if there is a wildcard MX record for
example.com, the domain foo.bar.example.com can receive mail through
the named mail exchanger. Conversely, the existence of the record
makes it impossible to tell whether foo.bar.example.com is a
legitimate name since a query for that name will not return an
NXDOMAIN error. For that reason, SSP coverage for subdomains of
domains containing a wildcard record is incomplete.
NON-NORMATIVE NOTE: Complete SSP coverage of domains containing 4. The DNS information could not be determined due to a transient
(or where any parent contains) wildcards generally cannot be error such as "SERVFAIL".
guaranteed.
4.3. Record Syntax 3.2.2. SSP Lookup Algorithm
SSP records follow the "tag=value" syntax described in section 3.2 of SSP Checkers doing an SSP lookup MUST produce a result that is
[RFC4871]. The SSP record syntax is a tag-list as defined in that semantically equivalent to applying the following steps in the order
section, including the restriction on duplicate tags, the use of listed below. In practice, several of these steps can be performed
white space, and case sensitivity. in parallel in order to improve performance. However,
implementations SHOULD avoid doing unnecessary DNS lookups. For the
purposes of this section a "valid SSP record" is one that is both
syntactically and semantically correct; in particular, it must match
the ABNF for a "tag-list" and must include a defined "dkim=" tag.
Tags used in SSP records are as follows. Unrecognized tags MUST be 1. _Fetch Named SSP Record._ The SSP Checker MUST query DNS for a
ignored. In the ABNF below, the FWS token is inherited from TXT record corresponding to the Author Domain prefixed by
[RFC2822] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens ""_ssp._domainkey."" (note the trailing dot). If the result of
are imported from [RFC4234]. this query is a "NOERROR" response with one or more answers which
are valid SSP records, return that record for interpretation by
the Evaluator; otherwise, continue to the next step.
dkim= Outbound signing practices for the domain (plain-text; 2. _Verify Domain Exists._ The SSP Checker MUST perform a DNS query
REQUIRED). Possible values are as follows: for a record corresponding to the Author Domain (with no prefix).
The type of the query can be of any type, since this step is only
to determine if the domain itself exists in DNS. This query MAY
be done in parallel with the query made in step 2. If the result
of this query is an "NXDOMAIN" error, the SSP Checker MUST return
an appropriate error to the Evaluator and terminate the
algorithm.
unknown The domain may sign some or all email. NON-NORMATIVE DISCUSSION: Any resource record type could be
used for this query since the existence of a resource record
of any type will prevent an "NXDOMAIN" error. "MX" is a
reasonable choice for this purpose is because this record type
is thought to be the most common for likely domains, and will
therefore result in a result which can be more readily cached
than a negative result.
all All mail from the domain is signed; unsigned email MUST be 3. _Try Parent Domain._ The SSP Checker MUST query DNS for a TXT
considered Suspicious. The domain may send messages through record for the immediate parent domain, prefixed with
agents that may modify and re-sign messages, so email signed ""_ssp._domainkey."" If the result of this query is anything
with a Verifier Acceptable Third-Party Signature SHOULD NOT be other than a "NOERROR" response with a valid SSP record, the
considered Suspicious. algorithm terminates returning a result indicating that no SSP
record was present. If the SSP "t" tag exists in the response
and any of the flags is "s" (indicating it should not apply to a
subdomain), the SSP Checker MUST also return a "No SSP Record"
result. Otherwise, return that record for interpretation by the
Evaluator.
strict All mail from the domain is signed; messages lacking a If any of the queries involved in the Sender Signing Practices Check
valid Originator Signature MUST be considered Suspicious. The result in a "SERVFAIL" error response, the SSP Checker MUST return
domain does not expect to send messages through agents that may that information to the Evaluator; possible actions include queuing
modify and re-sign messages. the message or returning an SMTP error indicating a temporary
failure.
NON-NORMATIVE RATIONALE: Strict practices may be used by 3.3. SSP Record Syntax
entities which send only transactional email to individual
addresses and which are willing to accept the consequence of
having some mail which is re-signed appear suspicious in
return 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.
ABNF: SSP Records MUST match the "tag-list" syntax defined in [RFC4871].
The specific tags used in SSP records are described below.
Unrecognized tags MUST be ignored.
ssp-dkim-tag = "dkim" [FWS] "=" [FWS] ("unknown" / dkim= Outbound signing practices for the domain (plain-text;
"all" / "strict") REQUIRED). Possible values are as follows:
handling= Non-compliant message handling request for the domain unknown The domain may sign none, some, or all email.
(plain-text; OPTIONAL). Possible values are as follows:
process Messages which are Suspicious from this domain SHOULD be all All mail from the domain is signed with an Author Signature.
processed by the verifier, although the SSP failure MAY be
considered in subsequent evaluation of the message. This is
the default value.
deny Messages which are Suspicious from this domain MAY be discardable All mail from the domain is signed with an Author
rejected, bounced, or otherwise not delivered at the option of Signature. Furthermore, if a message arrives without a valid
the verifier. Author Signature due to modification in transit, submission via
a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it.
NON-NORMATIVE EXPLANATION: The "deny" practice is intended NON-NORMATIVE DISCUSSION: Sender signing practices of
for use by domains that value security over deliverability. "discardable" would be usually inappropriate for domains of end
For example, a domain used by a financial institution to users, because of the potential for mailing lists and similar
send transactional email, which signs all of its messages, agents to modify messages in such a way as to render the
might consider their concern about phishing messages signature invalid. Domains sending mail that is expected to
purporting to come from their domain to be higher than their pass with no significant modification to the recipient, such as
concern about some some legitimate messages not being domains sending only transactional messages, are appropriate
delivered. The "handling=deny" practice allows them to places to consider the publication of a "discardable" practice.
express that concern in a way that can be acted upon by See [RFC5016] section 5.3 and Appendix A for further
verifiers, if they so choose. discussion.
ABNF: ABNF:
ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" / ssp-dkim-tag = "dkim" *WSP "=" *WSP ("unknown" /
"deny") "all" / "discardable")
t= Flags, represented as a colon-separated list of names (plain-text; t= Flags, represented as a colon-separated list of names (plain-text;
OPTIONAL, default is that no flags are set). Flag values are: OPTIONAL, default is that no flags are set). Flag values are:
y The domain is testing signing practices, and the Verifier
SHOULD NOT consider a message suspicious based on the record.
s The signing practices apply only to the named domain, and not s The signing practices apply only to the named domain, and not
to subdomains. to subdomains.
ABNF: ABNF:
ssp-t-tag = %x75 [FWS] "=" [FWS] ssp-t-tag-flag ssp-t-tag = %x75 *WSP "=" *WSP ssp-t-tag-flag
0*( [FWS] ":" [FWS] ssp-t-tag-flag ) 0*( *WSP ":" *WSP ssp-t-tag-flag )
ssp-t-tag-flag = "y" / "s" / hyphenated-word ssp-t-tag-flag = "s" / hyphenated-word
; for future extension ; for future extension
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
(ALPHA / DIGIT) ] (ALPHA / DIGIT) ]
Unrecognized flags MUST be included in the result that is provided
to the Evaluator.
Unrecognized flags MUST be ignored. 4. IANA Considerations
4.4. Sender Signing Practices Check Procedure
Verifiers MUST produce a result that is semantically equivalent to
applying the following steps in the order listed. In practice,
several of these steps can be performed in parallel in order to
improve performance.
1. If a valid Originator Signature exists, the message is not
Suspicious, and the algorithm terminates.
2. The Verifier MUST query DNS for a TXT record corresponding to
the Originator Domain prefixed by "_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 7.
3. The Verifier MUST query DNS for an MX record corresponding to
the Originator Domain (with no prefix). This query is made only
to check the existence of the domain name and MAY be done in
parallel with the query made in step 2. If the result of this
query is an NXDOMAIN error, the message is Suspicious and the
algorithm terminates.
NON-NORMATIVE DISCUSSION: Any resource record type could be
used for this query since the existence of a resource record
of any type will prevent an NXDOMAIN error. The choice of MX
for this purpose is because this record type is thought to be
the most common for likely domains, and will therefore result
in a result which can be more readily cached than a negative
result.
4. If the immediate parent of the Originator Domain is a top-level
domain (a domain consisting of a single element such as "com",
"us", or "jp"), then the message is not Suspicious (because no
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 an entry on the list.
5. The Verifier MUST query DNS for a TXT record for 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 the SSP "t" tag exists in the response and any of the flags
is "s" (indicating it should not apply to a subdomain), the
message is not Suspicious and the algorithm terminates.
7. If the SSP "t" tag exists in the response and any of the flags
is "y" (indicating testing), the message is not Suspicious and
the algorithm terminates.
8. If the value of the SSP "dkim" tag is "unknown", the message is
not Suspicious and the algorithm terminates.
9. If the value 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 any of the queries involved in the Sender Signing Practices Check
result in 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 to create a "DKIM selector name" registry and to IANA is requested to create a "DKIM selector name" registry and to
reserve the selector name "_ssp" to avoid confusion between DKIM key reserve the selector name ""_ssp"" to avoid confusion between DKIM
records and SSP records. key records and SSP records.
6. Security Considerations *<<< Needs to be updated to be more complete; see 4871 for examples
>>>*
5. Security Considerations
Security considerations in the Sender Signing Practices are mostly Security considerations in the Sender Signing Practices are mostly
related to attempts on the part of malicious senders to represent related to attempts on the part of malicious senders to represent
themselves as other senders, often in an attempt to defraud either themselves as other authors, often in an attempt to defraud either
the recipient or the Alleged Originator. the recipient or an Alleged Author.
Additional security considerations regarding Sender Signing Practices Additional security considerations regarding Sender Signing Practices
may be found in the DKIM threat analysis [RFC4686]. may be found in the DKIM threat analysis [RFC4686].
6.1. Fraudulent Sender Address *<<<THIS SECTION IS NOT COMPLETE.>>>*
[[Assuming 3rd party signature is based on Sender header field]] If
the Sender Signing Practices sanction third-party signing, an
attacker can create a message with a From header field of an
arbitrary sender and a legitimately signed Sender header field
6.2. DNS Attacks 5.1. DNS Attacks
An attacker might attack the DNS infrastructure in an attempt to An attacker might attack the DNS infrastructure in an attempt to
impersonate SSP records. However, such an attacker is more likely to impersonate SSP records. However, such an attacker is more likely to
attack at a higher level, e.g., redirecting A or MX record lookups in attack at a higher level, e.g., redirecting "A" or "MX" record
order to capture traffic that was legitimately intended for the lookups in order to capture traffic that was legitimately intended
target domain. Domains concerned about this should use DNSSEC for the target domain. Domains concerned about this should use
[RFC4033]. DNSSEC [RFC4033].
Because SSP operates within the framework of the legacy e-mail Because SSP operates within the framework of the legacy e-mail
system, the default result in the absence of an SSP record is that system, the default result in the absence of an SSP record is that
the domain does not sign all of its messages. Therefore, a DNS the domain does not sign all of its messages. It is therefore
attack which is successful in suppressing the SSP response to the important that the SSP Checker distinguish a DNS failure such as
verifier is sufficient to cause the verifier to see unsigned messages SERVFAIL from other DNS errors so that appropriate actions can be
as non-suspicious, even when that is not intended by the alleged taken.
originating domain.
7. References 5.2. DNS Wildcards
7.1. Normative References Wildcards within a domain publishing SSP records, including but not
limited to wildcard "MX" records, pose a particular problem. While
referencing the immediate parent domain allows the discovery of an
SSP record corresponding to an unintended immediate-child subdomain,
wildcard records apply at multiple levels. For example, if there is
a wildcard "MX" record for "example.com", the domain
"foo.bar.example.com" can receive mail through the named mail
exchanger. Conversely, the existence of the record makes it
impossible to tell whether "foo.bar.example.com" is a legitimate name
since a query for that name will not return an "NXDOMAIN" error. For
that reason, SSP coverage for subdomains of domains containing a
wildcard record is incomplete.
NON-NORMATIVE NOTE: Complete SSP coverage of domains containing
(or where any parent contains) wildcards generally cannot be
guaranteed.
6. References
6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
7.2. Informative References 6.2. Informative References
[I-D.ietf-dkim-ssp-requirements]
Thomas, M., "Requirements for a DKIM Signing Practices
Protocol", draft-ietf-dkim-ssp-requirements-05 (work in
progress), April 2007.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
Appendix A. Acknowledgements [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
(DKIM) Signing Practices Protocol", RFC 5016,
October 2007.
The authors wish to thank many members of the ietf-dkim mailing list, Appendix A. Usage Examples (INFORMATIVE)
in particular Arvel Hathcock and Eliot Lear, for valuable suggestions
and constructive criticism of earlier versions of this draft.
Appendix B. Change Log These examples are intended to illustrate typical uses of SSP. They
are not intended to be exhaustive, nor to apply to every domain or
mail system's individual situation.
B.1. Changes since -ietf-dkim-ssp-00 A.1. Single Location Domains
A common mail system configuration handles all of a domain's users'
incoming and outgoing mail through a single MTA or cluster of MTAs.
In that case, the MTA(s) can be configured to sign outgoing mail with
an Author Signature.
In this situation it might be appropriate to publish an SSP record
for the 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 advised to consider the ways that mail processing
can modify messages in ways that will invalidate an existing DKIM
signature, such as mailing lists, courtesy forwarders, and other
paths that could add or modify headers, or modify the message body.
In that case, if the modifications invalidate the DKIM signature,
recipient MTAs will consider the mail not to have an Author
Signature, even though the signature was present when the mail was
originally sent.
A.2. Bulk Mailing Domains
Another common configuration uses a domain solely for bulk or
broadcast mail, with no individual human users, again typically
sending all the mail through a single MTA or cluster of MTAs that can
apply an Author Signature. In this case, the 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 mailing lists, but could still send mail through other
paths that might invalidate signatures.
Domain owners often use specialist mailing providers to send their
bulk mail. In that case, the mailing provider needs access to a
suitable signing key in order to apply an Author Signature. One
possible route would be for the 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 mailing provider, for example,
bigbank.example might delegate email.bigbank.example to such a
provider. In that case, the provider can generate the keys and DKIM
DNS records itself and use the subdomain in the Author Address in the
mail.
A.3. Bulk Mailing Domains with Discardable Mail
In some cases, a domain might sign all its outgoing mail with an
Author Signature, but prefers that recipient systems discard mail
without a valid Author Signature to avoid confusion from mail sent
from sources that do not apply an Author Signature. (This latter
kind of mail is sometimes loosely called "forgeries".) In that case,
it may be appropriate to publish an SSP record containing
"discardable". Note that a domain SHOULD NOT publish a "discardable"
record if it wishes to maximize the likelihood that mail from the
domain is delivered, since it could cause some fraction of the mail
the domain sends to 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 domain is a forgery.
A.4. Third Party Senders
Another common use case is for a 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 the
RFC2822 From: or other headers. Due to the many and 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 other usages of DKIM.
Appendix B. Acknowledgements
The authors wish to thank many members of the ietf-dkim mailing 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 C. Change Log
*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 o Clarified Operation Overview and eliminated use of Legitimate as
the counterpart of Suspicious since the words have different the counterpart of Suspicious since the words have different
meanings. meanings.
o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT
records in DNS vs. a new RR type. records in DNS vs. a new RR type.
o Clarified publication rules for multilevel names. o Clarified publication rules for multilevel names.
o Better description of overall record syntax, in particular that o Better description of overall record syntax, in particular that
records with unknown tags are considered syntactically correct. records with unknown tags are considered syntactically correct.
o Clarified Sender Signing Practices Check Procedure, primarily by o Clarified Sender Signing Practices Check Procedure, primarily by
use of new term Originator Domain. use of new term Author Domain.
o Eliminated section "Third-Party Signatures and Mailing Lists" that o Eliminated section "Third-Party Signatures and Mailing Lists" that
is better included in the DKIM overview document. is better included in the DKIM overview document.
o Added "handling" tag to express alleged sending domain's o Added "handling" tag to express alleged sending domain's
preference about handling of Suspicious messages. preference about handling of Suspicious messages.
o Clarified handling of SERVFAIL error in SSP check. o Clarified handling of SERVFAIL error in SSP check.
o Replaced "entity" with "domain", since with the removal of user- o Replaced "entity" with "domain", since with the removal of user-
granularity SSP, the only entities having sender signing policies granularity SSP, the only entities having sender signing policies
are domains. are domains.
B.2. Changes since -allman-ssp-02 C.3. Changes since -allman-ssp-02
o Removed user-granularity SSP and u= tag. o Removed user-granularity SSP and u= tag.
o Replaced DKIMP resource record with a TXT record. o Replaced DKIMP resource record with a TXT record.
o Changed name of the primary tag from "p" to "dkim". o Changed name of the primary tag from "p" to "dkim".
o Replaced lookup algorithm with one which traverses upward at most o Replaced lookup algorithm with one which traverses upward at most
one level. one level.
o Added description of records which must be published, and effect o Added description of records which must be published, and effect
of wildcard records within the domain, on SSP. of wildcard records within the domain, on SSP.
B.3. Changes since -allman-ssp-01 C.4. Changes since -allman-ssp-01
o Changed term "Sender Signing Policy" to "Sender Signing o Changed term "Sender Signing Policy" to "Sender Signing
Practices". Practices".
o Changed query methodology to use a separate DNS resource record o Changed query methodology to use a separate DNS resource record
type, DKIMP. type, DKIMP.
o Changed tag values from SPF-like symbols to words. o Changed tag values from SPF-like symbols to words.
o User level policies now default to that of the domain if not o User level policies now default to that of the domain if not
specified. specified.
o Removed the "Compliance" section since we're still not clear on o Removed the "Compliance" section since we're still not clear on
what goes here. what goes here.
o Changed the "parent domain" policy to only search up one level o Changed the "parent domain" policy to only search up one level
(assumes that subdomains will publish SSP records if appropriate). (assumes that subdomains will publish SSP records if appropriate).
o Added detailed description of SSP check procedure. o Added detailed description of SSP check procedure.
B.4. Changes since -allman-ssp-00 C.5. Changes since -allman-ssp-00
From a "diff" perspective, the changes are extensive. Semantically, From a "diff" perspective, the changes are extensive. Semantically,
the changes are: the changes are:
o Added section on "Third-Party Signatures and Mailing Lists" o Added section on "Third-Party Signatures and Mailing Lists"
o Added "Compliance" (transferred from -base document). I'm not o Added "Compliance" (transferred from -base document). I'm not
clear on what needs to be done here. clear on what needs to be done here.
o Extensive restructuring. o Extensive restructuring.
Authors' Addresses Authors' Addresses
Eric Allman Eric Allman
Sendmail, Inc. Sendmail, Inc.
6475 Christie Ave, Suite 350 6475 Christie Ave, Suite 350
skipping to change at page 18, line 7 skipping to change at page 19, line 7
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA USA
Phone: +1 408 526 5914 Phone: +1 408 526 5914
Email: fenton@cisco.com Email: fenton@cisco.com
URI: URI:
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 96 change blocks. 
430 lines changed or deleted 452 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/