DomainKeys Identified Mail                                     T. Hansen
Internet-Draft                                         AT&T Laboratories
Intended status: Informational                                D. Crocker
Expires: September 5, December 13, 2007                   Brandenburg InternetWorking
                                                         P. Hallam-Baker
                                                           VeriSign Inc.
                                                           March 4,
                                                           June 11, 2007

               DomainKeys Identified Mail (DKIM) Message Signing Service Overview
                      draft-ietf-dkim-overview-04
                      draft-ietf-dkim-overview-05

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 5, December 13, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   DomainKeys Identified Mail (DKIM) associates a "responsible" identity
   with a message and provides a means of verifying that the association
   is legitimate.[I-D.ietf-dkim-base]. legitimate.  [RFC4871] DKIM defines a domain-level authentication
   framework for email using public-key cryptography and key server
   technology.  This permits verifying the source or intermediary for a
   message, as well as the contents of messages.  The ultimate goal of
   this framework is to permit a signing domain to assert responsibility
   for a message, thus proving and protecting the identity associated
   with the message and the integrity of the messages itself, while
   retaining the functionality of Internet email as it is known today.
   Such protection of email identity, identity may assist in the global control of
   "spam" and "phishing".  This document provides an overview of DKIM and DKIM,
   describes how it can fit into a messaging service, describes how it
   relates to other IETF message signature
   technologies.  It also technologies, and includes
   implementation and migration considerations.

Table of Contents

   1.  Introduction .  DKIM Framework . . . . . . . . . . . . . . . . . . . . . . . .  4  3
     1.1.  Background .  Introduction . . . . . . . . . . . . . . . . . . . . . . .  4  3
     1.2.  The DKIM Value Proposition . . . . . . . . . .  Goals  . . . . . .  5
     1.3.  Phishing . . . . . . . . . . . . . . . . . . . .  9
     1.3.  Function . . . . .  6
     1.4.  Conventions . . . . . . . . . . . . . . . . . . . . 11
     1.4.  Service Architecture . . .  6
   2.  Goals . . . . . . . . . . . . . . . . 13
   2.  Deployment and Operation of DKIM Base  . . . . . . . . . . . .  6 15
     2.1.  Treat verification failure as if unsigned. .  Development  . . . . . . .  7
     2.2.  Domain-level assurance . . . . . . . . . . . . . . . . 15
     2.2.  Email Infrastructure Agents  . .  7
     2.3.  Incremental adoption . . . . . . . . . . . . . 16
     2.3.  Filtering  . . . . . .  7
     2.4.  Minimal infrastructure . . . . . . . . . . . . . . . . . .  8
     2.5.  Transparent signature 17
     2.4.  DNS Server . . . . . . . . . . . . . . . . . .  8
     2.6.  Security policy . . . . . . 18
     2.5.  Deployment . . . . . . . . . . . . . . .  9
   3.  Function and Use . . . . . . . . . 18
     2.6.  On-going Operations  . . . . . . . . . . . . . .  9
     3.1.  What is a DKIM signature? . . . . . 24
     2.7.  Example Uses . . . . . . . . . . .  9
     3.2.  The Selector construct . . . . . . . . . . . . 27
   3.  Acknowledgements . . . . . .  9
     3.3.  Validation . . . . . . . . . . . . . . . . . 29
   4.  Informative References . . . . . . . 10
     3.4.  What does DKIM NOT do? . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . 10
     3.5.  Does DKIM eliminate anonymity for email? . . . . . . . . . 11
   4.  DKIM Within Existing Internet Email . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . 11
     4.1.  Review of Internet Mail Service Architecture . . . . . . . 11
     4.2.  Where to Place 32

1.  DKIM Functions  . . . . . . . . . . . . . . 14
     4.3.  Impact on Email Activities . . . . . . . . . . . . . . . . 15
     4.4.  Migrating from Framework

1.1.  Introduction

   DomainKeys  . . . . . . . . . . . . . . . . 17
   5.  Service Architecture . . . . . . . . . . . . . . . . . . . . . 18
   6.  Development  . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  Coding Criteria for Cryptographic Applications . . . . . . 20
     6.2.  Email Infrastructure Agents  . . . . . . . . . . . . . . . 21
     6.3.  Filtering  . . . . . . . . . . . . . . . . . . . . . . . . 22
     6.4.  DNS Server . . . . . . . . . . . . . . . . . . . . . . . . 23
   7.  Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     7.1.  Signing  . . . . . . . . . . . . . . . . . . . . . . . . . 23
     7.2.  Verifying  . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.3.  Mail User Agent  . . . . . . . . . . . . . . . . . . . . . 25
     7.4.  Transition strategy  . . . . . . . . . . . . . . . . . . . 25
   8.  On-going Operations  . . . . . . . . . . . . . . . . . . . . . 27
     8.1.  DNS Signature Record Deployment Considerations . . . . . . 27
     8.2.  Private Key Management . . . . . . . . . . . . . . . . . . 29
     8.3.  Mailing list manager developers  . . . . . . . . . . . . . 29
   9.  Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 30
     9.1.  Protection of Internal Mail  . . . . . . . . . . . . . . . 30
     9.2.  Recipient-based Assessments  . . . . . . . . . . . . . . . 30
     9.3.  DKIM Support in the Client . . . . . . . . . . . . . . . . 31
     9.4.  Per user signature . . . . . . . . . . . . . . . . . . . . 31
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
   11. { Misc Text -- Should go elsewhere, if used at all } . . . . . 32
   12. Informative References . . . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 35

1.  Introduction

   DomainKeys Identified Mail (DKIM) associates a "responsible" identity
   with a message and provides a means of verifying that the association
   is legitimate.[I-D.ietf-dkim-base].  DKIM defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology.  This permits verifying the source or
   intermediary for a message, as well as the contents of messages.  The
   ultimate goal of this framework is to permit a signing domain to
   assert responsibility for a message, thus proving and protecting the
   identity associated with the message and the integrity of the
   messages itself, while retaining the functionality of Internet email
   as it is known today.  Such protection of email identity, may assist
   in the global control of "spam" and "phishing".  This document
   provides an overview of DKIM and describes how it can fit into a
   messaging service, how it relates to other IETF message signature
   technologies.  It also includes implementation and migration
   considerations.

   This document provides an overview of DomainKeys Identified Mail
   (DKIM).  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 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 [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats],
   respectively.  The document assumes a background in basic network
   security technology and services.

   It must be stressed that neither this document nor DKIM attempt to
   provide solutions to the world's problems with spam, phish, virii,
   worms, joe jobs, etc.  DKIM creates one basic tool in what needs to
   be a large arsenal of tools, for improving the safety of Internet
   mail.  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.  Rather, it is a basic introduction to the
   technology and its deployment.

1.1.  Background

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

   o  Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989]

   o  PEM eventually transformed into MIME Object Security Services in
      1995 [RFC1848].  Today, these two are only of historical interest.

   o  Pretty Good Privacy (PGP) was developed by Phil Zimmerman and
      first released in 1991.[RFC1991] A later version was standardized
      as OpenPGP.  [RFC3156]

   o  RSA Security, the holder of the patent rights to the principle
      public key cryptography algorithm, independently developed Secure
      MIME (S/MIME) to transport a PKCS #7 data object.  [RFC3851]

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

   In principle the S/MIME protocol can support semantics such as domain
   level signatures or make use of keys stored in the DNS.  However the
   currently deployed base does not and modifying it to do so would
   require extensive effort.

   Unlike previous IETF email security initiatives, DKIM employs a key
   centric Public Key Infrastructure (PKI) as opposed to one that is
   based on a certificate in the style of Kohnfelder (X.509) or
   Zimmerman (web of trust).  That is, the owner of a key asserts its
   validity, rather than relying on 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
   validating signature service.

   Further, DKIM's PKI is supported as additional information records to
   the existing Domain Name Service, rather than requiring deployment of
   a new query infrastructure.  This approach also has significant
   performance advantages as DNS is layered on UDP and key retrieval is
   typically achieved in a single round trip.

1.2.  The DKIM Value Proposition

   Spam can be understood as two separate problems.  The first is the
   problem of companies that are inappropriately aggressive, in sending
   out unsolicited marketing email.  This accounts for, perhaps, 5% of
   the spam volume and is in any case usually handled by existing spam
   filters.  [N.B. need a reference for the 5%.]  The second problem is
   rogue spam -- often involving criminal activities -- mostly sent from
   coerced botnets of compromised machines.  For this latter set of
   mail, the origins of a message are often falsely stated.

      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.

   For messages that produce a valid signature, it will be possible to
   make affirmative trust assessments.  For messages using identities
   that are typically signed, it will be possible to detect some types
   of phishing emails and block them.

