8.  Security Considerations

   It has been observed that any introduced mechanism that attempts to
   stem the flow of spam is subject to intensive attack.  DKIM needs to
   be carefully scrutinized to identify potential attack vectors and the
   vulnerability to each.  See also [RFC4686].

8.1.  ASCII Art Attacks

   The relaxed body canonicalization algorithm may enable certain types
   of extremely crude "ASCII Art" attacks where a message may be
   conveyed by adjusting the spacing between words.  If this is a
   concern, the "simple" body canonicalization algorithm should be used
   instead.

8.2.  Misuse of Body Length Limits ("l=" Tag)

   Use of the "l=" tag might allow display of fraudulent content without
   appropriate warning to end users.  The "l=" tag is intended for
   increasing signature robustness when sending to mailing lists that
   both modify their content and do not sign their modified messages.
   However, using the "l=" tag enables attacks in which an intermediary
   with malicious intent can modify a message to include content that
   solely benefits the attacker.  It is possible for the appended

   content to completely replace the original content in the end
   recipient's eyes and to defeat duplicate message detection
   algorithms.

   An example of such an attack includes altering the MIME structure,
   exploiting lax HTML parsing in the MUA, and defeating duplicate
   message detection algorithms.

   To avoid this attack, Signers should be extremely wary of using this
   tag, and Assessors might wish to ignore signatures that use the tag.

8.3.  Misappropriated Private Key

   As with any other security application that uses private- or public-
   key pairs, DKIM requires caution around the handling and protection
   of keys.  A compromised private key or access to one means an
   intruder or malware can send mail signed by the domain that
   advertises the matching public key.

   Thus, private keys issued to users, rather than one used by an
   ADministrative Management Domain (ADMD) itself, create the usual
   problem of securing data stored on personal resources that can affect
   the ADMD.

   A more secure architecture involves sending messages through an
   outgoing MTA that can authenticate the submitter using existing
   techniques (e.g., SMTP Authentication), possibly validate the message
   itself (e.g., verify that the header is legitimate and that the
   content passes a spam content check), and sign the message using a
   key appropriate for the submitter address.  Such an MTA can also
   apply controls on the volume of outgoing mail each user is permitted
   to originate in order to further limit the ability of malware to
   generate bulk email.

8.4.  Key Server Denial-of-Service Attacks

   Since the key servers are distributed (potentially separate for each
   domain), the number of servers that would need to be attacked to
   defeat this mechanism on an Internet-wide basis is very large.
   Nevertheless, key servers for individual domains could be attacked,
   impeding the verification of messages from that domain.  This is not
   significantly different from the ability of an attacker to deny
   service to the mail exchangers for a given domain, although it
   affects outgoing, not incoming, mail.

   A variation on this attack involves a very large amount of mail being
   sent using spoofed signatures from a given domain: the key servers
   for that domain could be overwhelmed with requests in a denial-of-

   service attack (see [RFC4732]).  However, given the low overhead of
   verification compared with handling of the email message itself, such
   an attack would be difficult to mount.

8.5.  Attacks against the DNS

   Since the DNS is a required binding for key services, specific
   attacks against the DNS must be considered.

   While the DNS is currently insecure [RFC3833], these security
   problems are the motivation behind DNS Security (DNSSEC) [RFC4033],
   and all users of the DNS will reap the benefit of that work.

   DKIM is only intended as a "sufficient" method of proving
   authenticity.  It is not intended to provide strong cryptographic
   proof about authorship or contents.  Other technologies such as
   OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements.

   A second security issue related to the DNS revolves around the
   increased DNS traffic as a consequence of fetching selector-based
   data as well as fetching signing domain policy.  Widespread
   deployment of DKIM will result in a significant increase in DNS
   queries to the claimed signing domain.  In the case of forgeries on a
   large scale, DNS servers could see a substantial increase in queries.

   A specific DNS security issue that should be considered by DKIM
   Verifiers is the name chaining attack described in Section 2.3 of
   [RFC3833].  A DKIM Verifier, while verifying a DKIM-Signature header
   field, could be prompted to retrieve a key record of an attacker's
   choosing.  This threat can be minimized by ensuring that name
   servers, including recursive name servers, used by the Verifier
   enforce strict checking of "glue" and other additional information in
   DNS responses and are therefore not vulnerable to this attack.

