One document matched: draft-ietf-dkim-ssp-08.xml
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5321 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml'>
<!ENTITY rfc5322 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
<!ENTITY rfc4033 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc5234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY rfc4686 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4686.xml'>
<!ENTITY rfc4592 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4592.xml'>
<!ENTITY rfc4871 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4871.xml'>
<!ENTITY rfc5016 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5016.xml'>
<!ENTITY rfc5226 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<rfc category="std" docName="draft-ietf-dkim-ssp-08" ipr="full3978">
<front>
<title abbrev="ADSP">DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)</title>
<author fullname="Eric Allman" initials="E." surname="Allman">
<organization>Sendmail, Inc.</organization>
<address>
<postal>
<street>6475 Christie Ave, Suite 350</street>
<city>Emeryville</city>
<code>94608</code>
<region>CA</region>
</postal>
<phone>+1 510 594 5501</phone>
<email>eric+dkim@sendmail.org</email>
</address>
</author>
<author fullname="Jim Fenton" initials="J." surname="Fenton">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>MS SJ-9/2</street>
<street>170 W. Tasman Drive</street>
<city>San Jose</city>
<code>95134-1706</code>
<region>CA</region>
</postal>
<phone>+1 408 526 5914</phone>
<email>fenton@cisco.com</email>
</address>
</author>
<author fullname="Mark Delany" initials="M." surname="Delany">
<organization>Yahoo! Inc.</organization>
<address>
<postal>
<street>701 First Avenue</street>
<city>Sunnyvale</city>
<code>94089</code>
<region>CA</region>
</postal>
<phone>+1 408 349 6831</phone>
<email>markd+dkim@yahoo-inc.com</email>
</address>
</author>
<author fullname="John Levine" initials="J." surname="Levine">
<organization>Taughannock Networks</organization>
<address>
<postal>
<street>PO Box 727</street>
<city>Trumansburg</city>
<code>14886</code>
<region>NY</region>
</postal>
<phone>+1 831 480 2300</phone>
<email>standards@taugh.com</email>
<uri>http://www.taugh.com</uri>
</address>
</author>
<date month="December" year="2008" />
<area>Applications / Email</area>
<!-- <workgroup>DKIM</workgroup> -->
<keyword>email, e-mail, rfc5322, rfc 5322, rfc822, rfc 822, rfc5321, rfc
5321, rfc821, rfc 821, rfc4871, rfc 4871, DKIM, domain keys, domainkeys,
ADSP, ADSP, SSP, architecture, mta, user, delivery, smtp, submission,
email, e-mail, smtp, Internet, mailfrom, mail from, author, return
address, sender signing, signing practices</keyword>
<abstract>
<t>DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages. This document specifies an adjunct
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
record that can advertise whether a domain signs its outgoing mail, and
how other hosts can access that record. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key,
and thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain.</t>
<t>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
a priori indication of forgery. In fact, during early phases of
deployment it is very likely that most messages will remain unsigned.
However, some domains might decide to sign all of their outgoing mail,
for example, to protect their brand names. It might be
desirable for such
domains to be able to advertise that fact to other hosts. This is the
topic of Author Domain Signing Practices (ADSP).</t>
<t>Hosts implementing this specification can inquire what Author Signing
Practices a domain advertises. This inquiry is called an Author
Signing Practices check.</t>
<t>The basic requirements for ADSP are given in <xref target="RFC5016"
/>. This document refers extensively to <xref target="RFC4871" /> and
assumes the reader is familiar with it.</t>
<t>
<list style="hanging">
<t hangText="Requirements Notation: "> The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119" />
</t>
</list>
</t>
</section>
<section title="Language and Terminology">
<section title="Terms Imported from DKIM Signatures Specification">
<t>Some terminology used herein is derived directly from <xref
target="RFC4871" />. In several cases, references in that document
to Sender have been changed to Author here, to emphasize the
relationship to the Author address(es) in the From: header field
described in <xref target="RFC5322" />. Briefly, <list
style="symbols">
<t>A "Signer" is the agent that signs a message, as defined in
section 2.1 of <xref target="RFC4871" />.</t>
<!--
Selectors have nothing to do with ADSP.
<t>A "Selector" specifies which of the keys published by a signing
domain is to be queried, as defined in section 3.1 of <xref
target="RFC4871" />.</t>
-->
<t>A "Local-part" is the part of an address preceding the @ character,
as defined in <xref target="RFC5322" /> and used in <xref
target="RFC4871" />.</t>
</list></t>
</section>
<section title="Valid Signature">
<t>A "Valid Signature" is any signature on a message which correctly
verifies using the procedure described in section 6.1 of <xref
target="RFC4871" />.</t>
</section>
<section title="Author Address">
<t>An "Author Address" is an email address in the From header field of
a message <xref target="RFC5322" />. If the From header field
contains multiple addresses, the message has multiple Author
Addresses.</t>
</section>
<section title="Author Domain">
<t>An "Author Domain" is everything to the right of the "@" in an
Author Address (excluding the "@" itself).</t>
</section>
<!-- <section title="Alleged Signer">
<t>An "Alleged Signer" is the identity of the signer claimed in a DKIM-Signature
header field in a message received; it is
"alleged" because it has not yet been verified.</t>
</section> -->
<section title="Alleged Author">
<t>An "Alleged Author" is an Author Address of a message; it is
"alleged" because it has not yet been checked.</t>
</section>
<section title="Author Domain Signing Practices">
<t>"Author Domain Signing Practices" (or just "practices") consist of
a machine-readable record published by the domain of an Alleged
Author which includes statements about the domain's practices with
respect to mail it sends with its domain in the From: line.</t>
</section>
<section title="Author Signature">
<t>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 <spanx style="verb">i=</spanx> tag or its default value
from the <spanx style="verb">d=</spanx> tag) matches an Author
Address in the message. When the identity of the user or agent
includes a Local-part, the identities match if the Local-parts are
the same string,
and the domains are the same string.
Otherwise, the identities match if the domains are the same string.
Following <xref target="RFC5321" />, Local-part comparisons are
case sensitive, but domain comparisons are case insensitive.</t>
<t>For example, if a message has a Valid Signature, with the
DKIM-Signature field containing <spanx style="verb"
>i=a@domain.example</spanx>, then domain.example is asserting that
it takes responsibility for the message. If the message's From:
field contains the address <spanx style="verb"
>b@domain.example</spanx> and an ADSP query produces a <spanx
style="verb">dkim=all</spanx> or <spanx style="verb"
>dkim=discardable</spanx> result, that 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 satisfy ADSP.</t>
</section>
</section>
<section title="Operation Overview">
<t>Domain owners can publish ADSP information via a query mechanism such
as the Domain Name System; specific details are given in <xref
target="dnsrep" />.</t>
<t>Hosts can look up the ADSP information of the domain(s) specified by
the Author Address(es) as described in <xref target="Lookup" />. If a
message has multiple Author Addresses the ADSP lookups SHOULD be
performed independently on each address. This document does not
address the process a host might use to combine the lookup results. </t>
<section anchor="applicability" title="ADSP Applicability">
<t> ADSP as defined in this document is bound to DNS. For this reason,
ADSP is applicable only to Author Domains with appropriate DNS
records (see Note below). The handling of other Author Domains is
outside the scope of this document. However, attackers may use such
domain names in a deliberate attempt to sidestep an organization's
ADSP policy statements. It is up to the ADSP checker implementation
to return an appropriate error result for Author Domains outside the
scope of ADSP.</t>
<t>ADSP applies to specific domains, not domain subtrees.
If, for example, an Author Address were user@domain.example, the
Author Domain would be domain.example, and the applicable ADSP
record would be at _adsp._domainkey.domain.example.
An Author Address in a subdomain such as user@sub.domain.example
would have a different ADSP record at
_adsp._domainkey.sub.domain.example.
ADSP makes no connection between a domain and its parent or
child domains.
<list style="hanging">
<t hangText="Note: "> The results from DNS queries that are
intended to validate a domain name unavoidably approximate
the set of Author Domains that can appear in legitimate email.
For example, a DNS A record could belong to a device that does
not even have an email implementation. It is up to the checker
to decide what degree of approximation is acceptable.</t>
</list></t>
</section>
<section title="ADSP Usage">
<t>Depending on the Author Domain(s) and the signatures in a message,
a recipient gets varying amounts of useful information from each
ADSP lookup. <list style="symbols">
<t>If a message has no Valid Signature, the ADSP result is
directly relevant to the message.</t>
<t>If a message has a Valid Signature from an Author Domain, ADSP
provides no benefit relative to that domain since the message is
already known to be compliant with any possible ADSP for that
domain.</t>
<t>If a message has a Valid Signature from a domain other than an
Author Domain, the receiver can use both the Signature and the
ADSP result in its evaluation of the message.</t>
</list></t>
</section>
<section title="ADSP Results">
<t>An ADSP lookup for an Author Address produces one of four possible
results: <list style="symbols">
<t>Messages from this domain might or might not have an author
signature. This is the default if the domain exists in the DNS
but no ADSP record is found.</t>
<t>All messages from this domain are signed.</t>
<t>All messages from this domain are signed and
discardable, i.e., if a message
arrives without a valid Author Signature,
the domain encourages the recipient(s) to discard it.</t>
<t>This domain is out of scope, i.e., the domain does not
exist in the DNS.</t>
</list></t>
<t>An ADSP lookup could terminate without producing any result if
a DNS lookup results in a temporary failure.</t>
</section>
</section>
<section title="Detailed Description">
<section anchor="dnsrep" title="DNS Representation">
<t>ADSP records are published using the DNS TXT resource record type.</t>
<!-- <t>NON-NORMATIVE DISCUSSION [to be removed before publication]: There
has been considerable discussion on the DKIM WG mailing list
regarding the relative advantages of TXT and a new resource record
(RR) type. Read the archive for details.</t>-->
<t>The RDATA for ADSP resource records is textual in format, with
specific syntax and semantics relating to their role in describing
ADSP. The "Tag=Value List" syntax described in section 3.2 of <xref
target="RFC4871" /> is used, modified to use WSP rather than FWS.
Records not in compliance with that
syntax or the syntax of individual tags described in Section 4.3
MUST be ignored (considered equivalent to a NODATA result) for
purposes of ADSP, although they MAY cause the logging of warning
messages via an appropriate system logging mechanism. If the RDATA
contains multiple character strings, the strings are logically
concatenated with no delimiters between the strings.
<list style="hanging">
<t hangText="Note: "> ADSP changes the "Tag=Value List" syntax
from <xref target="RFC4871" /> to use WSP rather than FWS
in its DNS records.
Domains
MUST NOT publish ADSP records with wildcard names.
Wildcards within a domain publishing ADSP records pose
a particular
problem, as discussed in more detail in
<xref target="wildcards" />.</t>
</list></t>
</section>
<section title="Publication of ADSP Records">
<t>ADSP is intended to apply to all mail sent using the domain name
string of an Alleged Author.</t>
<section anchor="syntax" title="Record Syntax">
<t>ADSP records use the "tag=value" syntax described in section 3.2
of <xref target="RFC4871" />, modified to use WSP rather than FWS.
Every ADSP record MUST start with an outbound signing practices
tag, so
the first four characters of the record are lower case "dkim",
followed by optional whitespace and "=".</t>
<t>Tags used in ADSP records are described below. Unrecognized tags
MUST be ignored. In the ABNF below, the WSP token,
and the ALPHA and DIGIT tokens are
imported from <xref target="RFC5234" />. <list style="hanging">
<t hangText="dkim= ">Outbound signing practices for the domain
(plain-text; REQUIRED). Possible values are as follows: <list
style="hanging">
<t hangText="unknown ">The domain might sign some or all
email.</t>
<t hangText="all ">All mail from the domain is signed with
an Author Signature.</t>
<t hangText="discardable ">All mail from the domain is
signed with an Author Signature. Furthermore, if a message
arrives without a valid Author Signature due to
modification in transit, submission via a path without
access to a signing key, or any other reason, the domain
encourages the recipient(s) to discard it.</t>
</list>
Any other values are treated as "unknown".
<figure>
<preamble>ABNF:</preamble>
<artwork type="ABNF" align="center"><![CDATA[adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
("unknown" / "all" / "discardable")]]></artwork>
</figure>
</t>
</list></t>
</section>
</section>
<section anchor="Lookup" title="ADSP Lookup Procedure">
<t>Hosts doing an ADSP lookup MUST produce a result that is
semantically 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.</t>
<t>For the purposes of this section a "valid ADSP record" is one that
is both syntactically and semantically correct; in particular, it
matches the ABNF for a <spanx style="verb">tag-list</spanx> and
starts with a valid <spanx style="verb">dkim</spanx> tag.</t>
<t>
<list style="hanging">
<t hangText="Check Domain Scope: "> An ADSP checker
implementation MUST determine whether a given Author Domain is
within scope for ADSP. Given the background in <xref
target="applicability" /> the checker MUST decide which
degree of approximation is acceptable. The checker MUST
return an appropriate error result for Author Domains that are
outside the scope of ADSP.</t>
<t>The host MUST
perform a DNS query for a record corresponding to the Author
Domain (with no prefix). The type of the query can be of any type,
since this step is only to determine if the domain itself exists
in DNS. This query MAY be done in parallel with the query to
fetch the named ADSP Record. If the result of this query is that
the Author domain does not exist in the DNS (often called an
<spanx style="verb">NXDOMAIN</spanx> error, rcode=3 in <xref target="RFC1035" />), the algorithm
MUST terminate with an error indicating that the domain is
out of scope.
Note that a result with rcode=0 but no records
(often called <spanx style="verb">NODATA</spanx>)
is not the same as NXDOMAIN.
<list style="empty">
<t>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 <spanx
style="verb">NXDOMAIN</spanx> 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.</t>
</list></t>
<t>If the domain does exist,
the checker MAY make more extensive checks to verify the
existence of the domain, such as the ones described in
Section 5 of <xref target="RFC5321" />.
If those checks indicate that the Author domain does not exist
for mail, e.g., the domain has no MX, A, or AAAA record,
the checker SHOULD terminate with an error
indicating that the domain is out of scope.
</t>
<t hangText="Fetch Named ADSP Record: ">The host MUST query DNS
for a TXT record corresponding to the Author Domain prefixed by
<spanx style="verb">_adsp._domainkey.</spanx> (note the
trailing dot).</t>
<t>If the result of this query is a <spanx style="verb"
>NOERROR</spanx> response (rcode=0 in <xref target="RFC1035" />)
with an answer which is a single record that is a valid ADSP
record, use that record, and the algorithm
terminates.</t>
<t>If the result of the query is NXDOMAIN or NOERROR with zero
records, there is no ADSP record.
If the result of the query contains more than one record,
or a record that is not a valid ADSP record,
the ADSP result is undefined.</t>
<t>If a query results in a <spanx style="verb">SERVFAIL</spanx>
error response (rcode=2 in <xref target="RFC1035" />), the algorithm terminates without returning a
result; possible actions include queuing the message or
returning an SMTP error indicating a temporary failure.</t>
</list>
</t>
<t>See <xref target="lookupex" /> for examples of ADSP Lookup.</t>
</section>
</section>
<section title="IANA Considerations">
<t>ADSP adds the following namespaces to the IANA registry. In all
cases, new values are assigned only for values that have been
documented in a published RFC after IETF Review as specified in <xref
target="RFC5226" />.</t>
<!--
Selectors have nothing to do with ADSP.
<t>INFORMATIVE NOTE [ to be removed before publication ]: RFC 4871
defines a selector as a sub-domain, importing the term from RFC 5322.
A sub-domain starts with a letter or digit, hence names such as _asp
that start with an underscore cannot collide with valid selectors.</t>
-->
<section title="ADSP Specification Tag Registry">
<t>An ADSP record provides for a list of specification tags. IANA has
established the ADSP Specification Tag Registry for specification
tags that can be used in ADSP fields.</t>
<t>The initial entry in the registry is: <figure>
<artwork align="center"><![CDATA[+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| dkim | (this document) |
+------+-----------------+]]></artwork>
<postamble>ADSP Specification Tag Registry Initial
Values</postamble>
</figure>
</t>
</section>
<section title="ADSP Outbound Signing Practices Registry">
<t>The <spanx style="verb">dkim=</spanx> tag spec, defined in <xref
target="syntax" />, provides for a value specifying Outbound
Signing Practices. IANA has established the ADSP Outbound Signing
Practices Registry for Outbound Signing Practices.</t>
<t>The initial entries in the registry comprise: <figure>
<artwork align="center"><![CDATA[+-------------+-----------------+
| TYPE | REFERENCE |
+-------------+-----------------+
| unknown | (this document) |
| all | (this document) |
| discardable | (this document) |
+-------------+-----------------+]]></artwork>
<postamble>ADSP Outbound Signing Practices Registry Initial
Values</postamble>
</figure>
</t>
</section>
</section>
<section title="Security Considerations">
<t>Security considerations in the ADSP are mostly related to attempts on
the part of malicious senders to represent themselves as authors for
whom they are not authorized to send mail, often in an attempt to
defraud either the recipient or an Alleged Author.</t>
<t>Additional security considerations regarding Author Domain Signing
Practices are found in <xref target="RFC4686">the DKIM threat
analysis</xref>.</t>
<section title="ADSP Threat Model">
<t>Email recipients often have a core set of content authors that they
already trust. Common examples include financial institutions with
which they have an existing relationship and Internet web
transaction sites with which they conduct business.</t>
<t>Email abuse often seeks to exploit a legitimate email author's
name-recognition among recipients, by using the author's
domain name in the From: header field. Especially since many popular
MUAs do not display the author's email address, there is no
empirical evidence of the extent that this particular unauthorized
use of a domain name contributes to recipient deception or that
eliminating it will have significant effect.</t>
<t>However, closing this exploit could facilitate some types of
optimized processing by receive-side message filtering engines,
since it could permit them to maintain higher-confidence assertions
about From: header field uses of a domain, when the occurrence is
authorized.</t>
<t>Unauthorized uses of domain names occur elsewhere in messages, as
do unauthorized uses of organizations' names. These attacks are
outside the scope of this specification.</t>
<t>ADSP does not provide any benefit--nor, indeed, have any effect at
all--unless an external system acts upon the verdict, either by
treating the message differently during the delivery process or by
showing some indicator to the end recipient. Such a system is out of
scope for this specification.</t>
<t>ADSP checkers may perform multiple DNS lookups per Alleged Author
Domain. Since these lookups are driven by domain names in email
message headers of possibly fraudulent email, legitimate ADSP
checkers can become participants in traffic multiplication
attacks on domains that appear in fraudulent email.</t>
</section>
<section title="DNS Considerations">
<t>An attacker might attack the DNS infrastructure in an attempt to
impersonate ADSP records to influence a receiver's
decision on how it will handle mail. However, such an attacker is
more likely to attack at a higher level, e.g., redirecting A or MX
record lookups in order to capture traffic that was legitimately
intended for the target domain. These DNS security issues are
addressed by <xref target="RFC4033">DNSSEC</xref>.</t>
<t>Because ADSP operates within the framework of the legacy e-mail
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
important that the ADSP clients distinguish a DNS failure such as
<spanx style="verb">SERVFAIL</spanx> from other DNS errors so that
appropriate actions can be taken.</t>
</section>
<section anchor="wildcards" title="DNS Wildcards">
<t>DNS wildcards (described in <xref target="RFC4592" />) that exist
in the DNS hierarchy at or above the domain being checked
interfere with the ability to verify the
scope of the ADSP check described in <xref target="Lookup" />.
For example, a
wildcard record for *.domain.example makes all subdomains
such as foo.domain.example exist in the DNS.
Domains that intend to make active use of ADSP by publishing
a practice other than Unknown are advised
to avoid the use of wildcards elsewhere in their hierarchy.</t>
<t>If a domain contains wildcards, then any name that matches
the wildcard can appear to be a valid mail domain eligible for ADSP.
But the <spanx style="verb">_adsp._domainkey.</spanx> prefix
on ADSP records does not allow publication of wildcard records that
cover ADSP records without also covering non-ADSP records,
nor of wildcard records that cover non-ADSP records without
also covering ADSP records.
Hence a domain MUST NOT publish wildcard ADSP records.</t>
</section>
</section>
</middle>
<back>
<references title="References - Normative"> &rfc1035; &rfc2119; &rfc5226;
&rfc5322; &rfc4033; &rfc5234; &rfc4871; &rfc4592;</references>
<references title="References - Informative"> &rfc4686; &rfc5321; &rfc5016; </references>
<section anchor="lookupex" title="Lookup Examples">
<t>Assume the example domain publishes these DNS records:
(In these examples, the numbers in parentheses are comments to help
identify the records, not part of the records themselves.)</t>
<figure>
<artwork>
aaa.example A 192.0.2.1 (1)
_adsp._domainkey.aaa.example TXT "dkim=all" (2)
bbb.example MX 10 mail.bbb.example (3)
mail.bbb.example A 192.0.2.2 (4)
</artwork></figure>
<section title="Domain and ADSP exist">
<t>A mail message contains this From: header line:</t>
<figure>
<artwork>
From: bob@aaa.example (Bob the Author)</artwork>
</figure>
<t>The ADSP Lookup first identifies the Author Address
bob@aaa.example and the Author Domain aaa.example.
It does an MX DNS query for aaa.example, and gets back
a NOERROR result with no DNS records.
(There's no MX record, but since record (1) exists, the name
exists in the DNS.)
Since that query didn't return an error,
the Lookup proceeds to a TXT DNS
query for _adsp._domainkey.aaa.example, which returns
record (2).
Since this is a valid DKIM record, the result is that all messages
from this domain are signed.</t>
</section>
<section title="Domain exists, ADSP does not exist">
<t>A mail message contains this From: header line:</t>
<figure>
<artwork>
From: alice@bbb.example (Old-fashioned Alice)</artwork>
</figure>
<t>The ADSP Lookup first identifies the Author Address
alice@bbb.example and the Author Domain bbb.example.
It does an MX DNS query for bbb.example, and gets back
record (3).
Since that query didn't return an error, it then proceeds to a TXT DNS
query for _adsp._domainkey.bbb.example, which returns NXDOMAIN.
Since the domain exists but there is no ADSP record, ADSP returns
the default unknown result: messages may or may not have an author signature.
</t>
</section>
<section title="Domain does not exist">
<t>A mail message contains this From: header line:</t>
<figure>
<artwork>
From: frank@ccc.example (Unreliable Frank)</artwork>
</figure>
<t>The ADSP Lookup first identifies the Author Address
frank@ccc.example and the Author Domain ccc.example.
It does an MX DNS query for ccc.example, and gets back
an NXDOMAIN result since there are no records at all for ccc.example.
The lookup terminates with the result that the domain does not exist
in the DNS and so is out of scope.
</t>
</section>
</section>
<section title="Usage Examples">
<t>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
mail system's individual situation.</t>
<t>Domain managers are advised to consider the ways that mail processing
can modify messages in ways that will invalidate an existing DKIM
signature, such as mailing lists, courtesy forwarders, and other paths
that could add or modify headers, or modify the message body. In that
case, if the modifications invalidate the DKIM signature, recipient
hosts will consider the mail not to have an Author Signature, even
though the signature was present when the mail was originally sent.</t>
<section anchor="allexamp" title="Single Location Domains">
<t>A common mail system configuration handles all of a domain's users'
incoming and outgoing mail through a single MTA or group of MTAs. In
that case, the MTA(s) can be configured to sign outgoing mail with
an Author Signature.</t>
<t>In this situation it might be appropriate to publish an ADSP record
for the domain containing "all", depending on whether the users also
send mail through other paths that do not apply an Author Signature.
Such paths could include MTAs at hotels or hotspot networks used by
travelling users, web sites that provide "mail an article"
features,
user messages sent through mailing lists,
or third party mail clients that
support multiple user identities.</t>
</section>
<section title="Bulk Mailing Domains">
<t>Another common configuration uses a domain solely for bulk or
broadcast mail, with no individual human users, again typically
sending all the mail through a single MTA or group of MTAs that can
apply an Author Signature. In this case, the domain's management can
be confident that all of its outgoing mail will be sent through the
signing MTA. Lacking individual users, the domain is unlikely to
participate in mailing lists, but could still send mail through
other paths that might invalidate signatures.</t>
<t>Domain owners often use specialist mailing providers to send their
bulk mail. In that case, the mailing provider needs access to a
suitable signing key in order to apply an Author Signature. One
possible route would be for the domain owner to generate the key and
give it to the mailing provider. Another would be for the domain to
delegate a subdomain to the mailing provider, for example,
bigbank.example might delegate email.bigbank.example to such a
provider. In that case, the provider can generate the keys and DKIM
DNS records itself and use the subdomain in the Author address in
the mail.</t>
<t>Regardless of the DNS and key management strategy chosen, whoever
maintains the DKIM records for the domain could also install an
ADSP record containing "all".</t>
</section>
<section title="Bulk Mailing Domains with Discardable Mail">
<t>In some cases, a domain might sign all of its outgoing mail with an
Author Signature, but prefer that recipient systems discard mail
without a valid Author Signature to avoid confusion from mail sent
from sources that do not apply an Author Signature.
(In the case of domains with tightly controlled outgoing mail,
this latter
kind of mail is sometimes loosely called "forgeries".) In that case,
it might be appropriate to publish an ADSP record containing
"discardable". Note that a domain SHOULD NOT publish a "discardable"
record if it wishes to maximize the likelihood that mail from the
domain is delivered, since it could cause some fraction of the mail
the domain sends to be discarded.</t>
</section>
<section title="Third Party Senders">
<t>Another common use case is for a third party to enter into an
agreement whereby that third party will send bulk or other mail on
behalf of a designated author or author domain, using that domain in
the RFC5322 From: or other headers. Due to the many and varied
complexities of such agreements, third party signing is not
addressed in this specification.
<!-- The
authors anticipate that as mail systems gain experience
with DKIM, it will become possible to codify best practices
of this and other usages of DKIM. --></t>
</section>
<section title="Domains with Independent Users and Liberal Use Policies">
<t>When a domain has independent users and its usage policy
does not explicitly restrict them to sending mail only from
designated mail servers (e.g. many ISP domains and even some
corporate domains), then it is only appropriate to publish
an ADSP record containing "unknown". Publishing either "all"
or "discardable" will likely result in significant breakage
because independent users are likely to send mail from the
external paths enumerated in <xref target="allexamp" />.</t>
</section>
<section title="Non-email Domains">
<t>If a domain sends no mail at all, it can safely
publish a "discardable" ADSP record, since any mail with an author
address in the domain is a forgery.</t>
</section>
</section>
<section title="Acknowledgements">
<t>This document greatly benefited from comments by
Steve Atkins, Jon Callas, Dave Crocker,
JD Falk, Arvel Hathcock,
Ellen Siegel, Michael Thomas, and Wietse Venema.</t>
</section>
<section title="Change Log">
<t>
<spanx style="strong">NOTE TO RFC EDITOR: This section may be removed
upon publication of this document as an RFC.</spanx>
</t>
<section title="Changes since -ietf-dkim-07">
<t>Clarify that ADSP records use WSP rather than FWS in 4.1 and 4.2.1.</t>
</section>
<section title="Changes since -ietf-dkim-06">
<t>Minor editorial changes suggested by AD:
<list style="symbols">
<t>expand DKIM in title</t>
<t> clarify that there's no
subdomain matching in <xref target="applicability" /></t>
<t>ADSP lookup can terminate without a result if the DNS lookup fails</t>
<t>random dkim= values are treated as unknown</t>
<t>in 4.2 note WSP not FWS</t>
<t>in 4.3 note that NODATA is not NXDOMAIN</t>
<t>add new Appendix A with lookup examples</t>
</list>
</t>
<t>Also address Tony's nits in
http://mipassoc.org/pipermail/ietf-dkim/2008q3/010720.html.
Make the examples consistently use the .example domain.</t>
</section>
<section title="Changes since -ietf-dkim-05">
<t>Minor editorial nits: define NOERROR, SERVFAIL, NXDOMAIN as rfc1035
rcodes, change some punctuation, IANA section change IETF Consensus
to the new IETF Review.</t>
</section>
<section title="Changes since -ietf-dkim-04">
<t>
<list style="symbols">
<t>Require dkim at the front of each record.</t>
<t>Disparage wildcard records.</t>
<t>Changed ABNF use of whitespace from FWS back to WSP,
dkim-base is wrong.</t>
<t>RFC 2434 -> 5226, make ref to 4686 informational since it's
not standards track.</t>
<t>Improve examples with material from Ellen.</t>
</list>
</t>
</section>
<section title="Changes since -ietf-dkim-03">
<t>
<list style="symbols">
<t>Name change for title and filename, to be ADSP</t>
<t>String changes throughout, to author Domain signing practices
and to aDsp.</t>
<t>Added some keywords.</t>
<t>Clarified comparison of local part and domain in Author Address.</t>
<t>Streamlined the Abstract.</t>
<t>Revised text of last bullet in Results list.</t>
<t>Removed definitions not used in the document.</t>
<t>Removed all specification details pertaining to sub-domains.</t>
<t>Moved Lookup Procedure up one document level.</t>
<t>Revised domain validity specification. Part in ADSP Usage in
Operations section, and part as it as first step in Lookup.</t>
<t>Fixed xml for figures, including labeling ABNF with new xml2rfc
construct.</t>
<t>Revised wildcard text.</t>
<t>Removed 't' tag.</t>
<t>Removed ADSP Flags Registry section.</t>
<t>Changed ABNF use of whitespace from WSP back to FWS,
for consistency with dkim-base.</t>
</list>
</t>
</section>
<section title="Changes since -ietf-dkim-02">
<t>
<list style="symbols">
<t>Merge in more text from ADSP draft.</t>
<t>Phrase actions as host's rather than checker.</t>
<t>Explanatory description of i= matching.</t>
<t>Lookup procedure consistently refers to one ADSP record per
lookup.</t>
<t>Update security section w/ language from W. Venema</t>
<t>Simplify imports of terms from other RFCs, add Local-part, 4234
-> 5234.</t>
<t>Add usage example appendix.</t>
<t>Add IANA considerations.</t>
<t>Update authors list</t>
</list>
</t>
</section>
<section title="Changes since -ietf-dkim-ssp-01">
<t>
<list style="symbols">
<t>Reworded introduction for clarity.</t>
<t>Various definition clarifications.</t>
<t>Changed names of practices to unknown, all, and discardable.</t>
<t>Removed normative language mandating use of SSP in particular
situations (issue 1538).</t>
<t>Clarified possible confusion over handling of syntax errors.</t>
<t>Removed normative language from Introduction (issue 1538).</t>
<t>Changed "Originator" to "Author" throughout (issue 1529).</t>
<t>Removed all references to Third-Party Signatures (issues 1512,
1521).</t>
<t>Removed all mention of "Suspicious" (issues 1528, 1530).</t>
<t>Removed "t=y" (testing) flag (issue 1540).</t>
<t>Removed "handling" tag (issue 1513).</t>
<t>Broke up the "Sender Signing Practices Check Procedure" into
two algorithms: fetching the SSP record and interpretation
thereof (issues 1531, 1535; partially addresses issue 1520).
Interpretation is now the responsibility of the Evaluator.</t>
<t>Document restructuring for better flow and remove redundancies
(some may address issue 1523, but I'm not sure I understand that
issue completely; also issues 1532, 1537).</t>
<t>Removed all mention of how this interacts with users, even
though it makes parts of the document harder to understand
(issue 1526).</t>
<t>Introduced the concepts of "SSP Checker" and "Evaluator".</t>
<t>Multiple author case now handled my separate invocations of SSP
checker by Evaluator (issue 1525).</t>
<t>Removed check to avoid querying top-level domains.</t>
<t>Changed ABNF use of whitespace from [FWS] to *WSP (partially
addresses issue 1543).</t>
</list>
</t>
</section>
<section title="Changes since -ietf-dkim-ssp-00">
<t>
<list style="symbols">
<t>Clarified Operation Overview and eliminated use of Legitimate
as the counterpart of Suspicious since the words have different
meanings.</t>
<t>Improved discussion (courtesy of Arvel Hathcock) of the use of
TXT records in DNS vs. a new RR type.</t>
<t>Clarified publication rules for multilevel names.</t>
<t>Better description of overall record syntax, in particular that
records with unknown tags are considered syntactically correct.</t>
<t>Clarified Sender Signing Practices Check Procedure, primarily
by use of new term Author Domain.</t>
<t>Eliminated section "Third-Party Signatures and Mailing Lists"
that is better included in the DKIM overview document.</t>
<t>Added "handling" tag to express alleged sending domain's
preference about handling of Suspicious messages.</t>
<t>Clarified handling of SERVFAIL error in SSP check.</t>
<t>Replaced "entity" with "domain", since with the removal of
user-granularity SSP, the only entities having sender signing
policies are domains.</t>
</list>
</t>
</section>
<section title="Changes since -allman-ssp-02">
<t>
<list style="symbols">
<t>Removed user-granularity SSP and u= tag.</t>
<t>Replaced DKIMP resource record with a TXT record.</t>
<t>Changed name of the primary tag from "p" to "dkim".</t>
<t>Replaced lookup algorithm with one which traverses upward at
most one level.</t>
<t>Added description of records to be published, and effect of
wildcard records within the domain, on SSP.</t>
</list>
</t>
</section>
<section title="Changes since -allman-ssp-01">
<t>
<list style="symbols">
<t>Changed term "Sender Signing Policy" to "Sender Signing
Practices".</t>
<t>Changed query methodology to use a separate DNS resource record
type, DKIMP.</t>
<t>Changed tag values from SPF-like symbols to words.</t>
<t>User level policies now default to that of the domain if not
specified.</t>
<t>Removed the "Compliance" section since we're still not clear on
what goes here.</t>
<t>Changed the "parent domain" policy to only search up one level
(assumes that subdomains will publish SSP records if
appropriate).</t>
<t>Added detailed description of SSP check procedure.</t>
</list>
</t>
</section>
<section title="Changes since -allman-ssp-00">
<t>From a "diff" perspective, the changes are extensive. Semantically,
the changes are:<list style="symbols">
<t>Added section on "Third-Party Signatures and Mailing Lists"</t>
<t>Added "Compliance" (transferred from -base document). I'm not
clear on what needs to be done here.</t>
<t>Extensive restructuring.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:38:14 |