1.3.  Phishing

   The value of a cousin domain, that could be mistaken for the
   legitimate domain, is significantly reduced if the number of emails
   that can be successfully sent from it is small.

   Phishing attacks are typically made against trusted brands, that is,
   names that are closely affiliated with well-known organizations.  A
   DKIM-based accreditation service can enforce a basic separation
   between domains used by such known organizations and domains used by
   others.

   Receivers who successfully validate a signature can use information
   about the signer as part of a program to limit spam, spoofing,
   phishing, or other undesirable behavior, although the DKIM
   specification itself does not prescribe any specific actions by the
   recipient.

1.4.  Conventions

   In this document, references to structured fields of a message use a
   two-part dotted notation.  The first part cites the document that
   contains the specification for the field and the second is the name
   of the field.  Hence <RFC2822.From> is the From field in an email
   content header [RFC2822] and <RFC2821.MailFrom> is the address in the
   SMTP "Mail From" command.  [RFC2821]

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

2.  Goals

   DKIM lets an organization take responsibility for a message.  The
   organization taking responsibility typically is a handler of the
   message, either as its originator or as an intermediary.  It can also
   be an independent service, providing assistance to a handler of the
   message.  Their reputation 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.  This means that
   their reputation is at stake.

   By design, DKIM purposely:

   o  is compatible with the existing email infrastructure and
      transparent to the fullest extent possible

   o  requires minimal new infrastructure

   o  can be implemented independently of clients in order to reduce
      deployment time

   o  does not require the use of new trusted third parties (e.g.,
      certificate authorities) that might impose significant costs or
      introduce delays to deployment

   o  can be deployed incrementally, with separate deployment of signers
      and verifiers in either order

   o  allows delegation of signing to third parties

   o  is not intended be used for archival purposes

   DKIM authentication provides one link in a chain of responsibility,
   hopefully leading to better accountability by the senders.

2.1.  Treat verification failure as if unsigned.

   PGP and S/MIME were both designed for strong cryptographic
   protection.  This included treating validation failure as message
   failure.  For DKIM, the guidance is that an email 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.

2.2.  Domain-level assurance

   PGP and S/MIME apply the end-to-end principle in terms of individual
   originators and recipients, notably using full email addresses.  DKIM
   seeks accountability at the more coarse grain of an organization or,
   perhaps, a department.  A deployed construct that enables this
   granularity is the domain name, to which the signing key record is
   bound.

2.3.  Incremental adoption

   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 assessment services, they are not essential in order to
   obtain initial benefit.  For example DKIM allows pair-wise sets of
   (possibly large) 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 spam filters.  In effect the email receiver is
   using their set of known relationships to generate their own
   accreditation/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 Identified Mail (DKIM) associates a stable
   set of organizations.

   Over time, DKIM adoption might become sufficiently widespread to
   permit special, negative handling of messages that are not signed.
   However early benefits do not require this more-stringent
   enforcement.

2.4.  Minimal infrastructure

   DKIM can be implemented at "responsible" identity
   with 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
   infrastructure, rather than part of message and provides a more localized operation.
   Similarly, DKIM's reliance on the Domain Name Service greatly reduces
   the amount means of new administrative infrastructure verifying that must be deployed
   over the open Internet.

   Even with use of the DNS, one challenge is that it association
   is usually
   operated by different administrative staff than those who operate an
   organization's email service.  In order to ensure that legitimate.  [RFC4871] DKIM DNS
   records are accurate, accomplishes this imposes by defining a requirement
   domain-level authentication framework for careful
   coordination between the two operations groups.

2.5.  Transparent signature

   S/MIME and PGP both modify the message body.  Hence, their presence
   is visible to all email recipients using public-key
   cryptography and their user software must be
   able to process key server technology.  This permits verifying the associated constructs.  In order to facilitate
   incremental adoption,
   source or intermediary for a message, as well as the contents of
   messages.  DKIM is designed to be transparent to
   recipients will also provide a mechanism that do not support it.

2.6.  Security policy

   DKIM separates basic authentication from policy.  An authenticated
   identity may be subject permits potential
   email signers to a variety publish information about their email signing
   practices; this will permit email receivers to make additional
   assessments of processing policies, either
   ad hoc or standardized. unsigned messages.

   The only policy inherent in a DKIM signature
   is that the signer ultimate goal of this framework is asserting (some) responsibility for the
   message.  Other possible policies to consider developing include
   asserting permit a domain to assert
   responsibility for a relationship between message, thus proving and protecting the signing
   identity and associated with the author
   (RFC 2822 From) domain identity, as well as whether to tread unsigned message with that From domain and the integrity of the
   messages itself, while retaining the functionality of Internet email
   as problematic. it is known today.  Such protection of email identity, may assist
   in the global control of "spam" and "phishing".

   This document provides a description of DKIM's architecture,
   functionality, deployment and use.  It would, therefore, is intended for those who are
   adopting, developing, or deploying DKIM.  It also will be helpful for a potential signer to be able
   those who are considering extending DKIM, either into other areas of
   use or to publish various
   policies, support additional features.  This Overview does not
   provide information on threats to permit DKIM or email, or details on the
   protocol specifics, which can be found in [RFC4871] and [RFC4686],
   respectively.  The document assumes a receiver background in basic network
   security technology and services.

   It must be stressed that neither this document nor DKIM attempt to
   provide solutions to know more about the signer's
   practices

3.  Function and Use world's problems with spam, phish, virii,
   worms, joe jobs, etc.  DKIM has provides one basic tool, in what needs to
   be a very constrained set large arsenal, for improving the safety of capabilities, primarily targeting
   email while it Internet mail.
   However, by itself, DKIM is in transit, from an originator not sufficient to one or more
   recipients. that task and this
   overview does not pursue the issues of integrating DKIM defines a mechanism by which email messages can be
   cryptographically signed, permitting into these
   larger efforts.  Rather, it is a signing domain basic introduction to claim
   responsibility for the presence technology
   and its deployment.

1.1.1.  The DKIM Value Proposition

   The nature and origins of a message in the mail stream.  A
   responsible organization adds are often falsely stated.  As a digital signature to the message,
   foundation for distinguishing legitimate mail, DKIM provides a means
   of associating it a verifiable identity with a domain name message.  Given the
   presence of that organization.  Typically,
   signing will be done by identity, a service agent within the authority receiver can make decisions about
   further handling of the
   message originator's Administrative Management Domain (ADMD).
   (Signing might be performed by any message, based upon assessments of the functional components in that environment, including
   identity.

   Receivers who successfully verify a Mail User Agent (MUA), signature can use information
   about the signer as part of a Mail
   Submission Agent (MSA), program to limit spam, spoofing,
   phishing, or an Internet Boundary MTA. other undesirable behavior.  DKIM also
   permits signing to be performed does not, itself,
   prescribe any specific actions by authorized third-parties.)

3.1.  What the recipient; rather it is a DKIM signature?

   A signature covers an
   enabling technology for services that do.

   These services will typically:

   1.  Verify an identity

   2.  Determine whether the message body and selected header fields.  The
   signer computes identity is known or unknown

   3.  Determine whether a hash known identity is trusted

   An attack is made against an organization or against customers of the selected header fields and another hash an
   organization.  The name of the body.  They then organization is linked to particular
   Internet domain names.  One point of leverage used by attackers is
   either to spoof a legitimate domain name, or to use a private key "cousin" name
   that is similar to cryptographically encode
   this information, along with other signing parameters.  The signature
   information one that is placed into a new header field of legitimate, but is not controlled by
   the [RFC2822]
   message.

3.2.  The Selector construct

   For target organization.  A DKIM-based accreditation service can
   enforce a single domain, basic separation between domains used by such known
   organizations and domains used by others.

   DKIM permits use signatures can be created by a direct handler of multiple signing keys and/or
   multiple signers.  To do this, DKIM identifies a particular signature message,
   either as its originator or as an intermediary.  It can also be
   created by an independent service, providing assistance to a combination handler
   of the message.  Whoever does the signing chooses the domain name and an added field, called to
   be used as the
   "selector".  Both of these are coded into basis for later assessments.  Hence, reputation
   associated with that domain name is the DKIM-Signature header
   field.

   Selectors are assigned according basis for evaluating whether
   to trust the administrative needs message for delivery.  The owner of the
   signing domain, such as domain name
   being used for rolling over to a new key or DKIM signature is declaring that they are
   accountable for
   delegating of the right message.

   DKIM is intended to authenticate be a portion of value-added feature for email.  Mail that is
   not signed by email is handled in the namespace same way as it now is; it
   continues to
   a trusted third party.

      Examples include:   jun2005.eng._domainkey.example.com

         widget.promotion._domainkey.example.com

      NOTE: be evaluated by established analysis and filtering
   techniques.  Over time, widespread DKIM adoption could permit
   degraded handling of messages that are not signed.  However early
   benefits do not require this more-stringent enforcement.

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

   o  Does not include offer any assertions about the selector.  This
         permits behaviors of the selector to be used only identity
      doing the signing.

   o  Does not prescribe any specific actions for key administration,
         rather than having an effect on reputation assessment.

