Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4871

DomainKeys Identified Mail (DKIM) Signatures

Pages: 71
Obsoletes:  4870
Obsoleted by:  6376
Updated by:  5672
Part 4 of 4 – Pages 52 to 71
First   Prev   None

ToP   noToC   RFC4871 - Page 52   prevText

8. Security Considerations

It has been observed that any mechanism that is introduced 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. Misuse of Body Length Limits ("l=" Tag)

Body length limits (in the form of the "l=" tag) are subject to several potential attacks.

8.1.1. Addition of New MIME Parts to Multipart/*

If the body length limit does not cover a closing MIME multipart section (including the trailing "--CRLF" portion), then it is possible for an attacker to intercept a properly signed multipart message and add a new body part. Depending on the details of the MIME type and the implementation of the verifying MTA and the receiving MUA, this could allow an attacker to change the information displayed to an end user from an apparently trusted source.
ToP   noToC   RFC4871 - Page 53
   For example, if attackers can append information to a "text/html"
   body part, they may be able to exploit a bug in some MUAs that
   continue to read after a "</html>" marker, and thus display HTML text
   on top of already displayed text.  If a message has a
   "multipart/alternative" body part, they might be able to add a new
   body part that is preferred by the displaying MUA.

8.1.2. Addition of new HTML content to existing content

Several receiving MUA implementations do not cease display after a ""</html>"" tag. In particular, this allows attacks involving overlaying images on top of existing text. INFORMATIVE EXAMPLE: Appending the following text to an existing, properly closed message will in many MUAs result in inappropriate data being rendered on top of existing, correct data: <div style="position: relative; bottom: 350px; z-index: 2;"> <img src="" width=578 height=370> </div>

8.2. Misappropriated Private Key

If the private key for a user is resident on their computer and is not protected by an appropriately secure mechanism, it is possible for malware to send mail as that user and any other user sharing the same private key. The malware would not, however, be able to generate signed spoofs of other signers' addresses, which would aid in identification of the infected user and would limit the possibilities for certain types of attacks involving socially engineered messages. This threat applies mainly to MUA-based implementations; protection of private keys on servers can be easily achieved through the use of specialized cryptographic hardware. A larger problem occurs if malware on many users' computers obtains the private keys for those users and transmits them via a covert channel to a site where they can be shared. The compromised users would likely not know of the misappropriation until they receive "bounce" messages from messages they are purported to have sent. Many users might not understand the significance of these bounce messages and would not take action. One countermeasure is to use a user-entered passphrase to encrypt the private key, although users tend to choose weak passphrases and often reuse them for different purposes, possibly allowing an attack against DKIM to be extended into other domains. Nevertheless, the decoded private key might be briefly available to compromise by malware when it is entered, or might be discovered via keystroke
ToP   noToC   RFC4871 - Page 54
   logging.  The added complexity of entering a passphrase each time one
   sends a message would also tend to discourage the use of a secure

   A somewhat more effective countermeasure is to send 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.3. 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 is that if a very large amount of mail were to be sent using spoofed addresses from a given domain, the key servers for that domain could be overwhelmed with requests. However, given the low overhead of verification compared with handling of the email message itself, such an attack would be difficult to mount.

8.4. 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 [RFC2440] and S/MIME [RFC3851] 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
ToP   noToC   RFC4871 - Page 55
   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 the
   DNS Threat Analysis [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

8.5. Replay Attacks

In this attack, a spammer sends a message to be spammed to an accomplice, which results in the message being signed by the originating MTA. The accomplice resends the message, including the original signature, to a large number of recipients, possibly by sending the message to many compromised machines that act as MTAs. The messages, not having been modified by the accomplice, have valid signatures. 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 resent a large number of messages received from a victim in order to make them 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.6. 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.
ToP   noToC   RFC4871 - Page 56

8.7. 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.8. 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.9. 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 when the message was read.

8.10. 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.11. 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.12. 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.
ToP   noToC   RFC4871 - Page 57
   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

8.13. Inappropriate Signing by Parent Domains

The trust relationship described in Section 3.8 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 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 "" there are three administrative cuts (,, 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 example above any of the domains could potentially simply delegate "" 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.

9. References

9.1. Normative References

[FIPS.180-2.2002] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-2, August 2002. [ITU.X660.1997] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.660, 1997. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message header field Extensions for Non-ASCII Text", RFC 2047, November 1996.
ToP   noToC   RFC4871 - Page 58
   [RFC2119]          Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

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

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

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

   [RFC3490]          Faltstrom, P., Hoffman, P., and A. Costello,
                      "Internationalizing Domain Names in Applications
                      (IDNA)", RFC 3490, March 2003.

   [RFC4234]          Crocker, D., Ed. and P. Overell, "Augmented BNF
                      for Syntax Specifications: ABNF", RFC 4234,
                      October 2005.

9.2. Informative References

[BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing Attacks are Practical", 2003. [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for Public Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
ToP   noToC   RFC4871 - Page 59
   [RFC3851]          Ramsdell, B., "S/MIME Version 3 Message
                      Specification", RFC 3851, June 1999.

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

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

   [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.
ToP   noToC   RFC4871 - Page 60

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 <> To: Suzie Q <> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <> Hi. We lost the game. Are you hungry yet? Joe.
ToP   noToC   RFC4871 - Page 61

A.2. The Email Is Signed

This email is signed by the outbound email server and now looks like this: DKIM-Signature: v=1; a=rsa-sha256; s=brisbane;; c=simple/simple; q=dns/txt;; h=Received : From : To : Subject : Date : Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from [] by with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: Joe SixPack <> To: Suzie Q <> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <> Hi. We lost the game. Are you hungry yet? Joe. 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 "" 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: 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
ToP   noToC   RFC4871 - Page 62
   example) in the X-Authentication-Results header field line.  After
   successful verification, the email looks like this:

   X-Authentication-Results:; dkim=pass
   Received: from (
         by with SMTP;
         Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane;;
         c=simple/simple; q=dns/txt;;
         h=Received : From : To : Subject : Date : Message-ID;
   Received: from  []
         by with SUBMISSION;
         Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <>
   To: Suzie Q <>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <>


   We lost the game. Are you hungry yet?


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.
ToP   noToC   RFC4871 - Page 63

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) and granularity (the "g=" key 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 that authorizes a specific From header field Local-part. For example, a client with the domain "" could have the selector record specify "g=winter-promotions" so that this signature is only valid for mail with a From address of "". This would enable the provider to send messages using that specific address and have them verify properly. The client company retains control over the email address because it retains the ability to revoke the key at any time.
ToP   noToC   RFC4871 - Page 64
   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 wanted to be able to send messages using his corporate email address,, and his email device did 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 was equipped with a private key registered for by the administrator of the 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",
ToP   noToC   RFC4871 - Page 65
   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 <>.  (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 providers' 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
ToP   noToC   RFC4871 - Page 66
   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 which modify a message in a way that could make an existing signature invalid are particularly good candidates for adding their own signatures (e.g., 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
ToP   noToC   RFC4871 - Page 67
   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 [RFC2822].  The
   forwarder applies a new DKIM-Signature header field with the
   signature, public key, and related information of the forwarder.

Appendix C. Creating a Public Key (INFORMATIVE)

The default signature is an RSA signed SHA256 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
ToP   noToC   RFC4871 - Page 68
   This results in the file rsa.public containing the key information
   similar to this:

   -----BEGIN PUBLIC KEY-----
   -----END PUBLIC KEY-----

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


Appendix D. MUA Considerations

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 the user in a way that helps them is a matter of continuing human factors usability research. The tendency is to have the MUA highlight the address associated with this signing identity in some way, in an attempt to show the user the address from which the mail was sent. An MUA might do this with visual cues such as graphics, or it might include the address in an alternate view, or it 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 may 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.
ToP   noToC   RFC4871 - Page 69

Appendix E. Acknowledgements

The authors wish to thank 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 Gu[eth]mundsson, 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 team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing for their valuable suggestions and constructive criticism. The DomainKeys specification was a primary source from which this specification has been derived. Further information about DomainKeys is at [RFC4870].

Authors' Addresses

Eric Allman Sendmail, Inc. 6425 Christie Ave, Suite 400 Emeryville, CA 94608 USA Phone: +1 510 594 5501 EMail: URI: Jon Callas PGP Corporation 3460 West Bayshore Palo Alto, CA 94303 USA Phone: +1 650 319 9016 EMail:
ToP   noToC   RFC4871 - Page 70
   Mark Delany
   Yahoo! Inc
   701 First Avenue
   Sunnyvale, CA  95087

   Phone: +1 408 349 6831

   Miles Libbey
   Yahoo! Inc
   701 First Avenue
   Sunnyvale, CA  95087


   Jim Fenton
   Cisco Systems, Inc.
   MS SJ-9/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706

   Phone: +1 408 526 5914

   Michael Thomas
   Cisco Systems, Inc.
   MS SJ-9/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706

   Phone: +1 408 525 5386
ToP   noToC   RFC4871 - Page 71
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.