DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-07

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 May 21, 2008.

Abstract

DomainKeys Identified Mail (DKIM) allows an organization to take responsibility for a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agent's. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography and key server technology. This permits verifying the signer of a message, as well as the integrity of its contents. DKIM accomplishes this by defining a domain-level authentication framework for email using public-key cryptography and key server technology [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.). This permits verifying a message source, an intermediary, or one of their agents, as well as the integrity of its contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments of unsigned messages. Such protection of email identity can assist in the global control of "spam" and "phishing". This document provides an overview of the DKIM service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM.

Table of Contents

1.  Introduction
    1.1.  Prior Work
    1.2.  Discussion Venue
2.  Internet Mail Background
    2.1.  Administrative Management Domain (ADMD)
    2.2.  DKIM Placement within an ADMD
3.  The DKIM Value Proposition
4.  DKIM Goals
    4.1.  Functional Goals
    4.2.  Operational Goals
5.  DKIM Function
    5.1.  The Basic Signing Service
    5.2.  Characteristics of a DKIM signature
    5.3.  The Selector construct
    5.4.  Verification
6.  Service Architecture
    6.1.  Administration and Maintenance
    6.2.  Signing
    6.3.  Verifying
    6.4.  Unverified or Unsigned Mail
    6.5.  Evaluating
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgements
10.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

DomainKeys Identified Mail (DKIM) allows an organization to take responsibility for a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agent's. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography and key server technology. This permits verifying the signer of a message, as well as the integrity of its contents. DKIM accomplishes this by defining a domain-level authentication framework for email using public-key cryptography and key server technology [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.). This permits verifying a message source, an intermediary, or one of their agents, as well as the integrity of its contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments of unsigned messages. Such protection of email identity can assist in the global control of "spam" and "phishing".

This document provides a description of DKIM's architecture and functionality. It is intended for those who are adopting, developing, or deploying DKIM. It also will be helpful for those who are considering extending DKIM, either into other areas of use or to support additional features. This Overview does not provide information on threats to DKIM or email, or details on the protocol specifics, which can be found in [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) and [RFC4686] (Fenton, J., “Analysis of Threats Motivating DomainKeys Identified Mail (DKIM),” September 2006.), respectively. The document assumes a background in basic network security technology and services.

Neither this document nor DKIM attempt to provide solutions to the world's problems with spam, phishing, virii, worms, joe jobs, etc. DKIM provides one basic tool, in what needs to be a large arsenal, for improving basic trust in the Internet mail service. However by itself, DKIM is not sufficient to that task and this Overview does not pursue the issues of integrating DKIM into these larger efforts, beyond a simple reference within a system diagram. Rather, it is a basic introduction to the technology and its use.

1.1.  Prior Work

Historical email assessment based on identity has used the IP Address of a system that sent the message. The Address is obtained via underlying Internet information mechanisms and is therefore trusted to be accurate. Besides having some known security weaknesses, the use of Addresses present a number of functional and operational problems. Consequently there is an industry desire to use a more stable value that has better correspondence to organizational boundaries. Domain Names are viewed as often satisfying this need.

There have been four previous efforts at standardizing an Internet email signature scheme:

• Privacy Enhanced Mail (PEM) was first published in 1987. [RFC0989] (Linn, J. and IAB Privacy Task Force, “Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures,” February 1987.)
• PEM eventually transformed into MIME Object Security Services (MOSS) in 1995. [RFC1848] (Crocker, S., Galvin, J., Murphy, S., and N. Freed, “MIME Object Security Services,” October 1995.) Today, these two are only of historical interest.
• Pretty Good Privacy (PGP) was developed by Phil Zimmermann and first released in 1991. [RFC1991] (Atkins, D., Stallings, W., and P. Zimmermann, “PGP Message Exchange Formats,” August 1996.) A later version was standardized as OpenPGP. [RFC2440] (Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, “OpenPGP Message Format,” November 1998.) [RFC3156] (Elkins, M., Del Torto, D., Levien, R., and T. Roessler, “MIME Security with OpenPGP,” August 2001.) [I‑D.ietf‑openpgp‑rfc2440bis] (Callas, J., “OpenPGP Message Format,” April 2007.)
• RSA Security independently developed Secure MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851] (Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification,” July 2004.)

