draft-ietf-dkim-ssp-04.txt   draft-levine-dkim-adsp-00.txt 
Network Working Group E. Allman Network Working Group S. Atkins
Internet-Draft Sendmail, Inc. Internet-Draft Word to the Wise
Intended status: Standards Track J. Fenton Intended status: Standards Track J. Callas
Expires: January 3, 2009 Cisco Systems, Inc. Expires: November 24, 2008 PGP Corp.
M. Delany J. Levine, Ed.
Yahoo! Inc.
J. Levine
Taughannock Networks Taughannock Networks
July 2, 2008 E. Siegel
Constant Contact
May 23, 2008
DKIM Author Domain Signing Practices (ADSP) DKIM Author Domain Signing Practices (ADSP)
draft-ietf-dkim-ssp-04 draft-levine-dkim-adsp-00
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 39 skipping to change at page 1, line 39
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 January 3, 2009. This Internet-Draft will expire on November 24, 2008.
Abstract Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the authentication framework for email to permit verification of the
source and contents of messages. This document specifies an adjunct source and contents of messages. This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address. It defines a signature for the domain used in the author's address. It defines a
record that can advertise whether they sign their outgoing mail, and record that can advertise whether they sign their outgoing mail, and
how other hosts can access those records. how other hosts can access those records.
skipping to change at page 2, line 42 skipping to change at page 2, line 42
7.1. References - Normative . . . . . . . . . . . . . . . . . . 11 7.1. References - Normative . . . . . . . . . . . . . . . . . . 11
7.2. References - Informative . . . . . . . . . . . . . . . . . 11 7.2. References - Informative . . . . . . . . . . . . . . . . . 11
Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 11 Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 11
A.1. Single Location Domains . . . . . . . . . . . . . . . . . 12 A.1. Single Location Domains . . . . . . . . . . . . . . . . . 12
A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 12 A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 12
A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 13 A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 13
A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 13 A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 13
A.5. Non-email Domains . . . . . . . . . . . . . . . . . . . . 13 A.5. Non-email Domains . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 13
C.1. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 14 C.1. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 13
C.2. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 14 C.2. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 14
C.3. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 15 C.3. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 15
C.4. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 16 C.4. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 16
C.5. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16 C.5. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
C.6. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 17 C.6. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16
C.7. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 17 C.7. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 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, and the absence of a signature on a message is not an
a priori indication of forgery. In fact, during early phases of a priori indication of forgery. In fact, during early phases of
deployment it is very likely that most messages will remain unsigned. deployment it is very likely that most messages will remain unsigned.
However, some domains might decide to sign all of their outgoing However, some domains might decide to sign all of their outgoing
mail, for example, to protect their brand names. It is desirable for mail, for example, to protect their brand name. It is desirable for
such domains to be able to advertise that fact to other hosts. This such domains to be able to advertise that fact to other hosts. This
is the topic of Author Domain Signing Practices (ADSP). is the topic of Author Domain Signing Practices (ADSP).
Hosts implementing this specification can inquire what Author Signing Hosts implementing this specification can inquire what Author Signing
Practices a domain advertises. This inquiry is called an Author Practices a domain advertises. This inquiry is called an Author
Signing Practices check. Signing Practices check.
The basic requirements for ADSP are given in [RFC5016]. This The basic requirements for ADSP are given in [RFC5016]. This
document refers extensively to [RFC4871] and assumes the reader is document refers extensively to [RFC4871] and assumes the reader is
familiar with it. familiar with it.
skipping to change at page 3, line 50 skipping to change at page 3, line 50
Some terminology used herein is derived directly from [RFC4871]. In Some terminology used herein is derived directly from [RFC4871]. In
several cases, references in that document to Sender have been several cases, references in that document to Sender have been
changed to Author here, to emphasize the relationship to the Author changed to Author here, to emphasize the relationship to the Author
address(es) in the From: header field described in [RFC2822]. address(es) in the From: header field described in [RFC2822].
Briefly, Briefly,
o A "Signer" is the agent that signs a message, as defined in o A "Signer" is the agent that signs a message, as defined in
section 2.1 of [RFC4871]. section 2.1 of [RFC4871].
o A "Local-part" is the part of an address preceding the @ o A "Local-part" is the part of an address preceding the @ sign, as
character, as defined in [RFC2822] and used in [RFC4871]. defined in [RFC2822] and used in [RFC4871].
2.2. Valid Signature 2.2. Valid Signature
A "Valid Signature" is any signature on a message which correctly A "Valid Signature" is any signature on a message which correctly
verifies using the procedure described in section 6.1 of [RFC4871]. verifies using the procedure described in section 6.1 of [RFC4871].
2.3. Author Address 2.3. Author Address
An "Author Address" is an email address in the From header field of a An "Author Address" is an email address in the From header field of a
message [RFC2822]. If the From header field contains multiple message [RFC2822]. If the From header field contains multiple
skipping to change at page 4, line 37 skipping to change at page 4, line 37
"Author Domain Signing Practices" (or just "practices") consist of a "Author Domain Signing Practices" (or just "practices") consist of a
machine-readable record published by the domain of an Alleged Author machine-readable record published by the domain of an Alleged Author
which includes statements about the domain's practices with respect which includes statements about the domain's practices with respect
to mail it sends with its domain in the From: line. to mail it sends with its domain in the From: line.
2.7. Author Signature 2.7. Author Signature
An "Author Signature" is any Valid Signature where the identity of An "Author Signature" is any Valid Signature where the identity of
the user or agent on behalf of which the message is signed (listed in 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 the ""i="" tag or its default value from the ""d="" tag) matches an
Author Address in the message. When the identity of the user or Author Address in the message. When the identity of the user or
agent includes a Local-part, the identities match if the Local-parts agent includes a Local-part, the identities match if the Local-parts
are the same string, and the domains are the same string. Otherwise, match and the domains match. Otherwise, the identities match if the
the identities match if the domains are the same string. Following domains match.
[RFC2821], Local-part comparisons are case sensitive, domain
comparisons are case insensitive.
For example, if a message has a Valid Signature, with the DKIM- For example, if a message has a Valid Signature, with the DKIM-
Signature field containing "i=a@domain.example", then domain.example Signature field containing "i=a@domain.example", then domain.example
is asserting that it takes responsibility for the message. If the is asserting that it takes responsibility for the message. If the
message's From: field contains the address "b@domain.example" and an message's From: field contains the address "b@domain.example" and an
ADSP query produces a "dkim=all" or "dkim=discardable" result, that ADSP query produces a "dkim=all" or "dkim=discardable" result, that
would mean that the message does not have a valid Author Signature. would mean that the message does not have a valid Author Signature.
Even though the message is signed by the same domain, it fails to Even though the message is signed by the same domain, its failure to
satisfy ADSP. satisfy ADSP could be problematic.
3. Operation Overview 3. Operation Overview
Domain owners can publish ADSP information via a query mechanism such Domain owners can publish ADSP information via a query mechanism such
as the Domain Name System; specific details are given in Section 4.1. as the Domain Name System; specific details are given in Section 4.1.
Hosts can look up the ADSP information of the domain(s) specified by Hosts can look up the ADSP information of the domain(s) specified by
the Author Address(es) as described in Section 4.3. If a message has the Author Address(es) as described in Section 4.3. If a message has
multiple Author Addresses the ADSP lookups SHOULD be performed multiple Author Addresses the ADSP lookups SHOULD be performed
independently on each address. This standard does not address the independently on each address. This standard does not address the
skipping to change at page 7, line 11 skipping to change at page 7, line 11
Wildcards within a domain publishing ADSP records pose a particular Wildcards within a domain publishing ADSP records pose a particular
problem. This is discussed in more detail in Section 6.3. problem. This is discussed in more detail in Section 6.3.
4.2.1. Record Syntax 4.2.1. Record Syntax
ADSP records use the "tag=value" syntax described in section 3.2 of ADSP records use the "tag=value" syntax described in section 3.2 of
[RFC4871]. [RFC4871].
Tags used in ADSP records are described below. Unrecognized tags Tags used in ADSP records are described below. Unrecognized tags
MUST be ignored. In the ABNF below, the FWS token is imported from MUST be ignored. In the ABNF below, the WSP token is imported from
[RFC4871]. The ALPHA and DIGIT tokens are imported from [RFC5234]. [RFC2822]. The ALPHA and DIGIT tokens are imported from [RFC5234].
dkim= Outbound signing practices for the domain (plain-text; dkim= Outbound signing practices for the domain (plain-text;
REQUIRED). Possible values are as follows: REQUIRED). Possible values are as follows:
unknown The domain might sign some or all email. unknown The domain might sign some or all email.
all All mail from the domain is signed with an Author all All mail from the domain is signed with an Author
Signature. Signature.
discardable All mail from the domain is signed with an Author discardable All mail from the domain is signed with an Author
Signature. Furthermore, if a message arrives without a valid Signature. Furthermore, if a message arrives without a valid
Author Signature due to modification in transit, submission via Author Signature due to modification in transit, submission via
a path without access to a signing key, or other reason, the a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it. domain encourages the recipient(s) to discard it.
ABNF: ABNF:
adsp-dkim-tag = %x64.6b.69.6d *FWS "=" *FWS ADSP-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
("unknown" / "all" / "discardable") ("unknown" / "all" / "discardable")
4.3. ADSP Lookup Procedure Unrecognized flags MUST be ignored.
Hosts doing an ADSP lookup MUST produce a result that is semantically 4.3. ADSP Lookup Procedure
equivalent to applying the following steps in the order listed below.
In practice, these steps can be performed in parallel in order to
improve performance. However, implementations SHOULD avoid doing
unnecessary DNS lookups.
For the purposes of this section a "valid ADSP record" is one that is For the purposes of this section a "valid ADSP record" is one that is
both syntactically and semantically correct; in particular, it both syntactically and semantically correct; in particular, it
matches the ABNF for a "tag-list" and includes a defined "dkim=" tag. matches the ABNF for a "tag-list" and includes a defined "dkim=" tag.
Verify Domain Scope: An ADSP verifier implementation MUST determine Verify Domain Scope: An ADSP verifier implementation MUST determine
whether a given Author Domain is within scope for ADSP. Given the whether a given Author Domain is within scope for ADSP. Given the
background in Section 3.1 the verifier MUST decide which degree of background in Section 3.1 the verifier MUST decide which degree of
over-approximation is acceptable. The verifier MUST return an over-approximation is acceptable. The verifier MUST return an
appropriate error result for Author Domains that are outside the appropriate error result for Author Domains that are outside the
scope of ADSP. scope of ADSP.
The host MUST perform a DNS query for a record corresponding to One possible approach is to perform a single DNS MX query for an
the Author Domain (with no prefix). The type of the query can be Author Domain, and to declare the domain out of scope for ADSP if
of any type, since this step is only to determine if the domain the result is NXDOMAIN (i.e. no DNS record of any type exists for
itself exists in DNS. This query MAY be done in parallel with the the domain). Another approach is to follow section 5 of [SMTP],
query to fetch the Named ADSP Record. If the result of this query and to declare the domain out of scope for ADSP if the required
is that the Author domain does not exist in the DNS (often called DNS records do not exist.
an "NXDOMAIN" error), the algorithm MUST terminate with an error
indicating that the domain is out of scope.
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 because this record type is thought to
be the most common for domains used in e-mail, and will
therefore produce a result which can be more readily cached
than a negative result.
If the domain does exist, the verifier MAY make more extensive NOTE: Because an ADSP-publishing domain owner cannot tell which
checks to verify the existence of the domain, such as the ones of the discussed methods will be used by a verifier, the domain
described in Section 5 of [RFC2821]. If those checks indicate owner needs to be careful in publishing ADSP records to ensure
that the Author domain does not exist for mail, e.g., the domain that their practices are communicated correctly to all
has no MX, A, or AAAA record, the verifier SHOULD terminate with receivers, regardless of how receivers decide to check for ADSP
an error indicating that the domain is out of scope. applicability. When a registered domain name lacks a
corresponding ADSP record, attackers can use it as the Author
Domain in unauthorized email, and sidestep the domain owner's
ADSP policies. To ensure that ADSP will apply to all
registered hostnames in a domain sub-tree, the domain owner
needs to publish ADSP records corresponding to each and every
hostname that has any resource record within that domain and
that could be syntactically valid as the domain part of an
email address.
Fetch Named ADSP Record: The host MUST query DNS for a TXT record Fetch Named ADSP Record: The host MUST query DNS for a TXT record
corresponding to the Author Domain prefixed by "_adsp._domainkey." corresponding to the Author Domain prefixed by "_adsp._domainkey."
(note the trailing dot). (note the trailing dot).
If the result of this query is a "NOERROR" response with an answer If the result of this query is a "NOERROR" response with an answer
which is a valid ADSP record, use that record, and the algorithm which is a valid ADSP record, use that record, and the algorithm
terminates. terminates.
If a query results in a "SERVFAIL" error response, the algorithm If a query results in a "SERVFAIL" error response, the algorithm
skipping to change at page 9, line 47 skipping to change at page 9, line 45
Additional security considerations regarding Author Domain Signing Additional security considerations regarding Author Domain Signing
Practices are found in the DKIM threat analysis [RFC4686]. Practices are found in the DKIM threat analysis [RFC4686].
6.1. ADSP Threat Model 6.1. ADSP Threat Model
Email recipients often have a core set of content authors that they Email recipients often have a core set of content authors that they
already trust. Common examples include financial institutions with already trust. Common examples include financial institutions with
which they have an existing relationship and Internet web transaction which they have an existing relationship and Internet web transaction
sites with which they conduct business. sites with which they conduct business.
Email abuse often seeks to exploit a legitimate email author's name- Email abuse often seeks to exploit the name-recognition that
recognition among recipients, by using the author's domain name in recipients will have, for a legitimate email author, by using its
the From: header field. Especially since many popular MUAs do not domain name in the From: header field. Especially since many popular
display the author's email address, there is no empirical evidence of MUAs do not display the author's email address, there is no empirical
the extent that this particular unauthorized use of a domain name evidence of the extent that this particular unauthorized use of a
contributes to recipient deception or that eliminating it will have domain name contributes to recipient deception or that eliminating it
significant effect. will have significant effect.
However, closing this exploit could facilitate some types of However, closing this exploit could facilitate some types of
optimized processing by receive-side message filtering engines, since optimized processing by receive-side message filtering engines, since
it could permit them to maintain higher-confidence assertions about it could permit them to maintain higher-confidence assertions about
From: header field uses of a domain, when the occurrence is From: header field uses of a domain, when the occurrence is
authorized. authorized.
Unauthorized uses of domain names occur elsewhere in messages, as do Unauthorized uses of domain names occur elsewhere in messages, as do
unauthorized uses of organizations' names. These attacks are outside unauthorized uses of organizations' names. These attacks are outside
the scope of this specification. the scope of this specification.
ADSP does not provide any benefit--nor, indeed, have any effect at ADSP does not provide any benefit--nor, indeed, have any effect at
all--unless an external system acts upon the verdict, either by all--unless an external system acts upon the verdict, either by
treating the message differently during the delivery process or by treating the message differently during the delivery process or by
showing some indicator to the end recipient. Such a system is out of showing some indicator to the end recipient. Such a system is out of
scope for this specification. scope for this specification.
ADSP checkers may perform multiple DNS lookups per Alleged Author ADSP Checkers may perform multiple DNS lookups per Alleged Author
Domain. Since these lookups are driven by domain names in email Domain. Since these lookups are driven by domain names in email
message headers of possibly fraudulent email, legitimate ADSP message headers of possibly fraudulent email, legitimate ADSP
checkers can become participants in traffic multiplication attacks. Checkers can become participants in traffic multiplication attacks.
6.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 ADSP records to influence a receiver's decision on how it impersonate ADSP records, in an attempt to influence a receiver's
will handle mail. However, such an attacker is more likely to attack decision on how it will handle mail. However, such an attacker is
at a higher level, e.g., redirecting A or MX record lookups in order more likely to attack at a higher level, e.g., redirecting A or MX
to capture traffic that was legitimately intended for the target record lookups in order to capture traffic that was legitimately
domain. These DNS security issues are addressed by DNSSEC [RFC4033]. intended for the target domain. These DNS security issues are
addressed by DNSSEC [RFC4033].
Because ADSP operates within the framework of the legacy e-mail Because ADSP operates within the framework of the legacy e-mail
system, the default result in the absence of an ADSP record is that system, the default result in the absence of an ADSP record is that
the domain does not sign all of its messages. It is therefore the domain does not sign all of its messages. It is therefore
important that the ADSP clients distinguish a DNS failure such as important that the ADSP clients distinguish a DNS failure such as
"SERVFAIL" from other DNS errors so that appropriate actions can be "SERVFAIL" from other DNS errors so that appropriate actions can be
taken. taken.
6.3. DNS Wildcards 6.3. DNS Wildcards
If a domain contains wildcards, then any name that matches the If a domain has valid wildcard MX, A, or AAAA records, then any
wildcard according to [RFC4592] is potentially a valid mail domain subdomain that does not otherwise exist according to [RFC4592] is a
eligible for ADSP. It is possible to add a wildcard TXT record valid mail domain. It is possible to add a wildcard TXT record
alongside a wildcard MX that will provide suitable ADSP records for alongside a wildcard MX that will provide suitable ADSP records for
any domain chosen by an attacker, since if the wildcard synthesizes any domain chosen by an attacker, since if the wildcard synthesizes
chosen-name.example.com IN MX, it will then also synthesize chosen-name.example.com IN MX, it will then also synthesize
_adsp._domainkey.chosen-name.example.com IN TXT. However multiple _adsp._domainkey.chosen-name.example.com IN TXT. However multiple
wildcard TXT records produce an undefined ADSP result, which means wildcard TXT records produce an undefined ADSP result, which means
you cannot also publish both ADSP records and records for any other you cannot also publish both ADSP records and records for any other
TXT-using protocol (such as SPF) for a wildcard domain. TXT-using protocol (such as SPF) for a wildcard domain.
7. References 7. References
skipping to change at page 11, line 40 skipping to change at page 11, line 37
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
7.2. References - Informative 7.2. References - Informative
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
(DKIM) Signing Practices Protocol", RFC 5016, (DKIM) Signing Practices Protocol", RFC 5016,
October 2007. October 2007.
Appendix A. Usage Examples Appendix A. Usage Examples
These examples are intended to illustrate typical uses of ADSP. They These examples are intended to illustrate typical uses of ADSP. They
are not intended to be exhaustive, nor to apply to every domain's or are not intended to be exhaustive, nor to apply to every domain's or
mail system's individual situation. mail system's individual situation.
skipping to change at page 13, line 11 skipping to change at page 13, line 7
provider. In that case, the provider can generate the keys and DKIM 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 DNS records itself and use the subdomain in the Author address in the
mail. mail.
Regardless of the DNS and key management strategy chosen, whoever Regardless of the DNS and key management strategy chosen, whoever
maintains the DKIM records for the domain could also install an ADSP maintains the DKIM records for the domain could also install an ADSP
record containing "all". record containing "all".
A.3. Bulk Mailing Domains with Discardable Mail A.3. Bulk Mailing Domains with Discardable Mail
In some cases, a domain might sign all of its outgoing mail with an In some cases, a domain might sign all its outgoing mail with an
Author Signature, but prefer that recipient systems discard mail Author Signature, but prefer that recipient systems discard mail
without a valid Author Signature to avoid confusion from mail sent without a valid Author Signature to avoid confusion from mail sent
from sources that do not apply an Author Signature. (This latter from sources that do not apply an Author Signature. (This latter
kind of mail is sometimes loosely called "forgeries".) In that case, kind of mail is sometimes loosely called "forgeries".) In that case,
it might be appropriate to publish an ADSP record containing it might be appropriate to publish an ADSP record containing
"discardable". Note that a domain SHOULD NOT publish a "discardable" "discardable". Note that a domain SHOULD NOT publish a "discardable"
record if it wishes to maximize the likelihood that mail from the record if it wishes to maximize the likelihood that mail from the
domain is delivered, since it could cause some fraction of the mail domain is delivered, since it could cause some fraction of the mail
the domain sends to be discarded. the domain sends to be discarded.
skipping to change at page 13, line 39 skipping to change at page 13, line 35
in this specification. in this specification.
A.5. Non-email Domains A.5. Non-email Domains
If a domain sends no mail at all, it can safely publish a If a domain sends no mail at all, it can safely publish a
"discardable" ADSP record, since any mail with an author address in "discardable" ADSP record, since any mail with an author address in
the domain is a forgery. the domain is a forgery.
Appendix B. Acknowledgements Appendix B. Acknowledgements
This document greatly benefited from comments by Steve Atkins, Jon This document is a modification of draft-ietf-dkim-ssp-02, and
Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael greatly benefited from comments by Dave Crocker, JD Falk, Tony Finch,
Thomas, and Wietse Venema. Michael Hammer, Arvel Hathcock, Michael Thomas, and Wietse Venema.
Appendix C. Change Log Appendix C. Change Log
*NOTE TO RFC EDITOR: This section may be removed upon publication of *NOTE TO RFC EDITOR: This section may be removed upon publication of
this document as an RFC.* this document as an RFC.*
C.1. Changes since -ietf-dkim-03 C.1. Changes since -ietf-dkim-03
o Name change for title and filename, to be ADSP o Name change for title and filename, to be ADSP
o String changes throughout, to author Domain signing practices and o String changes throughout, to author Domain signing practices and
to aDsp. to aDsp.
o Added some keywords. o Added some keywords.
o Clarified comparison of local part and domain in Author Address.
o Streamlined the Abstract. o Streamlined the Abstract.
o Revised text of last bullet in Results list. o Revised text of last bullet in Results list.
o Removed definitions not used in the document. o Removed definitions not used in the document.
o Removed all specification details pertaining to sub-domains. o Removed all specification details pertaining to sub-domains.
o Moved Lookup Procedure up one document level. o Moved Lookup Procedure up one document level.
skipping to change at page 14, line 38 skipping to change at page 14, line 29
o Fixed xml for figures, including labeling ABNF with new xml2rfc o Fixed xml for figures, including labeling ABNF with new xml2rfc
construct. construct.
o Revised wildcard text. o Revised wildcard text.
o Removed 't' tag. o Removed 't' tag.
o Removed ADSP Flags Registry section. o Removed ADSP Flags Registry section.
o Changed ABNF use of whitespace from WSP back to FWS, for
consistency with dkim-base.
C.2. Changes since -ietf-dkim-02 C.2. Changes since -ietf-dkim-02
o Merge in more text from ADSP draft. o Merge in more text from ADSP draft.
o Phrase actions as host's rather than checker. o Phrase actions as host's rather than checker.
o Explanatory description of i= matching. o Explanatory description of i= matching.
o Lookup procedure consistently refers to one ADSP record per o Lookup procedure consistently refers to one ADSP record per
lookup. lookup.
skipping to change at page 18, line 7 skipping to change at page 17, line 35
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 Steve Atkins
Sendmail, Inc. Word to the Wise
6475 Christie Ave, Suite 350 PO Box 7086
Emeryville, CA 94608 San Carlos, CA 94070-7086
US
Phone: +1 510 594 5501
Email: eric+dkim@sendmail.org
Jim Fenton
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
Phone: +1 408 526 5914
Email: fenton@cisco.com
Mark Delany Phone: +1 650 678 3453
Yahoo! Inc. Email: steve-asp@wordtothewise.com
701 First Avenue URI: http://wordtothewise.com/
Sunnyvale, CA 94089 Jon Callas
PGP Corp.
3460 W Bayshore
Palo Alto, CA 94303
US
Phone: +1 408 349 6831 Phone: +1 650 319 9000
Email: markd+dkim@yahoo-inc.com Email: jon@pgp.com
URI: http://www.pgp.com/
John Levine John Levine (editor)
Taughannock Networks Taughannock Networks
PO Box 727 PO Box 727
Trumansburg, NY 14886 Trumansburg, NY 14886
Phone: +1 831 480 2300 Phone: +1 831 480 2300
Email: standards@taugh.com Email: standards@taugh.com
URI: http://www.taugh.com URI: http://www.taugh.com
Ellen Siegel
Constant Contact
1601 Trapelo Rd, Ste 329
Waltham, MA 02451
US
Phone: +1 781 472 8100
Email: esiegel@constantcontact.com
URI: http://constantcontact.com/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). 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
 End of changes. 32 change blocks. 
105 lines changed or deleted 94 lines changed or added

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