DomainKeys Identified Mail                                     T. Hansen
Internet-Draft                                         AT&T Laboratories
Intended status: Informational                           P. Hallam-Baker
Expires: August 28, 2008 May 7, 2009                                       VeriSign Inc.
                                                              D. Crocker
                                             Brandenburg InternetWorking
                                                       February 25,
                                                               E. Siegel
                                                  Constant Contact, Inc.
                                                        November 3, 2008

DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
                     draft-ietf-dkim-deployment-01
                     draft-ietf-dkim-deployment-02

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 August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008). May 7, 2009.

Abstract

   DomainKeys Identified Mail (DKIM) associates allows an organization to take
   responsibility for transmitting a "responsible" identity
   with message, in a message and provides way that can be
   validated by a means recipient.  The organization can be the author's, the
   originating sending site, an intermediary, or one of verifying that their agents.  A
   message can contain multiple signatures, from the association
   is legitimate.  [RFC4871] same or different
   organizations involved with the message.  DKIM defines a domain-level
   digital signature authentication framework for email email, using public-key cryptography and public
   key cryptography, using the domain name service as its key server
   technology.
   technology [RFC4871].  This permits verifying the source or intermediary for verification of a
   message, responsible
   organization, as well as the contents of messages.  The ultimate goal of
   this framework is to permit a signing domain to assert responsibility
   for sending 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 message contents.  DKIM
   will also provide a mechanism that permits potential email as it is known
   today.  Such protection signers to
   publish information about their email signing practices; this will
   permit email receivers to make additional assessments about messages.
   DKIM's authentication of email identity may can assist in the global
   control of "spam" and "phishing". "phishing.  This document provides
   implementation, deployment, operational and migration considerations
   for DKIM.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Development  Key Generation, Storage, and Management  . . . . . . . . . . .  3
     2.1.  General Coding Criteria for Cryptographic Applications . .  3
     2.2.  Key Generation and Storage . . . . . . . . . . . .  3
     2.1.  DKIM Signing Software . . . .  4
     2.3.  DNS Signature Record Deployment and Maintenance
           Considerations . . . . . . . . . . . . . .  3
     2.2.  General Coding Criteria for Cryptographic Applications . .  3
     2.3.  Mailing List Manager Software . . . . . .  5
   3.  Signing  . . . . . . . .  4
     2.4.  Email Infrastructure Agents . . . . . . . . . . . . . . .  5
     2.5.  Filtering Software . . . .  8
     3.1.  Deployment . . . . . . . . . . . . . . . .  6
     2.6.  DNS Server Software . . . . . . . .  8
     3.2.  Mailing Lists  . . . . . . . . . . .  6
   3.  Deployment . . . . . . . . . . . 10
     3.3.  Signature Transition Strategy  . . . . . . . . . . . . . . 12
   4.  Verifying  .  6
     3.1.  Signing . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Verifying 14
     4.1.  Verifier . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Key Management Deployment . 14
     4.2.  DNS Client . . . . . . . . . . . . . . .  9
     3.4.  Mailing Lists . . . . . . . . . 14
     4.3.  Boundary Enforcement . . . . . . . . . . . . . . 10
     3.5.  Mail User Agent . . . . . 15
     4.4.  Filtering Software . . . . . . . . . . . . . . . . 11
     3.6.  Transition Strategy . . . . 15
   5.  DKIM Deployment Considerations for Email Agents  . . . . . . . 15
     5.1.  Email Infrastructure Agents  . . . . . . . . . . . . . 12
     3.7. . . 15
     5.2.  Mail User Agent  . . . . . . . . . . . . . . . . . . . . . 17
   6.  Migrating from DomainKeys  . . . . . . . . . . . . . . . . 13
   4.  On-going Operations . . 17
     6.1.  Signing  . . . . . . . . . . . . . . . . . . . 14
     4.1.  DNS Signature Record Installation Considerations . . . . . 14
     4.2.  Private Key Management . 17
     6.2.  Verifying  . . . . . . . . . . . . . . . . . 16
   5. . . . . . . . 18
   7.  Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1. 18
     7.1.  Protection of Internal Mail  . . . . . . . . . . . . . . . 17
     5.2. 18
     7.2.  Recipient-based Assessments  . . . . . . . . . . . . . . . 17
     5.3. 19
     7.3.  DKIM Support in the Client . . . . . . . . . . . . . . . . 18
     5.4. 19
     7.4.  Per user signatures  . . . . . . . . . . . . . . . . . . . 18
   6. 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7. 20
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8. 20
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   9. 20
   11. Informative References . . . . . . . . . . . . . . . . . . . . 19 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 21 23