3.3.  Validation

   After receivers to take upon
      successful (or unsuccessful) signature verification.

   o  Does not provide protection after signature verification.

   o  Does not protect against re-sending (replay of) a message that
      already has been signed, any agent in the message a verified signature; therefore a transit
   path intermediary
      or a recipient can choose to validate re-post the signature, to determine message in such a way that the
   signing identity took responsibility for the message.  Message
   recipients can verify the
      signature would remain verifiable, although the new recipient(s)
      would not have been specified by querying the signer's domain
   directly originator.

1.1.2.  Prior Work

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

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

   o  Privacy Enhanced Mail (PEM) was first published in 1987.
      [RFC0989]

   o  PEM eventually transformed into MIME Object Security Services in
      1995.  [RFC1848] Today, these two are only of historical interest.

   o  Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
      first released in 1991.  [RFC1991] A later version was attested
      standardized as OpenPGP.  [RFC2440] [RFC3156]
      [I-D.ietf-openpgp-rfc2440bis]

   o  RSA Security independently developed Secure MIME (S/MIME) to by
      transport a party in possession PKCS #7 data object.  [RFC3851]

   Development of the
   private key for the signing domain.  Typically, validation will be
   done by an agent S/MIME and OpenPGP have continued.  While both have
   achieved a significant user base, neither have achieved ubiquity in the ADMD
   deployment or use, and their goals differ from those of DKIM.

   To the message recipient.

3.4.  What does DKIM NOT do?

   A extent that other message-signing services might have been
   adapted to do the job that DKIM signature does not:

   o  offer is designed to perform, it was felt
   that re-purposing any assertions about the behaviors of the identity doing the
      signing.

   o  prescribe any specific actions for receivers to take upon
      successful (or unsuccessful) signature validation.

   o  provide protection after message delivery.

   o  protect against re-sending (replay of) those would be more problematic than
   creating a message separate service.  That said, DKIM uses security algorithm
   components that already has have a valid signature; therefore long history, including use within some of
   those other messaging security services.

   DKIM has a transit intermediary or distinctive approach for distributing and vouching for
   keys.  It uses a recipient
      can re-post key-centric Public Key Infrastructure (PKI) rather
   than the message in such more typical approaches based on a way that the signature would
      remain valid, although certificate in the new recipient(s) would not have been
      specified by styles
   of Kohnfelder (X.509) or Zimmermann (web of trust).  For DKIM, the originator.

3.5.  Does DKIM eliminate anonymity for email?

   The ability to send
   owner of a message that does not identify key asserts its author is
   considered to be validity, rather than relying on the key
   having a broader semantic implication of the assertion, such as a valuable
   quality assessment of the current email system.  It
   turns out that key's owner.  DKIM is particularly helpful to this goal, because treats quality
   assessment as an independent, value-added service, beyond the initial
   work of deploying a
   DKIM verifying signature will typically be used service.

   Further, DKIM's PKI is supported by adding additional information
   records to identity an email system
   operator, the existing Domain Name Service (DNS) [RFC1034], rather
   than requiring deployment of a content author.  Knowing that new query infrastructure.  This
   approach has significant operational advantages.  First, it avoids
   the considerable barrier of creating a mail
   definitely came from example.com does not threaten new infrastructure; hence it
   leverages a global base of administrative experience and highly
   reliable distributed operation.  Second, the anonymity technical aspect of the user, if it
   DNS is still possible already known to obtain effectively anonymous
   accounts at example.com and other web mail providers.

4.  DKIM Within Existing Internet Email

4.1.  Review 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.1.3.  Internet Mail Service Architecture 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
   and delivering it to one or more other users, creating a virtual MUA-
   to-MUA exchange environment.  The first MTA is called the Mail
   Submission Agent (MSA) and the final MTA is called the Mail Delivery
   Agent (MDA)
                                 +--------+
               +---------------->|  User  |
               |                 +--------+
               |                      ^
   +--------+  |          +--------+  .
   |  User  +--+--------->|  User  |  .
   +--------+  |          +--------+  .
       .       |               ^      .
       .       |   +--------+  .      .
       .       +-->|  User  |  .      .
       .           +--------+  .      .
       .                ^      .      .
       .                .      .      .
       V                .      .      .
   +---+----------------+------+------+---+
   |   .                .      .      .   |
   |   +...............>+      .      .   |
   |   .                       .      .   |
   |   +......................>+      .   |
   |   .                              .   |
   |   +.............................>+   |
   |                                      |
   |     Mail Handling Service (MHS)      |
   +--------------------------------------+

                Figure 1: Basic Internet Mail Service Model (MDA).

   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.

4.1.1.

1.1.3.1.  Administrative Actors

   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 include: an end-
   user operating their desktop client, client that connects to an independent
   email service, a department operating a submission agent or a local
   Relay, an organization's IT department operating an group that operates enterprise Relay Relays,
   and an ISP operating a public shared email service.  These

   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 2 1 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 components of ADMD distinction 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.

   +-------+                           +-------+    +-------+
   | ADMD1 |                           | ADMD3 |    | ADMD4 |
   | ----- |                           | ----- |    | ----- |
   |       |   +---------------------->|       |    |       |
   | User  |   |                       |-Edge--+--->|-User  |
   |  |    |   |                  +--->|       |    |       |
   |  V    |   |                  |    +-------+    +-------+
   | Edge--+---+                  |
   |       |   |    +---------+   |
   +-------+   |    |  ADMD2  |   |
               |    |  -----  |   |
               |    |         |   |
               +--->|-Transit-+---+
                    |         |
                    +---------+

        Figure 2: 1: ADministrative Management Domains (ADMD) Example

   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 an ADMD are subject to the policies of that domain.

   Common ADMD examples are:

      Enterprise Service Providers:   Operating   Operators of an organization's
         internal data and/or mail services.

      Internet Service Providers:   Operating   Operators of underlying data
         communication services that, in turn, are used by one or more
         Relays 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.

1.1.4.  Conventions

   In this document, references to structured fields of a message use a
   two-part dotted notation.  The first part cites the document that
   contains the specification for the field and the second is the name
   of the field.  Hence <RFC2822.From> is the From field in an email
   content header [RFC2822] and <RFC2821.MailFrom> is the address in the
   SMTP "Mail From" command.  [RFC2821]

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

1.2.  Goals

   DKIM seeks to add authentication to the existing email transfer
   infrastructure.  This motivates functional goals about authentication
   and operational goals about integration with the existing email
   service.

1.2.1.  Functional

   Use Domain-level granularity for assurance.   OpenPGP and S/MIME
      apply the end-to-end principle in terms of individual originators
      and recipients, notably using full email addresses.  DKIM seeks
      accountability at the more coarse grain of an organization or,
      perhaps, a department.  A deployed construct that enables this
      granularity is the domain name, to which the signing key record is
      bound.  Further DKIM signing and/or validating may be implemented
      anywhere along the transit path, rather than only in the end
      systems.

   Allow delegation of signing to independent parties.   Different
      parties have different roles in the process of email exchange.
      Some of these parties 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 Users.  It is not necessarily their job needs to perform
         email functions, but
      permit them to sign with any domain name that they can, instead, provide deem
      appropriate.  As an environment
         in which those functions can be performed.

      Mail Service Providers:   Operating example an organization that creates email services, such as for
         end-users,
      content often delegates portions of its processing or mailing lists.