Development of S/MIME and OpenPGP has continued. While both have achieved a significant user base, neither have achieved ubiquity in deployment or use, and their goals differ from those of DKIM.

To the extent that other message-signing services might have been adapted to do the job that DKIM is designed to perform, it was felt that re-purposing any of those would be more problematic than creating a separate service. That said, DKIM uses security algorithm components that have a long history, including use within some of those other messaging security services.

DKIM has a distinctive approach for distributing and vouching for keys. It uses a key-centric Public Key Infrastructure (PKI) rather than the more typical approaches based on a certificate in the styles of Kohnfelder (X.509) or Zimmermann (web of trust). For DKIM, the owner of a key asserts its validity, rather than relying on the key having a broader semantic implication of the assertion, such as a quality assessment of the key's owner. DKIM treats quality assessment as an independent, value-added service, beyond the initial work of deploying a verifying signature service.

Further, DKIM's PKI is provided by adding information records to the existing Domain Name System (DNS) [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.), rather than requiring deployment of a new query infrastructure. This approach has significant operational advantages. First, it avoids the considerable barrier of creating a new global infrastructure; hence it leverages a global base of administrative experience and highly reliable distributed operation. Second, the technical aspect of the DNS is already known to be efficient. Any new service would have to undergo a period of gradual maturation, with potentially problematic early-stage behaviors. By (re-)using the DNS, DKIM avoids these growing pains.

1.2.  Discussion Venue

NOTE TO RFC EDITOR:

This "Discussion Venue" section is to be removed prior to publication.

This document is being discussed on the DKIM mailing list, ietf-dkim@mipassoc.org.

2.  Internet Mail Background

Internet Mail has a simple split between the user world, in the form of Mail User Agents (MUA), and the transmission world, in the form of the Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is responsible for accepting a message from one user, the author, and delivering it to one or more other users, the recipients. This creates a virtual MUA-to-MUA exchange environment. The first component of the MHS is called the Mail Submission Agent (MSA) and the last is called the Mail Delivery Agent (MDA).

An email Mediator is both an inbound MDA and outbound MSA. It takes delivery of a message and re-posts it for further distribution, retaining the original From header field. A mailing list is a common example of a Mediator

The modern Internet Mail service is marked by many independent operators, many different components for providing users with service and many other components for performing message transfer. Consequently, it is necessary to distinguish administrative boundaries that surround sets of functional components, which are subject to coherent operational policies.

As elaborated on below, every MSA is a candidate for signing using DKIM, and every MDA is a candidate for doing DKIM verification.

2.1.  Administrative Management Domain (ADMD)

Operation of Internet Mail services is apportioned to different providers (or operators). Each can be composed of an independent ADministrative Management Domain (ADMD). An ADMD operates with an independent set of policies and interacts with other ADMDs according to differing types and amounts of trust. Examples include: an end-user operating their desktop client that connects to an independent email service, a department operating a submission agent or a local Relay, an organization's IT group that operates enterprise Relays, and an ISP operating a public shared email service.

Each of these can be configured into many combinations of administrative and operational relationships, with each ADMD potentially having a complex arrangement of functional components. Figure 1 (ADministrative Management Domains (ADMD) Example) depicts the relationships among ADMDs. Perhaps the most salient aspect of an ADMD is the differential trust that determines its policies for activities within the ADMD, versus those involving interactions with other ADMDs.

Basic types of ADMDs include:

Edge:

Independent transfer services, in networks at the edge of the Internet Mail service.

User:

End-user services. These might be subsumed under an Edge service, such as is common for web-based email access.

Transit:

These are Mail Service Providers (MSP) offering value-added capabilities for Edge ADMDs, such as aggregation and filtering.

Note that Transit services are quite different from packet-level transit operation. Whereas end-to-end packet transfers usually go through intermediate routers, email exchange across the open Internet is often directly between the Edge ADMDs, at the email level.