8.6.  Replay/Spam Attacks

   In this attack, a spammer sends a piece of spam through an MTA that
   signs it, banking on the reputation of the signing domain (e.g., a
   large popular mailbox provider) rather than its own, and then re-
   sends that message to a large number of intended recipients.  The
   recipients observe the valid signature from the well-known domain,
   elevating their trust in the message and increasing the likelihood of
   delivery and presentation to the user.

   Partial solutions to this problem involve the use of reputation
   services to convey the fact that the specific email address is being
   used for spam and that messages from that Signer are likely to be
   spam.  This requires a real-time detection mechanism in order to

   react quickly enough.  However, such measures might be prone to
   abuse, if, for example, an attacker re-sent a large number of
   messages received from a victim in order to make the victim appear to
   be a spammer.

   Large Verifiers might be able to detect unusually large volumes of
   mails with the same signature in a short time period.  Smaller
   Verifiers can get substantially the same volume of information via
   existing collaborative systems.

8.7.  Limits on Revoking Keys

   When a large domain detects undesirable behavior on the part of one
   of its users, it might wish to revoke the key used to sign that
   user's messages in order to disavow responsibility for messages that
   have not yet been verified or that are the subject of a replay
   attack.  However, the ability of the domain to do so can be limited
   if the same key, for scalability reasons, is used to sign messages
   for many other users.  Mechanisms for explicitly revoking keys on a
   per-address basis have been proposed but require further study as to
   their utility and the DNS load they represent.

8.8.  Intentionally Malformed Key Records

   It is possible for an attacker to publish key records in DNS that are
   intentionally malformed, with the intent of causing a denial-of-
   service attack on a non-robust Verifier implementation.  The attacker
   could then cause a Verifier to read the malformed key record by
   sending a message to one of its users referencing the malformed
   record in a (not necessarily valid) signature.  Verifiers MUST
   thoroughly verify all key records retrieved from the DNS and be
   robust against intentionally as well as unintentionally malformed key
   records.

8.9.  Intentionally Malformed DKIM-Signature Header Fields

   Verifiers MUST be prepared to receive messages with malformed DKIM-
   Signature header fields and thoroughly verify the header field before
   depending on any of its contents.

8.10.  Information Leakage

   An attacker could determine when a particular signature was verified
   by using a per-message selector and then monitoring their DNS traffic
   for the key lookup.  This would act as the equivalent of a "web bug"
   for verification time rather than the time the message was read.

8.11.  Remote Timing Attacks

   In some cases, it may be possible to extract private keys using a
   remote timing attack [BONEH03].  Implementations should consider
   obfuscating the timing to prevent such attacks.

8.12.  Reordered Header Fields

   Existing standards allow intermediate MTAs to reorder header fields.
   If a Signer signs two or more header fields of the same name, this
   can cause spurious verification errors on otherwise legitimate
   messages.  In particular, Signers that sign any existing DKIM-
   Signature fields run the risk of having messages incorrectly fail to
   verify.

8.13.  RSA Attacks

   An attacker could create a large RSA signing key with a small
   exponent, thus requiring that the verification key have a large
   exponent.  This will force Verifiers to use considerable computing
   resources to verify the signature.  Verifiers might avoid this attack
   by refusing to verify signatures that reference selectors with public
   keys having unreasonable exponents.

   In general, an attacker might try to overwhelm a Verifier by flooding
   it with messages requiring verification.  This is similar to other
   MTA denial-of-service attacks and should be dealt with in a similar
   fashion.

8.14.  Inappropriate Signing by Parent Domains

   The trust relationship described in Section 3.10 could conceivably be
   used by a parent domain to sign messages with identities in a
   subdomain not administratively related to the parent.  For example,
   the ".com" registry could create messages with signatures using an
   "i=" value in the example.com domain.  There is no general solution
   to this problem, since the administrative cut could occur anywhere in
   the domain name.  For example, in the domain "example.podunk.ca.us",
   there are three administrative cuts (podunk.ca.us, ca.us, and us),
   any of which could create messages with an identity in the full
   domain.

      INFORMATIVE NOTE: This is considered an acceptable risk for the
      same reason that it is acceptable for domain delegation.  For
      example, in the case above, any of the domains could potentially
      simply delegate "example.podunk.ca.us" to a server of their choice

      and completely replace all DNS-served information.  Note that a
      Verifier MAY ignore signatures that come from an unlikely domain
      such as ".com", as discussed in Section 6.1.1.

