7Network Working Group E. Allman
8Request for Comments: 5617 Sendmail, Inc.
9Category: Standards Track J. Fenton
18DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
22 DomainKeys Identified Mail (DKIM) defines a domain-level
23 authentication framework for email to permit verification of the
24 source and contents of messages. This document specifies an adjunct
25 mechanism to aid in assessing messages that do not contain a DKIM
26 signature for the domain used in the author's address. It defines a
27 record that can advertise whether a domain signs its outgoing mail as
28 well as how other hosts can access that record.
32 This document specifies an Internet standards track protocol for the
33 Internet community, and requests discussion and suggestions for
34 improvements. Please refer to the current edition of the "Internet
35 Official Protocol Standards" (STD 1) for the standardization state
36 and status of this protocol. Distribution of this memo is unlimited.
40 Copyright (c) 2009 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents in effect on the date of
45 publication of this document (http://trustee.ietf.org/license-info).
46 Please review these documents carefully, as they describe your rights
47 and restrictions with respect to this document.
58Allman, et al. Standards Track [Page 1]
60RFC 5617 ADSP August 2009
65 1. Introduction ....................................................3
66 2. Language and Terminology ........................................3
67 2.1. Terms Imported from the DKIM Signatures Specification ......3
68 2.2. Valid Signature ............................................4
69 2.3. Author Address .............................................4
70 2.4. Author Domain ..............................................4
71 2.5. Alleged Author .............................................4
72 2.6. Author Domain Signing Practices ............................4
73 2.7. Author Domain Signature ....................................4
74 3. Operation Overview ..............................................5
75 3.1. ADSP Applicability .........................................5
76 3.2. ADSP Usage .................................................6
77 3.3. ADSP Results ...............................................6
78 4. Detailed Description ............................................7
79 4.1. DNS Representation .........................................7
80 4.2. Publication of ADSP Records ................................7
81 4.2.1. Record Syntax .......................................7
82 4.3. ADSP Lookup Procedure ......................................9
83 5. IANA Considerations ............................................10
84 5.1. ADSP Specification Tag Registry ...........................10
85 5.2. ADSP Outbound Signing Practices Registry ..................11
86 5.3. Authentication-Results Method Registry Update .............11
87 5.4. Authentication-Results Result Registry Update .............11
88 6. Security Considerations ........................................13
89 6.1. ADSP Threat Model .........................................14
90 6.2. DNS Considerations ........................................14
91 6.3. DNS Wildcards .............................................15
92 6.4. Inappropriate Application of Author Domain Signatures .....15
93 7. References .....................................................16
94 7.1. Normative References ......................................16
95 7.2. Informative References ....................................16
96 Appendix A. Lookup Examples ......................................17
97 A.1. Domain and ADSP Exist .....................................17
98 A.2. Domain Exists, ADSP Does Not Exist ........................17
99 A.3. Domain Does Not Exist .....................................17
100 Appendix B. Usage Examples .......................................18
101 B.1. Single Location Domains ...................................18
102 B.2. Bulk Mailing Domains ......................................18
103 B.3. Bulk Mailing Domains with Discardable Mail ................19
104 B.4. Third-Party Senders .....................................19
105 B.5. Domains with Independent Users and Liberal Use Policies ...19
106 B.6. Non-Email Domains .......................................20
107 Appendix C. Acknowledgements .....................................20
114Allman, et al. Standards Track [Page 2]
116RFC 5617 ADSP August 2009
121 DomainKeys Identified Mail (DKIM) defines a mechanism by which email
122 messages can be cryptographically signed, permitting a signing domain
123 to claim responsibility for the introduction of a message into the
124 mail stream. Message recipients can verify the signature by querying
125 the Signer's domain directly to retrieve the appropriate public key,
126 and thereby confirm that the message was attested to by a party in
127 possession of the private key for the signing domain.
129 However, the legacy of the Internet is such that not all messages
130 will be signed, and the absence of a signature on a message is not an
131 a priori indication of forgery. In fact, during early phases of
132 deployment, it is very likely that most messages will remain
133 unsigned. However, some domains might decide to sign all of their
134 outgoing mail, for example, to protect their brand names. It might
135 be desirable for such domains to be able to advertise that fact to
136 other hosts. This is the topic of Author Domain Signing Practices
139 Hosts implementing this specification can inquire what Author Domain
140 Signing Practices a domain advertises. This inquiry is called an
141 Author Domain Signing Practices check.
143 The basic requirements for ADSP are given in [RFC5016]. This
144 document refers extensively to [RFC4871] and assumes the reader is
147 Requirements Notation:
149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
150 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
151 in this document are to be interpreted as described in [RFC2119].
1532. Language and Terminology
1552.1. Terms Imported from the DKIM Signatures Specification
157 Some terminology used herein is derived directly from [RFC4871]. In
158 several cases, references in that document to "Sender" have been
159 changed to "Author" here, to emphasize the relationship to the Author
160 address(es) in the From: header field described in [RFC5322].
163 o A "Signer" is the agent that signs a message, as defined in
164 Section 2.1 of [RFC4871].
170Allman, et al. Standards Track [Page 3]
172RFC 5617 ADSP August 2009
175 o A "Local-part" is the part of an address preceding the @
176 character, as defined in [RFC5322] and used in [RFC4871].
180 A "Valid Signature" is any signature on a message that correctly
181 verifies using the procedure described in Section 6.1 of [RFC4871].
185 An "Author Address" is an email address in the From: header field of
186 a message [RFC5322]. If the From: header field contains multiple
187 addresses, the message has multiple Author Addresses.
191 An "Author Domain" is everything to the right of the "@" in an Author
192 Address (excluding the "@" itself).
196 An "Alleged Author" is an Author Address of a message; it is
197 "alleged" because it has not yet been checked.
1992.6. Author Domain Signing Practices
201 "Author Domain Signing Practices" (or just "practices") consist of a
202 machine-readable record published by the domain of an Alleged Author
203 that includes statements about the domain's practices with respect to
204 mail it sends with its domain in the From: line.
2062.7. Author Domain Signature
208 An "Author Domain Signature" is a Valid Signature in which the domain
209 name of the DKIM signing entity, i.e., the d= tag in the DKIM-
210 Signature header field, is the same as the domain name in the Author
211 Address. Following [RFC5321], domain name comparisons are case
214 For example, if the From: line address is bob@domain.example, and the
215 message has a Valid Signature with the DKIM-Signature header field
216 containing "d=domain.example", then the message has an Author Domain
226Allman, et al. Standards Track [Page 4]
228RFC 5617 ADSP August 2009
233 Domain owners publish ADSP information via a query mechanism such as
234 the Domain Name System; specific details are given in Section 4.1.
235 Hosts can look up the ADSP information of the domain(s) specified by
236 the Author Address(es) as described in Section 4.3. If a message has
237 multiple Author Addresses, the ADSP lookups SHOULD be performed
238 independently on each address. This document does not address the
239 process a host might use to combine the lookup results.
2413.1. ADSP Applicability
243 ADSP as defined in this document is bound to DNS. For this reason,
244 ADSP is applicable only to Author Domains with appropriate DNS
245 records (i.e., A, AAAA, and/or MX) indicating the possible use of the
246 domain for email. The handling of other Author Domains is outside
247 the scope of this document. However, attackers may use such domain
248 names in a deliberate attempt to sidestep an organization's ADSP
249 policy statements. It is up to the ADSP checker implementation to
250 return an appropriate error result for Author Domains outside the
253 ADSP applies to specific domains, not domain subtrees. If, for
254 example, an Author Address were user@domain.example, the Author
255 Domain would be domain.example, and the applicable ADSP record would
256 be at _adsp._domainkey.domain.example. An Author Address in a
257 subdomain such as user@sub.domain.example would have a different ADSP
258 record at _adsp._domainkey.sub.domain.example. ADSP makes no
259 connection between a domain and its parent or child domains.
261 Note: If an organization wants to publish Author Domain Signing
262 Practices for all the subdomains it uses, such as host names
263 of servers within the domain, it does so by creating ADSP
264 records for every _adsp._domainkey.<sub>.domain.example.
265 Wildcards cannot be used (see Section 6.3.); however,
266 suitable DNS management tools could automate creation of the
269 Note: The results from DNS queries that are intended to validate a
270 domain name unavoidably approximate the set of Author Domains
271 that can appear in legitimate email. For example, a DNS A
272 record could belong to a device that does not even have an
273 email implementation. It is up to the checker to decide what
274 degree of approximation is acceptable.
282Allman, et al. Standards Track [Page 5]
284RFC 5617 ADSP August 2009
289 Depending on the Author Domain(s) and the signatures in a message, a
290 recipient gets varying amounts of useful information from each ADSP
293 o If a message has no Valid Signature, the ADSP result is directly
294 relevant to the message.
296 o If a message has an Author Domain Signature, ADSP provides no
297 benefit relative to that domain since the message is already known
298 to be compliant with any possible ADSP for that domain.
300 o If a message has a Valid Signature other than an Author Domain
301 Signature, the receiver can use both the Signature and the ADSP
302 result in its evaluation of the message.
306 An ADSP lookup for an Author Address produces one of four possible
309 o Messages from this domain might or might not have an Author Domain
310 Signature. This is the default if the domain exists in the DNS
311 but no ADSP record is found.
313 o All messages from this domain are signed with an Author Domain
316 o All messages from this domain are signed with an Author Domain
317 Signature and are discardable, i.e., if a message arrives without
318 a valid Author Domain Signature, the domain encourages the
319 recipient(s) to discard it.
321 o This domain is out of scope, i.e., the domain does not exist in
324 An ADSP lookup could terminate without producing any result if a DNS
325 lookup results in a temporary failure.
338Allman, et al. Standards Track [Page 6]
340RFC 5617 ADSP August 2009
3434. Detailed Description
3454.1. DNS Representation
347 ADSP records are published using the DNS TXT resource record type.
349 The RDATA for ADSP resource records is textual in format, with
350 specific syntax and semantics relating to their role in describing
351 ADSP. The "Tag=Value List" syntax described in Section 3.2 of
352 [RFC4871] is used, modified to use whitespace (WSP) rather than
353 folding whitespace (FWS). Records not in compliance with that syntax
354 or the syntax of individual tags described in Section 4.3 MUST be
355 ignored (considered equivalent to a NODATA result) for purposes of
356 ADSP, although they MAY cause the logging of warning messages via an
357 appropriate system logging mechanism. If the RDATA contains multiple
358 character strings, the strings are logically concatenated with no
359 delimiters between the strings.
361 Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to
362 use WSP rather than FWS in its DNS records.
364 Domains MUST NOT publish ADSP records with wildcard names. Wildcards
365 within a domain publishing ADSP records pose a particular problem, as
366 discussed in more detail in Section 6.3.
3684.2. Publication of ADSP Records
370 ADSP is intended to apply to all mail sent using the domain name
371 string of an Alleged Author.
375 ADSP records use the "tag=value" syntax described in Section 3.2 of
376 [RFC4871], modified to use WSP rather than FWS. Every ADSP record
377 MUST start with an outbound signing-practices tag, so the first four
378 characters of the record are lowercase "dkim", followed by optional
381 Tags used in ADSP records are described below. Unrecognized tags
382 MUST be ignored. In the ABNF below, the WSP token is imported from
385 dkim= Outbound Signing Practices for the domain (plain-text;
386 REQUIRED). Possible values are as follows:
388 unknown The domain might sign some or all email.
394Allman, et al. Standards Track [Page 7]
396RFC 5617 ADSP August 2009
399 all All mail from the domain is signed with an Author
403 All mail from the domain is signed with an
404 Author Domain Signature. Furthermore, if a
405 message arrives without a valid Author Domain
406 Signature due to modification in transit,
407 submission via a path without access to a
408 signing key, or any other reason, the domain
409 encourages the recipient(s) to discard it.
411 Any other values are treated as "unknown".
415 ; Copyright (c) 2009 IETF Trust and the persons identified as
416 ; authors of the code. All rights reserved.
418 ; Redistribution and use in source and binary forms, with or without
419 ; modification, are permitted provided that the following conditions
422 ; - Redistributions of source code must retain the above copyright
423 ; notice, this list of conditions and the following disclaimer.
425 ; - Redistributions in binary form must reproduce the above copyright
426 ; notice, this list of conditions and the following disclaimer in
427 ; the documentation and/or other materials provided with the
430 ; - Neither the name of Internet Society, IETF or IETF Trust, nor the
431 ; names of specific contributors, may be used to endorse or promote
432 ; products derived from this software without specific prior
433 ; written permission.
435 ; THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
436 ; 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
437 ; LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
438 ; FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
439 ; COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
440 ; INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
441 ; (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
442 ; SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
443 ; HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
444 ; CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
445 ; OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
446 ; EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
450Allman, et al. Standards Track [Page 8]
452RFC 5617 ADSP August 2009
455 adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
456 ("unknown" / "all" / "discardable" /
458 x-adsp-dkim-tag = hyphenated-word ; for future extension
459 ; hyphenated-word is defined in RFC 4871
4614.3. ADSP Lookup Procedure
463 Hosts doing an ADSP lookup MUST produce a result that is semantically
464 equivalent to applying the following steps in the order listed below.
465 In practice, these steps can be performed in parallel in order to
466 improve performance. However, implementations SHOULD avoid doing
467 unnecessary DNS lookups.
469 For the purposes of this section, a "valid ADSP record" is one that
470 is both syntactically and semantically correct; in particular, it
471 matches the ABNF for a "tag-list" and starts with a valid "dkim" tag.
474 An ADSP checker implementation MUST determine whether a given
475 Author Domain is within the scope for ADSP. Given the background
476 in Section 3.1, the checker MUST decide which degree of
477 approximation is acceptable. The checker MUST return an
478 appropriate error result for Author Domains that are outside the
481 The host MUST perform a DNS query for a record corresponding to
482 the Author Domain (with no prefix). The type of the query can be
483 of any type, since this step is only to determine if the domain
484 itself exists in DNS. This query MAY be done in parallel with the
485 query to fetch the named ADSP Record. If the result of this query
486 is that the Author Domain does not exist in the DNS (often called
487 an NXDOMAIN error, rcode=3 in [RFC1035]), the algorithm MUST
488 terminate with an error indicating that the domain is out of
489 scope. Note that a result with rcode=0 but no records (often
490 called NODATA) is not the same as NXDOMAIN.
492 NON-NORMATIVE DISCUSSION: Any resource record type could be
493 used for this query since the existence of a resource record of
494 any type will prevent an NXDOMAIN error. MX is a reasonable
495 choice for this purpose because this record type is thought to
496 be the most common for domains used in email, and will
497 therefore produce a result that can be more readily cached than
500 If the domain does exist, the checker MAY make more extensive
501 checks to verify the existence of the domain, such as the ones
502 described in Section 5 of [RFC5321]. If those checks indicate
506Allman, et al. Standards Track [Page 9]
508RFC 5617 ADSP August 2009
511 that the Author Domain does not exist for mail, e.g., the domain
512 has no MX, A, or AAAA record, the checker SHOULD terminate with an
513 error indicating that the domain is out of scope.
515 Fetch Named ADSP Record:
516 The host MUST query DNS for a TXT record corresponding to the
517 Author Domain prefixed by "_adsp._domainkey." (note the trailing
520 If the result of this query is a NOERROR response (rcode=0 in
521 [RFC1035]) with an answer that is a single record that is a valid
522 ADSP record, use that record, and the algorithm terminates.
524 If the result of the query is NXDOMAIN or NOERROR with zero
525 records, there is no ADSP record. If the result of the query
526 contains more than one record, or a record that is not a valid
527 ADSP record, the ADSP result is undefined.
529 If a query results in a "SERVFAIL" error response (rcode=2 in
530 [RFC1035]), the algorithm terminates without returning a result;
531 possible actions include queuing the message or returning an SMTP
532 error indicating a temporary failure.
534 See Appendix A for examples of ADSP lookup.
5365. IANA Considerations
538 ADSP adds the following namespaces to the IANA registry. In all
539 cases, new values are assigned only for values that have been
540 documented in a published RFC after IETF Review, as specified in
5435.1. ADSP Specification Tag Registry
545 An ADSP record provides for a list of specification tags. IANA has
546 established the ADSP Specification Tag Registry for specification
547 tags that can be used in ADSP fields.
549 The initial entry in the registry is:
551 +------+-----------------+
553 +------+-----------------+
554 | dkim | (RFC 5617) |
555 +------+-----------------+
557 ADSP Specification Tag Registry Initial Values
562Allman, et al. Standards Track [Page 10]
564RFC 5617 ADSP August 2009
5675.2. ADSP Outbound Signing Practices Registry
569 The "dkim=" tag specification, defined in Section 4.2.1, provides for
570 a value specifying Outbound Signing Practices. IANA has established
571 the ADSP Outbound Signing Practices Registry for Outbound Signing
574 The initial entries in the registry comprise:
576 +-------------+-----------------+
578 +-------------+-----------------+
579 | unknown | (RFC 5617) |
581 | discardable | (RFC 5617) |
582 +-------------+-----------------+
584 ADSP Outbound Signing Practices Registry Initial Values
5865.3. Authentication-Results Method Registry Update
588 IANA has added the following to the Email Authentication Method Name
599 value: contents of the [RFC5322] From: header field, with comments
6025.4. Authentication-Results Result Registry Update
604 IANA has added the following in the Email Authentication Result Name
609 Existing/New Code: existing
611 Defined In: [RFC5451]
613 Auth Method: dkim-adsp (added)
618Allman, et al. Standards Track [Page 11]
620RFC 5617 ADSP August 2009
623 Meaning: No DKIM Author Domain Signing Practices (ADSP) record was
628 Existing/New Code: existing
630 Defined In: [RFC5451]
632 Auth Method: dkim-adsp (added)
634 Meaning: This message had an Author Domain Signature that was
635 validated. (An ADSP check is not strictly required to be
636 performed for this result since a valid Author Domain
637 Signature satisfies all possible ADSP policies.)
641 Existing/New Code: new
645 Auth Method: dkim-adsp
647 Meaning: No valid Author Domain Signature was found on the message
648 and the published ADSP was "unknown".
652 Existing/New Code: existing
654 Defined In: [RFC5451]
656 Auth Method: dkim-adsp (added)
658 Meaning: No valid Author Domain Signature was found on the message
659 and the published ADSP was "all".
663 Existing/New Code: new
667 Auth Method: dkim-adsp
669 Meaning: No valid Author Domain Signature was found on the message
670 and the published ADSP was "discardable".
674Allman, et al. Standards Track [Page 12]
676RFC 5617 ADSP August 2009
681 Existing/New Code: new
685 Auth Method: dkim-adsp
687 Meaning: Evaluating the ADSP for the Author's DNS domain indicated
688 that the Author's DNS domain does not exist.
692 Existing/New Code: existing
694 Defined In: [RFC5451]
696 Auth Method: dkim-adsp (added)
698 Meaning: An ADSP record could not be retrieved due to some error
699 that is likely transient in nature, such as a temporary DNS
700 error. A later attempt may produce a final result.
704 Existing/New Code: existing
706 Defined In: [RFC5451]
708 Auth Method: dkim-adsp (added)
710 Meaning: An ADSP record could not be retrieved due to some error
711 that is likely not transient in nature, such as a permanent
712 DNS error. A later attempt is unlikely to produce a final
7156. Security Considerations
717 Security considerations in the ADSP are mostly related to attempts on
718 the part of malicious senders to represent themselves as Authors for
719 whom they are not authorized to send mail, often in an attempt to
720 defraud either the recipient or an Alleged Author.
722 Additional security considerations regarding Author Domain Signing
723 Practices are found in the DKIM threat analysis [RFC4686].
730Allman, et al. Standards Track [Page 13]
732RFC 5617 ADSP August 2009
7356.1. ADSP Threat Model
737 Email recipients often have a core set of content Authors that they
738 already trust. Common examples include financial institutions with
739 which they have an existing relationship and Internet web transaction
740 sites with which they conduct business.
742 Email abuse often seeks to exploit a legitimate email Author's name-
743 recognition among recipients by using the Author's domain name in the
744 From: header field. Especially since many popular Mail User Agents
745 (MUAs) do not display the Author's email address, there is no
746 empirical evidence of the extent that this particular unauthorized
747 use of a domain name contributes to recipient deception or that
748 eliminating it will have significant effect.
750 However, closing this potential exploit could facilitate some types
751 of optimized processing by receive-side message filtering engines,
752 since it could permit them to maintain higher-confidence assertions
753 about From: header field uses of a domain when the occurrence is
756 Unauthorized uses of domain names occur elsewhere in messages, as do
757 unauthorized uses of organizations' names. These attacks are outside
758 the scope of this specification.
760 ADSP does not provide any benefit -- nor, indeed, have any effect at
761 all -- unless an external system acts upon the verdict, either by
762 treating the message differently during the delivery process or by
763 showing some indicator to the end recipient. Such a system is out of
764 scope for this specification.
766 ADSP checkers may perform multiple DNS lookups per Alleged Author
767 Domain. Since these lookups are driven by domain names in email
768 message headers of possibly fraudulent email, legitimate ADSP
769 checkers can become participants in traffic multiplication attacks on
770 domains that appear in fraudulent email.
7726.2. DNS Considerations
774 An attacker might attack the DNS infrastructure in an attempt to
775 impersonate ADSP records to influence a receiver's decision on how it
776 will handle mail. However, such an attacker is more likely to attack
777 at a higher level, e.g., redirecting A or MX record lookups in order
778 to capture traffic that was legitimately intended for the target
779 domain. These DNS security issues are addressed by DNSSEC [RFC4033].
786Allman, et al. Standards Track [Page 14]
788RFC 5617 ADSP August 2009
791 Because ADSP operates within the framework of the legacy email
792 system, the default result in the absence of an ADSP record is that
793 the domain does not sign all of its messages. It is therefore
794 important that the ADSP clients distinguish a DNS failure such as
795 "SERVFAIL" from other DNS errors so that appropriate actions can be
800 DNS wildcards (described in [RFC4592]) that exist in the DNS
801 hierarchy at or above the domain being checked interfere with the
802 ability to verify the scope of the ADSP check described in
803 Section 4.3. For example, a wildcard record for *.domain.example
804 makes all subdomains such as foo.domain.example exist in the DNS.
805 Domains that intend to make active use of ADSP by publishing a
806 practice other than unknown are advised to avoid the use of wildcards
809 If a domain contains wildcards, then any name that matches the
810 wildcard can appear to be a valid mail domain eligible for ADSP. But
811 the "_adsp._domainkey." prefix on ADSP records does not allow
812 publication of wildcard records that cover ADSP records without also
813 covering non-ADSP records, nor does it allow publication of wildcard
814 records that cover non-ADSP records without also covering ADSP
815 records. A domain that uses ADSP practices other than unknown SHOULD
816 NOT publish wildcard records.
8186.4. Inappropriate Application of Author Domain Signatures
820 In one model of DKIM usage, a domain signs messages that are in
821 transit through their system. Since any signature whose domain
822 matches the Author Domain is, by definition, an Author Domain
823 Signature, it would be unwise to sign mail whose Author Domain is the
824 Signer's domain if the mail is not known to meet the domain's
825 standards for an Author Domain Signature.
827 One such use case is where a domain might apply such a signature
828 following application of an Authentication-Results header field as
829 described in Section 7.1 of [RFC5451]. This problem can be easily
830 avoided either by not applying a signature that might be confused
831 with an Author Domain Signature or by applying a signature from some
832 other domain, such as a subdomain of the Author Domain.
842Allman, et al. Standards Track [Page 15]
844RFC 5617 ADSP August 2009
8497.1. Normative References
851 [RFC1035] Mockapetris, P., "Domain names - implementation and
852 specification", STD 13, RFC 1035, November 1987.
854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
855 Requirement Levels", BCP 14, RFC 2119, March 1997.
857 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
858 Rose, "DNS Security Introduction and Requirements",
859 RFC 4033, March 2005.
861 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
862 System", RFC 4592, July 2006.
864 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
865 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
866 Signatures", RFC 4871, May 2007.
868 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
869 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
872 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
873 Specifications: ABNF", STD 68, RFC 5234, January 2008.
875 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
878 [RFC5451] Kucherawy, M., "Message Header Field for Indicating
879 Message Authentication Status", RFC 5451, April 2009.
8817.2. Informative References
883 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
884 Identified Mail (DKIM)", RFC 4686, September 2006.
886 [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
887 (DKIM) Signing Practices Protocol", RFC 5016,
890 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
898Allman, et al. Standards Track [Page 16]
900RFC 5617 ADSP August 2009
903Appendix A. Lookup Examples
905 Assume the example domain publishes these DNS records (in these
906 examples, the numbers in parentheses are comments to help identify
907 the records, not part of the records themselves):
909 aaa.example A 192.0.2.1 (1)
910 _adsp._domainkey.aaa.example TXT "dkim=all" (2)
912 bbb.example MX 10 mail.bbb.example (3)
913 mail.bbb.example A 192.0.2.2 (4)
915A.1. Domain and ADSP Exist
917 A mail message contains this From: header line:
919 From: bob@aaa.example (Bob the Author)
921 The ADSP lookup first identifies the Author Address bob@aaa.example
922 and the Author Domain aaa.example. It does an MX DNS query for
923 aaa.example and gets back a NOERROR result with no DNS records.
924 (There's no MX record, but since record (1) exists, the name exists
925 in the DNS.) Since that query didn't return an error, the lookup
926 proceeds to a TXT DNS query for _adsp._domainkey.aaa.example, which
927 returns record (2). Since this is a valid ADSP record, the result is
928 that all messages from this domain are signed.
930A.2. Domain Exists, ADSP Does Not Exist
932 A mail message contains this From: header line:
934 From: alice@bbb.example (Old-fashioned Alice)
936 The ADSP lookup first identifies the Author Address alice@bbb.example
937 and the Author Domain bbb.example. It does an MX DNS query for
938 bbb.example and gets back record (3). Since that query didn't return
939 an error, it then proceeds to a TXT DNS query for
940 _adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the
941 domain exists but there is no ADSP record, ADSP returns the default
942 unknown result: messages may or may not have an author domain
945A.3. Domain Does Not Exist
947 A mail message contains this From: header line:
949 From: frank@ccc.example (Unreliable Frank)
954Allman, et al. Standards Track [Page 17]
956RFC 5617 ADSP August 2009
959 The ADSP lookup first identifies the Author Address frank@ccc.example
960 and the Author Domain ccc.example. It does an MX DNS query for
961 ccc.example and gets back an NXDOMAIN result since there are no
962 records at all for ccc.example. The lookup terminates with the
963 result that the domain does not exist in the DNS and so is out of
966Appendix B. Usage Examples
968 These examples are intended to illustrate typical uses of ADSP. They
969 are not intended to be exhaustive or to apply to every domain's or
970 mail system's individual situation.
972 Domain managers are advised to consider the ways that mail processing
973 can modify messages in ways that will invalidate an existing DKIM
974 signature, such as mailing lists, courtesy forwarders, and other
975 paths that could add or modify headers, or modify the message body.
976 If the modifications invalidate the DKIM signature, recipient hosts
977 will consider the mail not to have an Author Domain Signature, even
978 though the signature was present when the mail was originally sent.
980B.1. Single Location Domains
982 One common mail system configuration handles all of a domain's users'
983 incoming and outgoing mail through a single Mail Transport Agent
984 (MTA) or group of MTAs. With this configuration, the MTA(s) can be
985 configured to sign outgoing mail with an Author Domain Signature.
987 In this situation, it might be appropriate to publish an ADSP record
988 for the domain containing "all", depending on whether the users also
989 send mail through other paths that do not apply an Author Domain
990 Signature. Such paths could include MTAs at hotels or hotspot
991 networks used by travelling users, web sites that provide "mail an
992 article" features, user messages sent through mailing lists, or
993 third-party mail clients that support multiple user identities.
995B.2. Bulk Mailing Domains
997 Another common configuration uses a domain solely for bulk or
998 broadcast mail, with no individual human users -- again, typically
999 sending all the mail through a single MTA or group of MTAs that can
1000 apply an Author Domain Signature. In this case, the domain's
1001 management can be confident that all of its outgoing mail will be
1002 sent through the signing MTA(s). Lacking individual users, the
1003 domain is unlikely to participate in mailing lists, but could still
1004 send mail through other paths that might invalidate signatures.
1010Allman, et al. Standards Track [Page 18]
1012RFC 5617 ADSP August 2009
1015 Domain owners often use specialist mailing providers to send their
1016 bulk mail. In this case, the mailing provider needs access to a
1017 suitable signing key in order to apply an Author Domain Signature.
1018 One possible route would be for the domain owner to generate the key
1019 and give it to the mailing provider. Another would be for the domain
1020 to delegate a subdomain to the mailing provider, for example,
1021 bigbank.example might delegate email.bigbank.example to such a
1022 provider; in this case, the provider can generate the keys and DKIM
1023 DNS records itself and use the subdomain in the Author Address in the
1026 Regardless of the DNS and key management strategy chosen, whoever
1027 maintains the DKIM records for the domain could also install an ADSP
1028 record containing "all".
1030B.3. Bulk Mailing Domains with Discardable Mail
1032 In some cases, a domain might sign all of its outgoing mail with an
1033 Author Domain Signature and prefer that recipient systems discard
1034 mail without a valid Author Domain Signature in order to avoid having
1035 its mail confused with mail sent from sources that do not apply an
1036 Author Domain Signature. (In the case of domains with tightly
1037 controlled outgoing mail, this latter kind of mail is sometimes
1038 loosely called "forgeries".) In such cases, it might be appropriate
1039 to publish an ADSP record containing "discardable". Note that a
1040 domain SHOULD NOT publish a "discardable" record if it wishes to
1041 maximize the likelihood that mail from the domain is delivered, since
1042 it could cause some fraction of the mail the domain sends to be
1045B.4. Third-Party Senders
1047 Another common use case is for a third party to enter into an
1048 agreement whereby that third party will send bulk or other mail on
1049 behalf of a designated Author or Author Domain, using that domain in
1050 the [RFC5322] From: or other headers. Due to the many and varied
1051 complexities of such agreements, third-party signing is not addressed
1052 in this specification.
1054B.5. Domains with Independent Users and Liberal Use Policies
1056 When a domain has independent users and its usage policy does not
1057 explicitly restrict them to sending mail only from designated mail
1058 servers (e.g., many ISP domains and even some corporate domains),
1059 then it is only appropriate to publish an ADSP record containing
1060 "unknown". Publishing either "all" or "discardable" will likely
1061 result in significant breakage because independent users are likely
1062 to send mail from the external paths enumerated in Appendix B.1.
1066Allman, et al. Standards Track [Page 19]
1068RFC 5617 ADSP August 2009
1071B.6. Non-Email Domains
1073 If a domain sends no mail at all, it can safely publish a
1074 "discardable" ADSP record, since any mail with an Author Address in
1075 the domain is a forgery.
1077Appendix C. Acknowledgements
1079 This document greatly benefited from comments by Steve Atkins, Jon
1080 Callas, Dave Crocker, Pasi Eronen, JD Falk, Arvel Hathcock, Ellen
1081 Siegel, Michael Thomas, and Wietse Venema.
1122Allman, et al. Standards Track [Page 20]
1124RFC 5617 ADSP August 2009
1131 6475 Christie Ave, Suite 350
1132 Emeryville, CA 94608
1134 Phone: +1 510 594 5501
1135 EMail: eric+dkim@sendmail.org
1141 San Jose, CA 95134-1706
1143 Phone: +1 408 526 5914
1144 EMail: fenton@cisco.com
1152 Phone: +1 408 349 6831
1153 EMail: markd+dkim@yahoo-inc.com
1157 Taughannock Networks
1159 Trumansburg, NY 14886
1161 Phone: +1 831 480 2300
1162 EMail: standards@taugh.com
1163 URI: http://www.taugh.com
1178Allman, et al. Standards Track [Page 21]