+--------+                            +--------+    +--------+
| ADMD#1 |                            | ADMD#3 |    | ADMD#4 |
| ------ |                            | ------ |    | ------ |
|        |   +----------------------->|        |    |        |
| User   |   |                        |--Edge--+--->|--User  |
|  |     |   |                   +--->|        |    |        |
|  V     |   |                   |    +--------+    +--------+
| Edge---+---+                   |
|        |   |    +----------+   |
+--------+   |    |  ADMD#2  |   |
             |    |  ------  |   |
             |    |          |   |
             +--->|-Transit--+---+
                  |          |
                  +----------+

In Figure 1 (ADministrative Management Domains (ADMD) Example), ADMD numbers 1 and 2 are candidates for doing DKIM signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM verification.

The distinction between Transit network and Edge network transfer services is primarily significant because it highlights the need for concern over interaction and protection between independent administrations. The interactions between functional components within a single ADMD are subject to the policies of that domain. Although any pair of ADMDs can arrange for whatever policies they wish, Internet Mail is designed to permit inter-operation without prior arrangement.

Common ADMD examples are:

Enterprise Service Providers:

Operators of an organization's internal data and/or mail services.

Internet Service Providers:

Operators of underlying data communication services that, in turn, are used by one or more Relays and Users. It is not necessarily their job to perform email functions, but they can, instead, provide an environment in which those functions can be performed.

Mail Service Providers:

Operators of email services, such as for end-users, or mailing lists.

2.2.  DKIM Placement within an ADMD

It is expected that the most common venue for a DKIM implementation will be within the infrastructures of the originating organization's outbound service and the receiving organization's inbound service, such as a department or a boundary MTA. DKIM can be implemented in an author's or recipient MUA, but this is expected to be less typical, since it has higher administration and support costs.

A Mediator, such as a mailing list, often can re-post a message without breaking the DKIM signature. Furthermore it can add its own signature. This can be added by the Mediator software itself, or by any outbound component in the Mediator's ADMD.

3.  The DKIM Value Proposition

The nature and origins of a message are often falsely stated. As a foundation for distinguishing legitimate mail, DKIM provides a means of associating a verifiable identity with a message. Given the presence of that identity, a receiver can make decisions about further handling of the message, based upon assessments of that identity.

Receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behavior. DKIM does not, itself, prescribe any specific actions by the recipient; rather it is an enabling technology for services that do.

These services will typically:

1. Verify an identity
2. Determine whether the identity is known or unknown
3. Determine whether a known identity is trusted

The role of DKIM is in the first two of these; DKIM is an enabler for the third.

An attack is made against an organization or against customers of an organization. The name of the organization is linked to particular Internet domain names. One point of leverage used by attackers is either to use a legitimate domain name, without authorization or to use a "cousin" name that is similar to one that is legitimate, but is not controlled by the target organization. A DKIM-based assessment service can enforce a basic separation between domains used by such known organizations and domains used by others.

DKIM signatures can be created by a direct handler of a message, either as its originator or as an intermediary. It can also be created by an independent service, providing assistance to a handler of the message. Whoever does the signing chooses the domain name to be used as the basis for later assessments. Hence, reputation associated with that domain name is the basis for evaluating whether to trust the message for delivery. The owner of the domain name being used for a DKIM signature is declaring that they are accountable for the message.

DKIM is a value-added feature for email. Mail that is not signed by DKIM is handled in the same way as it was, before DKIM was defined; it continues to be evaluated by established analysis and filtering techniques. Over time, widespread DKIM adoption could permit more strict handling of messages that are not signed. However early benefits do not require this and probably do not warrant this.

It is important to be clear about the narrow scope of DKIM's capabilities. It is an enabling technology, intended for use in the larger context of determining message legitimacy. This larger context is complex, so it is easy to assume that a component like DKIM, which actually provides only a limited service, instead satisfies the broader set of requirements. A DKIM signature:

• Does not offer any assertions about the behaviors of the identity doing the signing.
• Does not prescribe any specific actions for receivers to take upon successful signature verification.
• Does not provide protection after signature verification.
• Does not protect against re-sending (replay of) a message that already has a verified signature; therefore a transit intermediary or a recipient can re-post the message in such a way that the signature would remain verifiable, although the new recipient(s) would not have been specified by the author.