8.15.  Attacks Involving Extra Header Fields

   Many email components, including MTAs, MSAs, MUAs, and filtering
   modules, implement message format checks only loosely.  This is done
   out of years of industry pressure to be liberal in what is accepted
   into the mail stream for the sake of reducing support costs;
   improperly formed messages are often silently fixed in transit,
   delivered unrepaired, or displayed inappropriately (e.g., by showing
   only the first of multiple From: fields).

   Agents that evaluate or apply DKIM output need to be aware that a
   DKIM Signer can sign messages that are malformed (e.g., violate
   [RFC5322], such as by having multiple instances of a field that is
   only permitted once), that become malformed in transit, or that
   contain header or body content that is not true or valid.  Use of
   DKIM on such messages might constitute an attack against a receiver,
   especially where additional credence is given to a signed message
   without adequate evaluation of the Signer.

   These can represent serious attacks, but they have nothing to do with
   DKIM; they are attacks on the recipient or on the wrongly identified
   author.

   Moreover, an agent would be incorrect to infer that all instances of
   a header field are signed just because one is.

   A genuine signature from the domain under attack can be obtained by
   legitimate means, but extra header fields can then be added, either
   by interception or by replay.  In this scenario, DKIM can aid in
   detecting addition of specific fields in transit.  This is done by
   having the Signer list the field name(s) in the "h=" tag an extra
   time (e.g., "h=from:from:..." for a message with one From field), so
   that addition of an instance of that field downstream will render the
   signature unable to be verified.  (See Section 3.5 for details.)
   This, in essence, is an explicit indication that the Signer
   repudiates responsibility for such a malformed message.

   DKIM signs and validates the data it is told to and works correctly.
   So in this case, DKIM has done its job of delivering a validated
   domain (the "d=" value) and, given the semantics of a DKIM signature,
   essentially the Signer has taken some responsibility for a
   problematic message.  It is up to the Identity Assessor or some other

   subsequent agent to act on such messages as needed, such as degrading
   the trust of the message (or, indeed, of the Signer), warning the
   recipient, or even refusing delivery.

   All components of the mail system that perform loose enforcement of
   other mail standards will need to revisit that posture when
   incorporating DKIM, especially when considering matters of potential
   attacks such as those described.

9.  References

9.1.  Normative References

   [FIPS-180-3-2008]
              U.S. Department of Commerce, "Secure Hash Standard", FIPS
              PUB 180-3, October 2008.

   [ITU-X660-1997]
              "Information Technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", 1997.

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

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Five: Conformance Criteria and
              Examples", RFC 2049, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              July 2009.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

9.2.  Informative References

   [BONEH03]  "Remote Timing Attacks are Practical", Proceedings 12th
              USENIX Security Symposium, 2003.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
              RFC 3766, April 2004.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, August 2004.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 4409, April 2006.

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

   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
              Service Considerations", RFC 4732, December 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.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451, April 2009.

   [RFC5585]  Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
              Identified Mail (DKIM) Service Overview", RFC 5585,
              July 2009.

   [RFC5672]  Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
              Signatures -- Update", RFC 5672, August 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5863]  Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
              "DomainKeys Identified Mail (DKIM) Development,
              Deployment, and Operations", RFC 5863, May 2010.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
              Mailing Lists", RFC 6377, September 2011.

Appendix A.  Example of Use (INFORMATIVE)

   This section shows the complete flow of an email from submission to
   final delivery, demonstrating how the various components fit
   together.  The key used in this example is shown in Appendix C.

A.1.  The User Composes an Email

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

                   Figure 1: The User Composes an Email

A.2.  The Email is Signed

   This email is signed by the example.com outbound email server and now
   looks like this:

   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
        c=simple/simple; q=dns/txt; i=joe@football.example.com;
        h=Received : From : To : Subject : Date : Message-ID;
        bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
        b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
        4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
        KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
        4bmp/YzhwvcubU4=;
   Received: from client1.football.example.com  [192.0.2.1]
        by submitserver.example.com with SUBMISSION;
        Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

                       Figure 2: The Email is Signed

   The signing email server requires access to the private key
   associated with the "brisbane" selector to generate this signature.

