DKIM Working Group M. Thomas Internet-Draft Cisco Systems Intended status: Informational
March 6,April 23, 2007 Expires: September 7,October 25, 2007 Requirements for a DKIM Signing Practices Protocol draft-ietf-dkim-ssp-requirements-03draft-ietf-dkim-ssp-requirements-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7,October 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism.mechanism, distinguishing between those that must be satisified (MUST), and those that are highly desirable (SHOULD). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. SSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 7 3.1. Problem Scenario 1: Is All Mail Signed with DKIM . .DKIM? . . . . 7 3.2. Problem Scenario 2: Illegitimate Domain Name Use . . . . . 8 4. SSP Deployment Scenarios . . .Considerations . . . . . . . . . . . . . . . . 10 4.1. Deployment ScenarioConsideration 1: Outsourced Signing . . . . . . . .10 4.2. Deployment ScenarioConsideration 2: Determinism in Lookup Mechanism andSubdomain Coverage . . . . . . . . . . . . . . . . . .10 4.3. Deployment ScenarioConsideration 3: Resent Original Mail . . . . . . .10 4.4. Deployment ScenarioConsideration 4: Incremental Deployment of Signing . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Deployment ScenarioConsideration 5: Transport Scenarios . . . . .Performance and Caching . . . 11 4.6. Deployment ScenarioConsideration 6: Human Legibility of Practices . . . 12 4.7. Deployment Scenario 7: Cryptographic Downgrade Attacks. . 12 4.8. Deployment Scenario 8: Extensibility. . . . . . . . . . . . . . . . . . . 12 18.104.22.168. Deployment Scenario 9: SecurityConsideration 7: Extensibility . . . . . . . . 12 4.8. Deployment Consideration 8: Security . . . . . . . . . . . 12 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 13 5.2. SSP Transport Requirements . . . . . . . . . . . . . . . . 14 5.3. Practice and Expectation Requirements . . . . . . . . . . 14 5.4. Extensibility and Forward Compatibility Requirements . . . 1716 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 1. Introduction DomainKeys Identified Mail [I-D.ietf-dkim-base]defines a message level signing and verification mechanism for email. While a DKIM signed message speaks for itself, there is ambiguity if a message doesn't have a valid first party signature:signature (ie, on behalf of the RFC2822.From address): is this to be expected or not?.not? For email this is an especially difficult problem since there is no expectation of a priori knowledge of a sending domain's practices. This ambiguity can be used to mount a bid down attack which is inherent with systems that allow optional authentication like email: if a receiver doesn't know otherwise, it should not assume that the lack of a valid signature is a priori invalid.exceptional without other information. Thus, an attacker can take advantage of the ambiguity and simply not sign messages. If a protocol could be developed for a domain to publish its DKIM signing practices, a message verifier could take that into account when it receives an unsigned piece of email. This document defines the requirements for a mechanism that permits the publication of Sender Signing Practices (SSP). The document is organized into two main sections: a Problem and Deployment Scenario section which describes the problems that SSP is intended to address as well as the deployment issues surrounding the base problems. The second section is the Requirements that arise because of those scenarios. 2. Definitions o Domain Holder: the entity that controls the contents of the DNS subtree starting at the domain, either directly or by delegation via NS records it controls. o First Party Address: For DKIM, a first party address is defined to be the [RFC2822].From address in the message header; a first party address is also known as an Author address o First Party Signature: a first party signature is a valid signature where the domain tag (d= or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [I-D.ietf-dkim-base] o Third Party Signature: a third party signature is a valid signature that does not qualify as a First Party Signature. Note that a DKIM third party signature is not required to correspond to a third party address such as Sender or Listid,List-Id, etc. o Practice: a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends. A practice should always be true when received by a topologically adjacent SMTP.SMTP server. o Expectation: an Expectation combines with a Practice to convey what the domain holder considers the likely survivability of the Practice for a non-topologically adjacent receiver. o DKIM Signing Complete: a Practice where the domain holder asserts that all legitimate mail will be sent with a valid First Party Signature. 3. SSP Problem Scenarios The email world is a diverse place with many deployment scenarios.considerations. This section tries to outline some usage scenarios that it is expected that DKIM signing/verifying will take place in, and how a new protocol might be helpful to clarify the relevance of DKIM signed mail. 3.1. Problem Scenario 1: Is All Mail Signed with DKIMDKIM? After auditing their outgoing mail and deploying DKIM signing for all of their legitimate outgoing mail, a domain could be said to be DKIM signing complete. That is, the domain has to the best of its ability insuredensured that all legitimate mail legitimatelypurporting to have come from that domain contains a valid DKIM signature. A receiver in the general case doesn't know what the practices are for a given domain, or what their expectations are for unsigned mail.domain. Thus the receiver is at a disadvantage in that it does not know if it should expect all mail to be signed from a given domain or not. This knowledge gap leads to a trivially exploitable bid-down attack where the attacker merely sends unsigned mail; since the receiver doesn't know the practices of the signing domain, it cannot treat the message any more harshly for lack of a valid signature. An information service which allowedallows a receiver to query for the practices and expectations of the first party domain when no valid first party signature is found could be useful in closing this gap. A receiver could use this information to treat such questionable mail with varying degrees of prejudice. Note that for the foreseeable future, unrestricted use patterns of mail (eg where users may be members of mailing lists, etc) will likely suffer occasional non-malicious signature failure in transit. While probably not a large percentage of total traffic, the kind of breakage may be a significant concern for those usage patterns. This scenario defines where the sender cannot set any expectation as to whether an individual message will arrive intact. Even without that expectation, a receiver may be able to take advantage of the knowledge that the domain's practice is to sign all mail and bias its filters against unsigned or damaged in transit mail. This information should not be expected to be used in a binary yes/no fashion, but instead as a data point among others in a filtering system. The following exchange illustrates problem scenario 1. 1. Mail with a [RFC2822].From A purportedlysends to B with a missing or broken DKIM first party signature from A 2. B would like to know whether that is an expected state of affairs. 3. A provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact first party signature. 4. B could use this information to bias its filters such that it looks somewhat more suspicious.to examines the message with some suspicion. 3.2. Problem Scenario 2: Illegitimate Domain Name Use A class of mail typified by transactional mail from high value domains is the target of phishing attacks. In particular, many phishing scams forge the [RFC2822].From address in addition to spoofing much of the content to trick unsuspecting users into revealing sensitive information. Domain holders sending this kind of mail would like the ability to give an enhanced guarantee that mail sent in their name should always arrive with the proof that the domain holder consented to its transmission. That is, the message should contain a valid first party signature as defined above. From a receiver's standpoint, knowing that a domain not only signs all of its mail, but places a very high value on the receipt of a valid first party signature from that domain is helpful. Hence a receiver can know that the domain not only signs all of its mail, but also feels it essential that legitimate mail must have its first party signatures survive transit. A receiver with the knowledge of the sender's expectations in hand might choose to process messages not conforming to the published practices in a special manner. Note that the ability to state an enhanced guarantee of a valid signature means that senders should expect mail that traverses modifying intermediaries (eg, mailing lists, etc) will be likely be quarantined or deleted, thus this scenario is more narrow than problem scenario 1. [Informative Note: in terms of a receiving filter, one may choose to treat scenario 2 much more harshly than scenario 1; where scenario 1 looks odd, scenario 2 looks like something is very wrong] 1. Mail with a [RFC2822].From A purportedly sends to B with a missing or broken first party DKIM signature from A 2. B would like to know whether that is an expected state of affairs. 3. A provides information that it signs all outgoing mail, but places an expectation that it should arrive with an intact first party signature, and that the receiver should be suspiciousmuch more wary if it does not. 4. B could use this information to bias its filters such that it looks much more suspicious.examines the message with great suspicion. 4. SSP Deployment ScenariosConsiderations Given the problems enumerated above for which we'd like SSP to provide information to recipients, there are a number of scenarios that are not related to the problems that are to be solved, per se, but the actual mechanics of implementing/deploying the information service that SSP would provide. 4.1. Deployment ScenarioConsideration 1: Outsourced Signing Many domains do not run their own mail infrastructure, or may outsource parts of it to third parties. It is desirable for a domain holder to have the ability delegate to other entities the ability to sign for the domain holder. One obvious use scenario is a domain holder from a small domain that needs to have the ability for their outgoing ISP to sign all of their mail on behalf of the domain holder. Other use scenarios include outsourced bulk mail for marketing campaigns, as well as outsourcing various business functions such as insurance benefits, etc. 4.2. Deployment ScenarioConsideration 2: Determinism in Lookup Mechanism andSubdomain Coverage SSP'sA SSP client will generally be deployedperform lookups on incoming mail streams to provide the information as proposed in the problem scenarios. The RFC2822.From address will be used as a basis for the lookup. More precisely thedomain part of the first address of the RFC2822.From will form the trustbasis to fetch the published information. A trivial attack to circumvent finding the published information couldcan be mounted by simply using a subdomain of the parent domain which doesn't have published information. This attack is called the subdomain attack: that is, a domain needswants to not only publish a policy for a given DNS label it controls, but it would also may needlike to protect all subdomains of that label as well. If this characteristic is not met, an attacker would need only create a possibly fictitious subdomain whichthat was not covered by SSP's information service. Thus, it would be advantageous for The ProtocolSSP to not only cover a given domain, but all subdomains of that domain as well. 4.3. Deployment ScenarioConsideration 3: Resent Original Mail Resent mail is a common occurrence in many scenarios in the email world of today. For example, Alice sends a DKIM signed message with a published practice of signing all messages to Bob's mailing list. Bob, being a good net citizen, wants to be able to take his part of the responsibility of the message in question, so he DKIM signs the message, perhaps corresponding to the Sender address. Note that this scenario is completely orthogonal to whether Alice's signature survived Bob's mailing list: Bob merely wants to assert his part in the chain of accountability for the benefit of the ultimate receivers. It would be useful for this practice to be encouraged as it gives a more accurate view of who handled the message. It also has the side benefit that remailers that are not friendly to DKIM first party signatures (ie, break them) can be potentially assessed by the receiver based on the receiver's opinion of the signing domains that actually survived. 4.4. Deployment ScenarioConsideration 4: Incremental Deployment of Signing As a practical matter, it may be difficult for a domain to roll out DKIM signing such that they can publish the DKIM Signing Complete practice given the complexities of the user population, outsourced vendors sending on its behalf, etc. This leaves open an exploit that high-value mail such as in Problem Scenario 2 must be classified to the least common denominator of the published practices. It would be desirable to allow a domain holder to publish a list of exceptions which would have a strongermore restrictive practices statement. NB: this consideration has been deemed met by the mechanisms provided by the base DKIM signing mechanism; it is merely documented here as having been an issue. For example, bigbank.example.com might be ready to say that firstname.lastname@example.org is always signed, but the rest of the domain, say, is not. Another situation is that the practices of some address local parts in a given domain are not the same as practices of other local parts. Using the same example of email@example.com being a transactional kind of email which would like to publish very strong practices, mixed in with the rest of the user population local parts which may go through mailing lists, etc, for which a less strong statement is appropriate. It should be said that DKIM, through the use of subdomains, can already support this kind of differentiation. That is, in order to publish a strong practice, one only has to segregate those cases into different subdomains. For example: accounts.bigbank.example.com would publish constrained practices while corporateusers.bigbank.example.com might publish more permissive practices. 4.5. Deployment ScenarioConsideration 5: Transport ScenariosPerformance and Caching Email service provides an any-any mesh of potential connections: all that is required is the publication of an MX record and a SMTP listener to receive mail. Thus the use of SSP is likely to fall into two main scenarios, the first of which are large, well known domains who are in constant contact with one another. In this case caching of records is essential for performance, including the caching of the non-existence of records (ie, negative caching). The second main scenario is when a domain exchanges mail with a much smaller volume domain. This scenario can be both perfectly normal as with the case of vanity domains, and sadly a vector for those sending mail for anti-social reasons. In this case we'd like the message exchange burden to SSP querier to be low, since many of the lookups will not provide a useful answer. Likewise, it would be advantageous to have upstream caching here as well so that, say, a mailing list exploder on a small domain does not result in an explosion of queries back at the root and authoritative server for the small domain. 4.6. Deployment ScenarioConsideration 6: Human Legibility of Practices While SSP records are likely to be primarily consumed by an automaton, for the foreseeable future they are also likely to be inspected by hand. It would be nice to have the practices stated in a fashion which is also intuitive to the human inspectors. 4.7. Deployment ScenarioConsideration 7: Cryptographic Downgrade Attacks There is a downgrade attack possible when a DKIM signature is hashed with a previously acceptable but now insecure hash algorithm. This could allow attackers to send their chosen text which is apparently signed by the targeted domain. It would be advantageous for a domain to publish what the allowable signing/hashing algorithms are to prevent this downgrade attack. 4.8. Deployment Scenario 8:Extensibility While this document pertains only to requirements surrounding DKIM signing practices, it would be beneficial for the protocol to be able to extend to other protocols. 22.214.171.124. Deployment Scenario 9:Consideration 8: Security SSP must be able to withstand life in a hostile open internet environment. These include DoS attacks, and especially DoS attacks that leverage themselves through amplification inherent in the protocol. In addition, while a useful protocol may be built without strong source authentication provided by the information service, a path to strong source authentication should be provided by the protocol, or underlying protocols. 5. Requirements This section defines the requirements for SSP. As with most requirements documents, these requirements define the MINIMUM requirements that a candidate protocol must provide. It should also be noted that SSP must fulfill all of the requirements. 5.1. Discovery Requirements Receivers need a means of obtaining information about a sender's DKIM practices. This requires a means of discovering where the information is and what it contains. 1. The author is the first-party sender of a message, as specified in the [rfc2822].From field. SSP's information is associated with the author's domain name and is published subordinate to that domain name. 2. In order to limit the cost of its use, any query service supplying SSP's information MUST provide a definitive responsive within a small, deterministic number of query exchanges. [Informative Note: this, for all intents and purposes is a prohibition on anything that might produce loops or result in extended delays and overhead; also though "deterministic" doesn't specify how many exchanges, the expectation is "few".] [Refs: Deployment Scenario 2]Considerations 2, 5] 3. SSP's publishing mechanism MUST be defined such that it does not lead to multiple records of different protocols residing at the same location. [Informative note: An example is multiple resource record of the same type within a common DNS leaf. Hence, uniquely defined leaf names or uniquely defined resource record types will ensure unambiguous reference.] [Refs: Deployment ScenarioConsideration 2] 4. SSP must be capable of providingretrieval SHOULD provide coverage for not only thea given domain but all of its subdomains as well. If all subdomains cannot be directly associated with the parent's information, the protocol MUST be able to communicate that the domain name is suspicious.The process of obtaining the parent domain's practices MUST complete in a deterministic number of steps, preferably few. In widening the scope to havesteps. It is recognized that there is some reasonable doubt about the possibilityfeasibility of all subdomains inherit the parent practice,a number of algorithms could be employed -- all seemingly with their own set of engineering tradeoffs. A common theme in the production ofwidely accepted solution to this document was thatrequirement. If the number of lookups,working group does not achieve rough consensus on average should be small, and thata solution, it MUST document the discovery process should always be bound to some small finite number of queries.relevant security considerations in the protocol specification. [Refs: Deployment Scenario 2Considerations 2, 5 5.2. SSP Transport Requirements The publication and query mechanism will operate over the Internetas an an internet- based message exchange. ThisThere are multiple requirements for this lower layer service must exhibit basic characteristics:service: 1. WidespreadThe exchange SHOULD have existing widespread deployment of the transport layer would be highly desirable,layer, especially if riding on top of a true transport layer (eg, TCP, UDP). [Refs: Deployment ScenarioConsiderations 5, 8]7] 2. A low-costThe query/response in terms of latency time and the number of packets involved is highly desirable.MUST be low (order of 1 or 2 exchanges). [Refs: Deployment ScenarioConsideration 5] 3. If the infrastructure doesn't provide caching (ala DNS), the records retrieved will need time-to-live values to allow querying verifiers toMUST provide initiators the ability maintain their own caches.cache. Existing caching infrastructure is, however, highly desirable. [Refs: Deployment ScenarioConsideration 5] 4. Multiple geographically and topologically diverse servers mustMUST be supported for high availability [Refs: Deployment ScenarioConsiderations 5, 8]7] 5.3. Practice and Expectation Requirements As stated in the definitions a Practice is a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends. As a sillyan example, a Practice might be defined that all email messages will contain an X-Silly header.a DKIM signature corresponding to the RFC2822.From address. Since there is a possibility of alteration between what a sender sends and a receiver examines, an Expectation combines with a Practice to convey what the RFC2822.From domain holderconsiders the likely outcome of the survivability of the Practice forat a receiver. For example, a Practice that X-Sillya valid DKIM for the RFC2822.From address is present when it is sent from the domain, and an Expectation that it will remain present and valid for all receivers whether topologically adjacent or not. 1. SSP MUST be able to make Practices and Expectation assertions about the domain part of a [RFC2822].From address in the context of DKIM. SSP will not make assertions about other addresses for DKIM at this time. [Refs: Problem ScenarioScenarios 1,2] 2. SSP MUST provide a concise linkage between the [RFC2822].From and the identity in the DKIM i= tag, or its default if it is missing in the signature. That is, SSP MUST precisely define the semantics of what qualifies as a First Party Signature. [Refs: Problem ScenarioScenarios 1,2] 3. SSP MUST be able to publish a Practice that the domain's signing behavior is "DKIM Signing Complete". That is, all messages were transmitted with a valid first party signature. [Refs: Problem Scenario 1] 4. SSP MUST be able to publish an Expectation that a verifiable first party DKIM Signature should be expected on receipt of a message. [Refs: Problem Scenario 2] 5. Practices and Expectations MUST be presented in SSP syntax using as intuitive a descriptor as possible. For example, p=? would be better represented as p=unknown. [Refs: Deployment ScenarioConsideration 6] 6. Because DKIM uses DNS to store selectors, there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to an affiliated party of the domain holder's choosing. That is, the domain holder may be able toset aan NS record for _domainkey.example.com to, say,to delegate to an email provider who manages thatthe entire namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain third parties. For example, a domain holder could delegate only _domainkey.benefits.example.com to a third party to constrain the third party to only be able to produce valid signatures in the benefits.example.com subdomain. Last, a domain holder can even use CNAME's to delegate individual leaf nodes. ThusGiven the above considerations, SSP need not invent a different means of allowing affiliated parties to sign on a domain's behalf at this time. [Refs: Deployment Consideration 4] 7. Practices and Expectations MUST be presented as an information service from the signing domain to be consumed as an added factor to the receiver's local policy. In particular, a Practice or Expectation MUST NOT mandate any disposition stance on the receiver. [Refs: Problem ScenarioScenarios 1, 2, 3]2] 8. There is no requirement that SSP publish a Practices of any/all third parties that MUST NOT sign on the domain holder's behalf. This should be considered out of scope. [INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.] [Refs: Problem Scenario 1-2]Scenarios 1,2] 9. SSP MUST NOT be required to be invoked if a valid first party signature is found. [Refs: Deployment ScenarioConsideration 2] 10. [PROVISIONAL] The signing policy statement MUST be capable of fully describing a signing practice in which multiple signatures are always provided such that the policy is of utility to any verifier is capable of verifying any of the signatures that are always provided. Such a mechanism MUST NOT: * Require the verifier to perform any additional DNS lookups * Require duplication of configuration data * In particular not require the policy record to provide for the description of any cryptographic or cannonicalization algorithm INFORMATIVE NOTE: The ability to specify multiple signatures is necessary in order to permit orderly transitions to new cryptographic and canonicalization algorithms. Unless the policy language is not sufficiently expressive to allow the signer to describe the actual signature practice in this case there is an opportunity for an attacker to exploit the fact that there are verifiers that do not yet support the new algorithm. [Refs: Deployment Scenario 7] 11.SSP MUST NOT provide a mechanism which impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. [INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver.] [Refs: Deployment ScenarioConsideration 3] 5.4. Extensibility and Forward Compatibility Requirements 1. SSP MUST NOT extend to any other protocol than DKIM for email at this time. SSP SHOULD be able to extendextensible for protocols other than DKIM. [Refs: Deployment Scenario 8]Consideration 7] 2. SSP MUST be able to add new Practices and Expectations within the existing discovery/transport/practices in a backward compatible fashion. [Refs: Deployment Scenario 8]Consideration 7] 6. Security Requirements 1. Minimize DoS potential:SSP for a high-value domain is potentially a high-value DoS target, especially since the unavailability of SSP's record could make unsigned messages less suspicious. 2. Amplification Attacks:SSP MUST NOT make highly leveraged amplification or make-work attacks possible. In particular any amplification mustthe work and message exchanges involved MUST be O(1). [Author's question: is it really O(1)? or O(n)?]order of a constant. [Refs: Deployment Scenario 9]Consideration 8] 3. Authenticity:SSP MUST have the ability for a domain holder to provide SSP's data such that a receiver can determine that it is authentically from the domain holder with a large degree of certainty. SSP may provide means which provide less certainty in trade off for ease of deployment. [Refs: Deployment Scenario 9]Consideration 8] 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations This document defines requirements for a new protocol and the security related requirements are defined above. There is an expectation that SSP will not always be required to have source authentication of the practices information which is noteworthy. 9. Acknowledgments Due to flipping in the market and raising interest rates, this home is no longer free.Dave Crocker and Jim Fenton helped me raise the walls onprovided substantial review of this document and are accorded a room at the inn. The inn is not yet full, however.document. 10. References 10.1. Normative References [I-D.ietf-dkim-base] Allman, E., "DomainKeys Identified Mail (DKIM) Signatures", draft-ietf-dkim-base-04 (work in progress), July 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 10.2. Informative References [I-D.ietf-dkim-overview] Hansen, T., "DomainKeys Identified Mail (DKIM) Service Overview", draft-ietf-dkim-overview-01 (work in progress), June 2006. [I-D.ietf-dkim-threats] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work in progress), May 2006.Author's Address Michael Thomas Cisco Systems 606 Sanchez St San Francisco, California 94114 USA Phone: +1-408-525-5386 Fax: +1-408-525-5386 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).