1.  Introduction

   There are many areas to be considered when deploying DomainKeys
   Identified Mail (DKIM).  This document provides practical tips for:
   those who are developing DKIM software, mailing list managers,
   filtering strategies based on the output from DKIM verification, and
   DNS servers; those who are deploying DKIM software, keys, mailing
   list software, and migrating from DomainKeys; and those who are
   responsible for the on-going operations of an email infrastructure
   that has deployed DKIM.

2.  Development

2.1.  DKIM Signing Software

   Signer implementations SHOULD provide a convenient means of
   generating DNS

   The document is organized aorund the key records corresponding concepts related to DKIM.
   Within each section, additional considerations specific to
   development, deployment, or ongoing operations are highlighted where
   appropriate.

   [[anchor2: maybe this is a good place to mention the signer configuration.
   Support for automatic insertion possibility of key records into the DNS is also
   highly desirable.  If supported however, such mechanism(s) MUST be
   properly authenticated.

   A
   collecting verification history for selectors domains as a means of verifying that the signer configuration is compatible with
   observing over time behaviour of signers for the signature policy is also highly desirable.

   Disclosure purpose of asserting
   local reputation]]

2.  Key Generation, Storage, and Management

   DKIM defines a private domain-level digital signature authentication
   framework for email, using public key component to a third party
   allows that third party to impersonate cryptography, using the sender.  The protection of
   private signature key data is therefore a critical concern.  Signers
   SHOULD support use of cryptographic hardware providing domain
   name service as its key management
   features.

2.2. server technology [RFC4871].  This section
   covers considerations around generating, deploying, and managing the
   public and private keys required for DKIM to function.

2.1.  General Coding Criteria for Cryptographic Applications

   NOTE: This section could possibly be changed into a reference to
   something else, such as another rfc.

   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 should be used
   when available.  In particular, great care MUST must be taken when
   releasing memory pages to the operating system to ensure that private
   key information is not disclosed to other processes.

   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.

2.3.  Mailing List Manager Software

   A mailing list often provides facilities

2.2.  Key Generation and Storage

2.2.1.  Assignment of Selectors

   Selectors  Selectors are assigned according to its administrator the administrative
      needs of the signing domain, such as for rolling over to
   manipulate parts a new key
      or for delegating of the mail messages that flow through right to authenticate a portion of the list.
   The desired goal
      namespace to a trusted third party.

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

      widget.promotion._domainkey.example.com

   NOTE:   It is intended that messages flowing through the mailing list
   will assessments of DKIM identities be verifiable by the recipient as being from based
      on the list, or
   failing that, as being from domain name, and not include the individual list members.

   In most cases, selector.  This permits
      the list and/or its mail host SHOULD add its own DKIM
   signature selector to list mail.  This could be done in the list management
   software, in used only for key administration, rather than
      having an outgoing MSA or MTA, or both.  List management
   software often makes modifications effect on reputation assessment.

      [[anchor7: The reputation of a selector could become relevant if
      it is known 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, have "gone rogue" before the list
   provides DNS owner has a verifiable, recognizable signature for list recipients.

   In some cases, the modifications made by the mailing list software
   are simple enough that signatures on incoming messages will still be
   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 and mail sent directly chance
      to published a list
   member.  In the absence of new zone update which contains a list signature, revoked key.]]