A.3.  The Email Signature is Verified

   The signature is normally verified by an inbound SMTP server or
   possibly the final delivery agent.  However, intervening MTAs can
   also perform this verification if they choose to do so.  The
   verification process uses the domain "example.com" extracted from the
   "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM-
   Signature header field to form the DNS DKIM query for:
   brisbane._domainkey.example.com

   Signature verification starts with the physically last Received
   header field, the From header field, and so forth, in the order
   listed in the "h=" tag.  Verification follows with a single CRLF
   followed by the body (starting with "Hi.").  The email is canonically
   prepared for verifying with the "simple" method.  The result of the
   query and subsequent verification of the signature is stored (in this
   example) in the X-Authentication-Results header field line.  After
   successful verification, the email looks like this:

   X-Authentication-Results: shopping.example.net
     header.from=joe@football.example.com; dkim=pass
   Received: from mout23.football.example.com (192.168.1.1)
     by shopping.example.net with SMTP;
     Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
     c=simple/simple; q=dns/txt; i=joe@football.example.com;
     h=Received : From : To : Subject : Date : Message-ID;
     bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
     b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
       4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
       KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
       4bmp/YzhwvcubU4=;
   Received: from client1.football.example.com  [192.0.2.1]
     by submitserver.example.com with SUBMISSION;
     Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

                     Figure 3: Successful Verification

Appendix B.  Usage Examples (INFORMATIVE)

   DKIM signing and validating can be used in different ways, for
   different operational scenarios.  This Appendix discusses some common
   examples.

      NOTE: Descriptions in this Appendix are for informational purposes
      only.  They describe various ways that DKIM can be used, given
      particular constraints and needs.  In no case are these examples
      intended to be taken as providing explanation or guidance
      concerning DKIM specification details when creating an
      implementation.

B.1.  Alternate Submission Scenarios

   In the most simple scenario, a user's MUA, MSA, and Internet
   (boundary) MTA are all within the same administrative environment,
   using the same domain name.  Therefore, all of the components
   involved in submission and initial transfer are related.  However, it
   is common for two or more of the components to be under independent
   administrative control.  This creates challenges for choosing and
   administering the domain name to use for signing and for its
   relationship to common email identity header fields.

B.1.1.  Delegated Business Functions

   Some organizations assign specific business functions to discrete
   groups, inside or outside the organization.  The goal, then, is to
   authorize that group to sign some mail but to constrain what
   signatures they can generate.  DKIM selectors (the "s=" signature
   tag) facilitate this kind of restricted authorization.  Examples of
   these outsourced business functions are legitimate email marketing
   providers and corporate benefits providers.

   Here, the delegated group needs to be able to send messages that are
   signed, using the email domain of the client company.  At the same
   time, the client often is reluctant to register a key for the
   provider that grants the ability to send messages for arbitrary
   addresses in the domain.

   There are multiple ways to administer these usage scenarios.  In one
   case, the client organization provides all of the public query
   service (for example, DNS) administration, and in another, it uses
   DNS delegation to enable all ongoing administration of the DKIM key
   record by the delegated group.

   If the client organization retains responsibility for all of the DNS
   administration, the outsourcing company can generate a key pair,
   supplying the public key to the client company, which then registers
   it in the query service using a unique selector.  The client company
   retains control over the use of the delegated key because it retains
   the ability to revoke the key at any time.

   If the client wants the delegated group to do the DNS administration,
   it can have the domain name that is specified with the selector point
   to the provider's DNS server.  The provider then creates and
   maintains all of the DKIM signature information for that selector.
   Hence, the client cannot provide constraints on the local-part of
   addresses that get signed, but it can revoke the provider's signing
   rights by removing the DNS delegation record.

B.1.2.  PDAs and Similar Devices

   PDAs demonstrate the need for using multiple keys per domain.
   Suppose that John Doe wants to be able to send messages using his
   corporate email address, jdoe@example.com, and his email device does
   not have the ability to make a Virtual Private Network (VPN)
   connection to the corporate network, either because the device is
   limited or because there are restrictions enforced by his Internet
   access provider.  If the device is equipped with a private key
   registered for jdoe@example.com by the administrator of the
   example.com domain and appropriate software to sign messages, John
   could sign the message on the device itself before transmission
   through the outgoing network of the access service provider.

