idnits 2.17.1 draft-allman-dkim-ssp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 628. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ID-DKIM-BASE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: (3) All valid messages from this entity are signed, and SHOULD have a valid signature from this entity. Third-party signatures SHOULD not be accepted. -- 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 (October 23, 2005) is 6761 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) == Outdated reference: A later version (-01) exists of draft-allman-dkim-base-00 -- Possible downref: Normative reference to a draft: ref. 'ID-DKIM-BASE' ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pre-DKIM E. Allman 3 Internet-Draft Sendmail, Inc. 4 Expires: April 26, 2006 M. Delany 5 Yahoo! Inc 6 J. Fenton 7 Cisco Systems, Inc. 8 October 23, 2005 10 DKIM Sender Signing Policy 11 draft-allman-dkim-ssp-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 April 26, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 DomainKeys Identified Mail (DKIM) defines a domain-level 45 authentication framework for email using public-key cryptography and 46 key server technology to permit verification of the source and 47 contents of messages by either Mail Transport Agents (MTAs) or Mail 48 User Agents (MUAs). The primary DKIM protocol is described in [ID- 49 DKIM-BASE]. 51 This document describes the policy records that senders may use to 52 advertise how they sign their outgoing mail, and how verifiers should 53 access and interpret those results. 55 Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC2119]. 61 (Unresolved Issues/To Be Done) 63 Security Considerations needs further work. 65 Need to add new and check existing ABNF. 67 DKP RR needs to be defined. 69 Text structure of document needs to be examined; this is a quick 70 slash-and-burn approach. Stop signs indicate sections that haven't 71 even been approached yet. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Language and Terminology . . . . . . . . . . . . . . . . . . 5 77 2.1 Terms Imported from DKIM-Base . . . . . . . . . . . . . . 5 78 2.2 Originator Address . . . . . . . . . . . . . . . . . . . . 5 79 2.3 Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 5 80 2.4 Alleged Originator . . . . . . . . . . . . . . . . . . . . 6 81 2.5 Sender Signing Policy . . . . . . . . . . . . . . . . . . 6 82 2.6 Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6 83 2.7 First Party Signature . . . . . . . . . . . . . . . . . . 6 84 2.8 Third Party Signature . . . . . . . . . . . . . . . . . . 6 85 2.9 Verifier Acceptable Third Party Signature . . . . . . . . 6 86 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 7 87 4. Query Mechanism . . . . . . . . . . . . . . . . . . . . . . 8 88 5. Policy Syntax and Semantics . . . . . . . . . . . . . . . . 9 89 6. Third Party Signatures and Mailing Lists . . . . . . . . . . 10 90 6.1 Verifier Actions . . . . . . . . . . . . . . . . . . . . . 10 91 6.2 Mailing List Manager Actions . . . . . . . . . . . . . . . 11 92 6.3 Signer Actions . . . . . . . . . . . . . . . . . . . . . . 12 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 94 8. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 9. Security Considerations . . . . . . . . . . . . . . . . . . 12 96 9.1 Fraudulent Sender Address . . . . . . . . . . . . . . . . 12 97 9.2 DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 13 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 10.1 Normative References . . . . . . . . . . . . . . . . . . 13 100 10.2 Informational References . . . . . . . . . . . . . . . . 13 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 102 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14 103 A.1 Changes since -00 . . . . . . . . . . . . . . . . . . . . 14 104 Intellectual Property and Copyright Statements . . . . . . . 15 106 1. Introduction 108 DomainKeys Identified Mail (DKIM) defines a simple, low cost, and 109 effective mechanism by which email messages can be cryptographically 110 signed, permitting a signing domain to claim responsibility for the 111 use of a given email address. Message recipients can verify the 112 signature by querying the signer's domain directly to retrieve the 113 appropriate public key, and thereby confirm that the message was 114 attested to by a party in possession of the private key for the 115 signing domain. 117 However, the legacy of the Internet is such that not all messages 118 will be signed, and the absence of a signature on a message is not an 119 a priori indication of forgery. In fact, during early phases of 120 deployment it must be expected that most messages will remain 121 unsigned. However, some senders may choose to sign all of their 122 outgoing mail, for example, to protect their brand name. Such 123 signers must be able to advertise to verifiers that messages claiming 124 to be from them that are not signed are forgeries. This is the topic 125 for sender signing policy. 127 In the absence of a valid DKIM signature on behalf of the "From" 128 address [RFC2822], the verifier of a message MUST determine whether 129 messages from that sender are expected to be signed, and what 130 signatures are acceptable. In particular, whether a domain is 131 participating in DKIM, whether they are testing, and whether it signs 132 all outbound email must be communicated to the verifier. Without 133 such a mechanism, the benefit of message signing techniques such as 134 DKIM is limited since unsigned messages will always need to be 135 considered to be potentially legitimate. This determination is 136 referred to as a Sender Signing Policy Check. 138 Sender Signing Policies MAY be expressed on behalf of an entity which 139 may be a domain or an individual address. Expression of signing 140 policy on behalf of individual addresses will, of course, entail 141 additional key server transaction load. 143 Conceivably, such policy expressions might be imagined to be extended 144 in the future to include information about what hashing algorithms a 145 domain uses, what kind of messages might be sent (e.g., bulk vs. 146 personal vs. transactional), etc. Such concerns are out of scope of 147 this standard; because of the need for outside auditing they fall 148 under the purview of reputation and accreditation. 150 This document refers to [ID-DKIM-BASE], which should be read as a 151 prerequisite to this document. 153 2. Language and Terminology 155 2.1 Terms Imported from DKIM-Base 157 Some terminology used herein is derived directly from [ID-DKIM-BASE]. 158 Briefly, 160 o A "Signer" is the agent that signs a message. In normal cases 161 it will probably correspond closely with the original author of 162 the message or an agent working on the author's behalf. 164 o A "Verifier" is the agent that verifies a message by checking 165 the actual signature against the message itself and the public key 166 published by the alleged signer. The Verifier also looks up the 167 Sender Signing Policy published by the domain of the Originator 168 Address if the message is not correctly signed by the Alleged 169 Originator. 171 o A "Selector" specifies which of the keys published by a signing 172 domain should be queried. It is essentially a way of subdividing 173 the address space to allow a single sending domain to publish 174 multiple keys. 176 2.2 Originator Address 178 The "Originator Address" is the email address in the From header 179 field of a message [RFC2822], or if and only if the From header field 180 contains multiple addresses, the first address in the From header 181 field. 183 NON-NORMATIVE RATIONALE: The alternative option when there are 184 multiple addresses in the From header field is to use the value of 185 the Sender header field. This would be closer to the semantics 186 indicated in [RFC2822] than using the first address in the From 187 header field. However, the large number of deployed Mail User 188 Agents that do not display the Sender header field value argues 189 against that. Multiple addresses in the From header field are 190 rare in real life. 192 2.3 Alleged Signer 194 An "Alleged Signer" is the identity of the signer claimed in the 195 DKIM-Signature header field in a message received by a Verifier; it 196 is "alleged" because it has not yet been verified. 198 2.4 Alleged Originator 200 An "Alleged Originator" is the Originator Address of a message 201 received by a Verifier; it is "alleged" because it has not yet been 202 verified. 204 2.5 Sender Signing Policy 206 A "Sender Signing Policy" (or just "policy") is a machine-readable 207 record published by the domain of the Alleged Originator which 208 includes information about whether that sender signs all, some, or 209 none of their email. It must be considered together with the "key" 210 records, which advertise the public keys associated with the Alleged 211 Originator. 213 2.6 Suspicious 215 Messages that fail an initial signature verification step (either by 216 an incorrect signature or a lack of signature) and also a further 217 Sender Signing Policy check are referred to as "Suspicious". The 218 handling of such messages is at the discretion of the verifier or 219 final recipient. "Suspicious" applies only to the DKIM layer; a 220 verifier may decide the message should be accepted on the basis of 221 other information beyond the scope of this document. Conversely, 222 messages deemed non-Suspicious may be rejected for other reasons. 224 2.7 First Party Signature 226 A First Party Signature is any valid signature where the signer name 227 (listed in the "i=" tag if present, otherwise the null address, 228 representing an unknown user, followed by "@", followed by the value 229 of the "d=" tag) matches the address in the "From" header. If the 230 signer name does not include a local-part, then only the domains must 231 match; otherwise, the two addresses must be identical. 233 2.8 Third Party Signature 235 A Third Party Signature is a valid signature where the signer (listed 236 in the "i=" tag) does not match the address in the "From" header. 238 2.9 Verifier Acceptable Third Party Signature 240 A Verifier Acceptable Third Party Signature is a Third Party 241 Signature that the Verifier is willing to accept as meaningful for 242 the message under consideration. "Accept" means that the Verifier 243 will, on the basis of local policy, take an action based on that 244 signature, such as matching against a locally maintained allow-list, 245 doing an external reputation lookup, or any other local action that 246 the Verifier deems useful for classifying or otherwise processing the 247 message. 249 A Verifier SHOULD accept signatures that correspond with addresses in 250 the "Sender" header, MAY accept signatures that are for identities 251 that the Verifier is certain will be displayed to end users, and MAY 252 accept signatures that pass other tests such as accreditation or 253 reputation. Verifiers SHOULD NOT accept signatures from identities 254 that have no known relationship with the message other than their 255 appearance in the "DKIM-Signature" header. 257 3. Operation Overview 259 Sender Signing Policy Checks MUST be based on the Originator Address. 260 If the message contains a valid signature on behalf of the Originator 261 Address no Sender Signing Policy Check need be performed: the 262 verifier SHOULD NOT look up the Sender Signing Policy and the message 263 SHOULD be considered non-Suspicious. 265 Verifiers checking messages that do not have at least one valid 266 signature on behalf of the Originator Address MUST perform a Sender 267 Signing Policy Check by doing a lookup for the "_policy" record as 268 described in Section 4 from the domain specified by the Originator 269 Address. 271 The result of a Sender Signing Policy Check is one of four possible 272 policies: 274 (1) Some messages from this entity are not signed; the message 275 SHOULD be presumed to be legitimate in the absence of a valid 276 signature. This is the default policy. 278 (2) All messages from this entity are signed; all messages from 279 this entity SHOULD have a valid signature, either directly on 280 behalf of the originator or on behalf of a third party (e.g., a 281 mailing list or an outsourcing house) handling the message. 283 (3) All valid messages from this entity are signed, and SHOULD 284 have a valid signature from this entity. Third-party signatures 285 SHOULD not be accepted. 287 (4) Signing policy for this domain is expressed at the individual 288 address level. A second Sender Signing Policy Check should be 289 performed specifying the individual address 291 If a message is encountered by a verifier without a valid signature 292 from the Originator Address, the policy results MUST be interpreted 293 as follows: 295 If the result of the check is policy (1) described above, the 296 message MUST be considered non-Suspicious. 298 If the result of the check is policy (2), and any verifiable 299 signature is present from some signer other than the Originator 300 Address in the message, the message SHOULD be considered non- 301 Suspicious. 303 If the result of the check is policy (3), the message MUST be 304 considered Suspicious. 306 If the result of the check is policy (4), a second Sender Signing 307 Policy Check SHOULD be performed based on the entire Originator 308 Address and interpreted using the above steps. If the result of 309 that check is policy (4), the signing policy for the originator is 310 misconfigured, and the message SHOULD be considered non- 311 Suspicious. 313 If the Sender Signing Policy record does not exist, verifier systems 314 MUST assume that some messages from this entity are not signed and 315 the message SHOULD NOT be considered to be Suspicious. 317 4. Query Mechanism 319 Signing policy records for a domain are published in key servers as 320 the "_policy" selector. Signing policy records for individual 321 addresses are published as the "._policy" selector. 323 NON-NORMATIVE RATIONALE: Use of a synthetic selector allows non- 324 DNS based access for signer policies. 326 Initially, the query mechanism defined uses DNS to look up the key 327 "._domainkey.", where is either 328 "_policy" for the initial lookup or "._policy" for per-user 329 lookups, and is the domain of the Originator Address. When 330 represented in DNS, signing policy checks MUST search for a DKSSP 331 (DomainKey Sender Signing Policy) RR type first. If no DKSSP RR is 332 found, signing policy checks MUST search for a TXT RR type. The 333 DKSSP record MUST override the TXT record. 335 To avoid a Denial-of-Service attack, signer policy searches for 336 signing policy checks of very deeply nested domains MUST strip off 337 all but the last five components of a domain name. If a policy 338 record is not found, the verifier MUST repeat the request to 339 successively higher levels of the domain hierarchy until the root is 340 reached. This allows subdomains to inherit the signing policy of 341 their parent domains without allowing attackers to specify extremely 342 deep subdomains such as 343 "a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com". 344 If presented with such a signing domain in a DKIM-Signature header 345 field, the search for a policy record would start at 346 "x.y.z.example.com" and proceed upwards. Verifiers MUST stop 347 searching at the first policy record they encounter. 349 NON-NORMATIVE DISCUSSION: It seems like this limitation should be 350 part of the DNS binding rather than a general restriction. 352 5. Policy Syntax and Semantics 354 Signing policy records follow the tag-value syntax described in [ID- 355 DKIM-BASE]. Tags used in signing policy records are as follows: 357 n= Human readable notes regarding the record (quoted-printable with 358 semicolon encoded in addition to the standard characters; 359 OPTIONAL, default is no notes). 361 o= Outbound signing policy for the entity (plain-text; OPTIONAL, 362 default is "~"). Possible values are as follows: 364 ~ The entity signs some but not all email. 366 - All mail from the entity is signed; unsigned email MUST NOT be 367 accepted, but email signed with a Verifier Acceptable Third 368 Party Signature SHOULD be accepted. 370 ! All mail from the entity is signed; Third-Party signatures 371 SHOULD NOT be accepted 373 . This entity never sends email. The "." policy can be used to 374 "short circuit" searches from subdomains; for example, the 375 "ad.jp" domain might use this. If an initial policy search 376 receives this policy then the email SHOULD NOT be accepted; if 377 found while searching parent domains then the search should 378 terminate as though no policy record was found. 380 ^ Repeat query at user level. This value MUST NOT be used in 381 user-level policy records. A Verifier MUST look up the 382 selector for "._policy" where is the local-part of 383 the Originator Address (i.e., the portion of the address before 384 the "@" character). 386 r= Email address for reports and inquiries regarding the signing 387 policy for this entity (plain-text; OPTIONAL, default is no 388 contact address available). 390 t= A vertical-bar separated list of flags (plain-text; OPTIONAL, 391 default is that no flags are set). Flag values are: 393 y The entity is testing signing policy, and the verifier SHOULD 394 NOT consider a message suspicious based on the record. 396 u= Reserved for future reference to a URI to provide more detailed 397 policy information. 399 6. Third Party Signatures and Mailing Lists 401 There are several forms of mailing lists, which interact with signing 402 in different ways. 404 o "Verbatim" mailing lists send messages without modification 405 whatsoever. They are often implemented as MTA-based aliases. 406 Since they do not modify the message, signatures are unaffected 407 and will continue to verify. There is no reason for the forwarder 408 to re-sign the message. 410 o "Digesting" mailing lists collect together one or more postings 411 and then retransmit them, often on a nightly basis, to the 412 subscription list. These are essentially entirely new messages 413 which must be independently authored (that is, they will have a 414 "From" header referring to the list, not the submitters) and 415 signed by the Mailing List Manager itself, if they are signed at 416 all. 418 o "Resending" mailing lists receive a message, modify it (often to 419 add "unsubscribe" information or advertising), and immediately 420 resend that message to the subscription list. They are 421 problematic because they usually do not change the "From" header 422 of the message, but they do invalidate the signature in the 423 process of modifying the message. 425 The first two cases act in obvious ways and do not require further 426 discussion. However, the third case is problematic. The remainder 427 of this session applies only to that case. 429 6.1 Verifier Actions 431 Generally speaking, a Verifier SHOULD treat messages as Suspicious 432 unless they have a First Party Signature or Verifier Acceptable Third 433 Party Signature. Since Verifiers SHOULD accept signatures for 434 identities listed in the Sender header field, adding such a field is 435 the recommended approach for Mailing List Managers. 437 6.2 Mailing List Manager Actions 439 Mailing List Managers should make every effort to ensure that 440 messages that they relay and which have valid signatures upon receipt 441 also have valid signatures upon retransmission. In particular, 442 Mailing List Managers that modify the message in ways that break 443 existing signatures SHOULD: 445 o Verify any existing DKIM Signatures. A DKIM-aware Mailing List 446 Manager MUST NOT re-sign an improperly signed message in such a 447 way that would imply that the existing signature is acceptable. 448 In particular, a DKIM-aware MLM MUST NOT sign an Authentication- 449 Results header field that it can not personally verify, whether 450 that header field be added locally or remotely. 452 NON-NORMATIVE RATIONALE: An attacker might send a message 453 through a DKIM-aware Mailing List Manager that included an 454 existing Authentication-Results header that claims that the MLM 455 verified the signature when the signature was not valid in an 456 attempt to gain creditability. 458 o Apply regular anti-spam policies. A Mailing List Manager SHOULD 459 apply message content security policy just as they would messages 460 destined for an individual user's mailbox. In fact, a Mailing 461 List Manager might apply a higher standard to messages destined to 462 a mailing list than would normally be applied to individual 463 messages. 465 NON-NORMATIVE RATIONALE: Since reputation will accrue to 466 signers, Mailing List Managers should verify the source and 467 content of messages before they are willing to sign lest their 468 reputation be sullied by nefarious parties. 470 o Add a Sender header using a valid address pointing back to the 471 Mailing List Administrator or an appropriate agent (such as an 472 "owner-" or a "-request" address). 474 o Sign the resulting message with a signature that is valid for the 475 Sender header address. The Mailing List Manager SHOULD NOT sign 476 messages for which they are unwilling to accept responsibility. 478 Mailing List Managers MAY: 480 o Reject messages with signatures that do not verify or otherwise 481 satisfy their policy. 483 6.3 Signer Actions 485 All Signers SHOULD: 487 o Include the From header as a signed header field (i.e., in the 488 "h=" tag) under all circumstances. 490 o Include any existing Sender header in the signed header field 491 list, if the Sender header exists. 493 Signers wishing to avoid the use of third party signatures SHOULD do 494 everything listed above, and also: 496 o Include the Sender header field name in the header field list 497 ("h=" tag) under all circumstances, even if the Sender header 498 field does not exist in the header block. This prevents another 499 entity from adding a Sender header field. 501 o Publish a Sender Signing Policy that does not permit the use of 502 Third Party Signatures 504 7. IANA Considerations 506 Use of the _policy prefix in DNS records will require registration by 507 IANA. 509 The DKSSP RR type must be registered by IANA. 511 8. Compliance 513 [[To be done.]] 515 9. Security Considerations 517 Security considerations in the Sender Signing Policy are mostly 518 related to attempts on the part of malicious senders to represent 519 themselves as other senders, often in an attempt to defraud either 520 the recipient or the Alleged Originator. 522 9.1 Fraudulent Sender Address 524 [[Assuming 3rd party signature is based on Sender header]] If the 525 Sender Signing Policy permits third party signing, an attacker can 526 create a message with a From header of an arbitrary sender and a 527 legitimately signed Sender header 529 9.2 DNS Attacks 531 An attacker might attack the DNS infrastructure in an attempt to 532 impersonate policy records. However, such an attacker is more likely 533 to attack at a higher level, e.g., redirecting A or MX record lookups 534 in order to capture traffic that was legitimately intended for the 535 target domain. Domains concerned about this should use DNSSEC 536 [RFC4033]. 538 10. References 540 10.1 Normative References 542 [ID-DKIM-BASE] 543 Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 544 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)", 545 draft-allman-dkim-base-00 (work in progress), July 2005. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 551 April 2001. 553 10.2 Informational References 555 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 556 Rose, "DNS Security Introduction and Requirements", 557 RFC 4033, March 2005. 559 Authors' Addresses 561 Eric Allman 562 Sendmail, Inc. 563 6425 Christie Ave, Suite 400 564 Emeryville, CA 94608 565 USA 567 Phone: +1 510 594 5501 568 Email: eric+dkim@sendmail.org 569 URI: 571 Mark Delany 572 Yahoo! Inc 573 701 First Avenue 574 Sunnyvale, CA 95087 575 USA 577 Phone: +1 408 349 6831 578 Email: markd+dkim@yahoo-inc.com 579 URI: 581 Jim Fenton 582 Cisco Systems, Inc. 583 MS SJ-24/2 584 170 W. Tasman Drive 585 San Jose, CA 95134-1706 586 USA 588 Phone: +1 408 526 5914 589 Email: fenton@cisco.com 590 URI: 592 Appendix A. Change Log 594 A.1 Changes since -00 596 From a "diff" perspective, the changes are extensive. Semantically, 597 the changes are: 599 o Added section on "Third Party Signatures and Mailing Lists" 601 o Added "Compliance" (transferred from -base document). I'm not 602 clear on what needs to be done here. 604 o Extensive restructuring. 606 Intellectual Property Statement 608 The IETF takes no position regarding the validity or scope of any 609 Intellectual Property Rights or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; nor does it represent that it has 613 made any independent effort to identify any such rights. Information 614 on the procedures with respect to rights in RFC documents can be 615 found in BCP 78 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the use of 620 such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR repository at 622 http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights that may cover technology that may be required to implement 627 this standard. Please address the information to the IETF at 628 ietf-ipr@ietf.org. 630 Disclaimer of Validity 632 This document and the information contained herein are provided on an 633 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 634 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 635 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 636 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 637 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 640 Copyright Statement 642 Copyright (C) The Internet Society (2005). This document is subject 643 to the rights, licenses and restrictions contained in BCP 78, and 644 except as set forth therein, the authors retain all their rights. 646 Acknowledgment 648 Funding for the RFC Editor function is currently provided by the 649 Internet Society.