|Network Working Group||E. Allman|
|INTERNET DRAFT||Sendmail, Inc.|
|Expires: January 2006|
DKIM Sender Signing Policy
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 in January 2006.
Copyright © The Internet Society (2005). All Rights Reserved.
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in [ID-DK-BASE]. This document describes the policy records that senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results.
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 [RFC2119].
Security Considerations needs further work.
Need to add new and check existing ABNF.
DKP RR needs to be defined.
Text structure of document needs to be examined; this is a quick slash-and-burn approach. Stop signs indicate sections that haven’t even been approached yet.
This initial version that is being submitted as an IETF Internet-Draft has been converted over to RFC format by Dave Crocker. Besides the many rough edges to the resulting format of the document, he suspects there also might be some more serious errors, such as sub-sections being at the wrong level. These errors will be repaired as soon as they are reported.
DomainKeys Identified Mail (DKIM) [ID-DK-BASE] defines a method whereby email senders ("signers") may sign their outgoing messages with a secret key that can be checked by a receiver ("verifier") to determine whether the signer was authorized to use the sending domain name. The method used is based on well-known public-key cryptography methods.
However, the legacy of the Internet is such that not all messages will be signed, and the absence of a signature on a message is not an a priori indication of forgery. In fact, during early phases of deployment it must be expected that most messages will remain unsigned. However, some senders may choose to sign all of their outgoing mail, for example, to protect their brand name. Such signers must be able to advertise to verifiers that messages claiming to be from them that are not signed are forgeries. This is the topic for sender signing policy.
In the absence of a valid DKIM signature on behalf of the "From" address [RFC2822], the verifier of a message MUST determine whether messages from a particular sender are expected to be signed, and what signatures are acceptable. In particular, whether a domain is participating in DKIM, whether they are testing, and whether it signs all outbound email must be communicated to the verifier. Without such a mechanism, the benefit of message signing techniques such as DKIM is limited since unsigned messages will always need to be considered to be potentially legitimate. This determination is referred to as a Sender Signing Policy Check.
Sender Signing Policies MAY be expressed on behalf of an entity which may be a domain or an individual address. Expression of signing policy on behalf of individual addresses will, of course, entail additional key server transaction load.
Conceivably, such policy expressions might be imagined to be extended in the future to include information about what hashing algorithms a domain uses, what kind of messages might be sent (e.g., bulk vs. personal vs. transactional), etc. Such concerns are out of scope of this standard; because of the need for outside auditing they fall under the purview of reputation and accreditation.
The email address in the "From" header field of a message [RFC2822], or if and only if the From header field contains multiple addresses, the email address in the "Sender" header field.
Messages that fail an initial signature verification step (either by an incorrect signature or a lack of signature) and also a further Sender Signing Policy check are referred to as "Suspicious". The handling of such messages is at the discretion of the verifier or final recipient. "Suspicious" applies only to the DKIM layer; a verifier may decide the message should be accepted on the basis of other information beyond the scope of this document. Conversely, messages deemed non-Suspicious may be rejected for other reasons.
Some terminology used herein is derived directly from [ID-DK-BASE]. Briefly,
This section is informative only and MUST NOT be treated as normative. The actual specification is described in [ID-DK-BASE] and must be consulted.
Briefly, when a verifier receives a message, they examine the header field of that message to see if it includes one or more DKIM-Signature header fields. If it does, the authenticity of that message may be validated using conventional cryptographic techniques. However, if the verifier receives a message containing no valid DKIM-Signature header fields, it must proceed with the algorithms defined in this document.
Sender Signing Policy Checks MUST be based on the Originator Address. If the message contains a valid signature on behalf of the Originator Address no Sender Signing Policy Check need be performed: the verifier SHOULD NOT look up the Sender Signing Policy and the message SHOULD be considered non-Suspicious.
Verifiers checking messages that do not have at least one valid signature MUST perform a Sender Signing Policy Check by doing a DNS query to the domain specified by the Originator Address. The query MUST be for the search key "_policy._domainkey.<domain>", where <domain> is the domain of the Originator Address. The query may return either a DKSSP record or a TXT record; the DKSSP record MUST override the TXT record.
The result of a Sender Signing Policy Check is one of four possible policies:
If a message is encountered by a verifier without a valid signature from the Originator Address, the policy results MUST be interpreted as follows:
Signing policy records for a domain are published in key servers as the "_policy" selector. Signing policy records for individual addresses are published as the "user._policy" selector.
To avoid a Denial-of-Service attack, signer policy searches for signing policy checks of very deeply nested domains MUST strip off all but the last five components of a domain name. If a policy record is not found, the verifier MUST repeat the request to successively higher levels of the domain hierarchy until the root is reached. This allows subdomains to inherit the signing policy of their parent domains without allowing attackers to specify extremely deep subdomains such as "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". If presented with such a signing domain in a DKIM-Signature header field, the search for a policy record would start at "x.y.z.example.com" and proceed upwards. Verifiers MUST stop searching at the first policy record they encounter.
Signing policy records follow the tag-value syntax described in [ID-DK-BASE]. Tags used in signing policy records are as follows:
When represented in DNS, signing policy checks MUST search for a DKSSP (DomainKey Sender Signing Policy) RR type first. If no DKSSP RR is found, signing policy checks MUST search for a TXT RR type.
Use of the _domainkey prefix in DNS records will require registration by IANA.
Use of the _policy prefix in DNS records will require registration by IANA.
The DKSSP RR type must be registered by IANA.
|[ID-DK-BASE]||Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM)”, Internet-Draft draft-allman-dkim-base-00, July 2005.|
|[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.|
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.
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 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.
Copyright © The Internet Society (2005). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.