B.1.3.  Roaming Users

   Roaming users often find themselves in circumstances where it is
   convenient or necessary to use an SMTP server other than their home
   server; examples are conferences and many hotels.  In such
   circumstances, a signature that is added by the submission service
   will use an identity that is different from the user's home system.

   Ideally, roaming users would connect back to their home server using
   either a VPN or a SUBMISSION server running with SMTP AUTHentication
   on port 587.  If the signing can be performed on the roaming user's
   laptop, then they can sign before submission, although the risk of
   further modification is high.  If neither of these are possible,
   these roaming users will not be able to send mail signed using their
   own domain key.

B.1.4.  Independent (Kiosk) Message Submission

   Stand-alone services, such as walk-up kiosks and web-based
   information services, have no enduring email service relationship
   with the user, but users occasionally request that mail be sent on
   their behalf.  For example, a website providing news often allows the
   reader to forward a copy of the article to a friend.  This is
   typically done using the reader's own email address, to indicate who
   the author is.  This is sometimes referred to as the "Evite" problem,
   named after the website of the same name that allows a user to send
   invitations to friends.

   A common way this is handled is to continue to put the reader's email
   address in the From header field of the message but put an address
   owned by the email posting site into the Sender header field.  The
   posting site can then sign the message, using the domain that is in
   the Sender field.  This provides useful information to the receiving
   email site, which is able to correlate the signing domain with the
   initial submission email role.

   Receiving sites often wish to provide their end users with
   information about mail that is mediated in this fashion.  Although
   the real efficacy of different approaches is a subject for human
   factors usability research, one technique that is used is for the
   verifying system to rewrite the From header field to indicate the
   address that was verified, for example: From: John Doe via
   news@news-site.example <jdoe@example.com>.  (Note that such rewriting
   will break a signature, unless it is done after the verification pass
   is complete.)

B.2.  Alternate Delivery Scenarios

   Email is often received at a mailbox that has an address different
   from the one used during initial submission.  In these cases, an
   intermediary mechanism operates at the address originally used, and
   it then passes the message on to the final destination.  This
   mediation process presents some challenges for DKIM signatures.

B.2.1.  Affinity Addresses

   "Affinity addresses" allow a user to have an email address that
   remains stable, even as the user moves among different email
   providers.  They are typically associated with college alumni
   associations, professional organizations, and recreational
   organizations with which they expect to have a long-term
   relationship.  These domains usually provide forwarding of incoming
   email, and they often have an associated Web application that
   authenticates the user and allows the forwarding address to be

   changed.  However, these services usually depend on users sending
   outgoing messages through their own service provider's MTAs.  Hence,
   mail that is signed with the domain of the affinity address is not
   signed by an entity that is administered by the organization owning
   that domain.

   With DKIM, affinity domains could use the Web application to allow
   users to register per-user keys to be used to sign messages on behalf
   of their affinity address.  The user would take away the secret half
   of the key pair for signing, and the affinity domain would publish
   the public half in DNS for access by Verifiers.

   This is another application that takes advantage of user-level
   keying, and domains used for affinity addresses would typically have
   a very large number of user-level keys.  Alternatively, the affinity
   domain could handle outgoing mail, operating a mail submission agent
   that authenticates users before accepting and signing messages for
   them.  This is, of course, dependent on the user's service provider
   not blocking the relevant TCP ports used for mail submission.

B.2.2.  Simple Address Aliasing (.forward)

   In some cases, a recipient is allowed to configure an email address
   to cause automatic redirection of email messages from the original
   address to another, such as through the use of a Unix .forward file.
   In this case, messages are typically redirected by the mail handling
   service of the recipient's domain, without modification, except for
   the addition of a Received header field to the message and a change
   in the envelope recipient address.  In this case, the recipient at
   the final address' mailbox is likely to be able to verify the
   original signature since the signed content has not changed, and DKIM
   is able to validate the message signature.