4.  DKIM Goals

DKIM adds an end-to-end authentication mechanism to the existing email transfer infrastructure. This motivates functional goals about the authentication itself and operational goals about its integration with the rest of the Internet email service.

4.1.  Functional Goals

4.1.1.  Use Domain-level granularity for assurance.

OpenPGP and S/MIME provide end-to-end validation in terms of individual originators and recipients, notably using full email addresses, whereas DKIM seeks accountability at the more coarse granularity of an organization or, perhaps, a department. An existing Internet service construct that enables this granularity is the Domain Name [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.), to which the signing key record is bound. Further DKIM signing and/or validating can be implemented anywhere along the transit path, rather than only in the end systems or only in the boundary MTA.

4.1.2.  Allow delegation of signing to independent parties.

Different parties have different roles in the process of email exchange. Some are easily visible to end users and others are primarily visible to operators of the service. DKIM needs to support signing by any of these different parties and needs to permit them to sign with any domain name that they deem appropriate (and for which they are authorized.) As an example an organization that creates email content often delegates portions of its processing or transmission to an outsourced group. DKIM supports this mode of activity, in a manner that is not visible to end users.

4.1.3.  Distinguish the core authentication mechanism from its derivative uses.

An authenticated identity can be subject to a variety of processing policies, either ad hoc or standardized. The only semantics inherent to a DKIM signature is that the signer is asserting (some) responsibility for the message. All other mechanisms and meanings are independent of this core service. One such mechanism might assert a relationship between the signing identity and the author, as specified in the From header field's domain identity[RFC2822] (Resnick, P., “Internet Message Format,” April 2001.). Another might specify how to treat an unsigned message with that From field domain.

4.1.4.  Retain ability to have anonymous email.

The ability to send a message that does not identify its author is considered to be a valuable quality of the current email service that needs to be retained. DKIM is compatible with this goal since it permits an email system operator to be authenticated, rather than the content author. Knowing that a message definitely came from example.com does not threaten the anonymity of the user who authored it, if it is still possible to obtain effectively anonymous accounts at example.com.

4.2.  Operational Goals

4.2.1.  Treat verification failure the same as no signature present.

OpenPGP and S/MIME were designed for strong cryptographic protection. This included treating verification failure as message failure. As a sub-goal to the requirement for transparency, a DKIM signature verifier is to treat messages with signatures that fail as if they were unsigned. Hence the message will revert to normal handling, through the receiver's existing filtering mechanisms. Thus, DKIM specifies that a sender is not to take a message that has a broken signature and treat it any differently than if the signature weren't there.

4.2.2.  Make signatures transparent to non-supporting recipients.

S/MIME and OpenPGP modify the message body. Hence, their presence is potentially visible to email recipients, whose user software needs to process the associated constructs. In order to facilitate incremental adoption, DKIM is designed to be transparent to recipients that do not support it. A DKIM signature does not "get in the way" for such recipients.

4.2.3.  Permit incremental adoption for incremental benefit.

DKIM can immediately provide benefits between any two organizations that exchange email and implement DKIM. In the usual manner of "network effects", the benefits of DKIM increase dramatically as its adoption increases.

Although it is envisioned that this mechanism will call upon independent services to aid in the assessment of DKIM results, they are not essential in order to obtain initial benefit. For example DKIM allows (possibly large) pair-wise sets of email providers and spam filtering companies to distinguish mail that is associated with a known organization, from mail that might deceptively purport to have the affiliation. This in turn allows the development of "whitelist" schemes whereby authenticated mail from a known source with good reputation is allowed to bypass some anti-abuse filters.

In effect the email receiver is using their set of known relationships to generate their own reputation data. This works particularly well for traffic between large sending providers and large receiving providers. However it also works well for any operator, public or private, that has mail traffic dominated by exchanges among a stable set of organizations.

4.2.4.  Minimize the amount of required infrastructure