4.2.  Where transmission
      to Place an outsourced group.  DKIM Functions

   Deciding which ADMD shall perform signing or verifying, which must support this mode of activity,
      in a manner that is not visible to end users.

   Distinguish the core authentication mechanism from its derivative
   uses.   An authenticated identity may be subject to assign and which functional components a variety of
      processing policies, either ad hoc or standardized.  The only
      semantics inherent to use for a DKIM
   processing depends upon the nature of the trust/reputation signature is that the signer is
      asserting (some) responsibility for the message.  All other
      mechanisms and meanings are independent of
   interest this core service.  One
      such mechanism might assert a relationship between the signing
      identity and the most convenient or efficient way author (<RFC2822.From>) domain identity.  Another
      might specify how to use it.
   Messages may be signed or verified by any functional component within treat an ADMD, as unsigned message with that domain wishes
      <RFC2822.From> domain.

   Retain ability to arrange.  Examples include:

      Outbound:   MUA, MSA or boundary MTA.

      Inbound:   Boundary MTA, MDA or MUA.

   By having an MUA do the signing or verifying, there is no dependence
   upon implementation by an email service infrastructure.  By having an
   MHS component do signing or verifying, there have anonymous email.   The ability to send a
      message that does not identify its author is no dependence upon
   user training or the upgrade of potentially large numbers considered to be a
      valuable quality of user
   applications.

   For implementation by the current email system that needs to be
      retained.  DKIM is compatible with this goal since it permits an ADMD's
      email service operators, perhaps the
   most obvious choices within system operator to be authenticated, rather than the MHS are content
      author.  Knowing that a mail definitely came from example.com does
      not threaten the MSA or MDA, and anonymity of the
   outbound or inbound (boundary) MTA.  By signing or verifying user, if it is still possible to
      obtain effectively anonymous accounts at the
   MSA example.com and MDA, respectively, this outermost portion of the MHS provides
   true end-to-end service, other
      mail providers.

1.2.2.  Operational

   Make signature transparent to non-supporting recipients.   S/MIME and requires
      OpenPGP both modify the smallest amount of trust of message body.  Hence, their presence is
      potentially visible to email recipients and their user software
      must be able to process the intervening service infrastructure.  By signing or verifying at a
   boundary, associated constructs.  In order to
      facilitate incremental adoption, DKIM is designed to be
      transparent to recipients that do not support it.

   Treat verification failure the smallest number of systems need modifying within an
   ADMD same as no signature unsigned.
      OpenPGP and S/MIME were both 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 subject to the smallest amount of handling 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.

   Permit incremental adoption for incremental benefit.   DKIM can break
      immediately provide benefits between any two organizations that
      exchange email and implement DKIM.  In the signature.  Note, however, usual manner of
      "network effects", the benefits of DKIM increase dramatically as
      its adoption increases.

      Although it is envisioned that this mechanism will
   eliminate DKIM signing for mail that stays within call upon
      independent services to aid in the ADMD.

   The choice assessment of identity to use might DKIM results,
      they are not be obvious.  Examples
   include:

      Author:   The domain associated with the RFC2822.From field
         provides basic authorization for the author essential in order to generate mail.
         Because the organization controlling obtain an initial benefit.  For
      example DKIM allows (possibly large) pair-wise sets of email
      providers and spam filtering companies to distinguish mail that domain is closest
      associated with a known organization, from mail that might
      deceptively purport to have the author, they well might be affiliation.  This in turn allows
      the best position to offer
         their reputation as development of 'whitelist' schemes whereby authenticated mail
      from a basis for asserting that the content known source with good reputation is
         "safe".

      Operator:   Email recipient services have long-used allowed to bypass some
      spam filters.  In effect the IP Address email receiver is using their set of a client SMTP server as the basis for assessing whether
      known relationships to
         permit relay generate their own accreditation/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 delivery of private, that has mail
      traffic dominated by exchanges among a message.  These Addresses
         identify the operator stable set of an email service, rather than
         necessarily indicating
      organizations.

   Minimize the author of messages being sent by
         that service.  Use amount of required infrastructure.   A new service, or
      an operator's domain name is a natural
         extension of this model.

      Third-party:   An independent service might wish enhancement to certify an
         author, a message or an operator, existing service, requires adoption by providing its own
         signature to a message.  Hence, evaluation some
      number of the message will systems, before it can be based upon useful.  The greater the identity of that third-party, rather than any
      number of required adopters, the identities involved in creating or transferring higher the
         message.  Indeed, this model is already emerging among a number
         of reputation-vetting services and adoption barrier.
      This becomes particularly serious when adoption is similar required by
      intermediary -- that is, infrastructure -- service providers.  In
      order to the way a
         credit card permits a customer allow early adopters to gain early benefit, DKIM seeks to
      make purchases, based upon
         the reputation of the credit card company -- and its
         willingness no changes to issue the card.

   Ultimately, deciding where core Internet Mail service and, instead, to sign
      allow a message will depend upon both useful benefit for any signer/verifier pair of
      participants exchanging mail.

      Similarly, DKIM's reliance on the identity being used and tradeoffs among flexibility Domain Name Service greatly
      reduces the amount of uses, new administrative control, and operational control.  Deciding where to
   verify a message will depend upon infrastructure that must
      be deployed over the intended use and similar
   concerns about flexibility and control.  A typical choice for
   reputation-related verification will open Internet.

   Permit wide range of deployment choices.   It should be possible to place
      implement DKIM at a variety of places within an organization's
      email service.  This permits the signature
   verification function "close" organization to the message-filtering engine.

4.3.  Impact on Email Activities

4.3.1.  Resources

   Although public-key cryptographic authentication is considered choose how much
      or how little they want DKIM to be
   computationally expensive, the real impact part of their service, rather
      than part of a mechanism like more localized operation.

1.3.  Function

   DKIM
   can be remarkably small.  Direct impact on CPU-load has been measured
   to be 10-15%.  Mail handling tends to be I/O-intensive, so that
   dedicated email platforms tend to have unused computational capacity.
   It is therefore likely that no new hardware will be required for
   these systems to be able to add DKIM support.

4.3.2.  Operations

   The costs to deploy, administer and operate DKIM vary greatly,
   depending upon the placement a very constrained set of DKIM-related modules.  The greatest
   flexibility comes capabilities, primarily targeting
   email while it is in transit, from placing an originator to a set of
   recipients.  It creates the modules as close as possible ability to associate verifiable
   information with a message, especially a responsible identity.  When
   a message is not signed, DKIM permits the end user.  However this also imposes identity of the greatest costs.  The
   most common scenarios are likely sender to be:

      Boundary MTA:   Here, DKIM is
   be used only for email external to obtaining information about their signing practices.

1.3.1.  The Basic Signing Service

   With the DKIM signature mechanism, a signer associates a domain name
   with an address, performs digital signing on the
         ADMD.  Administration message, and operation is records
   signature information in a DKIM header field.  A verifier obtains the simplest, but could
         cause problems
   domain name from the DKIM header field, queries for mobile users who are a public key
   associated with the
         organization but must send mail using facilities that are
         independent of their home ADMD.  It also provides no assistance
         for inter-departmental accountability within name, and verifies the ADMD..

      MSA/MDA (Department):   Placing signature.

   DKIM support at the points of
         submission permits any domain name to be use for signing, and delivery increases the deployment costs but
         still keeps control within the ADMD's operational staff.  It
         avoids the considerable, added costs supports
   extensible choices for various algorithms.  As is typical for
   Internet standards, there is a core set of having algorithms required to enhance be
   supported by all
         of the MUAs. implementations.  This does not improve ensures an initial ability to
   interoperate.

   DKIM permits restricting the lot use of mobile users who
         submit from independent MSAs, but does provide full protection
         within a signature key to 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 ADMD.

      MUA:   Obviously this can provide signer MUST explicitly list the most complete protection,
         but at headers that are
   signed.  By choosing the cost minimal set of considerable added administrative effort.
         Worse, there headers needed the signature
   is extensive evidence that email infrastructure
         services often perform changes likely to message content that can
         break a message signature.  Examples include transformation by be considerably more robust against the MSA to ensure that handling
   vagaries of intermediary MTAs.

1.3.2.  Characteristics of a DKIM signature

   A DKIM signature covers the message is in full conformance with
         Internet standards body and transformation by Boundary MTAs, to
         ensure conformance with organizational policies about external
         communications.

4.3.3.  Mobile Users

   Mobile users often must post messages through MSAs that are not under selected header fields.
   The signer computes a hash of the control selected header fields and another
   hash of the user's home ADMD.  Placing DKIM 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]
   header field of the
   MUA message.

1.3.3.  The Selector construct

   A signature is the only way to ensure that associated with a highly mobile user retains all
   of its benefits, domain name, as specified in spite of having to send mail through these
   independent MSAs.  However this leads to the administrative overhead
   of having a
   "d=" DKIM DNS key selector record parameter.  That domain name is the complete identity used
   for each mobile user.  For
   mail reading, no changes are needed.

