idnits 2.17.1 draft-ietf-dkim-ssp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 5, 2009) is 5553 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FWS' is mentioned on line 908, but not defined ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Allman 3 Internet-Draft Sendmail, Inc. 4 Intended status: Standards Track J. Fenton 5 Expires: August 9, 2009 Cisco Systems, Inc. 6 M. Delany 7 Yahoo! Inc. 8 J. Levine 9 Taughannock Networks 10 February 5, 2009 12 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) 13 draft-ietf-dkim-ssp-09 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 9, 2009. 38 Copyright Notice 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 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 DomainKeys Identified Mail (DKIM) defines a domain-level 53 authentication framework for email to permit verification of the 54 source and contents of messages. This document specifies an adjunct 55 mechanism to aid in assessing messages that do not contain a DKIM 56 signature for the domain used in the author's address. It defines a 57 record that can advertise whether a domain signs its outgoing mail, 58 and how other hosts can access that record. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4 64 2.1. Terms Imported from DKIM Signatures Specification . . . . 4 65 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 5 67 2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5 68 2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 5 69 2.6. Author Domain Signing Practices . . . . . . . . . . . . . 5 70 2.7. Author Signature . . . . . . . . . . . . . . . . . . . . . 5 71 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. ADSP Applicability . . . . . . . . . . . . . . . . . . . . 6 73 3.2. ADSP Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 7 75 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7 77 4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 8 78 4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 9 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 10 81 5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 11 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11 84 6.2. DNS Considerations . . . . . . . . . . . . . . . . . . . . 12 85 6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 7.1. References - Normative . . . . . . . . . . . . . . . . . . 13 88 7.2. References - Informative . . . . . . . . . . . . . . . . . 13 89 Appendix A. Lookup Examples . . . . . . . . . . . . . . . . . . . 14 90 A.1. Domain and ADSP exist . . . . . . . . . . . . . . . . . . 14 91 A.2. Domain exists, ADSP does not exist . . . . . . . . . . . . 14 92 A.3. Domain does not exist . . . . . . . . . . . . . . . . . . 15 93 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 15 94 B.1. Single Location Domains . . . . . . . . . . . . . . . . . 15 95 B.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15 96 B.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 16 97 B.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 16 98 B.5. Domains with Independent Users and Liberal Use Policies . 17 99 B.6. Non-email Domains . . . . . . . . . . . . . . . . . . . . 17 100 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17 101 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17 102 D.1. Changes since -ietf-dkim-08 . . . . . . . . . . . . . . . 17 103 D.2. Changes since -ietf-dkim-07 . . . . . . . . . . . . . . . 17 104 D.3. Changes since -ietf-dkim-06 . . . . . . . . . . . . . . . 18 105 D.4. Changes since -ietf-dkim-05 . . . . . . . . . . . . . . . 18 106 D.5. Changes since -ietf-dkim-04 . . . . . . . . . . . . . . . 18 107 D.6. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 18 108 D.7. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 19 109 D.8. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 20 110 D.9. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 21 111 D.10. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 21 112 D.11. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 22 113 D.12. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 22 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 116 1. Introduction 118 DomainKeys Identified Mail (DKIM) defines a mechanism by which email 119 messages can be cryptographically signed, permitting a signing domain 120 to claim responsibility for the introduction of a message into the 121 mail stream. Message recipients can verify the signature by querying 122 the signer's domain directly to retrieve the appropriate public key, 123 and thereby confirm that the message was attested to by a party in 124 possession of the private key for the signing domain. 126 However, the legacy of the Internet is such that not all messages 127 will be signed, and the absence of a signature on a message is not an 128 a priori indication of forgery. In fact, during early phases of 129 deployment it is very likely that most messages will remain unsigned. 130 However, some domains might decide to sign all of their outgoing 131 mail, for example, to protect their brand names. It might be 132 desirable for such domains to be able to advertise that fact to other 133 hosts. This is the topic of Author Domain Signing Practices (ADSP). 135 Hosts implementing this specification can inquire what Author Signing 136 Practices a domain advertises. This inquiry is called an Author 137 Signing Practices check. 139 The basic requirements for ADSP are given in [RFC5016]. This 140 document refers extensively to [RFC4871] and assumes the reader is 141 familiar with it. 143 Requirements Notation: The key words "MUST", "MUST NOT", 144 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 145 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 146 interpreted as described in [RFC2119] 148 2. Language and Terminology 150 2.1. Terms Imported from DKIM Signatures Specification 152 Some terminology used herein is derived directly from [RFC4871]. In 153 several cases, references in that document to Sender have been 154 changed to Author here, to emphasize the relationship to the Author 155 address(es) in the From: header field described in [RFC5322]. 156 Briefly, 158 o A "Signer" is the agent that signs a message, as defined in 159 section 2.1 of [RFC4871]. 161 o A "Local-part" is the part of an address preceding the @ 162 character, as defined in [RFC5322] and used in [RFC4871]. 164 2.2. Valid Signature 166 A "Valid Signature" is any signature on a message which correctly 167 verifies using the procedure described in section 6.1 of [RFC4871]. 169 2.3. Author Address 171 An "Author Address" is an email address in the From header field of a 172 message [RFC5322]. If the From header field contains multiple 173 addresses, the message has multiple Author Addresses. 175 2.4. Author Domain 177 An "Author Domain" is everything to the right of the "@" in an Author 178 Address (excluding the "@" itself). 180 2.5. Alleged Author 182 An "Alleged Author" is an Author Address of a message; it is 183 "alleged" because it has not yet been checked. 185 2.6. Author Domain Signing Practices 187 "Author Domain Signing Practices" (or just "practices") consist of a 188 machine-readable record published by the domain of an Alleged Author 189 which includes statements about the domain's practices with respect 190 to mail it sends with its domain in the From: line. 192 2.7. Author Signature 194 An "author signature" is a Valid Signature that has the same domain 195 name in the DKIM signing identity as the domain name in the Author 196 Address. If the DKIM signing identity has a Local-part, it is be 197 identical to the Local-part in the Author Address. Following 198 [RFC5321], Local-part comparisons are case sensitive, but domain 199 comparisons are case insensitive. 201 For example, if a message has a Valid Signature, with the DKIM- 202 Signature field containing "i=a@domain.example", then domain.example 203 is asserting that it takes responsibility for the message. If the 204 message's From: field contains the address "b@domain.example", that 205 would mean that the message does not have a valid Author Signature. 206 Even though the message is signed by the same domain, it will not 207 satisfy ADSP that specifies "dkim=all" or "dkim=discardable". 209 Note: ADSP is incompatible with valid DKIM usage in which a signer 210 uses "i=" with values that are not the same as addresses in mail 211 headers. In that case, a possible workaround could be to add a 212 second DKIM signature a "d=" value that matches the Author 213 Address, but no "i=". 215 3. Operation Overview 217 Domain owners publish ADSP information via a query mechanism such as 218 the Domain Name System; specific details are given in Section 4.1. 220 Hosts can look up the ADSP information of the domain(s) specified by 221 the Author Address(es) as described in Section 4.3. If a message has 222 multiple Author Addresses the ADSP lookups SHOULD be performed 223 independently on each address. This document does not address the 224 process a host might use to combine the lookup results. 226 3.1. ADSP Applicability 228 ADSP as defined in this document is bound to DNS. For this reason, 229 ADSP is applicable only to Author Domains with appropriate DNS 230 records (see Note below). The handling of other Author Domains is 231 outside the scope of this document. However, attackers may use such 232 domain names in a deliberate attempt to sidestep an organization's 233 ADSP policy statements. It is up to the ADSP checker implementation 234 to return an appropriate error result for Author Domains outside the 235 scope of ADSP. 237 ADSP applies to specific domains, not domain subtrees. If, for 238 example, an Author Address were user@domain.example, the Author 239 Domain would be domain.example, and the applicable ADSP record would 240 be at _adsp._domainkey.domain.example. An Author Address in a 241 subdomain such as user@sub.domain.example would have a different ADSP 242 record at _adsp._domainkey.sub.domain.example. ADSP makes no 243 connection between a domain and its parent or child domains. 245 Note: If an organization wants to publish Author Domain Signing 246 Practices for all the subdomains it uses, such as host names of 247 servers within the domain, it does so by creating ADSP records for 248 every _adsp._domainkey..domain.example. Wildcards cannot be 249 used (see Section 6.3.); however, suitable DNS management tools 250 could automate creation of the ADSP records. 252 Note: The results from DNS queries that are intended to validate a 253 domain name unavoidably approximate the set of Author Domains that 254 can appear in legitimate email. For example, a DNS A record could 255 belong to a device that does not even have an email 256 implementation. It is up to the checker to decide what degree of 257 approximation is acceptable. 259 3.2. ADSP Usage 261 Depending on the Author Domain(s) and the signatures in a message, a 262 recipient gets varying amounts of useful information from each ADSP 263 lookup. 265 o If a message has no Valid Signature, the ADSP result is directly 266 relevant to the message. 268 o If a message has an Author Signature, ADSP provides no benefit 269 relative to that domain since the message is already known to be 270 compliant with any possible ADSP for that domain. 272 o If a message has a Valid Signature other than an Author Signature, 273 the receiver can use both the Signature and the ADSP result in its 274 evaluation of the message. 276 3.3. ADSP Results 278 An ADSP lookup for an Author Address produces one of four possible 279 results: 281 o Messages from this domain might or might not have an author 282 signature. This is the default if the domain exists in the DNS 283 but no ADSP record is found. 285 o All messages from this domain are signed with an Author Signature. 287 o All messages from this domain are signed with an Author Signature 288 and discardable, i.e., if a message arrives without a valid Author 289 Signature, the domain encourages the recipient(s) to discard it. 291 o This domain is out of scope, i.e., the domain does not exist in 292 the DNS. 294 An ADSP lookup could terminate without producing any result if a DNS 295 lookup results in a temporary failure. 297 4. Detailed Description 299 4.1. DNS Representation 301 ADSP records are published using the DNS TXT resource record type. 303 The RDATA for ADSP resource records is textual in format, with 304 specific syntax and semantics relating to their role in describing 305 ADSP. The "Tag=Value List" syntax described in section 3.2 of 306 [RFC4871] is used, modified to use WSP rather than FWS. Records not 307 in compliance with that syntax or the syntax of individual tags 308 described in Section 4.3 MUST be ignored (considered equivalent to a 309 NODATA result) for purposes of ADSP, although they MAY cause the 310 logging of warning messages via an appropriate system logging 311 mechanism. If the RDATA contains multiple character strings, the 312 strings are logically concatenated with no delimiters between the 313 strings. 315 Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to 316 use WSP rather than FWS in its DNS records. Domains MUST NOT 317 publish ADSP records with wildcard names. Wildcards within a 318 domain publishing ADSP records pose a particular problem, as 319 discussed in more detail in Section 6.3. 321 4.2. Publication of ADSP Records 323 ADSP is intended to apply to all mail sent using the domain name 324 string of an Alleged Author. 326 4.2.1. Record Syntax 328 ADSP records use the "tag=value" syntax described in section 3.2 of 329 [RFC4871], modified to use WSP rather than FWS. Every ADSP record 330 MUST start with an outbound signing practices tag, so the first four 331 characters of the record are lower case "dkim", followed by optional 332 whitespace and "=". 334 Tags used in ADSP records are described below. Unrecognized tags 335 MUST be ignored. In the ABNF below, the WSP token, and the ALPHA and 336 DIGIT tokens are imported from [RFC5234]. 338 dkim= Outbound signing practices for the domain (plain-text; 339 REQUIRED). Possible values are as follows: 341 unknown The domain might sign some or all email. 343 all All mail from the domain is signed with an Author 344 Signature. 346 discardable All mail from the domain is signed with an Author 347 Signature. Furthermore, if a message arrives without a valid 348 Author Signature due to modification in transit, submission via 349 a path without access to a signing key, or any other reason, 350 the domain encourages the recipient(s) to discard it. 352 Any other values are treated as "unknown". 354 ABNF: 355 adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP 356 ("unknown" / "all" / "discardable") 358 4.3. ADSP Lookup Procedure 360 Hosts doing an ADSP lookup MUST produce a result that is semantically 361 equivalent to applying the following steps in the order listed below. 362 In practice, these steps can be performed in parallel in order to 363 improve performance. However, implementations SHOULD avoid doing 364 unnecessary DNS lookups. 366 For the purposes of this section a "valid ADSP record" is one that is 367 both syntactically and semantically correct; in particular, it 368 matches the ABNF for a "tag-list" and starts with a valid "dkim" tag. 370 Check Domain Scope: An ADSP checker implementation MUST determine 371 whether a given Author Domain is within scope for ADSP. Given the 372 background in Section 3.1 the checker MUST decide which degree of 373 approximation is acceptable. The checker MUST return an 374 appropriate error result for Author Domains that are outside the 375 scope of ADSP. 377 The host MUST perform a DNS query for a record corresponding to 378 the Author Domain (with no prefix). The type of the query can be 379 of any type, since this step is only to determine if the domain 380 itself exists in DNS. This query MAY be done in parallel with the 381 query to fetch the named ADSP Record. If the result of this query 382 is that the Author domain does not exist in the DNS (often called 383 an NXDOMAIN error, rcode=3 in [RFC1035]), the algorithm MUST 384 terminate with an error indicating that the domain is out of 385 scope. Note that a result with rcode=0 but no records (often 386 called NODATA) is not the same as NXDOMAIN. 388 NON-NORMATIVE DISCUSSION: Any resource record type could be 389 used for this query since the existence of a resource record of 390 any type will prevent an NXDOMAIN error. MX is a reasonable 391 choice for this purpose because this record type is thought to 392 be the most common for domains used in e-mail, and will 393 therefore produce a result which can be more readily cached 394 than a negative result. 396 If the domain does exist, the checker MAY make more extensive 397 checks to verify the existence of the domain, such as the ones 398 described in Section 5 of [RFC5321]. If those checks indicate 399 that the Author domain does not exist for mail, e.g., the domain 400 has no MX, A, or AAAA record, the checker SHOULD terminate with an 401 error indicating that the domain is out of scope. 403 Fetch Named ADSP Record: The host MUST query DNS for a TXT record 404 corresponding to the Author Domain prefixed by "_adsp._domainkey." 405 (note the trailing dot). 407 If the result of this query is a NOERROR response (rcode=0 in 408 [RFC1035]) with an answer which is a single record that is a valid 409 ADSP record, use that record, and the algorithm terminates. 411 If the result of the query is NXDOMAIN or NOERROR with zero 412 records, there is no ADSP record. If the result of the query 413 contains more than one record, or a record that is not a valid 414 ADSP record, the ADSP result is undefined. 416 If a query results in a "SERVFAIL" error response (rcode=2 in 417 [RFC1035]), the algorithm terminates without returning a result; 418 possible actions include queuing the message or returning an SMTP 419 error indicating a temporary failure. 421 See Appendix A for examples of ADSP Lookup. 423 5. IANA Considerations 425 ADSP adds the following namespaces to the IANA registry. In all 426 cases, new values are assigned only for values that have been 427 documented in a published RFC after IETF Review as specified in 428 [RFC5226]. 430 5.1. ADSP Specification Tag Registry 432 An ADSP record provides for a list of specification tags. IANA has 433 established the ADSP Specification Tag Registry for specification 434 tags that can be used in ADSP fields. 436 The initial entry in the registry is: 438 +------+-----------------+ 439 | TYPE | REFERENCE | 440 +------+-----------------+ 441 | dkim | (this document) | 442 +------+-----------------+ 443 ADSP Specification Tag Registry Initial Values 445 5.2. ADSP Outbound Signing Practices Registry 447 The "dkim=" tag spec, defined in Section 4.2.1, provides for a value 448 specifying Outbound Signing Practices. IANA has established the ADSP 449 Outbound Signing Practices Registry for Outbound Signing Practices. 451 The initial entries in the registry comprise: 452 +-------------+-----------------+ 453 | TYPE | REFERENCE | 454 +-------------+-----------------+ 455 | unknown | (this document) | 456 | all | (this document) | 457 | discardable | (this document) | 458 +-------------+-----------------+ 459 ADSP Outbound Signing Practices Registry Initial Values 461 6. Security Considerations 463 Security considerations in the ADSP are mostly related to attempts on 464 the part of malicious senders to represent themselves as authors for 465 whom they are not authorized to send mail, often in an attempt to 466 defraud either the recipient or an Alleged Author. 468 Additional security considerations regarding Author Domain Signing 469 Practices are found in the DKIM threat analysis [RFC4686]. 471 6.1. ADSP Threat Model 473 Email recipients often have a core set of content authors that they 474 already trust. Common examples include financial institutions with 475 which they have an existing relationship and Internet web transaction 476 sites with which they conduct business. 478 Email abuse often seeks to exploit a legitimate email author's name- 479 recognition among recipients, by using the author's domain name in 480 the From: header field. Especially since many popular MUAs do not 481 display the author's email address, there is no empirical evidence of 482 the extent that this particular unauthorized use of a domain name 483 contributes to recipient deception or that eliminating it will have 484 significant effect. 486 However, closing this exploit could facilitate some types of 487 optimized processing by receive-side message filtering engines, since 488 it could permit them to maintain higher-confidence assertions about 489 From: header field uses of a domain, when the occurrence is 490 authorized. 492 Unauthorized uses of domain names occur elsewhere in messages, as do 493 unauthorized uses of organizations' names. These attacks are outside 494 the scope of this specification. 496 ADSP does not provide any benefit--nor, indeed, have any effect at 497 all--unless an external system acts upon the verdict, either by 498 treating the message differently during the delivery process or by 499 showing some indicator to the end recipient. Such a system is out of 500 scope for this specification. 502 ADSP checkers may perform multiple DNS lookups per Alleged Author 503 Domain. Since these lookups are driven by domain names in email 504 message headers of possibly fraudulent email, legitimate ADSP 505 checkers can become participants in traffic multiplication attacks on 506 domains that appear in fraudulent email. 508 6.2. DNS Considerations 510 An attacker might attack the DNS infrastructure in an attempt to 511 impersonate ADSP records to influence a receiver's decision on how it 512 will handle mail. However, such an attacker is more likely to attack 513 at a higher level, e.g., redirecting A or MX record lookups in order 514 to capture traffic that was legitimately intended for the target 515 domain. These DNS security issues are addressed by DNSSEC [RFC4033]. 517 Because ADSP operates within the framework of the legacy e-mail 518 system, the default result in the absence of an ADSP record is that 519 the domain does not sign all of its messages. It is therefore 520 important that the ADSP clients distinguish a DNS failure such as 521 "SERVFAIL" from other DNS errors so that appropriate actions can be 522 taken. 524 6.3. DNS Wildcards 526 DNS wildcards (described in [RFC4592]) that exist in the DNS 527 hierarchy at or above the domain being checked interfere with the 528 ability to verify the scope of the ADSP check described in 529 Section 4.3. For example, a wildcard record for *.domain.example 530 makes all subdomains such as foo.domain.example exist in the DNS. 531 Domains that intend to make active use of ADSP by publishing a 532 practice other than Unknown are advised to avoid the use of wildcards 533 elsewhere in their hierarchy. 535 If a domain contains wildcards, then any name that matches the 536 wildcard can appear to be a valid mail domain eligible for ADSP. But 537 the "_adsp._domainkey." prefix on ADSP records does not allow 538 publication of wildcard records that cover ADSP records without also 539 covering non-ADSP records, nor of wildcard records that cover non- 540 ADSP records without also covering ADSP records. Hence a domain MUST 541 NOT publish wildcard ADSP records. 543 7. References 545 7.1. References - Normative 547 [RFC1035] Mockapetris, P., "Domain names - implementation and 548 specification", STD 13, RFC 1035, November 1987. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 554 Rose, "DNS Security Introduction and Requirements", 555 RFC 4033, March 2005. 557 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 558 System", RFC 4592, July 2006. 560 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 561 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 562 Signatures", RFC 4871, May 2007. 564 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 565 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 566 May 2008. 568 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 569 Specifications: ABNF", STD 68, RFC 5234, January 2008. 571 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 572 October 2008. 574 7.2. References - Informative 576 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 577 Identified Mail (DKIM)", RFC 4686, September 2006. 579 [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail 580 (DKIM) Signing Practices Protocol", RFC 5016, 581 October 2007. 583 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 584 October 2008. 586 Appendix A. Lookup Examples 588 Assume the example domain publishes these DNS records: (In these 589 examples, the numbers in parentheses are comments to help identify 590 the records, not part of the records themselves.) 592 aaa.example A 192.0.2.1 (1) 593 _adsp._domainkey.aaa.example TXT "dkim=all" (2) 595 bbb.example MX 10 mail.bbb.example (3) 596 mail.bbb.example A 192.0.2.2 (4) 598 A.1. Domain and ADSP exist 600 A mail message contains this From: header line: 602 From: bob@aaa.example (Bob the Author) 604 The ADSP Lookup first identifies the Author Address bob@aaa.example 605 and the Author Domain aaa.example. It does an MX DNS query for 606 aaa.example, and gets back a NOERROR result with no DNS records. 607 (There's no MX record, but since record (1) exists, the name exists 608 in the DNS.) Since that query didn't return an error, the Lookup 609 proceeds to a TXT DNS query for _adsp._domainkey.aaa.example, which 610 returns record (2). Since this is a valid DKIM record, the result is 611 that all messages from this domain are signed. 613 A.2. Domain exists, ADSP does not exist 615 A mail message contains this From: header line: 617 From: alice@bbb.example (Old-fashioned Alice) 619 The ADSP Lookup first identifies the Author Address alice@bbb.example 620 and the Author Domain bbb.example. It does an MX DNS query for 621 bbb.example, and gets back record (3). Since that query didn't 622 return an error, it then proceeds to a TXT DNS query for 623 _adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the 624 domain exists but there is no ADSP record, ADSP returns the default 625 unknown result: messages may or may not have an author signature. 627 A.3. Domain does not exist 629 A mail message contains this From: header line: 631 From: frank@ccc.example (Unreliable Frank) 633 The ADSP Lookup first identifies the Author Address frank@ccc.example 634 and the Author Domain ccc.example. It does an MX DNS query for 635 ccc.example, and gets back an NXDOMAIN result since there are no 636 records at all for ccc.example. The lookup terminates with the 637 result that the domain does not exist in the DNS and so is out of 638 scope. 640 Appendix B. Usage Examples 642 These examples are intended to illustrate typical uses of ADSP. They 643 are not intended to be exhaustive, nor to apply to every domain's or 644 mail system's individual situation. 646 Domain managers are advised to consider the ways that mail processing 647 can modify messages in ways that will invalidate an existing DKIM 648 signature, such as mailing lists, courtesy forwarders, and other 649 paths that could add or modify headers, or modify the message body. 650 In that case, if the modifications invalidate the DKIM signature, 651 recipient hosts will consider the mail not to have an Author 652 Signature, even though the signature was present when the mail was 653 originally sent. 655 B.1. Single Location Domains 657 A common mail system configuration handles all of a domain's users' 658 incoming and outgoing mail through a single MTA or group of MTAs. In 659 that case, the MTA(s) can be configured to sign outgoing mail with an 660 Author Signature. 662 In this situation it might be appropriate to publish an ADSP record 663 for the domain containing "all", depending on whether the users also 664 send mail through other paths that do not apply an Author Signature. 665 Such paths could include MTAs at hotels or hotspot networks used by 666 travelling users, web sites that provide "mail an article" features, 667 user messages sent through mailing lists, or third party mail clients 668 that support multiple user identities. 670 B.2. Bulk Mailing Domains 672 Another common configuration uses a domain solely for bulk or 673 broadcast mail, with no individual human users, again typically 674 sending all the mail through a single MTA or group of MTAs that can 675 apply an Author Signature. In this case, the domain's management can 676 be confident that all of its outgoing mail will be sent through the 677 signing MTA. Lacking individual users, the domain is unlikely to 678 participate in mailing lists, but could still send mail through other 679 paths that might invalidate signatures. 681 Domain owners often use specialist mailing providers to send their 682 bulk mail. In that case, the mailing provider needs access to a 683 suitable signing key in order to apply an Author Signature. One 684 possible route would be for the domain owner to generate the key and 685 give it to the mailing provider. Another would be for the domain to 686 delegate a subdomain to the mailing provider, for example, 687 bigbank.example might delegate email.bigbank.example to such a 688 provider. In that case, the provider can generate the keys and DKIM 689 DNS records itself and use the subdomain in the Author address in the 690 mail. 692 Regardless of the DNS and key management strategy chosen, whoever 693 maintains the DKIM records for the domain could also install an ADSP 694 record containing "all". 696 B.3. Bulk Mailing Domains with Discardable Mail 698 In some cases, a domain might sign all of its outgoing mail with an 699 Author Signature, but prefer that recipient systems discard mail 700 without a valid Author Signature to avoid confusion from mail sent 701 from sources that do not apply an Author Signature. (In the case of 702 domains with tightly controlled outgoing mail, this latter kind of 703 mail is sometimes loosely called "forgeries".) In that case, it 704 might be appropriate to publish an ADSP record containing 705 "discardable". Note that a domain SHOULD NOT publish a "discardable" 706 record if it wishes to maximize the likelihood that mail from the 707 domain is delivered, since it could cause some fraction of the mail 708 the domain sends to be discarded. 710 B.4. Third Party Senders 712 Another common use case is for a third party to enter into an 713 agreement whereby that third party will send bulk or other mail on 714 behalf of a designated author or author domain, using that domain in 715 the RFC5322 From: or other headers. Due to the many and varied 716 complexities of such agreements, third party signing is not addressed 717 in this specification. 719 B.5. Domains with Independent Users and Liberal Use Policies 721 When a domain has independent users and its usage policy does not 722 explicitly restrict them to sending mail only from designated mail 723 servers (e.g. many ISP domains and even some corporate domains), then 724 it is only appropriate to publish an ADSP record containing 725 "unknown". Publishing either "all" or "discardable" will likely 726 result in significant breakage because independent users are likely 727 to send mail from the external paths enumerated in Appendix B.1. 729 B.6. Non-email Domains 731 If a domain sends no mail at all, it can safely publish a 732 "discardable" ADSP record, since any mail with an author address in 733 the domain is a forgery. 735 Appendix C. Acknowledgements 737 This document greatly benefited from comments by Steve Atkins, Jon 738 Callas, Dave Crocker, Pasi Eronen, JD Falk, Arvel Hathcock, Ellen 739 Siegel, Michael Thomas, and Wietse Venema. 741 Appendix D. Change Log 743 *NOTE TO RFC EDITOR: This section may be removed upon publication of 744 this document as an RFC.* 746 D.1. Changes since -ietf-dkim-08 748 o Simplify and clarify interpretation of d= and i=. 750 o Add note pointing out that i= usage conflicts with normal usage, 751 and suggest workaround. 753 o Add note pointing out that you can mechanically add ADSP records 754 for all the subdomains you use. 756 o in Section 3.2 fix text to say that only an Author Signature 757 counts. 759 D.2. Changes since -ietf-dkim-07 761 Clarify that ADSP records use WSP rather than FWS in 4.1 and 4.2.1. 763 D.3. Changes since -ietf-dkim-06 765 Minor editorial changes suggested by AD: 767 o expand DKIM in title 769 o clarify that there's no subdomain matching in Section 3.1 771 o ADSP lookup can terminate without a result if the DNS lookup fails 773 o random dkim= values are treated as unknown 775 o in 4.2 note WSP not FWS 777 o in 4.3 note that NODATA is not NXDOMAIN 779 o add new Appendix A with lookup examples 781 Also address Tony's nits in 782 http://mipassoc.org/pipermail/ietf-dkim/2008q3/010720.html. Make the 783 examples consistently use the .example domain. 785 D.4. Changes since -ietf-dkim-05 787 Minor editorial nits: define NOERROR, SERVFAIL, NXDOMAIN as rfc1035 788 rcodes, change some punctuation, IANA section change IETF Consensus 789 to the new IETF Review. 791 D.5. Changes since -ietf-dkim-04 793 o Require dkim at the front of each record. 795 o Disparage wildcard records. 797 o Changed ABNF use of whitespace from FWS back to WSP, dkim-base is 798 wrong. 800 o RFC 2434 -> 5226, make ref to 4686 informational since it's not 801 standards track. 803 o Improve examples with material from Ellen. 805 D.6. Changes since -ietf-dkim-03 807 o Name change for title and filename, to be ADSP 809 o String changes throughout, to author Domain signing practices and 810 to aDsp. 812 o Added some keywords. 814 o Clarified comparison of local part and domain in Author Address. 816 o Streamlined the Abstract. 818 o Revised text of last bullet in Results list. 820 o Removed definitions not used in the document. 822 o Removed all specification details pertaining to sub-domains. 824 o Moved Lookup Procedure up one document level. 826 o Revised domain validity specification. Part in ADSP Usage in 827 Operations section, and part as it as first step in Lookup. 829 o Fixed xml for figures, including labeling ABNF with new xml2rfc 830 construct. 832 o Revised wildcard text. 834 o Removed 't' tag. 836 o Removed ADSP Flags Registry section. 838 o Changed ABNF use of whitespace from WSP back to FWS, for 839 consistency with dkim-base. 841 D.7. Changes since -ietf-dkim-02 843 o Merge in more text from ADSP draft. 845 o Phrase actions as host's rather than checker. 847 o Explanatory description of i= matching. 849 o Lookup procedure consistently refers to one ADSP record per 850 lookup. 852 o Update security section w/ language from W. Venema 854 o Simplify imports of terms from other RFCs, add Local-part, 4234 -> 855 5234. 857 o Add usage example appendix. 859 o Add IANA considerations. 861 o Update authors list 863 D.8. Changes since -ietf-dkim-ssp-01 865 o Reworded introduction for clarity. 867 o Various definition clarifications. 869 o Changed names of practices to unknown, all, and discardable. 871 o Removed normative language mandating use of SSP in particular 872 situations (issue 1538). 874 o Clarified possible confusion over handling of syntax errors. 876 o Removed normative language from Introduction (issue 1538). 878 o Changed "Originator" to "Author" throughout (issue 1529). 880 o Removed all references to Third-Party Signatures (issues 1512, 881 1521). 883 o Removed all mention of "Suspicious" (issues 1528, 1530). 885 o Removed "t=y" (testing) flag (issue 1540). 887 o Removed "handling" tag (issue 1513). 889 o Broke up the "Sender Signing Practices Check Procedure" into two 890 algorithms: fetching the SSP record and interpretation thereof 891 (issues 1531, 1535; partially addresses issue 1520). 892 Interpretation is now the responsibility of the Evaluator. 894 o Document restructuring for better flow and remove redundancies 895 (some may address issue 1523, but I'm not sure I understand that 896 issue completely; also issues 1532, 1537). 898 o Removed all mention of how this interacts with users, even though 899 it makes parts of the document harder to understand (issue 1526). 901 o Introduced the concepts of "SSP Checker" and "Evaluator". 903 o Multiple author case now handled my separate invocations of SSP 904 checker by Evaluator (issue 1525). 906 o Removed check to avoid querying top-level domains. 908 o Changed ABNF use of whitespace from [FWS] to *WSP (partially 909 addresses issue 1543). 911 D.9. Changes since -ietf-dkim-ssp-00 913 o Clarified Operation Overview and eliminated use of Legitimate as 914 the counterpart of Suspicious since the words have different 915 meanings. 917 o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT 918 records in DNS vs. a new RR type. 920 o Clarified publication rules for multilevel names. 922 o Better description of overall record syntax, in particular that 923 records with unknown tags are considered syntactically correct. 925 o Clarified Sender Signing Practices Check Procedure, primarily by 926 use of new term Author Domain. 928 o Eliminated section "Third-Party Signatures and Mailing Lists" that 929 is better included in the DKIM overview document. 931 o Added "handling" tag to express alleged sending domain's 932 preference about handling of Suspicious messages. 934 o Clarified handling of SERVFAIL error in SSP check. 936 o Replaced "entity" with "domain", since with the removal of user- 937 granularity SSP, the only entities having sender signing policies 938 are domains. 940 D.10. Changes since -allman-ssp-02 942 o Removed user-granularity SSP and u= tag. 944 o Replaced DKIMP resource record with a TXT record. 946 o Changed name of the primary tag from "p" to "dkim". 948 o Replaced lookup algorithm with one which traverses upward at most 949 one level. 951 o Added description of records to be published, and effect of 952 wildcard records within the domain, on SSP. 954 D.11. Changes since -allman-ssp-01 956 o Changed term "Sender Signing Policy" to "Sender Signing 957 Practices". 959 o Changed query methodology to use a separate DNS resource record 960 type, DKIMP. 962 o Changed tag values from SPF-like symbols to words. 964 o User level policies now default to that of the domain if not 965 specified. 967 o Removed the "Compliance" section since we're still not clear on 968 what goes here. 970 o Changed the "parent domain" policy to only search up one level 971 (assumes that subdomains will publish SSP records if appropriate). 973 o Added detailed description of SSP check procedure. 975 D.12. Changes since -allman-ssp-00 977 From a "diff" perspective, the changes are extensive. Semantically, 978 the changes are: 980 o Added section on "Third-Party Signatures and Mailing Lists" 982 o Added "Compliance" (transferred from -base document). I'm not 983 clear on what needs to be done here. 985 o Extensive restructuring. 987 Authors' Addresses 989 Eric Allman 990 Sendmail, Inc. 991 6475 Christie Ave, Suite 350 992 Emeryville, CA 94608 994 Phone: +1 510 594 5501 995 Email: eric+dkim@sendmail.org 996 Jim Fenton 997 Cisco Systems, Inc. 998 MS SJ-9/2 999 170 W. Tasman Drive 1000 San Jose, CA 95134-1706 1002 Phone: +1 408 526 5914 1003 Email: fenton@cisco.com 1005 Mark Delany 1006 Yahoo! Inc. 1007 701 First Avenue 1008 Sunnyvale, CA 94089 1010 Phone: +1 408 349 6831 1011 Email: markd+dkim@yahoo-inc.com 1013 John Levine 1014 Taughannock Networks 1015 PO Box 727 1016 Trumansburg, NY 14886 1018 Phone: +1 831 480 2300 1019 Email: standards@taugh.com 1020 URI: http://www.taugh.com