draft-ietf-dkim-ssp-00.txt   draft-ietf-dkim-ssp-01.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: December 19, 2007 Yahoo! Inc. Expires: March 20, 2008 Yahoo! Inc.
J. Fenton J. Fenton
Cisco Systems, Inc. Cisco Systems, Inc.
June 17, 2007 September 17, 2007
DKIM Sender Signing Practices DKIM Sender Signing Practices
draft-ietf-dkim-ssp-00 draft-ietf-dkim-ssp-01
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 December 19, 2007. This Internet-Draft will expire on March 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
and interpret those results. and interpret those results.
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)
Security Considerations needs further work. Need to consider handling of multiple responses to a DNS query for
the SSP record.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5
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. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5
2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5 2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5
2.4. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Originator Domain . . . . . . . . . . . . . . . . . . . . 6
2.5. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6 2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Sender Signing Practices . . . . . . . . . . . . . . . . . 6 2.6. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6
2.7. Originator Signature . . . . . . . . . . . . . . . . . . . 6 2.7. Sender Signing Practices . . . . . . . . . . . . . . . . . 6
2.8. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6 2.8. Originator Signature . . . . . . . . . . . . . . . . . . . 6
2.9. Third-Party Signature . . . . . . . . . . . . . . . . . . 6 2.9. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6
2.10. Verifier Acceptable Third-Party Signature . . . . . . . . 7 2.10. Third-Party Signature . . . . . . . . . . . . . . . . . . 7
2.11. Verifier Acceptable Third-Party Signature . . . . . . . . 7
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8
4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9 4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9
4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Sender Signing Practices Check Procedure . . . . . . . . . 11 4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12
5. Third-Party Signatures and Mailing Lists . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Mailing List Manager Actions . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.2. Signer Actions . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 B.1. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 B.2. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
A.1. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16 B.3. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16
A.2. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16 B.4. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16
A.3. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 18
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.
skipping to change at page 4, line 27 skipping to change at page 4, line 27
a priori indication of forgery. In fact, during early phases of a priori indication of forgery. In fact, during early phases of
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. However, some domains may choose to sign all of their
outgoing mail, for example, to protect their brand name. It is outgoing mail, for example, to protect their brand name. It is
highly desirable for such domains to be able to advertise that fact highly desirable for such domains to be able to advertise that fact
to verifiers, and that messages claiming to be from them that do not to verifiers, and that messages claiming to be from them that do not
have a valid signature are likely to be forgeries. This is the topic have a valid signature are likely to be forgeries. This is the topic
for sender signing practices. for sender signing practices.
In the absence of a valid DKIM signature on behalf of the "From" In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822], the verifier of a message MUST determine whether address [RFC2822], message verifiers implementing this specification
messages from that sender are expected to be signed, and what MUST determine whether messages from that sender are expected to be
signatures are acceptable. In particular, whether a domain signs all signed, and what signatures are acceptable. In particular, whether a
outbound email must be communicated to the verifier. Without such a domain signs all outbound email must be made available to the
mechanism, the benefit of message signing techniques such as DKIM is verifier. Without such a mechanism, the benefit of message signing
limited since unsigned messages will always need to be considered to techniques such as DKIM is limited since unsigned messages will
be potentially legitimate. This determination is referred to as a always need to be considered to be potentially legitimate. This
Sender Signing Practices check. determination is referred to as a Sender Signing Practices check.
Conceivably, such expressions might be imagined to be extended in the Conceivably, such expressions might be imagined to be extended in the
future to include information about what hashing algorithms a domain future to include information about what hashing algorithms a domain
uses, what kind of messages might be sent (e.g., bulk vs. personal uses, what kind of messages might be sent (e.g., bulk vs. personal
vs. transactional), etc. Such concerns are out of scope of this vs. transactional), etc. Such concerns are out of scope of this
standard, because they can be expressed in the key record standard, because they can be expressed in the key record
("Selector") with which the signature is verified. In contrast, this ("Selector") with which the signature is verified. In contrast, this
specification focuses on information which is relevant in the absence specification focuses on information which is relevant in the absence
of a valid signature. Expressions of signing practice which require of a valid signature. Expressions of signing practice which require
outside auditing are similarly out of scope for this specification outside auditing are similarly out of scope for this specification
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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 A "Verifier" is the agent that verifies a message by checking the
actual signature against the message itself and the public key actual signature against the message itself and the public key
published by the alleged signer. The Verifier also looks up the published by the Alleged Signer. The Verifier also looks up the
Sender Signing Practices published by the domain of the Originator Sender Signing Practices published by the domain of the Originator
Address if the message is not correctly signed by the Alleged Address if the message is not correctly signed by the Alleged
Originator. Originator.
o A "Selector" specifies which of the keys published by a signing o A "Selector" specifies which of the keys published by a signing
domain should be queried. It is essentially a way of subdividing 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 2.2. Valid Signature
skipping to change at page 6, line 5 skipping to change at page 5, line 49
NON-NORMATIVE RATIONALE: The alternative option when there are NON-NORMATIVE RATIONALE: The alternative option when there are
multiple addresses in the From header field is to use the value of multiple addresses in the From header field is to use the value of
the Sender header field. This would be closer to the semantics the Sender header field. This would be closer to the semantics
indicated in [RFC2822] than using the first address in the From indicated in [RFC2822] than using the first address in the From
header field. However, the large number of deployed Mail User header field. However, the large number of deployed Mail User
Agents that do not display the Sender header field value argues Agents that do not display the Sender header field value argues
against that. Multiple addresses in the From header field are against that. Multiple addresses in the From header field are
rare in real life. rare in real life.
2.4. Alleged Signer 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- 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 Signature header field in a message received by a Verifier; it is
"alleged" because it has not yet been verified. "alleged" because it has not yet been verified.
2.5. Alleged Originator 2.6. Alleged Originator
An "Alleged Originator" is the Originator Address of a message An "Alleged Originator" is the Originator Address of a message
received by a Verifier; it is "alleged" because it has not yet been received by a Verifier; it is "alleged" because it has not yet been
verified. verified.
2.6. Sender Signing Practices 2.7. Sender Signing Practices
"Sender Signing Practices" (or just "practices") consist of a "Sender Signing Practices" (or just "practices") consist of a
machine-readable record published by the domain of the Alleged machine-readable record published by the domain of the Alleged
Originator which includes information about whether or not that Originator which includes information about whether or not that
entity signs all of their email, and whether signatures from third domain signs all of their email, and whether signatures from third
parties are sanctioned by the Alleged Originator. parties are sanctioned by the Alleged Originator.
2.7. Originator Signature 2.8. Originator Signature
An "Originator Signature" is any Valid Signature where the signing An "Originator Signature" is any Valid Signature where the signing
address (listed in the "i=" tag if present, otherwise its default address (listed in the "i=" tag if present, otherwise its default
value, consisting of the null address, representing an unknown user, value, consisting of the null address, representing an unknown user,
followed by "@", followed by the value of the "d=" tag) matches the followed by "@", followed by the value of the "d=" tag) matches the
address in the "From" header field. If the signing address does not Originator Address. If the signing address does not include a local-
include a local-part, then only the domains must match; otherwise, part, then only the domains must match; otherwise, the two addresses
the two addresses must be identical. must be identical.
2.8. Suspicious 2.9. Suspicious
Messages that do not contain a valid Originator Signature and which Messages that do not contain a valid Originator Signature and which
are inconsistent with a Sender Signing Practices check (e.g., are are inconsistent with a Sender Signing Practices check (e.g., are
received without a Valid Signature and the sender's signing practices received without a Valid Signature and the sender's signing practices
indicate all messages from the entity are signed) are referred to as indicate all messages from the domain are signed) are referred to as
"Suspicious". The handling of such messages is at the discretion of "Suspicious". The handling of such messages is at the discretion of
the Verifier or final recipient. "Suspicious" applies only to the the Verifier or final recipient. "Suspicious" applies only to the
DKIM evaluation of the message; a Verifier may decide the message DKIM evaluation of the message; a Verifier may decide the message
should be accepted on the basis of other information beyond the scope should be accepted on the basis of other information beyond the scope
of this document. Conversely, messages deemed non-Suspicious may be of this document. Conversely, messages not deemed Suspicious may be
rejected for other reasons. rejected for other reasons.
2.9. Third-Party Signature 2.10. Third-Party Signature
A "Third-Party Signature" is a Valid Signature which is not an A "Third-Party Signature" is a Valid Signature which is not an
Originator Signature. Originator Signature.
2.10. Verifier Acceptable Third-Party Signature 2.11. Verifier Acceptable Third-Party Signature
A Verifier Acceptable Third-Party Signature is a Third-Party A Verifier Acceptable Third-Party Signature is a Third-Party
Signature that the Verifier is willing to accept as meaningful for Signature that the Verifier is willing to accept as meaningful for
the message under consideration. The Verifier may use any criteria the message under consideration. The Verifier may use any criteria
it deems appropriate for making this determination. it deems appropriate for making this determination.
3. Operation Overview 3. Operation Overview
Sender Signing Practices checks MUST be based on the Originator Sender Signing Practices checks MUST be based on the Originator
Address. If the message contains a valid Originator Signature, no Address. If the message contains a valid Originator Signature, no
Sender Signing Practices check need be performed: the Verifier Sender Signing Practices check need be performed: the Verifier
SHOULD NOT look up the Sender Signing Practices and the message SHOULD NOT look up the Sender Signing Practices and the message MUST
SHOULD be considered non-Suspicious. NOT be considered Suspicious.
Verifiers checking messages that do not have at least one valid Verifiers checking messages that do not have at least one valid
Originator Signature MUST perform a Sender Signing Practices check on Originator Signature MUST perform a Sender Signing Practices check on
the domain specified by the Originator Address as described in the domain specified by the Originator Address as described in
Section 4.4. Section 4.4.
The result of a Sender Signing Practices check is one of four A Sender Signing Practices check produces one of four possible
possible practices: results:
1. Some messages from this domain are not signed; the message SHOULD 1. Some messages from this domain are not signed; the message MUST
be presumed to be legitimate in the absence of a valid signature. NOT be considered Suspicious, even in the absence of a valid
This is the default. signature. This is the default.
2. All messages from this domain are signed; all messages from this 2. All messages from this domain are signed. Messages containing a
domain should have a Valid Signature. Signatures on behalf of a Verifier Acceptable Third-Party Signature MUST NOT be considered
third party (e.g., a mailing list) handling the message MAY be Suspicious.
accepted at the discretion of the verifier.
NON-NORMATIVE RATIONALE: Third-party signatures, since they NON-NORMATIVE RATIONALE: Third-party signatures, since they
can potentially represent any domain, are considered more can potentially represent any domain, are considered more
likely to be abused by attackers seeking to spoof a specific likely to be abused by attackers seeking to spoof a specific
address. It may therefore be desirable for verifiers to apply address. It may therefore be desirable for verifiers to apply
other criteria outside the scope of this specification in other criteria outside the scope of this specification in
deciding to accept a given third-party signature. For deciding to accept a given third-party signature. For
example, a list of known mailing list domains used by example, a list of known mailing list domains used by
addresses served by the verifier might be specifically addresses served by the verifier might be specifically
considered acceptable third-party signers. considered acceptable third-party signers.
3. All valid messages from this domain are signed, and SHOULD have a 3. All valid messages from this domain are signed; the domain of the
Valid Signature from this domain. Third-Party Signatures SHOULD Alleged Originator requests that only messages with valid
NOT be accepted. This practice would typically be used by Originator Signatures be considered not Suspicious; Third-Party
domains which send only transactional email (i.e., do not use 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 mailing lists and such that are likely to break signatures) and
which wish to emphasize security over deliverability of their which wish to emphasize security over deliverability of their
messages. messages. In the absence of a valid Originator Signature, the
message MUST be considered Suspicious.
4. The domain does not exist; the message SHOULD be presumed not to
be legitimate.
If a message is encountered by a Verifier without a valid Originator
Signature, the results MUST be interpreted as follows:
If the result of the check is practice (1) described above, the
message MUST be considered non-Suspicious.
If the result of the check is practice (2), and any verifiable 4. The domain does not exist; the message MUST be considered
signature is present from some signer other than the Originator
Address in the message, the message SHOULD be considered non-
Suspicious. Suspicious.
If the result of the check is practice (3) or (4), the message
MUST be considered Suspicious.
If the Sender Signing Practices record for the domain does not exist If the Sender Signing Practices record for the domain does not exist
but the domain does exist, Verifier systems MUST assume that some but the domain does exist, Verifier systems MUST assume that some
messages from this entity are not signed and the message SHOULD NOT messages from this domain are not signed and the message MUST NOT be
be considered to be Suspicious. considered Suspicious.
4. Detailed Description 4. Detailed Description
4.1. DNS Representation 4.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 NON-NORMATIVE DISCUSSION: There has been considerable discussion
on the DKIM WG mailing list regarding the relative advantages of on the DKIM WG mailing list regarding the relative advantages of
TXT and a new resource record (RR) type. The existence of DNS TXT and a new resource record (RR) type. Many DNS server and
server and resolver implementations which are unable to support resolver implementations are incapable of quickly and easily
resource record types other than a specific well-known set is supporting new resource record types. For this reason, support of
cited as a requirement for support of TXT records regardless of TXT records is required whether a new RR type is defined or not.
whether a new RR is defined. However, without a "flag day" on However, without a "flag day" on which SSP TXT record support is
which SSP TXT record support is to be withdrawn, such support is to be withdrawn, such support is likely to continue indefinitely.
likely to continue indefinitely. As a result, this specification As a result, this specification defines no new RR type for SSP.
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
skipping to change at page 9, line 23 skipping to change at page 9, line 16
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. The "Tag=Value List" syntax described in
section 3.2 of [RFC4871] is used. Records not in compliance with section 3.2 of [RFC4871] is used. Records not in compliance with
that syntax or the syntax of individual tags described in Section 4.3 that syntax or the syntax of individual tags described in Section 4.3
MUST be ignored (considered equivalent to a NODATA result) for MUST be ignored (considered equivalent to a NODATA result) for
purposes of message disposition, although they MAY cause the logging purposes of message disposition, although they MAY cause the logging
of warning messages via an appropriate system logging mechanism. of warning messages via an appropriate system logging mechanism.
SSP records for a domain are published at a location in the domain's 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 DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for
example.com would be a TXT record whcih is published at example.com would be a TXT record that is published at
_ssp._domainkey.example.com. _ssp._domainkey.example.com.
4.2. Publication of SSP Records 4.2. Publication of SSP Records
Sender Signing Policy is intended to apply to all mail allegedly sent Sender Signing Practices are intended to apply to all mail sent from
from a given Originating Domain, and to the greatest extent possible, the domain of an Alleged Originator, and to the greatest extent
to all subdomains of that domain. There are several cases that need possible, to all subdomains of that domain. There are several cases
to be considered in that regard: that need to be considered in that regard:
o The domain itself o The domain itself
o Subdomains which may or may not be used for email o Subdomains which may or may not be used for email
o Hostnames which may or may not be used for email o Hostnames which may or may not be used for email
o Other named resource records in the domain o Other named resource records in the domain
o Multi-level examples of the above, e.g., a.b.example.com o Multi-level examples of the above, e.g., a.b.example.com
o Non-existent cases, i.e., a subdomain or hostname that does not o Non-existent cases, i.e., a subdomain or hostname that does not
actually exist within the domain actually exist within the domain
In all of these cases, the records may be published either in
separate DNS zones or as records within a parent zone.
Normally, a domain expressing Sender Signing Practices will want to Normally, a domain expressing Sender Signing Practices will want to
do so for both itself and its all of its "descendents" (child do so for both itself and all of its "descendents" (child domains and
domains, and hosts, at all lower levels). Domains wishing to do so hosts, at all lower levels). Domains wishing to do so MUST publish
MUST publish SSP records as follows: SSP records as follows:
Publish an SSP record for the domain itself Publish an SSP record for the domain itself
Publish an SSP record for any existing subdomain Publish an SSP record for any existing subdomain
Publish an SSP record for any multilevel name within the
subdomain. For example, it is necessary to publish a record for
a.b.example.com even if the b.example.com subdomain does not exist
in the sense of being explicitly delegated.
Note that since the lookup algorithm described below references the Note that since the lookup algorithm described below references the
immediate parent of the alleged originating domain, it is not immediate parent of the alleged originating domain, it is not
necessary to publish SSP records for every single-level label within necessary to publish SSP records for every single-level label within
the domain. This has been done to relieve domain administrators of the domain. This has been done to relieve domain administrators of
the burden of publishing an SSP record for every other record in the the burden of publishing an SSP record for every other record in the
zone, which would be otherwise required. domain, which would be otherwise required.
Wildcards within a zone, including but not limited to wildcard MX Wildcards within a domain, including but not limited to wildcard MX
records, pose a particular problem. While referencing the immediate records, pose a particular problem. While referencing the immediate
parent domain allows the discovery of an SSP record corresponding to parent domain allows the discovery of an SSP record corresponding to
an unintended immediate-child subdomain, wildcard records apply at an unintended immediate-child subdomain, wildcard records apply at
multiple levels. For example, if there is a wildcard MX record for multiple levels. For example, if there is a wildcard MX record for
example.com, the domain foo.bar.example.com can receive mail through example.com, the domain foo.bar.example.com can receive mail through
the named mail exchanger. Conversely, the existence of the record the named mail exchanger. Conversely, the existence of the record
makes it impossible to tell whether foo.bar.example.com is a makes it impossible to tell whether foo.bar.example.com is a
legitimate name since a query for that name will not return an legitimate name since a query for that name will not return an
NXDOMAIN error. For that reason, SSP coverage for subdomains of NXDOMAIN error. For that reason, SSP coverage for subdomains of
domains containing a wildcard record is incomplete. 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.
4.3. Record Syntax 4.3. Record Syntax
Signing practices records follow the tag-value syntax described in SSP records follow the "tag=value" syntax described in section 3.2 of
section 3.2 of [RFC4871]. Tags used in SSP records are as follows. [RFC4871]. The SSP record syntax is a tag-list as defined in that
Unrecognized tags and tags with illegal values MUST be ignored. In section, including the restriction on duplicate tags, the use of
the ABNF below, the FWS token is inherited from [RFC2822] with the white space, and case sensitivity.
exclusion of obs-FWS. The ALPHA and DIGIT tokens are imported from
[RFC4234].
dkim= Outbound signing practices for the entity (plain-text; Tags used in SSP records are as follows. Unrecognized tags MUST be
OPTIONAL, default is "unknown"). Possible values are as follows: 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].
unknown The entity may sign some or all email. dkim= Outbound signing practices for the domain (plain-text;
REQUIRED). Possible values are as follows:
all All mail from the entity is signed; unsigned email MUST be unknown The domain may sign some or all email.
considered Suspicious. The entity may send messages through
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 agents that may modify and re-sign messages, so email signed
with a Verifier Acceptable Third-Party Signature SHOULD be with a Verifier Acceptable Third-Party Signature SHOULD NOT be
considered non-Suspicious. considered Suspicious.
strict All mail from the entity is signed; messages lacking a strict All mail from the domain is signed; messages lacking a
valid Originator Signature MUST be considered Suspicious. The valid Originator Signature MUST be considered Suspicious. The
entity does not expect to send messages through agents that may domain does not expect to send messages through agents that may
modify and re-sign messages. modify and re-sign messages.
NON-NORMATIVE RATIONALE: Strict practices may be used by NON-NORMATIVE RATIONALE: Strict practices may be used by
entities which send only transactional email to individual entities which send only transactional email to individual
addresses and which are willing to accept the consequence of addresses and which are willing to accept the consequence of
having some mail which is re-signed appear suspicious in having some mail which is re-signed appear suspicious in
return for additional control over their addresses. Strict return for additional control over their addresses. Strict
practices may also be used by entities which do not send practices may also be used by entities which do not send
(and therefore do not sign) any email. (and therefore do not sign) any email.
ABNF: ABNF:
ssp-dkim-tag = "dkim" [FWS] "=" [FWS] "unknown" / "all" / "strict" ssp-dkim-tag = "dkim" [FWS] "=" [FWS] ("unknown" /
"all" / "strict")
handling= Non-compliant message handling request for the domain
(plain-text; OPTIONAL). Possible values are as follows:
process Messages which are Suspicious from this domain SHOULD be
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
rejected, bounced, or otherwise not delivered at the option of
the verifier.
NON-NORMATIVE EXPLANATION: The "deny" practice 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 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 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 entity is testing signing practices, and the Verifier y The domain is testing signing practices, and the Verifier
SHOULD NOT consider a message suspicious based on the record. 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 [FWS] "=" [FWS] ssp-t-tag-flag
0*( [FWS] ":" [FWS] ssp-t-tag-flag ) 0*( [FWS] ":" [FWS] ssp-t-tag-flag )
ssp-t-tag-flag = "y" / "s" / hyphenated-word ; for future extension ssp-t-tag-flag = "y" / "s" / hyphenated-word
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] ; for future extension
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
(ALPHA / DIGIT) ]
Unrecognized flags MUST be ignored. Unrecognized flags MUST be ignored.
4.4. Sender Signing Practices Check Procedure 4.4. Sender Signing Practices Check Procedure
The Sender Signing Practices check SHOULD be performed after DKIM Verifiers MUST produce a result that is semantically equivalent to
signature(s), including any where the Alleged Signer is the Alleged applying the following steps in the order listed. In practice,
Originator, have been verified. Verifiers MUST produce a result that several of these steps can be performed in parallel in order to
is semantically equivalent to applying the following steps in the improve performance.
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 non- 1. If a valid Originator Signature exists, the message is not
Suspicious, and the algorithm terminates. Suspicious, and the algorithm terminates.
2. The Verifier MUST query DNS for a TXT record corresponding to the 2. The Verifier MUST query DNS for a TXT record corresponding to
domain part of the Originator Address prefixed by the Originator Domain prefixed by "_ssp._domainkey.". If the
"_ssp._domainkey.". If the result of this query is a NOERROR result of this query is a NOERROR response with one or more
response with one or more answer which is a syntactically-valid answers which are syntactically-valid SSP responses, proceed to
SSP response, proceed to step 6. step 7.
3. The Verifier MUST query DNS for a TXT record corresponding to the
domain part of the Originator Address (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
Supsicious and the algorithm terminates.
4. If the immediate parent of the domain part of the domain part of
the Originator Address is a top-level domain, then the message is
non-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 non-
Suspicious result if the parent domain matches an entry on the
list.
5. The Verifier MUST query DNS for a TXT record forthe immediate 3. The Verifier MUST query DNS for an MX record corresponding to
parent domain, prefixed with "_ssp._domainkey." If the result of the Originator Domain (with no prefix). This query is made only
this query is a NOERROR response which does not contain one or to check the existence of the domain name and MAY be done in
more answers which is a syntactically-valid SSP response, or the parallel with the query made in step 2. If the result of this
"t" tag exists and any of the flags is "s" (indicating it should query is an NXDOMAIN error, the message is Suspicious and the
not apply to a subdomain), the message is non-Suspicious and the
algorithm terminates. algorithm terminates.
6. If the SSP "t" tag exists and any of the flags is "y" (indicating NON-NORMATIVE DISCUSSION: Any resource record type could be
testing), the message is non-Suspicious and the algorithm used for this query since the existence of a resource record
terminates. of any type will prevent an NXDOMAIN error. The choice of MX
for this purpose is because this record type is thought to be
7. If the value of the SSP "dkim" tag is "unknown", the message is the most common for likely domains, and will therefore result
non-Suspicious and the algorithm terminates. in a result which can be more readily cached than a negative
result.
8. If the value of the SSP "dkim" tag is "all", and one or more
Valid Signatures are present on the message, the message is non-
Suspicious and the algorithm terminates.
9. The message is Suspicious and the algorithm terminates.
5. Third-Party Signatures and Mailing Lists
There are several forms of mailing lists, which interact with signing
in different ways.
o "Verbatim" mailing lists send messages without modification
whatsoever. They are often implemented as MTA-based aliases.
Since they do not modify the message, signatures are unaffected
and will continue to verify. It is not necessary for the
forwarder to re-sign the message; however, some may choose to do
so in order to certify that the message was sent through the list.
o "Digesting" mailing lists collect together one or more postings
and then retransmit them, often on a nightly basis, to the
subscription list. These are essentially entirely new messages
which must be independently authored (that is, they will have a
"From" header field referring to the list, not the submitters) and
signed by the Mailing List Manager itself, if they are signed at
all.
o "Resending" mailing lists receive a message, modify it (often to
add "unsubscribe" information or advertising), and immediately
resend that message to the subscription list. They are
problematic because they usually do not change the "From" header
field of the message, but they do invalidate the signature in the
process of modifying the message.
The first two cases act in obvious ways and do not require further
discussion. The remainder of this session applies only to the third
case.
5.1. Mailing List Manager Actions
Mailing List Managers should make every effort to ensure that
messages that they relay and which have Valid Signatures upon receipt
also have Valid Signatures upon retransmission. In particular,
Mailing List Managers that modify the message in ways that break
existing signatures SHOULD:
o Verify any existing DKIM Signatures. A DKIM-aware Mailing List
Manager MUST NOT re-sign an improperly signed message in such a
way that would imply that the existing signature is acceptable.
o Apply regular anti-spam policies. A Mailing List Manager SHOULD
apply message content security policy just as they would messages
destined for an individual user's mailbox. In fact, a Mailing
List Manager might apply a higher standard to messages destined to
a mailing list than would normally be applied to individual
messages.
NON-NORMATIVE RATIONALE: Since reputation will accrue to
signers, Mailing List Managers should verify the source and
content of messages before they are willing to sign lest their
reputation be sullied by nefarious parties.
o Add a Sender header field using a valid address pointing back to
the Mailing List Administrator or an appropriate agent (such as an
"owner-" or a "-request" address).
o Sign the resulting message with a signature that is valid for the
Sender header field address. The Mailing List Manager SHOULD NOT
sign messages for which they are unwilling to accept
responsibility.
Mailing List Managers MAY: 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.
o Reject messages with signatures that do not verify or are 5. The Verifier MUST query DNS for a TXT record for the immediate
otherwise Suspicious. 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.
5.2. Signer Actions 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.
All Signers SHOULD: 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.
o Include any existing Sender header field in the signed header 8. If the value of the SSP "dkim" tag is "unknown", the message is
field list, if the Sender header field exists. not Suspicious and the algorithm terminates.
Signers wishing to avoid the use of Third-Party Signatures SHOULD do 9. If the value of the SSP "dkim" tag is "all", and one or more
everything listed above, and also: Verifier Acceptable Third-Party Signatures are present on the
message, the message is not Suspicious and the algorithm
terminates.
o Include the Sender header field name in the header field list 10. The message is Suspicious and the algorithm terminates.
("h=" tag) under all circumstances, even if the Sender header
field does not exist in the header block. This prevents another
entity from adding a Sender header field.
o Publish Sender Signing Practices that does not sanction the use of If any of the queries involved in the Sender Signing Practices Check
Third-Party Signatures result in a SERVFAIL error response, the verifier MAY either queue
the message or return an SMTP error indicating a temporary failure.
6. IANA Considerations 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 key
records and SSP records. records and SSP records.
7. Security Considerations 6. 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 senders, often in an attempt to defraud either
the recipient or the Alleged Originator. the recipient or the Alleged Originator.
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].
7.1. Fraudulent Sender Address 6.1. Fraudulent Sender Address
[[Assuming 3rd party signature is based on Sender header field]] If [[Assuming 3rd party signature is based on Sender header field]] If
the Sender Signing Practices sanction third-party signing, an the Sender Signing Practices sanction third-party signing, an
attacker can create a message with a From header field of an attacker can create a message with a From header field of an
arbitrary sender and a legitimately signed Sender header field arbitrary sender and a legitimately signed Sender header field
7.2. DNS Attacks 6.2. 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 lookups in
order to capture traffic that was legitimately intended for the order to capture traffic that was legitimately intended for the
target domain. Domains concerned about this should use DNSSEC target domain. Domains concerned about this should use DNSSEC
[RFC4033]. [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 notsign all of its messages. Therefore, a DNS attack the domain does not sign all of its messages. Therefore, a DNS
which is successful in suppressing the SSP response to the verifier attack which is successful in suppressing the SSP response to the
is sufficient to cause the verifier to see unsigned messages as non- verifier is sufficient to cause the verifier to see unsigned messages
suspicious, even when that is not intended by the alleged originating as non-suspicious, even when that is not intended by the alleged
domain. originating domain.
8. References 7. References
8.1. Normative References 7.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.
8.2. Informative References 7.2. Informative References
[I-D.ietf-dkim-ssp-requirements] [I-D.ietf-dkim-ssp-requirements]
Thomas, M., "Requirements for a DKIM Signing Practices Thomas, M., "Requirements for a DKIM Signing Practices
Protocol", draft-ietf-dkim-ssp-requirements-04 (work in Protocol", draft-ietf-dkim-ssp-requirements-05 (work in
progress), April 2007. 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. Change Log Appendix A. Acknowledgements
A.1. Changes since -allman-ssp-02 The authors wish to thank many members of the ietf-dkim mailing list,
in particular Arvel Hathcock and Eliot Lear, for valuable suggestions
and constructive criticism of earlier versions of this draft.
Appendix B. Change Log
B.1. 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 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. 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.
A.2. Changes since -allman-ssp-01 B.3. 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.
A.3. Changes since -allman-ssp-00 B.4. 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.
6425 Christie Ave, Suite 400 6475 Christie Ave, Suite 350
Emeryville, CA 94608 Emeryville, CA 94608
USA USA
Phone: +1 510 594 5501 Phone: +1 510 594 5501
Email: eric+dkim@sendmail.org Email: eric+dkim@sendmail.org
URI: URI:
Mark Delany Mark Delany
Yahoo! Inc. Yahoo! Inc.
701 First Avenue 701 First Avenue
 End of changes. 77 change blocks. 
272 lines changed or deleted 261 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/