A new service, or an enhancement to an existing service, requires adoption by some number of systems, before it can be useful. The greater the number of required adopters, the higher the adoption barrier. This becomes particularly serious when adoption is required by intermediary -- that is, infrastructure -- service providers. In order to allow early adopters to gain early benefit, DKIM makes no changes to the core Internet Mail service and, instead, can provide a useful benefit for any signer/verifier pair of participants exchanging mail. Similarly, DKIM's reliance on the Domain Name System greatly reduces the amount of new administrative infrastructure that is need, across the open Internet.

4.2.5.  Permit wide range of deployment choices.

DKIM can be deployed at a variety of places within an organization's email service. This permits the organization to choose how much or how little they want DKIM to be part of their service, rather than part of a more localized operation.

5.  DKIM Function

DKIM has a very constrained set of capabilities, primarily targeting email while it is in transit, from an author to a set of recipients. It creates the ability to associate verifiable information with a message, especially a responsible identity. When a message is not signed, DKIM will permit the domain name of the author to be used for obtaining information about their signing practices.

5.1.  The Basic Signing Service

With the DKIM signature mechanism, a signer chooses a signing identity based on their domain name, performs digital signing on the message, and records signature information in a DKIM header field. A verifier obtains the domain name and the "selector" from the DKIM header field, queries for a public key associated with the name, and verifies the signature.

DKIM permits any domain name to be used for signing, and supports extensible choices for various algorithms. As is typical for Internet standards, there is a core set of algorithms that all implementations are required to support, in order to guarantee basic interoperability.

DKIM permits restricting the use of a signature key to signing messages for particular types of services, such as only for email. This is helpful when delegating signing authority, such as to a particular department or to a third-party outsourcing service.

With DKIM the signer explicitly lists the headers that are signed. By choosing the minimal set of headers needed, the signature is likely to be considerably more robust against the handling vagaries of intermediary MTAs.

5.2.  Characteristics of a DKIM signature

A DKIM signature covers the message body and selected header fields. The signer computes a hash of the selected header fields and another hash of the body. The signer then uses a private key to cryptographically encode this information, along with other signing parameters. Signature information is placed into a new [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) header field of the message.

5.3.  The Selector construct

The key for a signature is associated with a domain name, as specified in the d= DKIM-Signature header field parameter. That domain name is the complete identity used for making assessments about the signer. However this name is not sufficient for making a DNS query to obtain the key needed to verify the signature.

A single domain can use multiple signing keys and/or multiple signers. To support this, DKIM identifies a particular signature as a combination of the domain name and an added field, called the "selector", coded into separate DKIM-Signature header field parameters.

NOTE:

The selector is not intended to be part of the domain name that is used for making assessments. Rather, the selector is strictly reserved for use in administering keys that are associated with the domain name. If the selector becomes part of a name assessment mechanism, then there is no remaining mechanism for making a transition from an old, or compromised, key to a new one.

Signers often need to support multiple assessments about their organization, such as to distinguish one type of message from another, or one portion of the organization from another. To permit assessments that are independent, one method is for an organization to use different sub-domains in the "d=" parameter, such as "transaction.example.com" versus "newsletter.example.com", or "productA.example.com" versus "productB.example.com".

5.4.  Verification

After a message has been signed, any agent in the message transit path can verify the signature, to determine that the signing identity took responsibility for the message. Message recipients can verify the signature by querying the DNS for the signer's domain directly, to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. Typically, verification will be done by an agent in the ADMD of the message recipient.

6.  Service Architecture