B.2.3.  Mailing Lists and Re-Posters

   There is a wide range of behaviors in services that take delivery of
   a message and then resubmit it.  A primary example is with mailing
   lists (collectively called "forwarders" below), ranging from those
   that make no modification to the message itself, other than to add a
   Received header field and change the envelope information, to those
   that add header fields, change the Subject header field, add content
   to the body (typically at the end), or reformat the body in some
   manner.  The simple ones produce messages that are quite similar to
   the automated alias services.  More elaborate systems essentially
   create a new message.

   A Forwarder that does not modify the body or signed header fields of
   a message is likely to maintain the validity of the existing
   signature.  It also could choose to add its own signature to the
   message.

   Forwarders that modify a message in a way that could make an existing
   signature invalid are particularly good candidates for adding their
   own signatures (e.g., mailing-list-name@example.net).  Since
   (re-)signing is taking responsibility for the content of the message,
   these signing forwarders are likely to be selective and forward or
   re-sign a message only if it is received with a valid signature or if
   they have some other basis for knowing that the message is not
   spoofed.

   A common practice among systems that are primarily redistributors of
   mail is to add a Sender header field to the message to identify the
   address being used to sign the message.  This practice will remove
   any preexisting Sender header field as required by [RFC5322].  The
   forwarder applies a new DKIM-Signature header field with the
   signature, public key, and related information of the forwarder.

   See [RFC6377] for additional related topics and discussion.

Appendix C.  Creating a Public Key (INFORMATIVE)

   The default signature is an RSA-signed SHA-256 digest of the complete
   email.  For ease of explanation, the openssl command is used to
   describe the mechanism by which keys and signatures are managed.  One
   way to generate a 1024-bit, unencrypted private key suitable for DKIM
   is to use openssl like this:

   $ openssl genrsa -out rsa.private 1024

   For increased security, the "-passin" parameter can also be added to
   encrypt the private key.  Use of this parameter will require entering
   a password for several of the following steps.  Servers may prefer to
   use hardware cryptographic support.

   The "genrsa" step results in the file rsa.private containing the key
   information similar to this:

   -----BEGIN RSA PRIVATE KEY-----
   MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC
   jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb
   to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB
   AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX
   /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ
   gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO
   n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m
   3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/
   eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj
   7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA
   qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf
   eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX
   GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc=
   -----END RSA PRIVATE KEY-----

   To extract the public-key component from the private key, use openssl
   like this:

   $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

   This results in the file rsa.public containing the key information
   similar to this:

   -----BEGIN PUBLIC KEY-----
   MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
   oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
   tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
   MmPSPDdQPNUYckcQ2QIDAQAB
   -----END PUBLIC KEY-----

   This public-key data (without the BEGIN and END tags) is placed in
   the DNS:

   $ORIGIN _domainkey.example.org.
   brisbane IN  TXT  ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
                      "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
                      "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
                      "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
                      "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")

C.1.  Compatibility with DomainKeys Key Records

   DKIM key records were designed to be backward compatible in many
   cases with key records used by DomainKeys [RFC4870] (sometimes
   referred to as "selector records" in the DomainKeys context).  One
   area of incompatibility warrants particular attention.  The "g=" tag
   value may be used in DomainKeys and [RFC4871] key records to provide

   finer granularity of the validity of the key record to a specific
   local-part.  A null "g=" value in DomainKeys is valid for all
   addresses in the domain.  This differs from the usage in the original
   DKIM specification ([RFC4871]), where a null "g=" value is not valid
   for any address.  In particular, see the example public-key record in
   Section 3.2.3 of [RFC4870].

C.2.  RFC 4871 Compatibility

   Although the "g=" tag has been deprecated in this version of the DKIM
   specification (and thus MUST now be ignored), Signers are advised not
   to include the "g=" tag in key records because some [RFC4871]-
   compliant Verifiers will be in use for a considerable period to come.