2.2.2.  Third Party Key Management

   ????????????????

   [[anchor9: what are we trying to cover here?  The case where a recipient may still be
   able 3rd
   party generates keys and provides the public key to recognize the domain owner
   to publish?  Or the case where the domain owner generates keys and use
   provides the original signatures of private key to the list
   members.

2.4.  Email Infrastructure Agents

   It is expected third party?  Either way, I think we
   need some discussion of 1st vs. 3rd party (preferably that the most common venue for a DKIM implementation
   will be within
   distinction has little relevance except in the infrastructure presence of an organization's email service,
   such as a department or a boundary MTA.

      Outbound:   An MSA or Outbound MTA should allow for ADSP,
   since otherwise the automatic
         verification reputation of the MTA configuration such that signing domain and not the MTA can
         generate an operator alert if it determines that 1st
   or 3rd party nature of it is (1) an
         edge MTA, what is relevant.]]

   3rd party generates the public / private key pair and (2) configured to send email messages that do not
         comply with sends the published DKIM sending policy.

         An outbound MTA should
   public key to be aware that users may employ MUAs published in the DNS.

2.2.3.  Storing Public Keys: DNS Server Software Considerations

   At a minimum, a DNS server that handles queries for DKIM key records
   must allow the server administrators to add their own signatures and free-form TXT records.
   It would be prepared to take steps
         necessary to ensure that better if the message sent is in compliance with the advertised email sending policy.

      Inbound:   An inbound MTA or an MDA that does not support DKIM records could be entered using a
   structured form, supporting the DKIM-specific fields.

2.2.4.  Private Key Management: Deployment and Ongoing Operations

   The permissions of private key files must be carefully managed.  If
   key management hardware support is available, it should avoid modifying messages in ways that prevent
         verification by other MTAs, or MUAs be used.
   Auditing software should be used periodically to which verify that the message may be
         forwarded.

         An inbound MTA or an MDA may incorporate an indication of
   permissions on the
         verification results into private key files remain secure.

2.3.  DNS Signature Record Deployment and Maintenance Considerations

   Even with use of the message, such as using DNS, one challenge is that DNS record management
   is usually operated by an
         Authentication-Results header.
         [I-D.kucherawy-sender-auth-header]

      Intermediaries:   An email intermediary administrative staff that is both different from
   those who operate an inbound and
         outbound MTA.  Each of the requirements outlined in the
         sections relating organization's email service.  In order to MTAs apply.  If the intermediary modifies
         a message in a way
   ensure that breaks the signature, DKIM DNS records are accurate, this imposes a requirement
   for careful coordination between the intermediary

         +  SHOULD deploy abuse filtering measures on two operations groups.

   The key point to remember is that the inbound mail, DNS DKIM selectors WILL and

         +  MAY remove all signatures
   should be changed over time.  Some reasons for changing DKIM
   selectors are well understood, while others are still theoretical.
   There are several schemes that will may be broken

         In addition used to determine the intermediary MAY:

         +  Verify the message signature prior to modification.

         +  Incorporate an indication policies
   for changing DKIM selectors:

   o  time based

   o  associations with clusters of servers
   o  the verification results into
            the message, such as using an Authentication-Results header.
            [I-D.kucherawy-sender-auth-header]
         +  Sign the modified message including use of third party signers

   o  security considerations

   A potential mistake in creating the verification results
            (e.g., DNS key record is the Authentication-Results header).

2.5.  Filtering Software

   Developers erroneous
   use of filtering schemes designed a backslash (\) in the definition.  Some implementations
   reading a zone file allow a backslash to accept DKIM
   authentication results as input should be aware that their used anywhere, stripping
   any such occurrences.  Other implementations will be subject only allow it to counter-attack by email abusers.
   The efficacy be used
   in front of an quotation mark, storing the backslash in the record
   and causing a filtering scheme cannot therefore be determined by
   reference to static test vectors alone; resistance syntax error to counter attack
   must also be considered.

   Naive learning algorithms that only consider the presence or absence
   of a verified generated by DKIM signature, without considering more information
   about implementations
   reading the message, are vulnerable to an attack in which a spammer or
   other malefactor signs all their mail, thus creating a large negative
   value record.

2.3.1.  Time Basis and Security Considerations

   The reason for presence changing the selector periodically is usually related
   to the security exposure of a DKIM signature in system.  When the hope potential exposure of discouraging
   widespread use.

   If heuristic algorithms are employed, they should be trained on
   feature sets that sufficiently reveal
   the internal structure of private keys associated with the DKIM responses.  In particular selector have reached
   sufficient levels, the algorithm selector should consider the
   domains purporting be changed.  (It is unclear
   currently what kinds of metrics can be used to claim responsibility for aid in deciding when
   the signature, rather
   than exposure has reached sufficient levels to warrant changing the existence of
   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 signature or not.

   Unless gateway system that has numerous externally-accessible
      services running on it is more widely exposed than one that ONLY
      runs a scheme can correlate the DKIM signature with accreditation
   or reputation data, mail server.

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

   o  While the presence use of a DKIM signature SHOULD information is transient, keys with
      sufficient exposure do become stale and should be
   ignored.

2.6.  DNS Server Software

   At changed.

   o  Whenever you make a minimum, substantial system change, such as bringing up
      a DNS server that handles queries for DKIM key records
   must allow new server, or making a major operating system change, you
      should consider changing the server administrators selector.

      [[anchor14: above you refer to add free-form TXT records.
   It would be better if changing the key, here you refer to
      changing the DKIM records selector; they have not been explicitly declared as
      synonymous so this could be entered using a
   structured form, supporting confusing]]

   o  Whenever there is either suspicion or evidence of the DKIM-specific fields.

3.  Deployment

   This section describes compromise
      of the basic steps for introducing DKIM into an
   organization's email service operation.  The considerations are
   divided between system or the generating DKIM signatures (Signing) and private keys, you should change the
   processing of messages that contain selector.

2.3.2.  Deploying New Selectors

   A primary consideration in changing the selector is remembering to
   change it.  It needs to be a DKIM signature (Verifying).

3.1.  Signing

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

   o  Addition of relevant DNS information.

   o  Addition of operational staff
   Methods and Procedures for your systems.  If they are separate, both
   the signature by a trusted module within mail team and the
      organization's email handling service.

   The signing module uses DNS team will be involved in deploying new
   selectors.

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

   1.  Generate the appropriate new public / private key to pair and create a
   signature.  The means by which the signing module obtains new
       selector record with the private public 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 in it.

   2.  Add the new selector record to your DNS.

   3.  Verify that key information should not the new selector record can be hard-coded into software.

3.1.1.  DNS Records

   A receiver attempting used to verify a DKIM signature must obtain
       signatures.

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

   5.  Remove the old private key that is associated with from your servers.

   6.  After a period of time, remove the signature for that message. old selector from your DNS.

   The DKIM-Signature header time an unused selector should be kept in the message will specify DNS system is
   dependent on the basic
   domain name doing reason it's being changed.  If the signing and private key has
   definitely been exposed, the corresponding selector to should be used for the
   specific public key.  Hence, the relevant
   <selector>._domainkey.<domain-name> DNS record needs to contain removed
   immediately.  Otherwise, longer periods are allowable.

   [[anchor16: interesting; should we have included a
   DKIM-related resource record (RR) that provides the public "u=" ('until') tag
   on key
   information.

   The administrator of the zone containing records allowing an advertised "good until" timestamp?]]

2.3.3.  Subdomain Considerations

   A Domain Name is the relevant domain name
   adds this information.  Initial DKIM DNS information basis for making differential quality
   assessments about a DKIM-signed message.  It is contained
   within TXT RRs.  DNS administrative software varies considerably in
   its abilities reasonable for a
   single organization to add new types have a variety of DNS records.

3.1.2.  Signing Module

   The module doing signing can be placed anywhere within an
   organization's trusted Administrative Management Domain (ADMD);
   common choices are expected very different activities,
   which warrant a variety of very different assessments.  A convenient
   way to be department-level posting and
   delivering agents, as well as boundary MTAs distinguish among such activities is to sign with different
   domain names.  That is, the open Internet.
   (Note organization should sign with sub-domain
   names that it is entirely acceptable are used for MUAs different organizational activities.

2.3.4.  Delegating Signing Authority to perform signing and
   verification.)  Hence the choice among a Third party

   Allowing third parties to sign email from your domain opens your
   system security to include the modules depends upon
   software development and administrative overhead tradeoffs.  One
   perspective that helps resolve this choice is security of the difference between third party's systems.
   At a minimum, you should not allow the flexibility of third parties to use by systems at (or close to) the MUA, versus the centralized control that same
   selector and private key as your main mail system.  It is more easily obtained by implementing
   the mechanism "deeper" into the organization's email infrastructure,
   such as at its boundary MTA.

3.1.3.  Signing Policies and Practices

   Every organization (ADMD) will have recommended
   that each third party be given its own policies private key and practices selector.
   This limits the exposure 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, any given private key, and minimizes the likelihood
   impact if any given private key were exposed.

3.  Signing

3.1.  Deployment

   Creating messages that signing
   practices will change over time, it will be useful to have these
   decisions represented in some sort DKIM signatures requires a modification
   to only two portions of configuration information,
   rather than being more deeply coded into the signing software.

3.2.  Verifying

3.2.1.  Verifier

   Verifiers SHOULD treat the result email service:

   o  Addition of relevant DNS information.

   o  Addition 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 signature by a domain does not say much about trusted module within the legitimacy of
      organization's email handling service.

   The signing module uses the message,
   unless appropriate private key to create a
   signature.  The means by which the characteristics of signing module obtains the domain claiming responsibility are
   known.

   In particular, verifiers SHOULD NOT automatically assume that an
   email message that does private
   key is not contain a signature, or that contains a
   signature specified by DKIM.  Given that does not verify, DKIM is forged.  Verifiers should treat a
   signature intended for use
   during email transit, rather than for long-term storage, it is
   expected that fails keys will be changed regularly.  Clearly this means
   that key information should not be hard-coded into software.

3.1.1.  DNS Records

   A receiver attempting to verify the same as if no a DKIM signature were
   present.  NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP

   Verification is performed within an ADMD that wishes to make
   assessments based upon must obtain the DKIM signature's domain name.  Any
   component within
   public key that is associated with the ADMD signature for that handles messages, whether message.
   The DKIM-Signature header 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 message will specify the MDA.

   As with basic
   domain name doing the signing process, choice of service venues for
   verification and assessment -- such as filtering or presentation to the recipient user -- depend on trade-offs selector to be used for flexibility, control,
   and operational ease.  An added concern is that the linkage between
   verification and assessment entails essential trust:
   specific public key.  Hence, the assessment
   module MUST have relevant
   <selector>._domainkey.<domain-name> DNS record needs to contain a strong basis for believing
   DKIM-related resource record (RR) that provides the verification
   information is correct.

3.2.2.  DNS Client public key
   information.

   The primary means administrator of publishing the zone containing the relevant domain name
   adds this information.  Initial DKIM key information, initially, is
   initially through DNS information is contained
   within TXT records.  Some RRs.  DNS client administrative software might
   have problems obtaining these records; as varies considerably in
   its abilities to add new types of DNS client software
   improves this will not records.

3.1.2.  Signing Module

   The module doing signing can be a concern.

3.2.3.  Boundary Enforcement

   In order for placed anywhere within an assessment module
   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 trust the information it
   receives about verification (e.g., Authentication-Results headers), open Internet.
   (Note that it MUST eliminate verification information originating from outside is entirely acceptable for MUAs to perform signing and
   verification.)  Hence the ADMD in which choice among the assessment mechanism operates.  As modules depends upon
   software development and administrative overhead tradeoffs.

   [[anchor23: See earlier note about signing by MUAs being a matter of
   friendly practice, it is equally important to make sure security
   concern]] One perspective that
   verification information generated within helps resolve this choice is the ADMD not escape outside
   difference between the flexibility of it.

   In most environments, use by systems at (or close to)
   the easiest way to enforce this is to place
   modules in MUA, versus the receiving and sending Boundary MTA(s) centralized control that strip any
   existing verification information.

3.3.  Key Management Deployment

   More to be added

3.3.1.  First Party Key Management

   Selectors  Selectors are assigned according to is more easily obtained
   by implementing the administrative
      needs of mechanism "deeper" into the signing domain, organization's email
   infrastructure, such as for rolling over to at its boundary MTA.

3.1.3.  DKIM Signing Software Development

   Signer implementations should provide a new convenient means of
   generating DNS key
      or records corresponding to the signer configuration.
   Support for delegating automatic insertion of key records into the right to authenticate a portion DNS is also
   highly desirable.  If supported however, such mechanism(s) must be
   properly authenticated.

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

   Disclosure of a private signature key component to a trusted third party.

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

      widget.promotion._domainkey.example.com

   NOTE:   It is intended party
   allows 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.

3.3.2.  Third Party Key Management

   ???????????????? 3rd third party generates to impersonate the public / sender.  The protection of
   private signature key pair
   and sends the public data is therefore a critical concern.  Signers
   should support use of cryptographic hardware providing key to be published in the DNS.

3.3.3. management
   features.

3.1.3.1.  Signer Actions

   All Signers SHOULD: should:

   o  Include any existing Sender header field in the signed header
      field list, if the Sender header field exists.

   o  ...

   Signers wishing to avoid the use of Third-Party Signatures SHOULD should do
   everything listed above, and also:

   o  Include the Sender header field name in the header field list
      ("h=" tag) under all circumstances, even if the Sender header
      field does not exist in the header block.  This prevents another
      entity from adding a Sender header field.

   o  Publish Signing Practices that do not sanction the use of Third-
      Party Signatures.

3.4.  Mailing Lists

   There are several forms of mailing lists, which interact with signing
   in different ways.

   o  "Verbatim" mailing lists send messages without modification
      whatsoever.  They are often implemented as MTA-based aliases.
      Since they do not modify the message, signatures are unaffected

3.1.4.  Signing Policies and Practices

   Every organization (ADMD) will continue to verify.  It is not necessary have its own policies and practices
   for the
      forwarder deciding when to re-sign 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 message; however, some may choose likelihood that signing
   practices will change over time, it will be useful to do
      so have these
   decisions represented in some sort of configuration information,
   rather than being more deeply coded into the signing software.

3.2.  Mailing Lists

   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.

   There are several forms of mailing lists, which interact with signing
   in different ways.

   o  "Verbatim" mailing lists send messages without modification
      whatsoever.  They are often implemented as MTA-based aliases.
      Since they do not modify the message, signatures are unaffected
      and will continue to verify.  It is not necessary for the
      forwarder to re-sign the message; however, some may choose to do
      so in order to certify that the message was sent through the list.

   o  "Digesting" mailing lists collect together one or more postings
      and then retransmit them, often on a nightly basis, to the
      subscription list.  These are essentially entirely new messages
      which must be independently authored (that is, they will have a
      "From" header field referring to the list, not the submitters) and
      signed by the Mailing List Manager itself, if they are signed at
      all.

   o  "Resending" mailing lists receive a message, modify it (often to
      add "unsubscribe" information or advertising), and immediately
      resend that message to the subscription list.  They are
      problematic because they usually do not change the "From" header
      field of the message, but they do invalidate the signature in the
      process of modifying the message.

   The first two cases act in obvious ways and do not require further
   discussion.  The remainder of this session applies only to

   In most cases, the third
   case.

3.4.1.  Mailing List Manager Actions

   Mailing List Managers list and/or its mail host should make every effort add its own DKIM
   signature to ensure that
   messages that they relay and which have Valid Signatures upon receipt
   also have Valid Signatures upon retransmission.  In particular,
   Mailing List Managers that modify list mail.  This could be done in the message list management
   software, in ways an outgoing MSA or MTA, or both.  List management
   software often makes modifications to messages that will break
   existing signatures SHOULD:

   o  Verify any existing DKIM Signatures.  A DKIM-aware Mailing List
      Manager MUST NOT re-sign an improperly signed message in
   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 verifiable, recognizable signature for list recipients.

   In some cases, the modifications made by the mailing list software
   are simple enough that signatures on incoming messages will still be
   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 and mail sent directly to a list
   member.  In the absence of a list signature, a recipient may still be
   able to recognize and use the original signatures of the list
   members.

   The first two cases act in obvious ways and do not require further
   discussion.  The remainder of this session applies only to the third
   case.

3.2.1.  Mailing List Manager Actions

   Mailing List Managers should make every effort to ensure that
   messages that they relay and which have Valid Signatures upon receipt
   also have Valid Signatures upon retransmission.  In particular,
   Mailing List Managers that modify the message in ways that break
   existing signatures should:

   o  Verify any existing DKIM Signatures.  A DKIM-aware Mailing List
      Manager must NOT re-sign an improperly signed message in such a
      way that would imply that the existing signature is acceptable.

   o  Apply regular anti-spam policies.  A Mailing List Manager SHOULD should
      apply message content security policy just as they would be done to
      messages destined for an individual user's mailbox.  In fact, a
      Mailing List Manager might apply a higher standard to messages
      destined to a mailing list than would normally be applied to
      individual messages.
      NON-NORMATIVE RATIONALE: Since reputation will accrue to signers,
      Mailing List Managers should verify the source and content of
      messages before they are willing to sign lest their reputation be
      sullied by nefarious parties.

   o  Add a Sender header field using a valid address pointing back to
      the Mailing List Administrator or an appropriate agent (such as an
      "owner-" or a "-request" address).

   o  Sign the resulting message with a signature that is valid for the
      Sender header field address.  The Mailing List Manager SHOULD should NOT
      sign messages for which they are unwilling to accept
      responsibility.

   Mailing List Managers MAY:

   o  Reject messages with signatures that do not verify or are
      otherwise Suspicious.

3.5.  Mail User Agent

   DKIM

      [[anchor29: Is "Suspicious" still a formal term in DKIM?]]

3.3.  Signature Transition Strategy

   [[anchor31: I'm not entirely clear what is designed to support deployment meant by "algorithm"
   beyond the combination of key, selector, and use signing parameters
   included 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 DKIMSignature header.  Unless I'm way off base, I
   think 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), section belongs either here under "Signing", 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.

   It section
   1 under "Key Generation, Storage, and Management".  Either way, we
   should be more clear about what is common for components of an ADMD's email infrastructure to do
   violence to a message, such as to render a DKIM signature invalid.
   Hence, users of MUAs that support DKIM signing and/or verifying need
   a basis for knowing that their associated email infrastructure will
   not break a signature.

3.6.  Transition Strategy meant by the term "signature
   algorithm".]]

   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.]

   [[anchor32: safe to presume ADSP?]]

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

3.6.1.

3.3.1.  Signer transition strategy

   Let the old signing algorithm be A, A and 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 either algorithm A or
           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

3.6.2.

3.3.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.

3.7.  Migrating from DomainKeys

3.7.1.  Signing

      DNS Records:   DKIM is upwardly compatible with existing
         DomainKeys (DK) [RFC4870] DNS records, so

4.  Verifying

4.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 DKIM module message is authentically sent
   by a domain does not automatically require additional DNS administration!
         However DKIM has enhanced say much about the DomainKeys DNS key record format 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.  NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP

   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 adding several additional optional parameters. the Boundary MTA: 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.

4.2.  DNS Client

   The principle use primary means of DomainKeys publishing DKIM key information, initially, is at
   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.

4.3.  Boundary
         MTAs.  Because no operational transition is ever instantaneous, Enforcement

   In order for an assessment module to trust the information it
   receives about verification (e.g., Authentication-Results header
   fields), 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 adviseable for existing DomainKeys signers escape
   outside of it.

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

4.4.  Filtering Software

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

   Naive learning algorithms that only consider the presence or absence
   of a
         DomainKeys verified DKIM signature, until such time as DomainKeys receive-
         side support is sufficiently reduced.  With respect without considering more information
   about the message, are vulnerable to signing
         policies, an attack in which spammers or
   other malefactors sign all their mail, thus creating a large negative
   value for presence of a reasonable, initial approach is to use DKIM
         signatures signature in the same way as DomainKeys signatures hope of discouraging
   widespread use.

   If heuristic algorithms are already
         being used.

3.7.2.  Verifying

      DNS Client:   DNS queries for employed, they should be trained on
   feature sets that sufficiently reveal the internal structure of the
   DKIM key record, use responses.  In particular the same
         Domain Name naming conventions as were used for DomainKeys, and algorithm should consider the same basic record format.  No changes
   domains purporting to claim responsibility for the DNS client
         should be required.

      Verifying module:   See signature, rather
   than the section on Signing above.

4.  On-going Operations

   This section describes existence of a signature or not.

   Unless a scheme can correlate the basic steps for operation DKIM signature with accreditation
   or reputation data, the presence of email systems a DKIM signature should be
   ignored.

5.  DKIM Deployment Considerations for Email Agents

5.1.  Email Infrastructure Agents

   It is expected that use DKIM, after the capability has initially been deployed.  The
   primary considerations are:

   o  the upkeep of the selector files, and

   o most common venue for a DKIM implementation
   will be within the security 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 private keys.

4.1.  DNS Signature Record Installation Considerations

   Even with use automatic
         verification of the DNS, one challenge is MTA configuration such that DNS record management
   is usually operated by the MTA can
         generate an administrative staff operator alert if it determines that it is different from
   those who operate (1) 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
         edge MTA, and (2) configured to remember is send email messages that do not
         comply with the DNS published DKIM selectors WILL and
   SHOULD sending policy.

         An outbound MTA should be changed over time.  Some reasons for changing DKIM
   selectors are well understood, while others are still theoretical.
   There are several schemes aware that users may employ MUAs that
         add their own signatures and be used prepared to determine take steps
         necessary to ensure that the policies
   for changing DKIM selectors:

   o  time based

   o  associations message sent is in compliance with clusters of servers

   o  the use of third party signers

   o  security considerations

4.1.1.  Time Basis and Security Considerations

   The reason for changing
         the selector periodically is usually related advertised email sending policy.

         [[anchor42: MUAs being able to the sign is a security exposure of
         consideration; MUAs are more prone to vulnerabilities, so an
         MUA having direct access to signing keys is a system.  When security concern;
         general MUA vulnerability came up during the potential exposure IETF Security
         Directorate review of
   the private keys associated with the draft-kucherawy-sender-auth-header]]

      Inbound:   An inbound MTA or an MDA that does not support DKIM selector have reached
   sufficient levels, the selector
         should avoid modifying messages in ways that prevent
         verification by other MTAs, or MUAs to which the message may be changed.  (It
         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 field.
         [I-D.kucherawy-sender-auth-header]

      Intermediaries:   An email intermediary is unclear
   currently what kinds both an inbound and
         outbound MTA.  Each of metrics can be used to aid the requirements outlined in deciding when the exposure has reached sufficient levels
         sections relating to warrant changing MTAs apply.  If 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, intermediary modifies
         a gateway system that has numerous externally-accessible
      services running on it, is more widely exposed than one that ONLY
      runs message in a mail server.

   o  Selectors way that breaks the signature, the intermediary

         +  should be changed more frequently deploy abuse filtering measures on operating systems
      that are under wide attack.

   o  While the use of DKIM information is transient, keys with
      sufficient exposure do become stale inbound mail,
            and should

         +  MAY remove all signatures that will 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 broken

         In addition the intermediary MAY:

         +  Verify the selector.

   o  Whenever there is either suspicion or evidence message signature prior to modification.

         +  Incorporate an indication of the compromise
      of verification results into
            the system or message, such as using an Authentication-Results header
            field.  [I-D.kucherawy-sender-auth-header]
         +  Sign the private keys, you should change modified message including the selector.

4.1.2.  Deploying New Selectors

   A primary consideration in changing verification results
            (e.g., the selector Authentication-Results header field).

5.2.  Mail User Agent

   DKIM is remembering to
   change it.  It needs designed to be a standard part of the operational staff
   Methods support deployment and Procedures for your systems. use in email components
   other than an MUA.  However an MUA MAY also implement DKIM features
   directly.

      Outbound:   If they are separate, both
   the mail team and an MUA is configured to send email directly, rather
         than relay it through an outbound MSA, the DNS team will MUA should be involved in deploying new
   selectors.

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

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

   2.  Add were an outbound MTA for the new selector record purposes of
         DKIM.  An MUA MAY support signing even if mail is to your DNS.

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

   4.  Turn on signing with the new private key.

   5.  Remove relayed
         through an outbound MSA.  In this case the old private key from your servers.

   6.  After a period of time, remove signature applied by
         the old selector from your DNS.

   The time an unused selector should MUA may be kept in the DNS system is
   dependent 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 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.

4.1.3.  Subdomain Considerations inbound MTA
         path (e.g., an Authentication-Results header field), or an MUA
         MAY perform DKIM signature verification directly.  A Domain Name verifying
         MUA should allow for the case where mail is modified in the basis for making differential quality
   assessments about a DKIM-signed message.
         inbound MTA path.

   It is reasonable common for components of an ADMD's email infrastructure to do
   violence to a
   single organization message, such as to have render a variety DKIM signature invalid.
   Hence, users of very different activities,
   which warrant MUAs that support DKIM signing and/or verifying need
   a variety of very different assessments.  A convenient
   way to distinguish among such activities basis for knowing that their associated email infrastructure will
   not break a signature.

6.  Migrating from DomainKeys

6.1.  Signing

      DNS Records:   DKIM is to sign 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.

         [[anchor46: Explicit "g=" has different
   domain names.  That is, meaning in DomainKeys
         and DKIM, which has been an interoperability issue in the organization should sign with sub-domain
   names past
         (DomainKeys interprets that are used as "match any" while DKIM
         interprets it as "match none")]]
      Boundary MTA:   The principal use of DomainKeys is at Boundary
         MTAs.  Because no operational transition is ever instantaneous,
         it is not adviseable for different organizational activities.

4.1.4.  Delegating Signing Authority existing DomainKeys signers to switch
         to DKIM without continuing to perform DomainKeys signing.  A
         signer should add a Third party

   Allowing third parties DKIM signature to sign email from your domain opens your
   system security a message that also has a
         DomainKeys signature, until such time as DomainKeys receive-
         side support is sufficiently reduced.  With respect to include the security of the third party's systems.
   At signing
         policies, a minimum, you should not allow the third parties reasonable, initial approach is to use DKIM
         signatures in the same
   selector and private key way as your main mail system.  It is recommended
   that each third party be given their own private DomainKeys signatures are already
         being used.

6.2.  Verifying

      DNS Client:   DNS queries for the DKIM key and selector.
   This limits record use the exposure same
         Domain Name naming conventions as were used for any given private key, DomainKeys, and minimizes
         the
   impact if any given private key were exposed.

4.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 same basic record format.  No changes to the DNS client
         should be used to periodically verify that required.

      Verifying module:   See the
   permissions section on the private key files remain secure.

5. Signing above.

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.

5.1.

7.1.  Protection of Internal Mail

   One identity is particularly amenable to easy and accurate
   assessment: The organization's own 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 does not contain a verifiable signature.  Such mail
   can be presumed to be spurious.

   WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN
   SIGNATURE????

5.2.  Need to include some of the breakage examples from
   ADSP spec.

7.2.  Recipient-based Assessments

   Recipients of large volumes of email can internally generate
   reputation data for email 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.

5.2.1.

7.2.1.  Third-party Reputation and Accreditation Services

   For scaling efficiency, it is appealing to use Trusted Third Party
   reputation and accreditation 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.

5.3.

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 verifying in MUAs.

   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.

5.4.

7.4.  Per user signatures

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

   NOTE:   As stated earlier, it is important to distinguish between the
      use of selectors for differential administration of keys, versus
      the use of sub-domains for differential reputations.  It's also
      probably a good idea to note that receivers are unlikely to pay
      attention to reputation at a user granularity even if it's
      technically feasible to publish it.

   As a constraint on an authorized DKIM signing agent, their its 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.

6.

8.  Security Considerations

   TBD

7.

9.  IANA Considerations

   TBD

8.

10.  Acknowledgements

   TBD

9.

11.  Informative References

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

   [I-D.kucherawy-sender-auth-header]
              Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status",
              draft-kucherawy-sender-auth-header-11
              draft-kucherawy-sender-auth-header-17 (work in progress),
              February
              October 2008.

   [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

   Phillip Hallam-Baker
   VeriSign Inc.

   Email: pbaker@verisign.com

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

   Email: dcrocker@bbiw.net

   Ellen Siegel
   Constant Contact, Inc.
   1601 Trapelo Rd, Ste 329
   Waltham, MA  02451
   USA

   Email: esiegel@constantcontact.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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).