4.3.4.  Mailing Lists

   A mailing list takes delivery of making assessments about the signer.  However this name is not
   sufficient for making a message and reposts it, usually
   with significant changes query to obtain the message.  This will often break a
   DKIM signature, although DKIM has some features key needed to survive simple
   mailing list modifications.  For mailing lists that impose
   substantial changes, it will be 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 responsibility domain name and an added field, called the
   "selector".  Both of these are coded into the list
   operator to add their own DKIM signature.

4.4.  Migrating from DomainKeys

4.4.1.  Signing

      DNS Records:   DKIM is upward compatible with existing DomainKeys
         (DK) [I-D.delany-domainkeys-base] DNS records, so DKIM-Signature header
   field.

   It must be stressed that a DKIM
         module does the selector is not automatically require additional DNS
         administration!  However, it should be noted part of the domain name
   that DKIM has
         enhanced is used for making assessments.  Rather, the DomainKeys DNS key record format by adding several
         optional parameters.

      Boundary MTA:   The principle selector is
   strictly reserved for use in administering keys that are associated
   with the domain name.  If the selector becomes part of DomainKeys a name
   assessment mechanism, then there is at Boundary
         MTAs.  Because no operational transition is ever instantaneous,
         a signer SHOULD add remaining mechanism for making
   a DKIM signature transition from an old, or compromised, key to a message that has a
         DomainKeys signature, rather than replacing it, until new one.

   Signers do have the need for supporting multiple assessments about
   their organization, such time as DomainKeys receive-side support is sufficiently reduced.
         With respect to signing policies, a reasonable, initial
         approach is to distinguish one type of message from
   another, or one portion of the organization from another.  To permit
   assessments that are independent, an organization should use DKIM signatures
   different sub-domains in the same way "d=" parameter, such as
         DomainKeys signatures are already being use.

4.4.2.  Verifying

      DNS Client:   DNS queries
   "transaction.example.com" versus "newsletter.example.com", or
   productA.example.com versus productB.example.com.

1.3.4.  Verification

   After a message has been signed, any agent in the message transit
   path can choose to verify the signature, to determine that the
   signing identity took responsibility for the DKIM key record, use message.  Message
   recipients can verify the same
         Domain Name naming conventions and signature by querying the same basic record
         format.  No changes signer's domain
   directly to retrieve the DNS client should be required.

      Verifying module:   See "Signing Module".

4.4.3.  Boundary MTA

   Independent of whether a Boundary MTA is performing general message
   filtering, a helpful practice is to have it check for DKIM signatures appropriate public key, and thereby confirm
   that purport the message was attested to be made with by a domain name that belongs to the ADMD party in possession of the Boundary MTA.  If
   private key for the signature does not validate, signing domain.  Typically, verification will be
   done by an agent in the MTA MAY
   decide to delete ADMD of the signature.

5. message recipient.

1.4.  Service Architecture

   The DKIM provides an end-to-end service for signing and verifying
   messages that are in transit.  It is divided into components that can be performed
   using different, external services (e.g., services, such as for key
   retrieval), although retrieval.
   However the basic DKIM operation provides signing specification defines an initial
   set.

                                            | set
   of these services, in order to ensure a basic level of
   interoperability.

                           | -
                           |- RFC2822 Message
                           V
                        +---------------------------------------------+
    +-----------+
            +------------------------------+
            | ORIGINATING OR RELAYING ADMD |
            |  Signer                              |
        +..>| Sign Message                 |         ============================
        .   +--------------+---------------+
        .                  |
        .private           | Practices +......>|  SIGN MESSAGE
    +---+---+              |
    +-----+-----+               +-----------+
    |   ...> ADD A SIGNATURE HEADER FIELD  Key  |
          .         ...>|   .     GET (Domain, Selector, Priv-Key)              |
          .        /               |   ...   COMPUTE SIGNATURE  Sender   |
          .        V    +----------------+----------------------------+
          .    +-------+
    | - Message
          . Store |  Key          [Internet]          | Practices |      1*(Domain, Selector,
          .
    +---+---+              | Store               +-----+-----+
        .public            |                [Internet]    Sig)                     .    +---+---+
        .                  V                     .
        .    +---------------------------------------------+   +------------------------------+     .
        .   | RELAYING OR DELIVERING ADMD  |     .
        .   |          ===========================                              |     .
        .   |  VERIFY MESSAGE (Verifier Practices) Message Signed?              |     .
        .    |   ...> VERIFY A SIGNATURE HEADER FIELD      |   +-------+----------------+-----+     .
        .    |           |yes             |no         .     GET A SIGNATURE                     |
        .        \...>|           V                V           .     LOOKUP PUB-KEY (Domain, Selector)   |
        .             |      +-----------+     +-----------+   .     VERIFY SIGNATURE VALUE
        +.....>| Verify    | +..>| Check     |<..+
               | Signature | |   | Practices |
               +---+-----+-+ |   +---+-------+
                   |     |   |       |
                   |     +---+       |
                   |pass  fail       |
                   V                 |
               +--------+            |
      +.......>| Assess |            |
      .        |   ...   EVALUATE SIGNATURE CONSTRAINTS Signer |            |
      .             +-------------------+-------------------------+        +---+----+            |
      .  assessment|                 |  - Verified Domain(s)
      .                                 V  - [Report]            +------+   +------+
      .             +---------------------------------------------+
          \............>|   MESSAGE DISPOSITION                       |
           ............>|       SIGNER PRACTICES                   |
          /   |       REPUTATION
    +-+----------+         V   V
    | Reputation |    +-----------+
    +-----+------+      +---------------------------------------------+    | Reputation Message   |
    +------------+>
                      | Filtering |
                      | Engine    |
                      +-----------+>

                    Figure 3: 2: DKIM Service Architecture

   Basic

   As shown in the Figure, basic message processing is divided between
   signing the message,
   validating verifying the signature, signature or determining whether a
   signature was required, and then making further decisions based upon
   the validated signature.  The signing results.  Signing may be performed by a component applies whatever
   signing policies are in force, including ones of the ADMD
   that determine which creates the message, and/or within any ADMD, along the relay
   path.  The signer uses the appropriate private key to use.  Validation key.

   Verification may be performed by any functional component along the
   relay and delivery path.  Validators  Verifiers retrieve the public key based
   upon the parameters stored in the message.  The figure shows using the validated
   verified identity as being used to assess an associated reputation,
   but it could be applied to for other tasks, such as management tracking
   of mail.

6.

   Note that a failed signature causes the message to be treated in the
   same manner as one that is unsigned.  Unsigned messages prompt a
   query for any published "sender practices" information, as an aid in
   determining whether the sender information has been used without
   authorization.

   For signature verification and for the assessment of unsigned
   messages, the results of these processes are treated as additional
   input to the receiver's filtering engine.  The engine determines
   message disposition, such as whether to deliver it.

2.  Deployment and Operation of DKIM Base

2.1.  Development

6.1.

2.1.1.  Coding Criteria for Cryptographic Applications

   Correct implementation of a cryptographic algorithm is a necessary
   but not a sufficient condition for the coding of cryptographic
   applications.  Coding of cryptographic libraries requires close
   attention to security considerations that are unique to cryptographic
   applications.

   In addition to the usual security coding considerations, such as
   avoiding buffer or integer overflow and underflow, implementers
   should pay close attention to management of cryptographic private
   keys and session keys, ensuring that these are correctly initialized
   and disposed of.

   Operating system mechanisms that permit the confidentiality of
   private keys to be protected against other processes SHOULD be used
   when available.  In particular, great care MUST be taken when
   releasing memory pages to the operating system to ensure that private
   key information is not disclosed to other processes.

   On multiple processor and dual core architectures, certain
   implementations of public key algorithms such as RSA may be
   vulnerable to a timing analysis attack.

   Support for cryptographic hardware providing key management
   capabilities is strongly encouraged.  In addition to offering
   performance benefits, many cryptographic hardware devices provide
   robust and verifiable management of private keys.

   Fortunately appropriately designed and coded cryptographic libraries
   are available for most operating system platforms under license terms
   compatible with commercial, open source and free software license
   terms.  Use of standard cryptographic libraries is strongly
   encouraged.  These have been extensively tested, reduce development
   time and support a wide range of cryptographic hardware.

6.1.1.