Appendix D.  MUA Considerations (INFORMATIVE)

   When a DKIM signature is verified, the processing system sometimes
   makes the result available to the recipient user's MUA.  How to
   present this information to users in a way that helps them is a
   matter of continuing human factors usability research.  The tendency
   is to have the MUA highlight the SDID, in an attempt to show the user
   the identity that is claiming responsibility for the message.  An MUA
   might do this with visual cues such as graphics, might include the
   address in an alternate view, or might even rewrite the original From
   address using the verified information.  Some MUAs might indicate
   which header fields were protected by the validated DKIM signature.
   This could be done with a positive indication on the signed header
   fields, with a negative indication on the unsigned header fields, by
   visually hiding the unsigned header fields, or some combination of
   these.  If an MUA uses visual indications for signed header fields,
   the MUA probably needs to be careful not to display unsigned header
   fields in a way that might be construed by the end user as having
   been signed.  If the message has an "l=" tag whose value does not
   extend to the end of the message, the MUA might also hide or mark the
   portion of the message body that was not signed.

   The aforementioned information is not intended to be exhaustive.  The
   MUA can choose to highlight, accentuate, hide, or otherwise display
   any other information that may, in the opinion of the MUA author, be
   deemed important to the end user.

Appendix E.  Changes since RFC 4871

   o  Abstract and introduction refined based on accumulated experience.

   o  Various references updated.

   o  Several errata resolved (see http://www.rfc-editor.org/):

      *  1376 applied

      *  1377 applied

      *  1378 applied

      *  1379 applied

      *  1380 applied

      *  1381 applied

      *  1382 applied

      *  1383 discarded (no longer applies)

      *  1384 applied

      *  1386 applied

      *  1461 applied

      *  1487 applied

      *  1532 applied

      *  1596 applied

   o  Introductory section enumerating relevant architectural documents
      added.

   o  Introductory section briefly discussing the matter of data
      integrity added.

   o  Allowed tolerance of some clock drift.

   o  Dropped "g=" tag from key records.  The implementation report
      indicates that it is not in use.

   o  Removed errant note about wildcards in the DNS.

   o  Removed SMTP-specific advice in most places.

   o  Reduced (non-normative) recommended signature content list, and
      reworked the text in that section.

   o  Clarified signature generation algorithm by rewriting its pseudo-
      code.

   o  Numerous terminology subsections added, imported from [RFC5672].
      Also, began using these terms throughout the document (e.g., SDID,
      AUID).

   o  Sections added that specify input and output requirements.  Input
      requirements address a security concern raised by the working
      group (see also new sections in Security Considerations).  Output
      requirements are imported from [RFC5672].

   o  Appendix subsection added discussing compatibility with DomainKeys
      ([RFC4870]) records.

   o  Referred to [RFC5451] as an example method of communicating the
      results of DKIM verification.

   o  Removed advice about possible uses of the "l=" signature tag.

   o  IANA registry updated.

   o  Added two new Security Considerations sections talking about
      malformed message attacks.

   o  Various copy editing.

Appendix F.  Acknowledgments

   The previous IETF version of DKIM [RFC4871] was edited by Eric
   Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton, and
   Michael Thomas.

   That specification was the result of an extended collaborative
   effort, including participation by Russ Allbery, Edwin Aoki, Claus
   Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve
   Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis
   Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark
   Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur
   Gudmundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel
   Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Hughes,
   Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry
   Leiba, John Levine, Charles Lindsey, Simon Longsdale, David Margrave,
   Justin Mason, David Mayne, Thierry Moreau, Steve Murphy, Russell
   Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer Pizzorno,
   Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, Neil

   Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the
   Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam
   Weiler, and Dan Wing.

   The earlier DomainKeys was a primary source from which DKIM was
   derived.  Further information about DomainKeys is at [RFC4870].

   This revision received contributions from Steve Atkins, Mark Delany,
   J.D. Falk, Jim Fenton, Michael Hammer, Barry Leiba, John Levine,
   Charles Lindsey, Jeff Macdonald, Franck Martin, Brett McDowell, Doug
   Otis, Bill Oxley, Hector Santos, Rolf Sonneveld, Michael Thomas, and
   Alessandro Vesely.

Authors' Addresses

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

   Phone: +1.408.246.8253
   EMail: dcrocker@bbiw.net
   URI:   http://bbiw.net


   Tony Hansen (editor)
   AT&T Laboratories
   200 Laurel Ave. South
   Middletown, NJ  07748
   USA

   EMail: tony+dkimsig@maillennium.att.com


   Murray S. Kucherawy (editor)
   Cloudmark
   128 King St., 2nd Floor
   San Francisco, CA  94107
   USA

   EMail: msk@cloudmark.com