doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc4870.txt b/doc/rfc/rfc4870.txt
new file mode 100644
index 0000000..7182f12
--- /dev/null
+++ b/doc/rfc/rfc4870.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                          M. Delany
+Request for Comments: 4870                                    Yahoo! Inc
+Obsoleted By: 4871                                              May 2007
+Category: Historic
+
+
+          Domain-Based Email Authentication Using Public Keys
+                   Advertised in the DNS (DomainKeys)
+
+Status of This Memo
+
+   This memo defines a Historic Document for the Internet community.  It
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   "DomainKeys" creates a domain-level authentication framework for
+   email by using public key technology and the DNS to prove the
+   provenance and contents of an email.
+
+   This document defines a framework for digitally signing email on a
+   per-domain basis.  The ultimate goal of this framework is to
+   unequivocally prove and protect identity while retaining the
+   semantics of Internet email as it is known today.
+
+   Proof and protection of email identity may assist in the global
+   control of "spam" and "phishing".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Delany                          Historic                        [Page 1]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Lack of Authentication Is Damaging Internet Email ..........3
+      1.2. Digitally Signing Email Creates Credible Domain
+           Authentication .............................................4
+      1.3. Public Keys in the DNS .....................................4
+      1.4. Initial Deployment Is Likely at the Border MTA .............5
+      1.5. Conveying Verification Results to MUAs .....................5
+      1.6. Technical Minutiae Are Not Completely Covered ..............5
+      1.7. Motivation .................................................6
+      1.8. Benefits of DomainKeys .....................................6
+      1.9. Definitions ................................................7
+      1.10. Requirements Notation .....................................8
+   2. DomainKeys Overview .............................................8
+   3. DomainKeys Detailed View ........................................8
+      3.1. Determining the Sending Address of an Email ................9
+      3.2. Retrieving the Public Key Given the Sending Domain ........10
+           3.2.1. Introducing "selectors" ............................10
+           3.2.2. Public Key Signing and Verification Algorithm ......11
+           3.2.3. Public key Representation in the DNS ...............13
+           3.2.4. Key Sizes ..........................................14
+      3.3. Storing the Signature in the Email Header .................15
+      3.4. Preparation of Email for Transit and Signing ..............17
+           3.4.1. Preparation for Transit ............................18
+           3.4.2. Canonicalization for Signing .......................18
+                  3.4.2.1. The "simple" Canonicalization Algorithm ...19
+                  3.4.2.2. The "nofws" Canonicalization Algorithm ....19
+      3.5. The Signing Process .......................................20
+           3.5.1. Identifying the Sending Domain .....................20
+           3.5.2. Determining Whether an Email Should Be Signed ......21
+           3.5.3. Selecting a Private Key and Corresponding
+                  Selector Information ...............................21
+           3.5.4. Calculating the Signature Value ....................21
+           3.5.5. Prepending the "DomainKey-Signature:" Header .......21
+      3.6. Policy Statement of Sending Domain ........................22
+      3.7. The Verification Process ..................................23
+           3.7.1. Presumption that Headers Are Not Reordered .........24
+           3.7.2. Verification Should Render a Binary Result .........24
+           3.7.3. Selecting the Most Appropriate
+                  "DomainKey-Signature:" Header ......................24
+           3.7.4. Retrieve the Public Key Based on the
+                  Signature Information ..............................26
+           3.7.5. Verify the Signature ...............................27
+           3.7.6. Retrieving Sending Domain Policy ...................27
+           3.7.7. Applying Local Policy ..............................27
+      3.8. Conveying Verification Results to MUAs ....................27
+
+
+
+
+Delany                          Historic                        [Page 2]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   4. Example of Use .................................................29
+      4.1. The User Composes an Email ................................29
+      4.2. The Email Is Signed .......................................29
+      4.3. The Email Signature Is Verified ...........................30
+   5. Association with a Certificate Authority .......................31
+      5.1. The "DomainKey-X509:" Header ..............................31
+   6. Topics for Discussion ..........................................32
+      6.1. The Benefits of Selectors .................................32
+      6.2. Canonicalization of Email .................................33
+      6.3. Mailing Lists .............................................33
+      6.4. Roving Users ..............................................33
+   7. Security Considerations ........................................34
+      7.1. DNS .......................................................34
+           7.1.1. The DNS Is Not Currently Secure ....................34
+           7.1.2. DomainKeys Creates Additional DNS Load .............35
+      7.2. Key Management ............................................35
+      7.3. Implementation Risks ......................................35
+      7.4. Privacy Assumptions with Forwarding Addresses .............35
+      7.5. Cryptographic Processing Is Computationally Intensive .....36
+   8. The Trial ......................................................36
+      8.1. Goals .....................................................36
+      8.2. Results of Trial ..........................................37
+   9. Note to Implementors Regarding TXT Records .....................37
+   10. References ....................................................37
+      10.1. Normative References .....................................37
+      10.2. Informative References ...................................38
+      Appendix A - Syntax Rules for the Tag=Value Format .............39
+      Acknowledgments ................................................40
+
+1.  Introduction
+
+   This document proposes an authentication framework for email that
+   stores public keys in the DNS and digitally signs email on a domain
+   basis.  Separate documents discuss how this framework can be extended
+   to validate the delivery path of email as well as facilitate per-user
+   authentication.
+
+   The DomainKeys specification was a primary source from which the
+   DomainKeys Identified Mail [DKIM] specification has been derived.
+   The purpose in submitting this document is as an historical reference
+   for deployed implementations written prior to the DKIM specification.
+
+1.1.  Lack of Authentication Is Damaging Internet Email
+
+   Authentication of email is not currently widespread.  Not only is it
+   difficult to prove your own identity, it is impossible to prevent
+   others from abusing your identity.
+
+
+
+
+Delany                          Historic                        [Page 3]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   While most email exchanges do not intrinsically need authentication
+   beyond context, it is the rampant abuse of identity by "spammers",
+   "phishers", and their criminal ilk that makes proof necessary.  In
+   other words, authentication is as much about protection as proof.
+
+   Importantly, the inability to authenticate email effectively
+   delegates much of the control of the disposition of inbound email to
+   the sender, since senders can trivially assume any email address.
+   Creating email authentication is the first step to returning
+   dispositional control of email to the recipient.
+
+   For the purposes of this document, authentication is seen from a user
+   perspective, and is intended to answer the question "who sent this
+   email?" where "who" is the email address the recipient sees and "this
+   email" is the content that the recipient sees.
+
+1.2.  Digitally Signing Email Creates Credible Domain Authentication
+
+   DomainKeys combines public key cryptography and the DNS to provide
+   credible domain-level authentication for email.
+
+   When an email claims to originate from a certain domain, DomainKeys
+   provides a mechanism by which the recipient system can credibly
+   determine that the email did in fact originate from a person or
+   system authorized to send email for that domain.
+
+   The authentication provided by DomainKeys works in a number of
+   scenarios in which other authentication systems fail or create
+   complex operational requirements.  These include the following:
+
+      o forwarded email
+
+      o distributed sending systems
+
+      o authorized third-party sending
+
+   This base definition of DomainKeys is intended to primarily enable
+   domain-level authenticity.  Whether a given message is really sent by
+   the purported user within the domain is outside the scope of the base
+   definition.  Having said that, this specification includes the
+   possibility that some domains may wish to delegate fine-grained
+   authentication to individual users.
+
+1.3.  Public Keys in the DNS
+
+   DomainKeys differs from traditional hierarchical public key systems
+   in that it leverages the DNS for public key management, placing
+   complete and direct control of key generation and management with the
+
+
+
+Delany                          Historic                        [Page 4]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   owner of the domain.  That is, if you have control over the DNS for a
+   given domain, you have control over your DomainKeys for that domain.
+
+   The DNS is proposed as the initial mechanism for publishing public
+   keys.  DomainKeys is specifically designed to be extensible to other
+   key-fetching services as they become available.
+
+1.4.  Initial Deployment Is Likely at the Border MTA
+
+   For practical reasons, it is expected that initial implementations of
+   DomainKeys will be deployed on Mail Transfer Agents (MTAs) that
+   accept or relay email across administrative or organizational
+   boundaries.  There are numerous advantages to deployment at the
+   border MTA, including:
+
+      o  a reduction in the number of MTAs that have to be changed to
+         support an implementation of DomainKeys
+
+      o  a reduction in the number of MTAs involved in transmitting the
+         email between a signing system and a verifying system, thus
+         reducing the number of places that can make accidental changes
+         to the contents
+
+      o  removing the need to implement DomainKeys within an internal
+         email network.
+
+   However, there is no necessity to deploy DomainKeys at the border as
+   signing and verifying can effectively occur anywhere from the border
+   MTA right back to the Mail User Agent (MUA).  In particular, the best
+   place to sign an email for many domains is likely to be at the point
+   of SUBMISSION where the sender is often authenticated through SMTP
+   AUTH or other identifying mechanisms.
+
+1.5.  Conveying Verification Results to MUAs
+
+   It follows that testing the authenticity of an email results in some
+   action based on the results of the test.  Oftentimes, the action is
+   to notify the MUA in some way -- typically via a header line.
+
+   The "Domainkey-Status:" header is defined in this specification for
+   recording authentication results in the email.
+
+1.6.  Technical Minutiae Are Not Completely Covered
+
+   The intent of this specification is to communicate the fundamental
+   characteristics of DomainKeys for an implementor.  However, some
+   aspects are derived from the functionality of the openssl command
+   [OPENSSL] and, rather than duplicate that documentation, implementors
+
+
+
+Delany                          Historic                        [Page 5]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   are expected to understand the mechanics of the openssl command,
+   sufficient to complete the implementation.
+
+1.7.  Motivation
+
+   The motivation for DomainKeys is to define a simple, cheap, and
+   "sufficiently effective" mechanism by which domain owners can control
+   who has authority to send email using their domain.  To this end, the
+   designers of DomainKeys set out to build a framework that:
+
+      o  is transparent and compatible with the existing email
+         infrastructure
+
+      o  requires no new infrastructure
+
+      o  can be implemented independently of clients in order to reduce
+         deployment time
+
+      o  does not require the use of a central certificate authority
+         that might impose fees for certificates or introduce delays to
+         deployment
+
+      o  can be deployed incrementally
+
+   While we believe that DomainKeys meets these criteria, it is by no
+   means a perfect solution.  The current Internet imposes considerable
+   compromises on any similar scheme, and readers should be careful not
+   to misinterpret the information provided in this document to imply
+   that DomainKeys makes stronger credibility statements than it is able
+   to do.
+
+1.8.  Benefits of DomainKeys
+
+   As the reader will discover, DomainKeys is solely an authentication
+   system.  It is not a magic bullet for spam, nor is it an
+   authorization system, a reputation system, a certification system, or
+   a trust system.
+
+   However, a strong authentication system such as DomainKeys creates an
+   unimpeachable framework within which comprehensive authorization
+   systems, reputations systems, and their ilk can be developed.
+
+
+
+
+
+
+
+
+
+
+Delany                          Historic                        [Page 6]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+1.9.  Definitions
+
+   With reference to the following sample email:
+
+   Line   Data
+   Number Bytes               Content
+   ----   --- --------------------------------------------
+     01    46 From: "Joe SixPack" <joe@football.example.com>
+     02    40 To: "Suzie Q" <suzie@shopping.example.net>
+     03    25 Subject: Is dinner ready?
+     04    43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
+     05    40 Comment: This comment has a continuation
+     06    51   because this line begins with folding white space
+     07    60 Message-ID: <20030712040037.46341@football.example.com>
+     08    00
+     09    03 Hi.
+     10    00
+     11    37 We lost the game. Are you hungry yet?
+     12    00
+     13    04 Joe.
+     14    00
+     15    00
+
+   Line 01 is the first line of the email and the first line of the
+         headers.
+
+   Lines 05 and 06 constitute the "Comment:" header.
+
+   Line 06 is a continuation header line.
+
+   Line 07 is the last line of the headers.
+
+   Line 08 is the empty line that separates the header from the body.
+
+   Line 09 is the first line of the body.
+
+   Lines 10, 12, 14, and 15 are empty lines.
+
+   Line 13 is the last non-empty line of the email.
+
+   Line 15 is the last line of the body and the last line of the email.
+
+   Lines 01 to 15 constitute the complete email.
+
+   Line 01 is earlier than line 02, and line 02 is later than line 01.
+
+
+
+
+
+
+Delany                          Historic                        [Page 7]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+1.10.  Requirements Notation
+
+   This document occasionally uses terms that appear in capital letters.
+   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
+   NOT", and "MAY" appear capitalized, they are being used to indicate
+   particular requirements of this specification.  A discussion of the
+   meanings of these terms appears in [RFC2119].
+
+2.  DomainKeys Overview
+
+   Under DomainKeys, a domain owner generates one or more private/public
+   key pairs that will be used to sign messages originating from that
+   domain.  The domain owner places the public key in his domain
+   namespace (i.e., in a DNS record associated with that domain), and
+   makes the private key available to the outbound email system.  When
+   an email is submitted by an authorized user of that domain, the email
+   system uses the private key to digitally sign the email associated
+   with the sending domain.  The signature is added as a header to the
+   email, and the message is transferred to its recipients in the usual
+   way.
+
+   When a message is received with a DomainKey signature header, the
+   receiving system can verify the signature as follows:
+
+      1. Extract the signature and claimed sending domain from the
+         email.
+
+      2. Fetch the public key from the claimed sending domain namespace.
+
+      3. Use public key to determine whether the signature of the email
+         has been generated with the corresponding private key, and thus
+         whether the email was sent with the authority of the claimed
+         sending domain.
+
+   In the event that an email arrives without a signature or when the
+   signature verification fails, the receiving system retrieves the
+   policy of the claimed sending domain to ascertain the preferred
+   disposition of such email.
+
+   Armed with this information, the recipient system can apply local
+   policy based on the results of the signature test.
+
+3.  DomainKeys Detailed View
+
+   This section discusses the specifics of DomainKeys that are needed to
+   create interoperable implementations.  This section answers the
+   following questions:
+
+
+
+
+Delany                          Historic                        [Page 8]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+      Given an email, how is the sending domain determined?
+
+      How is the public key retrieved for a sending domain?
+
+      As email transits the email system, it can potentially go through
+      a number of changes.  Which parts of the email are included in the
+      signature and how are they protected from such transformations?
+
+      How is the signature represented in the email?
+
+      If a signature is not present, or a verification fails, how does
+      the recipient determine the policy intent of the sending domain?
+
+      Finally, on verifying the authenticity of an email, how is that
+      result conveyed to participating MUAs?
+
+   While there are many alternative design choices, most lead to
+   comparable functionality.  The overriding selection criteria used to
+   choose among the alternatives are as follows:
+
+      o  use deployed technology whenever possible
+
+      o  prefer ease of implementation
+
+      o  avoid trading risk for excessive flexibility or
+         interoperability
+
+      o  include basic flexibility
+
+   Adherence to these criteria implies that some existing email
+   implementations will require changes to participate in DomainKeys.
+   Ultimately, some hard choices need to be made regarding which
+   requirements are more important.
+
+3.1.  Determining the Sending Address of an Email
+
+   The goal of DomainKeys is to give the recipient confidence that the
+   email originated from the claimed sender.  As with much of Internet
+   email, agreement over what constitutes the "sender" is no easy
+   matter.  Forwarding systems and mailing lists add serious
+   complications to an overtly simple question.  From the point of view
+   of the recipient, the authenticity claim should be directed at the
+   domain most visible to the recipient.
+
+   In the first instance, the most visible address is clearly the RFC
+   2822 "From:" address [RFC2822].  Therefore, a conforming email MUST
+   contain a single "From:" header from which an email address with a
+   domain name can be extracted.
+
+
+
+Delany                          Historic                        [Page 9]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   A conforming email MAY contain a single RFC 2822 "Sender:" header
+   from which an email address with a domain name can be extracted.
+
+   If the email has a valid "From:" and a valid "Sender:" header, then
+   the signer MUST use the sending address in the "Sender:" header.
+
+   If the email has a valid "From:" and no "Sender:" header, then the
+   signer MUST use the first sending address in the "From:" header.
+
+   In all other cases, a signer MUST NOT sign the email.  Implementors
+   should note that an email with a "Sender:" header and no "From:"
+   header MUST NOT be signed.
+
+   The domain name in the sending address constitutes the "sending
+   domain".
+
+3.2.  Retrieving the Public Key Given the Sending Domain
+
+   To avoid namespace conflicts, it is proposed that the DNS namespace
+   "_domainkey." be reserved within the sending domain for storing
+   public keys, e.g., if the sending domain is example.net, then the
+   public keys for that domain are stored in the _domainkey.example.net
+   namespace.
+
+3.2.1.  Introducing "selectors"
+
+   To support multiple concurrent public keys per sending domain, the
+   DNS namespace is further subdivided with "selectors".  Selectors are
+   arbitrary names below the "_domainkey." namespace.  A selector value
+   and length MUST be legal in the DNS namespace and in email headers
+   with the additional provision that they cannot contain a semicolon.
+
+   Examples of namespaces using selectors are as follows:
+
+      "coolumbeach._domainkey.example.net"
+      "sebastopol._domainkey.example.net"
+      "reykjavik._domainkey.example.net"
+      "default._domainkey.example.net"
+
+   and
+
+      "2005.pao._domainkey.example.net"
+      "2005.sql._domainkey.example.net"
+      "2005.rhv._domainkey.example.net"
+
+   Periods are allowed in selectors and are to be treated as component
+   separators.  In the case of DNS queries, that means the period
+   defines subdomain boundaries.
+
+
+
+Delany                          Historic                       [Page 10]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   The number of public keys and corresponding selectors for each domain
+   is determined by the domain owner.  Many domain owners will be
+   satisfied with just one selector, whereas administratively
+   distributed organizations may choose to manage disparate selectors
+   and key pairs in different regions, or on different email servers.
+
+   Beyond administrative convenience, selectors make it possible to
+   seamlessly replace public keys on a routine basis.  If a domain
+   wishes to change from using a public key associated with selector
+   "2005" to a public key associated with selector "2006", it merely
+   makes sure that both public keys are advertised in the DNS
+   concurrently for the transition period during which email may be in
+   transit prior to verification.  At the start of the transition
+   period, the outbound email servers are configured to sign with the
+   "2006" private key.  At the end of the transition period, the "2005"
+   public key is removed from the DNS.
+
+   While some domains may wish to make selector values well known,
+   others will want to take care not to allocate selector names in a way
+   that allows harvesting of data by outside parties.  For example, if
+   per-user keys are issued, the domain owner will need to make the
+   decision as to whether to make this selector associated directly with
+   the user name or make it some unassociated random value, such as the
+   fingerprint of the public key.
+
+3.2.2.  Public Key Signing and Verification Algorithm
+
+   The default signature is an RSA signed SHA1 digest of the complete
+   email.
+
+   For ease of explanation, the openssl command is used throughout this
+   document to describe the mechanism by which keys and signatures are
+   managed.
+
+   One way to generate a 768-bit private key suitable for DomainKeys is
+   to use openssl like this:
+
+   $ openssl genrsa -out rsa.private 768
+
+
+
+
+
+
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 11]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   which results in the file rsa.private containing the key information
+   similar to this:
+
+   -----BEGIN RSA PRIVATE KEY-----
+   MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5
+   ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo
+   AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH
+   +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn
+   Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/
+   3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew
+   ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs
+   FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb
+   weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG
+   6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U=
+   -----END RSA PRIVATE KEY-----
+
+   Once a private key has been generated, the openssl command can be
+   used to sign an appropriately prepared email, like this:
+
+   $ openssl dgst -sign rsa.private -sha1 <input.file
+
+   which results in signature data similar to this when represented in
+   Base64 [BASE64] format:
+
+   aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz
+   msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl
+
+   How this signature is added to the email is discussed later in this
+   document.
+
+   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
+
+   which results in the file rsa.public containing the key information
+   similar to this:
+
+   -----BEGIN PUBLIC KEY-----
+   MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
+   MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
+   XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
+   -----END PUBLIC KEY-----
+
+   This public key data is placed in the DNS.
+
+
+
+
+
+
+Delany                          Historic                       [Page 12]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   With the signature, canonical email contents and public key, a
+   verifying system can test the validity of the signature.  The openssl
+   invocation to verify a signature looks like this:
+
+ $ openssl dgst -verify rsa.public -sha1 -signature sig.file <input.file
+
+3.2.3.  Public key Representation in the DNS
+
+   There is currently no standard method defined for storing public keys
+   in the DNS.  As an interim measure, the public key is stored as a TXT
+   record derived from a Privacy-Enhanced Mail (PEM) format [PEM], that
+   is, as a Base64 representation of a DER encoded key.  Here is an
+   example of a 768-bit RSA key in PEM form:
+
+   -----BEGIN PUBLIC KEY-----
+   MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
+   MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
+   XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
+   -----END PUBLIC KEY-----
+
+   To save scarce DNS packet space and aid extensibility, the PEM
+   wrapping MUST be removed and the remaining public key data along with
+   other attributes relevant to DomainKeys functionality are stored as
+   tag=value pairs separated by semicolons, for example, as in the
+   following:
+
+   brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
+
+   Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048
+   bits.  Signers MUST support at least one of the verifier supported
+   key sizes.
+
+   The current valid tags are as follows:
+
+      g = granularity of the key.  If present with a non-zero length
+          value, this value MUST exactly match the local part of the
+          sending address.  This tag is optional.
+
+          The intent of this tag is to constrain which sending address
+          can legitimately use this selector.  An email with a sending
+          address that does not match the value of this tag constitutes
+          a failed verification.
+
+      k = key type (rsa is the default).  Signers and verifiers MUST
+          support the 'rsa' key type.  This tag is optional.
+
+
+
+
+
+
+Delany                          Historic                       [Page 13]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+      n = Notes that may be of interest to a human.  No interpretation
+          is made by any program.  This tag is optional.
+
+      p = public key data, encoded as a Base64 string.  An empty value
+          means that this public key has been revoked.  This tag MUST be
+          present.
+
+      t = a set of flags that define boolean attributes.  Valid
+          attributes are as follows:
+
+          y = testing mode.  This domain is testing DomainKeys and
+              unverified email MUST NOT be treated differently from
+              verified email.  Recipient systems MAY wish to track
+              testing mode results to assist the sender.
+
+          This tag is optional.
+
+   (Syntax rules for the tag=value format are discussed in Appendix A.)
+
+   Keeping the size of the TXT record to a minimum is important as some
+   implementations of content and caching DNS servers are reported to
+   have problems supporting large TXT records.  In the example above,
+   the encoding generates a 182-byte TXT record.  That this encoding is
+   less than 512 bytes is of particular significance as it fits within a
+   single UDP response packet.  With careful selection of query values,
+   a TXT record can accommodate a 2048 bit key.
+
+   For the same size restriction reason, the "n" tag SHOULD be used
+   sparingly.  The most likely use of this tag is to convey a reason why
+   a public key might have been revoked.  In this case, set the "n" tag
+   to the explanation and remove the public key value from the "p" tag.
+
+3.2.4.  Key Sizes
+
+   Selecting appropriate key sizes is a trade-off between cost,
+   performance, and risk.  This specification does not define either
+   minimum or maximum key sizes -- that decision is a matter for each
+   domain owner.
+
+   Factors that should influence this decision include the following:
+
+      o  the practical constraint that a 2048-bit key is the largest key
+         that fits within a 512-byte DNS UDP response packet
+
+      o  larger keys impose higher CPU costs to verify and sign email
+
+      o  keys can be replaced on a regular basis; thus, their lifetime
+         can be relatively short
+
+
+
+Delany                          Historic                       [Page 14]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+      o  the security goals of this specification are modest compared to
+         typical goals of public key systems
+
+   In general, it is expected that most domain owners will use keys that
+   are no larger than 1024 bits.
+
+3.3.  Storing the Signature in the Email Header
+
+   The signature of the email is stored in the "DomainKey-Signature:"
+   header.  This header contains all of the signature and key-fetching
+   data.
+
+   When generating the signed email, the "DomainKey-Signature:" header
+   MUST precede the original email headers presented to the signature
+   algorithm.
+
+   The "DomainKey-Signature:" header is not included in the signature
+   calculation.
+
+   For extensibility, the "DomainKey-Signature:" header contains
+   tag=value pairs separated by semicolons, for example, as in the
+   following:
+
+   DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
+     q=dns; c=simple
+
+   The current valid tags are as follows:
+
+      a = The algorithm used to generate the signature.  The default is
+          "rsa-sha1", an RSA signed SHA1 digest.  Signers and verifiers
+          MUST support "rsa-sha1".
+
+      b = The signature data, encoded as a Base64 string.  This tag MUST
+          be present.
+
+          Whitespace is ignored in this value and MUST be removed when
+          reassembling the original signature.  This is another way of
+          saying that the signing process can safely insert folding
+          whitespace in this value to conform to line-length limits.
+
+      c = Canonicalization algorithm.  The method by which the headers
+          and content are prepared for presentation to the signing
+          algorithm.  This tag MUST be present.  Verifiers MUST support
+          "simple" and "nofws".  Signers MUST support at least one of
+          the verifier-supported algorithms.
+
+
+
+
+
+
+Delany                          Historic                       [Page 15]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+      d = The domain name of the signing domain.  This tag MUST be
+          present.  In conjunction with the selector tag, this domain
+          forms the basis of the public key query.  The value in this
+          tag MUST match the domain of the sending email address or MUST
+          be one of the parent domains of the sending email address.
+          Domain name comparison is case insensitive.
+
+             The matching process for this tag is called subdomain
+             matching, as the sending email address must be the domain
+             or subdomain of the value.
+
+      h = A colon-separated list of header field names that identify the
+          headers presented to the signing algorithm.  If present, the
+          value MUST contain the complete list of headers in the order
+          presented to the signing algorithm.
+
+          If present, this tag MUST include the header that was used to
+          identify the sending domain, i.e., the "From:" or "Sender:"
+          header; thus, this tag can never contain an empty value.
+
+          If this tag is not present, all headers subsequent to the
+          signature header are included in the order found in the email.
+
+          A verifier MUST support this tag.  A signer MAY support this
+          tag.  If a signer generates this tag, it MUST include all
+          email headers in the original email, as a verifier MAY remove
+          or render suspicious, lines that are not included in the
+          signature.
+
+          In the presence of duplicate headers, a signer may include
+          duplicate entries in the list of headers in this tag.  If a
+          header is included in this list, a verifier must include all
+          occurrences of that header, subsequent to the "DomainKey-
+          Signature:" header in the verification.
+
+          If a header identified in this list is not found after the
+          "DomainKey-Signature:" header in the verification process, a
+          verifier may "look" for a matching header prior to the
+          "DomainKey-Signature:" header; however, signers should not
+          rely on this as early experience suggests that most verifiers
+          do not try to "look" back before the "DomainKey-Signature:"
+          header.
+
+          Whitespace is ignored in this value and header comparisons are
+          case insensitive.
+
+
+
+
+
+
+Delany                          Historic                       [Page 16]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+      q = The query method used to retrieve the public key.  This tag
+          MUST be present.  Currently, the only valid value is "dns",
+          which defines the DNS lookup algorithm described in this
+          document.  Verifiers and signers MUST support "dns".
+
+      s = The selector used to form the query for the public key.  This
+          tag MUST be present.  In the DNS query type, this value is
+          prepended to the "_domainkey." namespace of the sending
+          domain.
+
+   (Syntax rules for the tag=value format are discussed in Appendix A.)
+
+   Here is an example of a signature header spread across multiple
+   continuation lines:
+
+      DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
+       c=simple; q=dns;
+       b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
+         VoG4ZHRNiYzR;
+
+   Extreme care must be taken to ensure that any new tags added to this
+   header are defined and used solely for the purpose of fetching and
+   verifying the signature.  Any semantics beyond verification cannot be
+   trusted, as this header is not protected by the signature.
+
+   If additional semantics not pertaining directly to signature
+   verification are required, they must only be added as subsequent
+   headers protected by the signature.  Semantic additions might include
+   audit information describing the initial submission.
+
+3.4.  Preparation of Email for Transit and Signing
+
+   The fundamental purpose of a cryptographic signature is to ensure
+   that the signed content matches the contents presented for
+   verification.  However, unlike just about every other Internet
+   protocol, the email content is routinely modified as it enters and
+   transits the email system.
+
+   Fortunately most of the modifications typically made to email can be
+   predicted and consequently accounted for when signing and verifying.
+
+   To maximize the chance of a successful verification, submitted email
+   should be prepared for transport prior to signing, and the data
+   presented to the signing algorithm is canonicalized to exclude the
+   most common and minor changes made to email.
+
+
+
+
+
+
+Delany                          Historic                       [Page 17]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+3.4.1.  Preparation for Transit
+
+   The SMTP protocol defines a number of potential limitations to email
+   transport, particularly pertaining to line lengths and 8-bit content.
+
+   While the editor has observed that most modern SMTP implementations
+   accept 8-bit email and long lines, some implementations still do not.
+   Consequently, a DomainKeys implementation SHOULD prepare an email to
+   be suitable for the lowest common denominator of SMTP prior to
+   presenting the email for signing.
+
+3.4.2.  Canonicalization for Signing
+
+   DomainKeys is initially expected to be deployed at, or close to, the
+   email borders of an organization rather than in MUAs or SUBMISSION
+   servers.  In other words, the signing and verifying algorithms
+   normally apply after an email has been packaged, transmogrified, and
+   generally prepared for transmission across the Internet via SMTP and,
+   thus the likelihood of the email being subsequently modified is
+   reduced.
+
+   Nonetheless, empirical evidence suggests that some mail servers and
+   relay systems modify email in transit, potentially invalidating a
+   signature.
+
+   There are two competing perspectives on such modifications.  For most
+   senders, mild modification of email is immaterial to the
+   authentication status of the email.  For such senders, a
+   canonicalization algorithm that survives modest in-transit
+   modification is preferred.
+
+   For other senders however, any modification of the email - however
+   minor -- results in a desire for the authentication to fail.  In
+   other words, such senders do not want a modified email to be seen as
+   being authorized by them.  These senders prefer a canonicalization
+   algorithm that does not tolerate in-transit modification of the
+   signed email.
+
+   To satisfy both requirements, two canonicalization algorithms are
+   defined.  A "simple" algorithm that tolerates almost no modification
+   and a "nofws" algorithm that tolerates common modifications as
+   whitespace replacement and header line rewrapping.
+
+   A sender may choose either algorithm when signing an email.  A
+   verifier MUST be able to process email using either algorithm.
+
+   Either algorithm can be used in conjunction with the "h" tag in the
+   "DomainKey-Signature:" header.
+
+
+
+Delany                          Historic                       [Page 18]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   Canonicalization simply prepares the email for the signing or
+   verification algorithm.  It does not change the transmitted data in
+   any way.
+
+3.4.2.1.  The "simple" Canonicalization Algorithm
+
+   o  Each line of the email is presented to the signing algorithm in
+      the order it occurs in the complete email, from the first line of
+      the headers to the last line of the body.
+
+   o  If the "h" tag is used, only those header lines (and their
+      continuation lines if any) added to the "h" tag list are included.
+
+   o  The "h" tag only constrains header lines.  It has no bearing on
+      body lines, which are always included.
+
+   o  Remove any local line terminator.
+
+   o  Append CRLF to the resulting line.
+
+   o  All trailing empty lines are ignored.  An empty line is a line of
+      zero length after removal of the local line terminator.
+
+      If the body consists entirely of empty lines, then the header/body
+      line is similarly ignored.
+
+3.4.2.2.  The "nofws" Canonicalization Algorithm
+
+   The "No Folding Whitespace" algorithm (nofws) is more complicated
+   than the "simple" algorithm for two reasons; folding whitespace is
+   removed from all lines and header continuation lines are unwrapped.
+
+      o  Each line of the email is presented to the signing algorithm in
+         the order it occurs in the complete email, from the first line
+         of the headers to the last line of the body.
+
+      o  Header continuation lines are unwrapped so that header lines
+         are processed as a single line.
+
+      o  If the "h" tag is used, only those header lines (and their
+         continuation lines if any) added to the "h" tag list are
+         included.
+
+      o  The "h" tag only constrains header lines.  It has no bearing on
+         body lines, which are always included.
+
+
+
+
+
+
+Delany                          Historic                       [Page 19]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+      o  For each line in the email, remove all folding whitespace
+         characters.  Folding whitespace is defined in RFC 2822 as being
+         the decimal ASCII values 9 (HTAB), 10 (NL), 13 (CR), and 32
+         (SP).
+
+      o  Append CRLF to the resulting line.
+
+      o  Trailing empty lines are ignored.  An empty line is a line of
+         zero length after removal of the local line terminator.  Note
+         that the test for an empty line occurs after removing all
+         folding whitespace characters.
+
+         If the body consists entirely of empty lines, then the
+         header/body line is similarly ignored.
+
+3.5.  The Signing Process
+
+   The previous sections defined the various components and mechanisms
+   needed to sign an email.  This section brings those together to
+   define the complete process of signing an email.
+
+   A signer MUST only sign email from submissions that are authorized to
+   use the sending address.
+
+   Once authorization of the submission has been determined, the signing
+   process consists of the following steps:
+
+      o  identifying the sending domain
+
+      o  determining if an email should be signed
+
+      o  selecting a private key and corresponding selector information
+
+      o  calculating the signature value
+
+      o  prepending the "DomainKey-Signature:" header
+
+   If an email cannot be signed for some reason, it is a local policy
+   decision as to what to do with that email.
+
+3.5.1.  Identifying the Sending Domain
+
+   The sending domain is determined by finding the email address in the
+   "Sender:" header, or, if the "Sender:" header is not present, the
+   first email address of the "From:" header is used to determine the
+   sending domain.
+
+
+
+
+
+Delany                          Historic                       [Page 20]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   If the email has an invalid "From:" or an invalid "Sender:" header,
+   it MUST NOT be signed.
+
+   If the signer adds the "h" tag to the "DomainKey-Signature:" header,
+   that tag MUST include the header that was used to determine the
+   sending domain.
+
+3.5.2.  Determining Whether an Email Should Be Signed
+
+   A signer can obviously only sign email for domains for which it has a
+   private key and the necessary knowledge of the corresponding public
+   key and selector information, however there are a number of other
+   reasons why a signer may choose not to sign an email.
+
+   A signer MUST NOT sign an email if the email submission is not
+   authorized to use the sending domain.
+
+   A signer MUST NOT sign an email that already contains a "DomainKey-
+   Signature:" header unless a "Sender:" header has been added that was
+   not included in the original signature.  The most obvious case where
+   this occurs is with mailing lists.
+
+   A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.
+
+3.5.3.  Selecting a Private Key and Corresponding Selector Information
+
+   This specification does not define the basis by which a signer should
+   choose which private key and selector information to use.  Currently,
+   all selectors are equal as far as this specification is concerned, so
+   the decision should largely be a matter of administrative
+   convenience.
+
+3.5.4.  Calculating the Signature Value
+
+   The signer MUST use one of the defined canonicalization algorithms to
+   present the email to the signing algorithm.  Canonicalization is only
+   used to prepare the email for signing.  It does not affect the
+   transmitted email in any way.
+
+   To avoid possible ambiguity, a signing server may choose to remove
+   any pre-existing "DomainKey-Status:" headers from the email prior to
+   preparation for signing and transmission.
+
+3.5.5.  Prepending the "DomainKey-Signature:" Header
+
+   The final step in the signing process is that the signer MUST prepend
+   the "DomainKey-Signature:" header prior to continuing with the
+   process of transmitting the email.
+
+
+
+Delany                          Historic                       [Page 21]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+3.6.  Policy Statement of Sending Domain
+
+   While the disposition of inbound email is ultimately a matter for the
+   receiving system, the introduction of authentication in email creates
+   a need for the sender domain to indicate their signing policy and
+   preferred disposition of unsigned email, in particular, whether a
+   domain is participating in DomainKeys, whether it is testing, and
+   whether it signs all outbound email.
+
+   The sending domain policy is very simple and is expressed in the
+   _domainkey TXT record in the DNS of the sending domain.  For example,
+   in the example.com domain, the record is called
+   _domainkey.example.com.
+
+   The contents of this TXT record are stored as tag=value pairs
+   separated by semicolons, for example, as in the following:
+
+   _domainkey   IN TXT "t=y; o=-; n=notes; r=emailAddress"
+
+   All tags are optional.  The current valid tags are as follows:
+
+      n = Notes that may be of interest to a human.  No interpretation
+          is made by any program.
+
+      o = Outbound Signing policy ("-" means that this domain signs all
+          email; "~" is the default and means that this domain may sign
+          some email with DomainKeys).
+
+      r = A reporting email address.  If present, this defines the email
+          address where invalid verification results are reported.  This
+          tag is primarily intended for early implementers -- the
+          content and frequency of the reports will be defined in a
+          separate document.
+
+      t = a set of flags that define boolean attributes.  Valid
+          attributes are as follows:
+
+          y = testing mode.  This domain is testing DomainKeys, and
+              unverified email MUST NOT be treated differently from
+              verified email.  Recipient systems MAY wish to track
+              testing mode results to assist the sender).
+
+          Note that testing mode cannot be turned off by this tag;
+          thus, policy cannot revert the testing mode setting of a
+          Selector.
+
+          This tag is optional.
+
+
+
+
+Delany                          Historic                       [Page 22]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   (Syntax rules for the tag=value format are discussed in Appendix A.)
+
+   Recipient systems SHOULD only retrieve this policy TXT record to
+   determine policy when an email fails to verify or does not include a
+   signature.  Recipient systems SHOULD not retrieve this policy TXT
+   record for email that successfully verifies.  Note that "testing
+   mode" SHOULD also be in the Selector TXT record if the domain owner
+   is running a DomainKeys test.
+
+   If the policy TXT record does not exist, recipient systems MUST
+   assume the default values.
+
+   There is an important implication when a domain states that it signs
+   all email with the "o=-" setting, namely that the sending domain
+   prefers that the recipient system treat unsigned mail with a great
+   deal of suspicion.  Such suspicion could reasonably extend to
+   rejecting such email.  A verifying system MAY reject unverified email
+   if a domain policy indicates that it signs all email.
+
+   Of course, nothing compels a recipient MTA to abide by the policy of
+   the sender.  In fact, during the trial, a sending domain would want
+   to be very certain about setting this policy, as processing by
+   recipient MTAs may be unpredictable.  Nonetheless, a domain that
+   states that it signs all email MUST expect that unverified email may
+   be rejected by some receiving MTAs.
+
+3.7.  The Verification Process
+
+   There is no defined or recommended limit on the lifetime of a
+   selector and corresponding public key; however, it is recommended
+   that verification occur in a timely manner with the most timely place
+   being during acceptance or local delivery by the MTA.
+
+   Verifying a signature consists of the following three steps:
+
+      o  extract signature information from the headers
+
+      o  retrieve the public key based on the signature information
+
+      o  check that the signature verifies against the contents
+
+   In the event that any of these steps fails, the sending domain policy
+   is ascertained to assist in applying local policy.
+
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 23]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+3.7.1.  Presumption that Headers Are Not Reordered
+
+   Indications from deployment of previous versions of this
+   specification suggest that the canonicalization algorithms in
+   conjunction with the "h" tag in the "DomainKey-Signature:" header
+   allows most email to cryptographically survive intact between signing
+   and verifying.
+
+   The one assumption that most of the early deployments make is that
+   the headers included in the signature are not reordered prior to
+   verification.
+
+   While nothing in this specification precludes a verifier from
+   "looking" for a header that may have been reordered, including being
+   moved to a position prior to the "DomainKey-Signature:" header, such
+   reordered email is unlikely to be successfully verified by most
+   implementations.
+
+   A second consequence of this assumption -- particularly in the
+   presence of multiple "DomainKey-Signature:" headers -- is that the
+   first "DomainKey-Signature:" header in the email was the last
+   signature added to the email and thus is the one to be verified.
+
+3.7.2.  Verification Should Render a Binary Result
+
+   While the symptoms of a failed verification are obvious -- the
+   signature doesn't verify -- establishing the exact cause can be more
+   difficult.  If a selector cannot be found, is that because the
+   selector has been removed, or was the value changed somehow in
+   transit? If the signature line is missing, is that because it was
+   never there, or was it removed by an overzealous filter?
+
+   For diagnostic purposes, the exact reason why the verification fails
+   SHOULD be recorded; however, in terms of presentation to the end
+   user, the result SHOULD be presented as a simple binary result:
+   either the email is verified or it is not.  If the email cannot be
+   verified, then it SHOULD be rendered the same as all unverified email
+   regardless of whether or not it looks like it was signed.
+
+3.7.3.  Selecting the Most Appropriate "DomainKey-Signature:" Header
+
+   In most cases, a signed email is expected to have just one signature
+   -- that is, one "DomainKey-Signature:" header.  However, it is
+   entirely possible that an email can contain multiple signatures.  In
+   such cases, a verifier MUST find the most appropriate signature to
+   use and SHOULD ignore all other signatures.
+
+
+
+
+
+Delany                          Historic                       [Page 24]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   The process of finding the most appropriate signature consists of the
+   following "best match" rules.  The rules are to be evaluated in
+   order.
+
+      1. Selecting the sending domain
+
+         If the email contains a "Sender:" header, the sending domain is
+         extracted from the "Sender:" address.  If this extraction
+         fails, the email SHALL fail verification.
+
+         If no "Sender:" header is present, the sending domain is
+         extracted from the first address of the "From:" header.  If
+         this extraction fails, the email SHALL fail verification.
+
+      2. Domain matching
+
+         A signature can only match if the sending domain matches the
+         "d" tag domain -- according to the "d" tag subdomain matching
+         rules.
+
+      3. "h" tag matching
+
+         If the signature contains the "h" tag list of headers, that
+         list must include the header used to extract the sending domain
+         in rule 1, above.
+
+      4. Most secure signing algorithm
+
+         While it is not yet the case, in the event that additional
+         algorithms are added to this specification, a verifier MUST use
+         the signature that contains the most secure algorithm as
+         defined by the future specification.  For current
+         implementations, that means verifiers MUST ignore signatures
+         that are coded with an unrecognized signing algorithm.
+
+      5. Earlier signatures are preferred
+
+         If multiple signatures are equal as far as these rules apply,
+         the signature from the earlier header MUST be used in
+         preference to later signature headers.
+
+   Implementors MUST meticulously validate the format and values in the
+   "DomainKey-Signature:" header; any inconsistency or unexpected values
+   MUST result in ignoring that header.  Being "liberal in what you
+   accept" is definitely a bad strategy in this security context.
+
+
+
+
+
+
+Delany                          Historic                       [Page 25]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   In all cases, if a verification fails, the "DomainKey-Status:" header
+   SHOULD be generated and include a message to help explain the reason
+   for failure.
+
+3.7.4.  Retrieve the Public Key Based on the Signature Information
+
+   The public key is needed to complete the verification process.  The
+   process of retrieving the public key depends on the query type as
+   defined by the "q" tag in the "DomainKey-Signature:" header line.
+   Obviously, a public key should only be retrieved if the process of
+   extracting the signature information is completely successful.
+
+   Currently, the only valid query type is "dns".  The public key
+   retrieval process for this type is as follows:
+
+      1. Using the selector name defined by the "s" tag, the
+         "_domainkey" namespace and the domain name defined by the "d"
+         tag, construct and issue the DNS TXT record query string.
+
+         For example, if s=brisbane and d=example.net, the query string
+         is "brisbane._domainkey.example.net".
+
+      2. If the query for the public key fails to respond, the verifier
+         SHOULD defer acceptance of this email (normally this will be
+         achieved with a 4XX SMTP response code).
+
+      3. If the query for the public key fails because the corresponding
+         data does not exist, the verifier MUST treat the email as
+         unverified.
+
+      4. If the result returned from the query does not adhere to the
+         format defined in this specification, the verifier MUST treat
+         the email as unverified.
+
+      5. If the public key data is not suitable for use with the
+         algorithm type defined by the "a" tag in the "DomainKey-
+         Signature:" header, the verifier MUST treat the email as
+         unverified.
+
+   Implementors MUST meticulously validate the format and values
+   returned by the public key query.  Any inconsistency or unexpected
+   values MUST result in an unverified email.  Being "liberal in what
+   you accept" is definitely a bad strategy in this security context.
+
+   Latency critical implementations may wish to initiate the public key
+   query in parallel with calculating the SHA-1 hash, as the public key
+   is not needed until the final RSA is calculated.
+
+
+
+
+Delany                          Historic                       [Page 26]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+3.7.5.  Verify the Signature
+
+   Armed with the signature information from the "DomainKey-Signature:"
+   header and the public key information returned by the query, the
+   signature of the email can now be verified.
+
+   The canonicalization algorithm defined by the "c" tag in the
+   "DomainKey-Signature:" header defines how the data is prepared for
+   the verification algorithm, and the "a" tag in the same header
+   defines which verification algorithm to use.
+
+3.7.6.  Retrieving Sending Domain Policy
+
+   In the event that an email fails to verify, the policy of the sending
+   domain MUST be consulted.  For now, that means consulting the
+   _domainkey TXT record in the DNS of the domain in the sending domain
+   as defined in Section 3.5.1.  For example, if example.net is the
+   sending domain the TXT query is:
+
+      _domainkey.example.net
+
+   A verifier SHOULD consider the sending domain policy statement and
+   act accordingly.  The range of possibilities is up to the receiver,
+   but it MAY include rejecting the email.
+
+3.7.7.  Applying Local Policy
+
+   After all verification processes are complete, the recipient system
+   has authentication information that can help it decide what to do
+   with the email.
+
+   It is beyond the scope of this specification to describe what actions
+   a recipient system should take, but an authenticated email presents
+   an opportunity to a receiving system that unauthenticated email
+   cannot.  Specifically, an authenticated email creates a predictable
+   identifier by which other decisions can reliably be managed, such as
+   trust and reputation.
+
+   Conversely, unauthenticated email lacks a reliable identifier that
+   can be used to assign trust and reputation.  It is not unreasonable
+   to treat unauthenticated email as lacking any trust and having no
+   positive reputation.
+
+3.8.  Conveying Verification Results to MUAs
+
+   Apart from the application of automated policy, the result of a
+   signature verification should be conveyed to the user reading the
+   email.
+
+
+
+Delany                          Historic                       [Page 27]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   Most email clients can be configured to recognize specific headers
+   and apply simple rules, e.g., filing into a particular folder.  Since
+   DomainKey signatures are expected to be initially verified at the
+   border MTA, the results of the verification need to be conveyed to
+   the email client.  This is done with the "DomainKey-Status:" header
+   line prepended to the email.
+
+   The "DomainKey-Status:" header starts with a string that indicate the
+   result of the verification.  Valid values are as follows:
+
+   "good"         - the signature was verified at the time of testing
+   "bad"          - the signature failed the verification
+   "no key"       - the public key query failed as the key does not
+                    exist
+   "revoked"      - the public key query failed as the key has been
+                    revoked
+   "no signature" - this email has no "DomainKey-Signature:" header
+   "bad format"   - the signature or the public key contains unexpected
+                    data
+   "non-participant" - this sending domain has indicated that it does
+                       not participate in DomainKeys
+
+   Verifiers may append additional data that expands on the reason for
+   the particular status value.
+
+   A client SHOULD just look for "good" and assume that all other values
+   imply that the verification could not be performed for some reason.
+   Policy action as a consequence of this header is entirely a local
+   matter.
+
+   Here are some examples:
+
+      DomainKey-Status: good
+      DomainKey-Status: bad format
+
+   Although it is expected that MTAs will be DomainKey aware before
+   MUAs, it is nonetheless possible that a DomainKey-aware MUA can be
+   fooled by a spoofed "DomainKey-Status:" header that passes through a
+   non-DomainKey-aware MTA.
+
+   If this is perceived to be a serious problem, then it may make sense
+   to preclude the "good" value and only have values that effectively
+   demote the email as far as the UA is concerned.  That way successful
+   spoofing attempts can only serve to demote themselves.
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 28]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+4.  Example of Use
+
+   This section shows the complete flow of an email from submission to
+   final delivery, demonstrating how the various components fit
+   together.
+
+4.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.
+
+4.2.  The Email Is Signed
+
+   This email is signed by the football.example.com outbound email
+   server and now looks like this:
+
+   DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
+     c=simple; q=dns;
+     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
+       VoG4ZHRNiYzR;
+   Received: from dsl-10.2.3.4.football.example.com  [10.2.3.4]
+        by submitserver.football.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.
+
+   The signing email server requires access to the private key
+   associated with the "brisbane" selector to generate this signature.
+   Distribution and management of private keys are outside the scope of
+   this document.
+
+
+
+Delany                          Historic                       [Page 29]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+4.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 "football.example.com"
+   extracted from the "From:" header and the selector "brisbane" from
+   the "DomainKey-Signature:" header to form the DNS TXT query for:
+
+      brisbane._domainkey.football.example.com
+
+   Since there is no "h" tag in the "DomainKey-Signature:" header,
+   signature verification starts with the line following the
+   "DomainKey-Signature:" line.  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 the "DomainKey-Status:" header line.  After successful
+   verification, the email looks like this:
+
+   DomainKey-Status: good
+    from=joe@football.example.com; domainkeys=pass
+   Received: from mout23.brisbane.football.example.com (192.168.1.1)
+             by shopping.example.net with SMTP;
+             Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
+   DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
+    c=simple; q=dns;
+    b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
+      VoG4ZHRNiYzR;
+   Received: from dsl-10.2.3.4.network.example.com  [10.2.3.4]
+        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.
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 30]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+5.  Association with a Certificate Authority
+
+   A fundamental aspect of DomainKeys is that public keys are generated
+   and advertised by each domain at no additional cost.  This
+   accessibility markedly differs from traditional Public Key
+   Infrastructures where there is typically a Certificate Authority (CA)
+   who validates an applicant and issues a signed certificate --
+   containing their public key -- often for a recurring fee.
+
+   While CAs do impose costs, they also have the potential to provide
+   additional value as part of their certification process.  Consider
+   financial institutions, public utilities, law enforcement agencies,
+   and the like.  In many cases, such entities justifiably need to
+   discriminate themselves above and beyond the authentication that
+   DomainKeys offers.
+
+   Creating a link between DomainKeys and CA-issued certificates has the
+   potential to access additional authentication mechanisms that are
+   more authoritative than domain-owner-issued authentication.  It is
+   well beyond the scope of this specification to describe such
+   authorities apart from defining how the linkage could be achieved
+   with the "DomainKey-X509:" header.
+
+5.1.  The "DomainKey-X509:" Header
+
+   The "DomainKey-X509:" header provides a link between the public key
+   used to sign the email and the certificate issued by a CA.
+
+   The exact content, syntax, and semantics of this header are yet to be
+   resolved.  One possibility is that this header contains an encoding
+   of the certificate issued by a CA.  Another possibility is that this
+   header contains a URL that points to a certificate issued by a CA.
+
+   In either case, this header can only be consulted if the signature
+   verifies and MUST be part of the content signed by the corresponding
+   "DomainKey-Signature:" header.  Furthermore, it is likely that MUAs
+   rather than MTAs will confirm that the link to the CA-issued
+   certificate is valid.  In part, this is because many MUAs already
+   have built-in capabilities as a consequence of Secure/Multipurpose
+   Internet Mail Extensions (S/MIME) [SMIME] and Secure Socket Layer
+   (SSL) [SSL] support.
+
+   The proof of linkage is made by testing that the public key in the
+   certificate matches the public key used to sign the email.
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 31]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   An example of an email containing the "DomainKey-X509:" header is:
+
+      DomainKey-Signature: a=rsa-sha1; s=statements;
+        d=largebank.example.com; c=simple; q=dns;
+        b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
+          VoG4ZHRNiYzR;
+      DomainKey-X509: https://ca.example.net/largebank.example.com
+      From: "Large Bank" <statements@largebank.example.com>
+      To: "Suzie Q" <suzie@shopping.example.net>
+      Subject: Statement for Account: 1234-5678
+      ...
+
+   The format of the retrieved value from the URL is not yet defined,
+   nor is the determination of valid CAs.
+
+   The whole matter of linkage to CA-issued certificates is one aspect
+   of DomainKeys that needs to be resolved with relevant CA's and
+   certificate-issuing entities.  The primary point is that a link is
+   possible to a higher authority.
+
+6.  Topics for Discussion
+
+6.1.  The Benefits of Selectors
+
+   Selectors are at the heart of the flexibility of DomainKeys.  A
+   domain administrator is free to use a single DomainKey for all
+   outbound mail.  Alternatively, the domain administrator may use many
+   DomainKeys differentiated by selector and assign each key to
+   different servers.
+
+   For example, a large outbound email farm might have a unique
+   DomainKey for each server, and thus their DNS will advertise
+   potentially hundreds of keys via their unique selectors.
+
+   Another example is a corporate email administrator who might generate
+   a separate DomainKey for each regional office email server.
+
+   In essence, selectors allow a domain owner to distribute authority to
+   send on behalf of that domain.  Combined with the ability to revoke
+   by removal or Time to Live (TTL) expiration, a domain owner has
+   coarse-grained control over the duration of the distributed
+   authority.
+
+   Selectors are particularly useful for domain owners who want to
+   contract a third-party mailing system to send a particular set of
+   mail.  The domain owner can generate a special key pair and selector
+   just for this mail-out.  The domain owner has to provide the private
+   key and selector to the third party for the life of the mail-out.
+
+
+
+Delany                          Historic                       [Page 32]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   However, as soon as the mail-out is completely delivered, the domain
+   owner can revoke the public key by the simple expedient of removing
+   the entry from the DNS.
+
+6.2.  Canonicalization of Email
+
+   It is an unfortunate fact that some email software routinely (and
+   often unnecessarily) transforms email as it transits through the
+   network.  Such transformations conflict with the fundamental purpose
+   of cryptographic signatures - to detect modifications.
+
+   While two canonicalization algorithms are defined in this
+   specification, the primary goal of "nofws" is to provide a transition
+   path to "simple".  With a mixture of "simple" and "nofws" email, a
+   receiver can determine which systems are modifying email in ways that
+   cause the signature to fail and thus provide feedback to the
+   modifying system.
+
+6.3.  Mailing Lists
+
+   Integrating existing Mailing List Managers (MLMs) into the DomainKeys
+   authentication system is a complicated area, as the behavior of MLMs
+   is highly variable.  Essentially, there are two types of MLMs under
+   consideration: those that modify email to such an extent that
+   verification of the original content is not possible, and those that
+   make minimal or no modifications to an email.
+
+   MLMs that modify email in a way that causes verification to fail MUST
+   prepend a "Sender:" header and SHOULD prepend a "List-ID:"  header
+   prior to signing for distribution to list recipients.
+
+   A participating SUBMISSION server can deduce the need to re-sign such
+   an email by the presence of a "Sender:" or "List-ID:" header from an
+   authorized submission.
+
+   MLMs that do not modify email in a way that causes verification to
+   fail MAY perform the same actions as a modifying MLM.
+
+6.4.  Roving Users
+
+   One scenario that presents a particular problem with any form of
+   email authentication, including DomainKeys, is the roving user: a
+   user who is obliged to use a third-party SUBMISSION service when
+   unable to connect to the user's own SUBMISSION service.  The classic
+   example cited is a traveling salesperson being redirected to a hotel
+   email server to send email.
+
+
+
+
+
+Delany                          Historic                       [Page 33]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   As far as DomainKeys is concerned, email of this nature clearly
+   originates from an email server that does not have authority to send
+   on behalf of the domain of the salesperson and is therefore
+   indistinguishable from a forgery.  While DomainKeys does not
+   prescribe any specific action for such email, it is likely that over
+   time, such email will be treated as second-class email.
+
+   The typical solution offered to roving users is to submit email via
+   an authorized server for their domain -- perhaps via a Virtual
+   Private Network (VPN) or a web interface or even SMTP AUTH back to a
+   SUBMISSION server.
+
+   While these are perfectly acceptable solutions for many, they are not
+   necessarily solutions that are available or possible for all such
+   users.
+
+   One possible way to address the needs of this contingent of
+   potentially disenfranchised users is for the domain to issue per-user
+   DomainKeys.  Per-user DomainKeys are identified by a non-empty "g"
+   tag value in the corresponding DNS record.
+
+7.  Security Considerations
+
+7.1.  DNS
+
+   DomainKeys is primarily a security mechanism.  Its core purpose is to
+   make claims about email authentication in a credible way.  However,
+   DomainKeys, like virtually all Internet applications, relies on the
+   DNS, which has well-known security flaws [RFC3833].
+
+7.1.1.  The DNS Is Not Currently Secure
+
+   While the DNS is currently insecure, it is expected that the security
+   problems should and will be solved by DNS Security (DNSSEC) [DNSSEC],
+   and all users of the DNS will reap the benefit of that work.
+
+   Secondly, the types of DNS attacks relevant to DomainKeys are very
+   costly and are far less rewarding than DNS attacks on other Internet
+   applications.
+
+   To systematically thwart the intent of DomainKeys, an attacker must
+   conduct a very costly and very extensive attack on many parts of the
+   DNS over an extended period.  No one knows for sure how attackers
+   will respond; however, the cost/benefit of conducting prolonged DNS
+   attacks of this nature is expected to be uneconomical.
+
+   Finally, DomainKeys is only intended as a "sufficient" method of
+   proving authenticity.  It is not intended to provide strong
+
+
+
+Delany                          Historic                       [Page 34]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   cryptographic proof about authorship or contents.  Other technologies
+   such as GnuPG and S/MIME address those requirements.
+
+7.1.2.  DomainKeys Creates Additional DNS Load
+
+   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 sending domain policy.  Widespread
+   deployment of DomainKeys will result in a significant increase in DNS
+   queries to the claimed sending domain.  In the case of forgeries on a
+   large scale, DNS servers could see a substantial increase in queries.
+
+7.2.  Key Management
+
+   All public key systems require management of key pairs.  Private keys
+   in particular need to be securely distributed to each signing mail
+   server and protected on those servers.  For those familiar with SSL,
+   the key management issues are similar to those of managing SSL
+   certificates.  Poor key management may result in unauthorized access
+   to private keys, which in essence gives unauthorized access to your
+   identity.
+
+7.3.  Implementation Risks
+
+   It is well recognized in cryptographic circles that many security
+   failures are caused by poor implementations rather than poor
+   algorithms.  For example, early SSL implementations were vulnerable
+   because the implementors used predictable "random numbers".
+
+   While some MTA software already supports various cryptographic
+   techniques, such as TLS, many do not.  This proposal introduces
+   cryptographic requirements into MTA software that implies a much
+   higher duty of care to manage the increased risk.
+
+   There are numerous articles, books, courses, and consultants that
+   help programming security applications.  Potential implementors are
+   strongly encouraged to avail themselves of all possible resources to
+   ensure secure implementations.
+
+7.4.  Privacy Assumptions with Forwarding Addresses
+
+   Some people believe that they can achieve anonymity by using an email
+   forwarding service.  While this has never been particularly true, as
+   bounces, over-quota messages, vacation messages, and web bugs all
+   conspire to expose IP addresses and domain names associated with the
+   delivery path, the DNS queries that are required to verify DomainKeys
+   signature can provide additional information to the sender.
+
+
+
+
+Delany                          Historic                       [Page 35]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+   In particular, as mail is forwarded through the mail network, the DNS
+   queries for the selector will typically identify the DNS cache used
+   by the forwarding and delivery MTAs.
+
+7.5.  Cryptographic Processing Is Computationally Intensive
+
+   Verifying a signature is computationally significant.  Early
+   indications are that a typical mail server can expect to increase CPU
+   demands by 8-15 percent.  While this increased demand is modest
+   compared to other common mail processing costs -- such as Bayesian
+   filtering -- any increase in resource requirements can make a
+   denial-of-service attack more effective against a mail system.
+
+   A constraining factor of such attacks is that the net computational
+   cost of verifying is bounded by the maximum key size allowed by this
+   specification and is essentially linear to the rate at which mail is
+   accepted by the verifying system.  Consequently, the additional
+   computational cost may augment a denial-of-service attack, but it
+   does not add a non-linear component to such attacks.
+
+8.  The Trial
+
+   The DomainKeys protocol was deployed as a trial to better understand
+   the implications of deploying wide-scale cryptographic email
+   authentication.
+
+   Open Source implementations were made available at various places,
+   particularly Source Forge [SOURCEFORGE], which includes links to
+   numerous implementations, both Open Source and commercial.
+
+8.1.  Goals
+
+   The primary goals of the trial were to:
+
+      o  understand the operational implications of running a DNS-based
+         public key system for email
+
+      o  measure the effectiveness of the canonicalization algorithms
+
+      o  experiment with possible per-user key deployment models
+
+      o  fully define the semantics of the "DomainKey-X509:" header
+
+
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 36]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+8.2.  Results of Trial
+
+   The DomainKeys trial ran for approximately 2 years, in which time
+   numerous large ISPs and many thousands of smaller domains
+   participated in signing or verifying with DomainKeys.  The low order
+   numbers are that at least one billion DomainKey signed emails transit
+   the Internet each day between some 12,000 participating domains.
+
+   The operational and development experience of that trial was applied
+   to DKIM.
+
+9.  Note to Implementors Regarding TXT Records
+
+   The DNS is very flexible in that it is possible to have multiple TXT
+   records for a single name and for those TXT records to contain
+   multiple strings.
+
+   In all cases, implementors of DomainKeys should expect a single TXT
+   record for any particular name.  If multiple TXT records are
+   returned, the implementation is free to pick any single TXT record as
+   the authoritative data.  In other words, if a name server returns
+   different TXT records for the same name, it can expect unpredictable
+   results.
+
+   Within a single TXT record, implementors should concatenate multiple
+   strings in the order presented and ignore string boundaries.  Note
+   that a number of popular DNS command-line tools render multiple
+   strings as separately quoted strings, which can be misleading to a
+   novice implementor.
+
+10.  References
+
+10.1.  Normative References
+
+   [BASE64]      Josefsson, S., "The Base16, Base32, and Base64 Data
+                 Encodings", RFC 4648, October 2006.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [PEM]         Linn, J., "Privacy Enhancement for Internet Electronic
+                 Mail: Part I: Message Encryption and Authentication
+                 Procedures", RFC 1421 February, 1993.
+
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 37]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+10.2.  Informative References
+
+   [DKIM]        Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
+                 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
+                 Signatures", RFC 4871, May 2007.
+
+   [DNSSEC]      http://www.ietf.org/html.charters/dnsext-charter.html
+
+   [OPENSSL]     http://www.openssl.org
+
+   [RFC2822]     Resnick, P., Editor, "Internet Message Format", RFC
+                               2822, April 2001.
+
+   [RFC3833]     Atkins, D. and R. Austein, "Threat Analysis of the
+                 Domain Name System (DNS)", RFC 3833, August 2004.
+
+   [SMIME]       Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+                 Extensions (S/MIME) Version 3.1 Message Specification",
+                 RFC 3851, July 2004.
+
+   [SOURCEFORGE] http://domainkeys.sourceforge.net
+
+   [SSL]         http://wp.netscape.com/security/techbriefs/ssl.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 38]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+Appendix A - Syntax Rules for the Tag=Value Format
+
+   A simple tag=value syntax is used to encode data in the response
+   values for DNS queries as well as headers embedded in emails.  This
+   section summarized the syntactic rules for this encoding:
+
+      o  A tag=value pair consists of three tokens, a "tag", the "="
+         character, and the "value"
+
+      o  A tag MUST be one character long and MUST be a lowercase
+         alphabetic character
+
+      o  Duplicate tags are not allowed
+
+      o  A value MUST only consist of characters that are valid in RFC
+         2822 headers and DNS TXT records and are within the ASCII range
+         of characters from SPACE (0x20) to TILDE (0x7E) inclusive.
+         Values MUST NOT contain a semicolon but they may contain "="
+         characters.
+
+      o  A tag=value pair MUST be terminated by a semicolon or the end
+         of the data
+
+      o  Values MUST be processed as case sensitive unless the specific
+         tag description of semantics imply case insensitivity.
+
+      o  Values MAY be zero bytes long
+
+      o  Whitespace MAY surround any of the tokens; however, whitespace
+         within a value MUST be retained unless explicitly excluded by
+         the specific tag description.  Currently, the only tags that
+         specifically ignore embedded whitespace are the "b" and "h"
+         tags in the "DomainKey-Signature:" header.
+
+      o  Tag=value pairs that represent the default value MAY be
+         included to aid legibility.
+
+      o  Unrecognized tags MUST be ignored
+
+
+
+
+
+
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 39]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+Acknowledgments
+
+   The editor wishes to thank Russ Allbery, Eric Allman, Edwin Aoki,
+   Claus Asmann, Steve Atkins, Jon Callas, Dave Crocker, Michael Cudahy,
+   Jutta Degener, Timothy Der, Jim Fenton, Duncan Findlay, Phillip
+   Hallam-Baker, Murray S. Kucherawy, John Levine, Miles Libbey, David
+   Margrave, Justin Mason, David Mayne, Russell Nelson, Juan Altmayer
+   Pizzorno, Blake Ramsdell, Scott Renfro, the Spamhaus.org team, Malte
+   S. Stretz, Robert Sanders, Bradley Taylor, and Rand Wacker for their
+   valuable suggestions and constructive criticism.
+
+Author's Address
+
+   Mark Delany
+   Yahoo! Inc
+   701 First Avenue
+   Sunnyvale, CA 95087
+   USA
+
+   EMail: markd+domainkeys@yahoo-inc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 40]
+
+RFC 4870                       DomainKeys                       May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Delany                          Historic                       [Page 41]
+