2.1.2.  Signer

   Signer implementations SHOULD provide a convenient means of
   generating DNS key records corresponding to the signer configuration.
   Support for automatic insertion of key records into the DNS is also
   highly desirable.  If supported however however, such mechanism(s) MUST be
   properly authenticated.

   Means

   A means of verifying that the signer configuration is compatible with
   the signature policy is also highly desirable.

   Disclosure of a private signature key component to a third party
   allows that third party to impersonate the sender.  Protection  The protection of
   private signature key data is therefore a critical concern.  Signers
   SHOULD support use of cryptographic hardware providing key management
   features.

   The import and export of private keys, and the ability to generate a
   Certificate Signing Request (CSR) for certificate registration are
   highly desirable.

6.1.2.  Verifier

   Verifiers SHOULD treat the result of the verification step as an
   input to the message evaluation process rather than as providing a
   final decision.  The knowledge that a message is authentically sent
   by a domain does not say much about the legitimacy of the message,
   unless the characteristics of the domain claiming responsibility are
   known.

   In particular, verifiers SHOULD NOT automatically assume that an
   email message that does not contain a signature, or that contains a
   signature that does not validate, is forged.  Verifiers should treat
   a signature that fails to validate the same as if no signature were
   present.

6.2. private keys, and the ability to generate a
   Certificate Signing Request (CSR) for certificate registration are
   highly desirable.

2.2.  Email Infrastructure Agents

   It is expected that the most common venue for a DKIM implementation
   will be within the infrastructure of an organization's email service,
   such as a department or a boundary MTA.

      Outbound:   An MSA or Outbound MTA should allow for the automatic
         verification of the MTA configuration such that the MTA can
         generate an operator alert if it determines that it is (1) an
         edge MTA, and (2) configured to send email messages that do not
         comply with the published DKIM sending policy.

         An outbound MTA should be aware that users may employ MUAs that
         add their own signatures and be prepared to take steps
         necessary to ensure that the message sent is in compliance with
         the advertised email sending policy.

      Inbound:   An inbound MTA or an MDA that does not support DKIM
         should avoid modifying messages in ways that prevent
         verification by other MTAs, or MUAs to which the message may be
         forwarded.

         An inbound MTA or an MDA may incorporate an indication of the
         verification results into the message, such as using an
         Authentication-Results header.
         [I-D.kucherawy-sender-auth-header]

      Intermediaries:   An email intermediary is both an inbound and
         outbound MTA.  Each of the requirements outlined in the
         sections relating to MTAs apply.  If the intermediary modifies
         a message in a way that breaks the signature, the intermediary

         +  SHOULD deploy abuse filtering measures on the inbound mail,
            and

         +  MAY remove all signatures that will be broken

         In addition the intermediary MAY:

      *

         +  Verify the message signature prior to modification.

      *

         +  Incorporate an indication of the verification results into
            the message, such as using an Authentication-Results header
         [I-D.kucherawy-sender-auth-header].

      * header.
            [I-D.kucherawy-sender-auth-header]

         +  Sign the modified message including the verification results
            (e.g., the Authentication-Results header).

6.3.

2.3.  Filtering

   Developers of filtering schemes designed to accept DKIM
   authentication results as input should be aware that their
   implementations will be subject to counter-attack by email abusers.
   The efficacy of a filtering scheme cannot therefore be determined by
   reference to static test vectors alone; resistance to counter attack
   must also be considered.

   Naive learning algorithms that only consider the presence or absence
   of a valid verified DKIM signature signature, without considering more information
   about the message, are vulnerable to an attack in which a spammer or
   other malefactor signs all their mail, thus creating a large negative
   value for presence of a DKIM signature in the hope of discouraging
   widespread use.

   If heuristic algorithms are employed, they should be trained on
   feature sets that sufficiently reveal the internal structure of the
   DKIM responses.  In particular the algorithm should consider the
   domains purporting to claim responsibility for the signature, rather
   than the existence of a signature or not.

   Unless a scheme can correlate the DKIM signature with accreditation
   or reputation data, the presence of a DKIM signature SHOULD be
   ignored.

6.4.

2.4.  DNS Server

   At a minimum, a DNS server that handles queries for DKIM key records
   must perform allow the server administrators to add free-form TXT records.
   It would, of course, be better for provide them with a structured
   form, to support the DKIM-specific fields.

7.

2.5.  Deployment

   This section describes the basic steps for introducing DKIM into an
   organization's email service operation.  The considerations are
   divided between the generating DKIM signatures (Signing) and the
   processing of messages that contain a DKIM signature (Verifying).

7.1.

2.5.1.  Key Management

   Selectors  Selectors are assigned according to the administrative
      needs of the signing domain, such as for rolling over to a new key
      or for delegating of the right to authenticate a portion of the
      namespace to a trusted third party.

         Examples include:   jun2005.eng._domainkey.example.com
            widget.promotion._domainkey.example.com

         NOTE:   It is intended that assessments of DKIM identities be
            based on the domain name, and not include the selector.
            This permits the selector to be used only for key
            administration, rather than having an effect on reputation
            assessment.

2.5.2.  Signing

   Creating messages that have DKIM signatures requires a modification of
   to only two portions of the email service:

   o  Addition of relevant DNS information.

   o  Addition of the signature by a trusted module within the
      organization's email handling service.

   The signing module uses the appropriate private key to create a
   signature.  The means by which the signing module obtains this the private
   key is not specified by DKIM.  Given that DKIM is intended for use
   during email transit, rather than for long-term storage, it is
   expected that keys will be changed regularly.  Clearly this means
   that key information should not be hard-coded into software.

7.1.1.

2.5.2.1.  DNS Records

   A receiver attempting to validate verify a DKIM signature must obtain the
   public key that is associated with the signature for that message.
   The DKIM-Signature header in the message will specify the basic
   domain name doing the signing and the selector to be used for the
   specific public key.  Hence, the relevant
   <selector>._domainkeys.<domain-name>
   <selector>._domainkey.<domain-name> DNS record needs to contain a
   DKIM-related resource record (RR) that provides the public key
   information.

   The administrator of the zone containing the relevant domain name
   adds this information.  Initial DKIM DNS information is contained
   within TXT RRs.  DNS administrative software varies considerably in
   its abilities to add new types of DNS records.

7.1.2.

2.5.2.2.  Signing Module

   The module doing signing can be placed anywhere within an
   organization's trusted Administrative Management Domain (ADMD);
   common choices are expected to be department-level posting and
   delivering agents, as well as boundary MTAs to the open Internet.
   (Note that it is entirely acceptable for MUAs to perform signing and
   validation.)
   verification.)  Hence the choice among the modules depends upon
   software development and administrative overhead tradeoffs.  One
   perspective that helps resolve this choice is the difference between
   the flexibility of use by systems at (or close to) the MUA, versus
   the centralized control that is more easily obtained by implementing
   the mechanism "deeper" into the organization's email infrastructure,
   such as at its boundary MTA.

7.1.3.

2.5.2.3.  Signing Policies and Practices

   Every organization (ADMD) will have its own policies and practices
   for deciding when to sign messages and with what domain name and key
   (selector).  Examples include signing all mail, signing mail from
   particular email addresses, or signing mail from particular sub-
   domains.  Given this variability, and the likelihood that signing
   practices will change over time, it will be useful to have these
   decisions represented in some sort of configuration information,
   rather than being more deeply coded into the signing software.

7.2.

2.5.3.  Verifying

2.5.3.1.  Verifier

   Verifiers SHOULD treat the result of the verification step as an
   input to the message evaluation process rather than as providing a
   final decision.  The knowledge that a message is authentically sent
   by a domain does not say much about the legitimacy of the message,
   unless the characteristics of the domain claiming responsibility are
   known.

   In particular, verifiers SHOULD NOT automatically assume that an
   email message that does not contain a signature, or that contains a
   signature that does not verify, is forged.  Verifiers should treat a
   signature that fails to verify the same as if no signature were
   present.

   Verification is performed within an ADMD that wishes to make
   assessments based upon the DKIM signature's domain name.  Any
   component within the ADMD that handles messages, whether in transit
   or being delivered, can do the verifying and subsequent assessments.
   Verification and assessment might occur within the same software
   mechanism, such as a Boundary MTA, or an MDA.  Or they may be
   separated, such as having verification performed by the Boundary MTA
   and assessment performed by the MDA.

   As with the signing process, choice of service venues for
   verification and assessment -- such as filtering or presentation to
   the recipient user -- depend on trade-offs for flexibility, control,
   and operational ease.  An added concern is that the linkage between
   verification and assessment entails essential trust: the assessment
   module MUST have a strong basis for believing that the verification
   information is correct.

7.2.1.