The DKIM service is divided into components that can be performed using different, external services, such as for key retrieval. However the basic DKIM signing specification defines an initial set of these services, in order to ensure a basic level of interoperability.

                        |
                        |- RFC2822 Message
                        V
         +------------------------------------+
         | ORIGINATING OR RELAYING ADMD (MSA) |
         |                                    |
     +..>| Sign Message                       |
     .   +--------------+---------------------+
     .                  |
     .private           |
 +---+---+              |
 |  Key  |              |                    +-----------+
 | Store |          [Internet]               |  Sender   |
 +---+---+              |                    | Practices |
     .public            |                    +-----+-----+
     .                  V                          .
     .   +-----------------------------------+     .
     .   | RELAYING OR DELIVERING ADMD (MDA) |     .
     .   |                                   |     .
     .   | Message Signed?                   |     .
     .   +-------+----------------+----------+     .
     .           |yes             |no              .
     .           V                V                .
     .      +-----------+     +-----------+        .
     +.....>| Verify    | +-->| Check     |<.......+
            | Signature | |   | Practices |<.......+
            +---+-----+-+ |   +---+-------+        .
                |     |   |       |                .
                |     +---+       |                .
            pass|      fail       |                .
                V                 |          +-----+-----+
            +--------+            |          |  Local    |
   +.......>| Assess |            |          |  Sender   |
   .        | Signer |            |          | Practices |
   .        +---+----+            |          +-----------+
   .  assessment|                 |
   .            +------+   +------+
   .                   |   |
 +-+-----------+       V   V
 | Reputation/ |   +-----------+
 |Accreditation|   | Message   |
 |    Info     |   | Filtering |
 +-----+-------+   | Engine    |
                   +-----------+>

As shown in Figure 2 (DKIM Service Architecture), basic message processing is divided between the MSA and the MDA.

The MSA

The MSA signs the message, using private information from the Key Store.

The MDA

The MDA verifies the signature or determines whether a signature was required. Verifying the signature uses public information from the Key Store. If the signature passes, reputation information is used to asses the signer and that information is passed to the message filtering system. If the signature fails or there is no signature, information about the sender's practices is retrieved remotely and/or locally, and that information is passed to the message filtering system.

Note:

Figure 2 (DKIM Service Architecture) does not show the effects on the message-handling flow when multiple signatures or third-party signatures are present.

6.1.  Administration and Maintenance

A number of tables and services are used to provide external information. Each of these introduces administration and maintenance requirements.

Key Store

DKIM uses public/private (asymmetric) key technology. The signer users a private key and the validator uses the corresponding public key. The current DKIM signing specification provides for querying the Domain Names Service (DNS), to permit a validator to obtain the public key. The signing organization therefore must have a means of adding a key to the DNS, for every selector/domain-name combination. Further, the signing organization needs policies for distributing and revising keys.

Sender Practices

If a message contains a valid signature, then the verifier can evaluate the associated domain name's reputation. If a message does not contain a valid signature, that fact could be useful, if the verifier can discover information about the DKIM-related practices of one of the agents purportedly involved with the message, such as the domain listed in the author's FROM header field. Such information might come from tables developed through private agreement or from standards-based mechanisms. As they are defined, each domain name owner will need to consider what information to publish through the mechanism and then will need to create and maintain it.

Reputation/Accreditation

"Reputation/Accreditation" provides quality-assessment information that is associated with a domain name, and comes in many forms and from many sources. DKIM does not define these services. It's relevance to them is to provide a validated domain name, upon which assessments can be made.

6.2.  Signing

Signing can be performed by a component of the ADMD that creates the message, and/or within any ADMD along the relay path. The signer uses the appropriate private key.

6.3.  Verifying

Verification can be performed by any functional component along the relay and delivery path. Verifiers retrieve the public key based upon the parameters stored in the message.

6.4.  Unverified or Unsigned Mail

Note that a failed signature causes the message to be treated in the same manner as one that is unsigned. Messages lacking a valid originator signature (a signature associated with the originator of the message as opposed to a signature associated with an intermediary) prompt a query for any published "sender practices" information, as an aid in determining whether the sender information has been used without authorization.

6.5.  Evaluating

The Figure shows the verified identity as being used to assess an associated reputation, but it could be applied for other tasks, such as management tracking of mail. A popular use of reputation information is as input to a filtering engine that decides whether to deliver -- and possibly whether to specially mark -- a message. Filtering engines have become complex and sophisticated. Their details are outside of DKIM's scope, other than the expectation that DKIM-related information is added to the varied soup of rules used by the engines. The rules can cover signed messages and can deal with unsigned messages from a domain, if the domain has published information about is practices

7.  Security Considerations

TBD

8.  IANA Considerations

TBD

9.  Acknowledgements

TBD

10. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © 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 ietf-ipr@ietf.org.