2.5.3.2.  DNS Client

   The primary means of publishing DKIM key information, initially, is
   initially through DNS TXT records.  Some DNS client software might
   have problems obtaining these records; as DNS client software
   improves this will not be a concern.

7.2.2.

2.5.3.3.  Boundary Enforcement

   In order for an assessment module to trust the information it
   receives about verification (e.g., Authentication-Results headers),
   it MUST eliminate verification information originating from outside
   the ADMD in which the assessment mechanism operates.  As a matter of
   friendly practice, it is equally important to make sure that
   verification information generated within the ADMD not escape outside
   of it.

   In most environments, the easiest way to enforce this is to place
   modules in the receiving and sending Boundary MTA(s) that strip any
   existing verification information.

7.3.

2.5.4.  Mail User Agent

   DKIM is designed to support deployment and use in email components
   other than an MUA.  However an MUA MAY also implement DKIM features
   directly.

      Outbound:   If an MUA is configured to send email directly, rather
         than relayed through an outbound MSA, the MUA SHOULD be
         considered as if it were an outbound MTA for the purposes of
         DKIM.  An MUA MAY support signing even if mail is to be relayed
         through an outbound MSA.  In this case the signature applied by
         the MUA may be in addition to any MSA signature.

      Inbound:   An MUA MAY rely on a report of a DKIM signature
         verification that took place at some point in the inbound MTA
         path (e.g., an Authentication-Results header), or an MUA MAY
         perform DKIM signature verification directly.  A verifying MUA
         SHOULD allow for the case where mail is modified in the inbound
         MTA path.

7.4.

2.5.5.  Transition strategy

   Deployment of a new signature algorithm without a 'flag day' requires
   a transition strategy such that signers and verifiers can phase in
   support for the new algorithm independently, and (if necessary) phase
   out support for the old algorithm independently.

   [Note: this section assumes that a security policy mechanism exists.
   It is subject to change.]

   DKIM achieves these requirements through two features: First a signed
   message may contain multiple signatures created by the same signer.
   Secondly the security policy layer allows the signing algorithms in
   use to be advertised, thus preventing a downgrade attack.

7.4.1.

2.5.5.1.  Signer transition strategy

   Let the old signing algorithm be A, the new signing algorithm be B.
   The sequence of events by which a Signer may introduce the new
   signing algorithm B, without disruption of service to legacy
   verifiers, is as follows:

   1.  Signer signs with algorithm A

       A.  Signer advertises that it signs with algorithm A

   2.  Signer signs messages twice, with both algorithm A and algorithm
       B

       A.  The signer tests new signing configuration

       B.  Signer advertises that it signs with algorithm A and
           algorithm B

   3.  Signer determines that support for Algorithm A is no longer
       necessary

   4.  Signer determines that support for algorithm A is to be withdrawn

       A.  Signer removes advertisement for Algorithm A

       B.  Signer waits for cached copies of earlier signature policy to
           expire

       C.  Signer stops signing with Algorithm A

7.4.2.

2.5.5.2.  Verifier transition strategy

   The actions of the verifier are independent of the signer's actions
   and do not need to be performed in a particular sequence.  The
   verifier may make a decision to cease accepting algorithm A without
   first deploying support for algorithm B. Similarly a verifier may be
   upgraded to support algorithm B without requiring algorithm A to be
   withdrawn.  The decisions of the verifier must make are therefore:

   o  The verifier MAY change the degree of confidence associated with
      any signature at any time, including determining that a given
      signature algorithm provides a limited assurance of authenticity
      at a given key strength.

      *  A verifier MAY evaluate signature records in any order it
         chooses, including using the signature algorithm to choose the
         order.

   o  The verifier MAY make a determination that Algorithm A does not
      offer a useful level of security, or that the cost of verifying
      the signature is less than the value of doing so.

      *  In this case the verifier would ignore signatures created using
         algorithm A and references to algorithm A in policy records
         would be treated as if the algorithm were not implemented.

   o  The verifier MAY decide to add support for additional signature
      algorithms at any time.

      *  The verifier MAY add support for algorithm B at any time.

8.

2.5.6.  Migrating from DomainKeys

2.5.6.1.  Signing

      DNS Records:   DKIM is upwardly compatible with existing
         DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module
         does not automatically require additional DNS administration!
         However DKIM has enhanced the DomainKeys DNS key record format
         by adding several additional optional parameters.

      Boundary MTA:   The principle use of DomainKeys is at Boundary
         MTAs.  Because no operational transition is ever instantaneous,
         it is not adviseable for existing DomainKeys signers to switch
         to DKIM without continuing to perform DomainKeys signing.  A
         signer should add a DKIM signature to a message that also has a
         DomainKeys signature, until such time as DomainKeys receive-
         side support is sufficiently reduced.  With respect to signing
         policies, a reasonable, initial approach is to use DKIM
         signatures in the same way as DomainKeys signatures are already
         being used.

2.5.6.2.  Verifying

      DNS Client:   DNS queries for the DKIM key record, use the same
         Domain Name naming conventions as were used for DomainKeys, and
         the same basic record format.  No changes to the DNS client
         should be required.

      Verifying module:   See the section on Signing above.

2.6.  On-going Operations

   This section describes the basic steps for operation of email systems
   that use DKIM, after the capability has initially been deployed.  The
   primary considerations are:

   o  the upkeep of the selector files, and

   o  the security of the private keys.

8.1.

2.6.1.  DNS Signature Record Deployment Installation Considerations

   Even with use of the DNS, one challenge is that DNS record management
   is usually operated by an administrative staff that is different from
   those who operate an organization's email service.  In order to
   ensure that DKIM DNS records are accurate, this imposes a requirement
   for careful coordination between the two operations groups.

   The key point to remember is that the DNS DKIM selectors WILL and
   SHOULD be changed over time.  Some reasons for changing DKIM
   selectors are well understood; understood, while others are still theoretical.
   There are several schemes that may be used to determine the policies
   for changing DKIM selectors:

   o  time based

   o  associations with clusters of servers

   o  the use of third party signers
   o  security considerations

8.1.1.

2.6.1.1.  Time Basis and Security Considerations

   The reason for changing the selector periodically is usually related
   to the security exposure of a system.  When the potential exposure of
   the private keys associated with the DKIM selector have reached
   sufficient levels, the selector should be changed.  (It is unclear
   currently what kinds of metrics can be used to aid in deciding when
   the exposure has reached sufficient levels to warrant changing the
   selector.)

   For example,

   o  Selectors should be changed more frequently on systems that are
      widely exposed, than on systems that are less widely exposed.  For
      example, a gateway system that has numerous externally-accessible
      services running on it, is more widely exposed than one that ONLY
      runs a mail server.

   o  Selectors should be changed more frequently on operating systems
      that are under wide attack.

   o  While the use of DKIM information is transient, keys with
      sufficient exposure do become stale and should be changed.

   o  Whenever you make a substantial system change, such as bringing up
      a new server, or making a major operating system change, you
      should consider changing the selector.

   o  Whenever there is either suspicion or evidence of the compromise
      of the system or the private keys, you should change the selector.

8.1.2.

2.6.1.2.  Deploying New Selectors

   A primary consideration in changing the selector is remembering to
   change it.  It needs to be a standard part of the operational staff
   Methods and Procedures for your systems.  If they are separate, both
   the mail team and the DNS team will be involved in deploying new
   selectors.

   When deploying a new selector, it needs to be phased in:

   1.  generate  Generate the new public / private key pair and create a new
       selector record with the public key in it it.

   2.  add  Add the new selector record to your DNS DNS.

   3.  verify  Verify that the new selector record can be used to verify
       signatures
       signatures.

   4.  turn  Turn on signing with the new private key key.

   5.  remove  Remove the old private key from your servers servers.

   6.  after  After a period of time, remove the old selector from your DNS DNS.

   The time an unused selector should be kept in the DNS system is
   dependent on the reason it's being changed.  If the private key has
   definitely been exposed, the corresponding selector should be removed
   immediately.  Otherwise, longer periods are allowable.

8.1.3.

2.6.1.3.  Subdomain Considerations

   A Domain Name is the basis for making differential quality
   assessments about a DKIM-signed message.  It is reasonable for a
   single organization to have a variety of very different activities,
   which warrant a variety of very different assessments.  A convenient
   way to distinguish among such activities is to sign with different
   domain names.  That is, the organization should sign with sub-domain
   names that are used for different organizational activities.

8.1.4.

2.6.1.4.  Third party Signature Delegations

   Allowing third parties to sign email from your domain opens your
   system security to include the security of the third party's systems.
   At a minimum, you should not allow the third parties to use the same
   selector and private key as your main mail system.  It is recommended
   that each third party be given their own private key and selector.
   This limits the exposure for any given private key, and minimizes the
   impact if any given private key were exposed.

8.2.

2.6.2.  Private Key Management

   The permissions of private key files must be carefully managed.  If
   key management hardware support is available, it should be used.
   Auditing software should be used to periodically verify that the
   permissions on the private key files remain secure. [ Expand this
   section? ]

8.3.

2.6.3.  Mailing list manager developers

   A mailing list often provides facilities to its administrator to
   manipulate parts of the mail messages that flow through the list.
   The desired goal is that messages flowing through the mailing list
   will be verifiable by the recipient as being from the list, or
   failing that, as being from the individual list members.

   In most cases, the list and/or its mail host SHOULD add its own DKIM
   signature to list mail.  This could be done in the list management
   software, in an outgoing MSA or MTA, or both.  List management
   software often makes modifications to messages that will break
   incoming signatures, such as adding subject tags, adding message
   headers or footers, and adding, deleting, or reordering MIME parts.
   By adding its own signature after these modifications, the list
   provides a valid verifiable, recognizable signature for list recipients.

   In some cases, the modifications made by the mailing list software is
   are simple enough that signatures on incoming messages will still be valid
   verifiable after being remailed by the list.  It is still preferable
   that the list sign its mail so that recipients can distinguish
   between mail sent through the list from and mail sent directly by to a list members, but in
   member.  In the absence of a list signature, a recipient may still be
   able to recognize and use the original signatures of list
   members known to the recipient.

9. list
   members.

2.7.  Example Uses

   A DKIM signature tells the signature verifier that the owner of a
   particular domain name accepts responsibility for the message.
   Combining this information with information that allows the history
   of the domain name owner to be assessed may allow processing the
   message, based on the probability that the message is likely to be
   trustworthy, or not, without the need for heuristic content analysis.

9.1.

2.7.1.  Protection of Internal Mail

   One identity is particularly amenable to easy and accurate
   assessment: The organization's own identity! identity.  Members of an
   organization tend to trust messages that purport to be from within
   that organization.  However Internet Mail does not provide a
   straightforward means of determining whether such mail is, in fact,
   from within the organization.  DKIM can be used to remedy this
   exposure.  If the organization signs all of its mail, then its
   boundary MTAs can look for mail purporting to be from the
   organization but which does not contain a valid verifiable signature.  Such mail
   can be presumed to be spurious.

9.2.

2.7.2.  Recipient-based Assessments

   Recipients of large volumes of email can internally generate
   reputation data for email senders internally. senders.  Recipients of smaller volumes of
   messages are likely to need to acquire reputation data from a third
   party.  In either case the use of reputation data is intrinsically
   limited to email senders that have established a prior history of
   sending messages.

   In fact, an email receiving service may be in a position to establish
   bilateral agreements with particular senders, such as business
   partners or trusted bulk sending services.  Although it is not
   practical for each recipient to accredit every sender, the definition
   of core networks of explicit trust can be quite useful.

9.2.1.

2.7.2.1.  Third-party Assessments

   For scaling efficiency, it is appealing to have Trusted Third Party
   assessment services, to allow an email sender to obtain a single
   assessment that is then recognized by every email recipient that
   recognizes the Trusted Third Party.

9.3.

2.7.3.  DKIM Support in the Client

   The DKIM specification is expected to be used primarily between
   Boundary MTAs, or other infrastructure components of the originating
   and receiving ADMDs.  However there is nothing in DKIM that is
   specific to those venues.  In particular, it should be possible to
   support signing and validating verifying in MUAs.

   However, it is comment common for components of an ADMD's email
   infrastructure to do violence to a message, so such as to render a DKIM
   signature invalid.  Hence, users of MUAs that support DKIM signing
   and/or validating verifying need a basis for knowing that their associated email
   infrastructure will maintain signature validity. not break a signature.

   DKIM requires that all verifiers treat messages with signatures that
   do not verify as if they are unsigned.  If verification in the client
   is to be acceptable to users, it is also essential that successful
   verification of a signature not result in a less than satisfactory
   user experience compared to leaving the message unsigned.

9.4.

2.7.4.  Per user signature signatures

   Although DKIM's use of domain names is optimized for a scope of
   organization-level signing, it is possible to have administer sub-domains
   and/or selectors be administered in a way that supports per-user signing.

   NOTE:   As stated earlier, it is important to distinguish between the
      use of selectors, selectors for differential administration of keys, versus sub-
      domains,
      the use of sub-domains for differential reputations.

   As a constraint on an authorized DKIM signing agent, their associated
   key record can specify restrictions on the email addresses permitted
   to be signed with that domain and key.  A typical intent of this
   feature is to allow a company to delegate the signing authority for
   bulk marketing communications without the risk of effectively
   delegating the authority to sign messages purporting to come from the
   domain-owning organization's CEO.

   NOTE:   Any scheme that involves maintenance of a significant number
      of public keys is likely to require infrastructure enhancements,
      to support that management.  For example, a system in which the
      end user is required to generate a public key pair and transmit it
      to the DNS administrator out of band is not likely to meet
      acceptance criteria for either usability or security.

10.  Acknowledgements

   TBD

11.  { Misc Text -- Should go elsewhere, if used at all }

   DKIM permits the signing identity to be different from the identities
   used for the author or the initial posting agent.  This is essential,
   for example, to enable support of signing by authorized third-
   parties, and to permit signatures by email providers who are
   otherwise independent of the domain name of the message author.

   DKIM permits restricting the use of a signature key to 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 MUST explicitly list the headers that are
   signed.  This intent of this
   feature is an improvement because it requires the signer to use
   the more conservative (likely allow a company to verify correctly) mechanism and
   makes it considerably more robust against delegate the handling signing authority for
   bulk marketing communications without the risk of
   intermediary MTAs.

   DKIM self-signs effectively
   delegating the DKIM-Signature header field, authority to protect against
   its being modified.

   In order sign messages purporting to survive come from the vagaries
   domain-owning organization's CEO.

   NOTE:   Any scheme that involves maintenance of different email transfer systems,
   mechanisms like DKIM must evaluate the message data in some canonical
   form, such as treating a string significant number
      of spaces as tabs as if they were public keys is likely to require infrastructure enhancements,
      to support that management.  For example, a
   single space.  DKIM has added the "relaxed" canonicalization system in place
   of "nofws".

   MUA UI considerations which the
      end user is required to generate a public key delegation/ 3rd party

12.  Informative References

   [I-D.delany-domainkeys-base]
              Delany, M., "Domain-based Email Authentication Using
              Public Keys Advertised in pair and transmit it
      to the DNS  (DomainKeys)",
              draft-delany-domainkeys-base-06 (work in progress),
              July 2006.

   [I-D.ietf-dkim-base]
              Allman, E., "DomainKeys Identified Mail (DKIM)
              Signatures", draft-ietf-dkim-base-10 (work in progress),
              February 2007.

   [I-D.ietf-dkim-threats]
              Fenton, J., "Analysis administrator out of Threats Motivating DomainKeys
              Identified Mail (DKIM)", draft-ietf-dkim-threats-03 band is not likely to meet
      acceptance criteria for either usability or security.

3.  Acknowledgements

   TBD

4.  Informative References

   [I-D.ietf-openpgp-rfc2440bis]
              Callas, J., "OpenPGP Message Format",
              draft-ietf-openpgp-rfc2440bis-22 (work in progress), May 2006.
              April 2007.

   [I-D.kucherawy-sender-auth-header]
              Kucherawy, M., "Message Header for Indicating Sender
              Authentication Status",
              draft-kucherawy-sender-auth-header-04 (work in progress),
              February 2007.

   [RFC0989]  Linn, J. and IAB Privacy Task Force, "Privacy enhancement
              for Internet electronic mail: Part I: Message encipherment
              and authentication procedures", RFC 989, February 1987.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1848]  Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
              Object Security Services", RFC 1848, October 1995.

   [RFC1991]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
              Exchange Formats", RFC 1991, August 1996.

   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
              "OpenPGP Message Format", RFC 2440, November 1998.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156, August 2001.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
              August 2001.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC4870]  Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
              May 2007.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

Authors' Addresses

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

   Email: tony+dkimov@maillennium.att.com

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA  94086
   USA

   Email: dcrocker@bbiw.net
   Phillip Hallam-Baker
   VeriSign Inc.

   Email: pbaker@verisign.com

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

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).