DKIM                                                     D. Crocker, Ed.
Internet-Draft                               Brandenburg InternetWorking
Obsoletes: 4871, 5672 (if approved)                    M. Kucherawy, Ed.
Intended status: Standards                                     Cloudmark
Expires: July 18, 2011                                  January 14, 2011



       DomainKeys Identified Mail (DKIM) Signatures - Over DOSETA
                draft-crocker-dkim-rfc4871bis-doseta-00

Abstract

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization that owns the signing domain to claim some
   responsibility for a message by associating the domain with the
   message.  This can be an author's organization, an operational relay
   or one of their agents.  DKIM separates the question of the identity
   of the signer of the message from the purported author of the
   message.  Assertion of responsibility is validated through a
   cryptographic signature and querying the signer's domain directly to
   retrieve the appropriate public key.  Message transit from author to
   recipient is through relays that typically make no substantive change
   to a message or its content and thus preserve the DKIM signature.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 18, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Crocker & Kucherawy       Expires July 18, 2011                 [Page 1]


Internet-Draft                 RFC4871bis                   January 2011


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Signing Identity {rfc4871bis-02 1.1} . . . . . . . . . . .  4
     1.2.  Terminology and Definitions  . . . . . . . . . . . . . . .  4
   2.  Signing and Verifying Protocol {added} . . . . . . . . . . . .  5
   3.  Extensions to DOSETA Template {rfc4871bis-02  - adapted
       for Doseta overlay}  . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Signature Data Structure {rfc4871bis-02 3.5, subset} . . .  6
     3.2.  Relationship between SDID and AUID {rfc4871bis-02 3.9} . . 13
     3.3.  Stored Key Data {rfc4871bis-02 3.6.1, subset}  . . . . . . 14
   4.  Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  Security Considerations {rfc4871bis-02 8, subset}  . . . . 16
     4.2.  IANA Considerations {rfc4871bis-02 7, subset}  . . . . . . 17
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  MUA Considerations {rfc4871bis-02 D}  . . . . . . . . 20
   Appendix B.  End-to-End Scenario Example {rfc4871bis-02 A} . . . . 21
     B.1.  The User Composes an Email . . . . . . . . . . . . . . . . 21
     B.2.  The Email is Signed  . . . . . . . . . . . . . . . . . . . 21
     B.3.  The Email Signature is Verified  . . . . . . . . . . . . . 22
   Appendix C.  Types of Use {rfc4871bis-02 B}  . . . . . . . . . . . 23
     C.1.  Alternate Submission Scenarios . . . . . . . . . . . . . . 24
     C.2.  Alternate Delivery Scenarios . . . . . . . . . . . . . . . 26
   Appendix D.  Acknowledgements  . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28














Crocker & Kucherawy       Expires July 18, 2011                 [Page 2]


Internet-Draft                 RFC4871bis                   January 2011


1.  Introduction

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name [RFC1034] with the message [RFC5322].  This
   can be an author's organization, an operational relay or one of their
   agents.  Assertion of responsibility is validated through a
   cryptographic signature and querying the signer's domain directly to
   retrieve the appropriate public key.  Message transit from author to
   recipient is through relays that typically make no substantive change
   to the message content and thus preserve the DKIM signature.  A
   message can contain multiple signatures, from the same or different
   organizations involved with the message.

   The DKIM service is described in detail in [RFC5585] and [RFC5863].

      This version of DKIM is based on a split between DKIM-specific
      details, versus an underlying component mechanism, called DOSETA,
      that can be used for other services.  [I-D.Doseta].

      NOTE:   Much of the text for this draft is taken from the DKIM
         working group draft-ietf-DKIM-rfc4871bis-02 revision.  Sections
         in this document cross reference their source with the
         notation:
   {rfc4871bis-02 xx}
         where "xx" indicates the section number.  It might also
         indicate that a subset is taken, such as when a portion is
         applied to the DKIM-over-DOSETA draft and a portion to the
         DOSETA draft.  In some cases the base text also has been
         enhanced.

   The approach taken by DKIM differs from previous approaches to
   message signing (for example., Secure/Multipurpose Internet Mail
   Extensions (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that:

   o  the message signature is written as a message header field so that
      neither human recipients nor existing MUA (Mail User Agent)
      software is confused by signature-related content appearing in the
      message body;

   o  there is no dependency on public and private key pairs being
      issued by well-known, trusted certificate authorities;

   o  there is no dependency on the deployment of any new Internet
      protocols or services for public key distribution or revocation;

   o  signature verification failure does not force rejection of the
      message;



Crocker & Kucherawy       Expires July 18, 2011                 [Page 3]


Internet-Draft                 RFC4871bis                   January 2011


   o  no attempt is made to include encryption as part of the mechanism;

   o  message archiving is not a design goal.

   DKIM:

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

   o  requires minimal new infrastructure;

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

   o  can be deployed incrementally;

   o  allows delegation of signing to third parties.

1.1.  Signing Identity {rfc4871bis-02 1.1}

   DKIM separates the question of the identity of the signer of the
   message from the purported author of the message.  In particular, a
   signature includes the identity of the signer.  Verifiers can use the
   signing information to decide how they want to process the message.
   The signing identity is included as part of the signature header
   field.

   The signing identity specified by a DKIM signature is not required to
   match an address in any particular header field because of the broad
   methods of interpretation by recipient mail systems, including MUAs.

1.2.  Terminology and Definitions

   This specification incorporates the terminology defined in
   [I-D.Doseta].

   Syntax descriptions use Augmented BNF (ABNF) [RFC5234].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Additional terminology: {rfc4871bis-02 #2, subset}








Crocker & Kucherawy       Expires July 18, 2011                 [Page 4]


Internet-Draft                 RFC4871bis                   January 2011


      Signing Domain Identifier (SDID):   This augments the definition
         provided by DOSETA [I-D.Doseta].  A single domain name that is
         the mandatory payload output of DKIM and that refers to the
         identity claiming responsibility for introduction of a message
         into the mail stream.  For DKIM processing, the name has only
         basic domain name semantics; any possible owner-specific
         semantics are outside the scope of DKIM.  It is specified in
         Section 3.1.

      Agent or User Identifier (AUID):   A single identifier that refers
         to the agent or user on behalf of whom the Signing Domain
         Identifier (SDID) has taken responsibility.  The AUID comprises
         a domain name and an optional <local-part>.  The domain name is
         the same as that used for the SDID or is a sub-domain of it.
         For DOSETA processing, the domain name portion of the AUID has
         only basic domain name semantics; any possible owner-specific
         semantics are outside the scope of DOSETA.  It is specified in
         Section 3.1 .

      Identity Assessor:   This augments the definition of Assessor in
         [I-D.Doseta].  A module that consumes DOSETA's mandatory
         payload, which is the responsible Signing Domain Identifier
         (SDID).  The module is dedicated to the assessment of the
         delivered identifier.  Other DOSETA (and non-DOSETA) values can
         also be delivered to this module as well as to a more general
         message evaluation filtering engine.  However, this additional
         activity is outside the scope of the DKIM signature
         specification.


2.  Signing and Verifying Protocol {added}

   DKIM uses the DOSETA "Generic Header/Content Signing Service
   Template" [I-D.Doseta] as its base.

   The DOSETA template specifies TEMPLATE information that is required
   to tailor the signing service:



      Signature Association:   The DOSETA-Signature data are stored in a
         DKIM-Signature header field that is part of the Header of the
         message being signed.  This contains all of the signature and
         key-fetching data, per [I-D.Doseta].







Crocker & Kucherawy       Expires July 18, 2011                 [Page 5]


Internet-Draft                 RFC4871bis                   January 2011


      Semantics Signaling:   The presence of a DKIM-Signature header
         fields signals the use of DKIM.

      Semantics:   A DKIM signature means that the owner of the signing
         domain is taking "some" responsibility for the message.  Hence,
         the payload, or output, of DKIM is:

         +  A validated domain name, specifically the d= parameter in
            the DKIM-Signature header field

         +  An indication that its use has been validated

         The nature and extent of a DKIM signer's responsibility can
         vary widely and is beyond the scope of this specification.

      Header/Content Mapping:   DKIM maps the DOSETA Header processing
         to an email header and the DOSETA Content to an email body, per
         [RFC5322]


3.  Extensions to DOSETA Template {rfc4871bis-02  - adapted for Doseta
    overlay}

   This section contains specifications that are added to the basic
   DOSETA H/C Signing Template.

3.1.  Signature Data Structure {rfc4871bis-02 3.5, subset}

   These are DKIM-specific tags: (



      i=   The Agent or User Identifier (AUID) on behalf of which the
         SDID is taking responsibility (DOSETA-quoted-printable;
         OPTIONAL, default is an empty <local-part> followed by an "@"
         followed by the domain from the "d=" tag).

         The syntax is a standard email address where the <local-part>
         MAY be omitted.  The domain part of the address MUST be the
         same as, or a subdomain of, the value of the "d=" tag.

         Internationalized domain names MUST be converted using the
         steps listed in Section 4 of [RFC5890] using the "ToASCII"
         function.







Crocker & Kucherawy       Expires July 18, 2011                 [Page 6]


Internet-Draft                 RFC4871bis                   January 2011






            ABNF:
   sig-i-tag       = %x69 [FWS] "=" [FWS]
                     [ local-part ] "@" domain-name

         The AUID is specified as having the same syntax as an email
         address, but is not required to have the same semantics.
         Notably, the domain name is not required to be registered in
         the DNS -- so it might not resolve in a query -- and the
         <local-part> MAY be drawn from a namespace unrelated to any
         mailbox.  The details of the structure and semantics for the
         namespace are determined by the Signer.  Any knowledge or use
         of those details by verifiers or assessors is outside the scope
         of the DOSETA Signing specification.  The Signer MAY choose to
         use the same namespace for its AUIDs as its users' email
         addresses or MAY choose other means of representing its users.
         However, the signer SHOULD use the same AUID for each message
         intended to be evaluated as being within the same sphere of
         responsibility, if it wishes to offer receivers the option of
         using the AUID as a stable identifier that is finer grained
         than the SDID.

         NOTE:   The <local-part> of the "i=" tag is optional because in
            some cases a signer might not be able to establish a
            verified individual identity.  In such cases, the signer
            might wish to assert that although it is willing to go as
            far as signing for the domain, it is unable or unwilling to
            commit to an individual user name within their domain.  It
            can do so by including the domain part but not the <local-
            part> of the identity.

         NOTE:   Absent public standards for the semantics of an AUID,
            an assessment based on AUID requires a non-standardized
            basis.

         NOTE:   This specification does not require the value of the
            "i=" tag to match the identity in any Header field.  This is
            considered to be an assessment-time policy issue.
            Constraints between the value of the "i=" tag and other
            identities in other Header fields might seek to apply basic
            authentication into the semantics of trust associated with a
            role such as content author.  Trust is a broad and complex
            topic and trust mechanisms are subject to highly creative
            attacks.  The real-world efficacy of any but the most basic
            bindings between the "i=" value and other identities is not



Crocker & Kucherawy       Expires July 18, 2011                 [Page 7]


Internet-Draft                 RFC4871bis                   January 2011


            well established, nor is its vulnerability to subversion by
            an attacker.  Hence reliance on the use of these options
            needs to be strictly limited.  In particular, it is not at
            all clear to what extent a typical end-user recipient can
            rely on any assurances that might be made by successful use
            of the "i=" options.

      l=    Content length count (plain-text unsigned decimal integer;
         OPTIONAL, default is entire Content).  This tag informs the
         verifier of the number of octets in the Content of the data
         after canonicalization included in the cryptographic hash,
         starting from 0 immediately following the CRLF preceding the
         Content.  This value MUST NOT be larger than the actual number
         of octets in the canonicalized Content.



            ABNF:
   sig-l-tag    = %x6c [FWS] "=" [FWS]
                  1*76DIGIT

         NOTE:   Use of the "l=" tag might allow display of fraudulent
            content without appropriate warning to end users.  The "l="
            tag is intended for increasing signature robustness when
            sending to intermediaries that append data to Content, such
            as mailing lists that both modify their content and do not
            sign their messages.  However, using the "l=" tag enables
            attacks in which an intermediary with malicious intent
            modifies a message to include content that solely benefits
            the attacker.  It is possible for the appended content to
            completely replace the original content in the end
            recipient's eyes and to defeat duplicate message detection
            algorithms.  Examples are described in Security
            Considerations Section 4.1.  To avoid this attack, signers
            need be extremely wary of using this tag, and verifiers
            might wish to ignore the tag or remove text that appears
            after the specified content length.

         NOTE:   The value of the "l=" tag is constrained to 76 decimal
            digits.  This constraint is not intended to predict the size
            of future data or to require implementations to use an
            integer representation large enough to represent the maximum
            possible value, but is intended to remind the implementer to
            check the length of this and all other tags during
            verification and to test for integer overflow when decoding
            the value.  Implementers might need to limit the actual
            value expressed to a value smaller than 10^76, for example,
            to allow a message to fit within the available storage



Crocker & Kucherawy       Expires July 18, 2011                 [Page 8]


Internet-Draft                 RFC4871bis                   January 2011


            space.

      z=    Copied Header fields (DOSETA-quoted-printable, but see
         description; OPTIONAL, default is null).  A vertical-bar-
         separated list of selected Header fields present when the
         message was signed, including both the field name and value.
         It is not required to include all Header fields present at the
         time of signing.  This field need not contain the same Header
         fields listed in the "h=" tag.  The Header field text itself
         MUST encode the vertical bar ("|", %x7C) character.  That is,
         vertical bars in the "z=" text are meta-characters, and any
         actual vertical bar characters in a copied header field MUST be
         encoded.  Note that all whitespace MUST be encoded, including
         whitespace between the colon and the header field value.  After
         encoding, FWS MAY be added at arbitrary locations in order to
         avoid excessively long lines; such whitespace is NOT part of
         the value of the header field, and MUST be removed before
         decoding.

         The Header fields referenced by the "h=" tag refer to the
         fields in the [RFC5322] Header, not to any copied fields in the
         "z=" tag.  Copied header field values are for diagnostic use.

         Header fields with characters requiring conversion (perhaps
         from legacy MTAs that are not [RFC5322] compliant) SHOULD be
         converted as described in MIME Part Three [RFC2047].





            ABNF:

   sig-z-tag      = %x7A [FWS] "=" [FWS]
                    sig-z-tag-copy
                    *( "|" [FWS] sig-z-tag-copy )
   sig-z-tag-copy = hdr-name [FWS] ":"
                    qp-hdr-value













Crocker & Kucherawy       Expires July 18, 2011                 [Page 9]


Internet-Draft                 RFC4871bis                   January 2011


   EXAMPLE of a signature header field spread across multiple
   continuation lines:
   DKIM-Signature: v=1; a=rsa-sha256; d=example.net;
     s=brisbane;   c=simple; q=dns/txt; i=@eng.example.net;
     t=1117574938; x=1118006938;
     h=from:to:subject:date;
     z=From:foo@eng.example.net|To:joe@example.com|
      Subject:demo=20run|
      Date:July=205,=202005=203:44:08=20PM=20-0700;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

3.1.1.  Content Length Limits {rfc4871bis-02 3.4.5}

   A text length count MAY be specified to limit the signature
   calculation to an initial prefix of an ASCII text data portion,
   measured in octets.  If the Content length count is not specified,
   the entire Content is signed.

   This capability is provided because it is very common for
   intermediate data handling services to add trailers to text (for
   example, instructions how to get off a mailing list).  Until such
   data is signed by the intermediate handler, the text length count can
   be a useful tool for the verifier since it can, as a matter of
   policy, accept messages having valid signatures that do not cover the
   additional data.

   NOTE:   Using text length limits enables an attack in which an
      attacker modifies a message to include content that solely
      benefits the attacker.  It is possible for the appended content to
      completely replace the original content in the end recipient's
      eyes and to defeat duplicate message detection algorithms.  To
      avoid this attack, signers need to be wary of using this tag, and
      verifiers might wish to ignore the tag or remove text that appears
      after the specified content length, perhaps based on other
      criteria.

   The text length count allows the signer of text to permit data to be
   appended to the end of the text of a signed message.  The text length
   count MUST be calculated following the canonicalization algorithm;
   for example, any whitespace ignored by a canonicalization algorithm
   is not included as part of the Content length count.  Signers of MIME
   messages that include a Content length count SHOULD be sure that the
   length extends to the closing MIME boundary string.







Crocker & Kucherawy       Expires July 18, 2011                [Page 10]


Internet-Draft                 RFC4871bis                   January 2011


   NOTE:   A creator wishing to ensure that the only acceptable
      modifications are to add to a MIME postlude would use a text
      length count encompassing the entire final MIME boundary string,
      including the final "--CRLF".  A signer wishing to allow
      additional MIME parts but not modification of existing parts would
      use a Content length count extending through the final MIME
      boundary string, omitting the final "--CRLF".  Note that this only
      works for some MIME types, such as, multipart/mixed but not
      multipart/signed.

   A text length count of zero means that the text is completely
   unsigned.

   Creators wishing to ensure that no modification of any sort can occur
   will specify the "simple" canonicalization algorithm for all data
   portions and will and omit the text length counts.

3.1.2.  Recommended Signature Content {rfc4871bis-02 5.5}

   In order to maximize compatibility with a variety of verifiers, it is
   recommended that signers follow the practices outlined in this
   section when signing a message.  However, these are generic
   recommendations applying to the general case; specific senders might
   wish to modify these guidelines as required by their unique
   situations.  Verifiers MUST be capable of verifying signatures even
   if one or more of the recommended Header fields is not signed (with
   the exception of From:, which MUST always be signed) or if one or
   more of the dis-recommended Header fields is signed.  Note that
   verifiers do have the option of ignoring signatures that do not cover
   a sufficient portion of the header or Content, just as they might
   ignore signatures from an identity they do not trust.

   The following Header fields SHOULD be included in the signature, if
   they are present in the message being signed:

   o  From (REQUIRED in all signatures)

   o  Sender, Reply-To

   o  Subject

   o  Date, Message-ID

   o  To, Cc

   o  MIME-Version





Crocker & Kucherawy       Expires July 18, 2011                [Page 11]


Internet-Draft                 RFC4871bis                   January 2011


   o  Content-Type, Content-Transfer-Encoding, Content-ID, Content-
      Description

   o  Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc,
      Resent-Message-ID

   o  In-Reply-To, References

   o  List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
      List-Owner, List-Archive

   The following Header fields SHOULD NOT be included in the signature:

   o  Return-Path

   o  Received

   o  Comments, Keywords

   o  Bcc, Resent-Bcc

   o  DOSETA-Signature

   Optional Header fields (those not mentioned above) normally SHOULD
   NOT be included in the signature, because of the potential for
   additional Header fields of the same name to be legitimately added or
   reordered prior to verification.  There are likely to be legitimate
   exceptions to this rule, because of the wide variety of application-
   specific Header fields that might be applied to a message, some of
   which are unlikely to be duplicated, modified, or reordered.

   Signers SHOULD choose canonicalization algorithms based on the types
   of data they process and their aversion to risk.  For example,
   e-commerce sites sending primarily purchase receipts, which are not
   expected to be processed by intermediaries such as mailing lists or
   other software likely to modify data, will generally prefer "simple"
   canonicalization.  Sites sending primarily person-to-person data will
   likely prefer to be more resilient to modification during transport
   by using "relaxed" canonicalization.

   Signers SHOULD NOT use "l=" unless they intend to accommodate
   intermediate data processors that append text to a message.  For
   example, many mailing list processors append "unsubscribe"
   information to message bodies.  If signers use "l=", they SHOULD
   include the entire Content existing at the time of signing in
   computing the count.  In particular, signers SHOULD NOT specify a
   Content length of 0 since this might be interpreted as a meaningless
   signature by some verifiers.



Crocker & Kucherawy       Expires July 18, 2011                [Page 12]


Internet-Draft                 RFC4871bis                   January 2011


3.1.3.  Signature Verification {rfc4871bis-02 6.1.3, subset}

   A Content length specified in the "l=" tag of the signature limits
   the number of bytes of the Content passed to the verification
   algorithm.  All data beyond that limit is not validated by DOSETA.
   Hence, verifiers might treat a message that contains bytes beyond the
   indicated Content length with suspicion, such as by truncating the
   message at the indicated Content length, declaring the signature
   invalid (for example, by returning PERMFAIL (unsigned content)), or
   conveying the partial verification to the policy module.

   NOTE:   Verifiers that truncate the Content at the indicated Content
      length might pass on a malformed MIME message if the signer used
      the "N-4" trick (omitting the final "--CRLF") described in the
      informative note in Section 3.1.1.  Such verifiers might wish to
      check for this case and include a trailing "--CRLF" to avoid
      breaking the MIME structure.  A simple way to achieve this might
      be to append "--CRLF" to any "multipart" message with a Content
      length; if the MIME structure is already correctly formed, this
      will appear in the postlude and will not be displayed to the end
      user.

3.2.  Relationship between SDID and AUID {rfc4871bis-02 3.9}

   DOSETA's primary task is to communicate from the Signer to a
   recipient-side Identity Assessor a single Signing Domain Identifier
   (SDID) that refers to a responsible identity.  DOSETA MAY optionally
   provide a single responsible Agent or User Identifier (AUID).

   Hence, DOSETA's mandatory output to a receive-side Identity Assessor
   is a single domain name.  Within the scope of its use as DOSETA
   output, the name has only basic domain name semantics; any possible
   owner-specific semantics are outside the scope of DOSETA.  That is,
   within its role as a DOSETA identifier, additional semantics cannot
   be assumed by an Identity Assessor.

   Upon successfully verifying the signature, a receive-side DOSETA
   verifier MUST communicate the Signing Domain Identifier (d=) to a
   consuming Identity Assessor module and MAY communicate the Agent or
   User Identifier (i=) if present.

   To the extent that a receiver attempts to intuit any structured
   semantics for either of the identifiers, this is a heuristic function
   that is outside the scope of DOSETA's specification and semantics.
   Hence, it is relegated to a higher-level service, such as a delivery
   handling filter that integrates a variety of inputs and performs
   heuristic analysis of them.




Crocker & Kucherawy       Expires July 18, 2011                [Page 13]


Internet-Draft                 RFC4871bis                   January 2011


   This document does not require the value of the SDID or AUID to match
   an identifier in any other message header field.  Such a requirement
   is, instead, an assessor policy issue.  The purpose of such a linkage
   could be to authenticate the value in that other header field.  This,
   in turn, is the basis for applying a trust assessment based on the
   identifier value.  Trust is a broad and complex topic and trust
   mechanisms are subject to highly creative attacks.  The real-world
   efficacy of any but the most basic bindings between the SDID or AUID
   and other identities is not well established, nor is its
   vulnerability to subversion by an attacker.  Hence, reliance on the
   use of such bindings SHOULD be strictly limited.  In particular, it
   is not at all clear to what extent a typical end-user recipient can
   rely on any assurances that might be made by successful use of the
   SDID or AUID.

3.3.  Stored Key Data {rfc4871bis-02 3.6.1, subset}

   This section defines additions to the DOSETA Library, concerning
   stored key data.



      g=    Granularity of the key (plain-text; OPTIONAL, default is
         "*").  This value MUST match the Local-part of the "i=" tag of
         the DKIM- Signature header field (or its default value of the
         empty string if "i=" is not specified), with a single, optional
         "*" character matching a sequence of zero or more arbitrary
         characters ("wildcarding").  An email with a signing address
         that does not match the value of this tag constitutes a failed
         verification.  The intent of this tag is to constrain which
         signing address can legitimately use this selector, for
         example, when delegating a key to a third party that should
         only be used for special purposes.  Wildcarding allows matching
         for addresses such as "user+*" or "*-offer".  An empty "g="
         value never matches any addresses.



            ABNF:
   key-g-tag       = %x67 [FWS] "=" [FWS] key-g-tag-lpart
                        key-g-tag-lpart = [dot-atom-text]
                                          ["*" [dot-atom-text] ]

      h=    Acceptable hash algorithms (plain-text; OPTIONAL, defaults
         to allowing all algorithms).  A colon-separated list of hash
         algorithms that might be used.  Signers and Verifiers MUST
         support the "sha256" hash algorithm.  Verifiers MUST also
         support the "sha1" hash algorithm.  Unrecognized hash



Crocker & Kucherawy       Expires July 18, 2011                [Page 14]


Internet-Draft                 RFC4871bis                   January 2011


         algorithms MUST be ignored.





            ABNF:

   key-h-tag       = %x68 [FWS] "=" [FWS]
                     key-h-tag-alg
                     0*( [FWS] ":" [FWS]
                     key-h-tag-alg )
   key-h-tag-alg   = "sha1" / "sha256" /
                     x-key-h-tag-alg
   x-key-h-tag-alg = hyphenated-word
                          ; for future extension

      s=    Service Type (plain-text; OPTIONAL; default is "*").  A
         colon-separated list of service types to which this record
         applies.  Verifiers for a given service type MUST ignore this
         record if the appropriate type is not listed.  Unrecognized
         service types MUST be ignored.  Currently defined service types
         are as follows:



         *  matches all service types

         email   electronic mail (not necessarily limited to SMTP)

         This tag is intended to constrain the use of keys for other
         purposes, if use of DOSETA is defined by other services in the
         future.





            ABNF:

   key-s-tag        = %x73 [FWS] "=" [FWS]
                      key-s-tag-type
                      0*( [FWS] ":" [FWS]
                      key-s-tag-type )
   key-s-tag-type   = "email" / "*" /
                      x-key-s-tag-type
   x-key-s-tag-type = hyphenated-word
                           ; for future extension



Crocker & Kucherawy       Expires July 18, 2011                [Page 15]


Internet-Draft                 RFC4871bis                   January 2011


      t=    Flags, represented as a colon-separated list of names
         (plain-text; OPTIONAL, default is no flags set).  Unrecognized
         flags MUST be ignored.  The defined flags are as follows:

         y    This domain is testing DOSETA.  Verifiers MUST NOT treat
            data from signers in testing mode differently from unsigned
            data, even if the signature fails to verify.  Verifiers MAY
            wish to track testing mode results to assist the signer.

         s    Any DOSETA-Signature Header fields using the "i=" tag MUST
            have the same domain value on the right-hand side of the "@"
            in the "i=" tag and the value of the "d=" tag.  That is, the
            "i=" domain MUST NOT be a subdomain of "d=".  Use of this
            flag is RECOMMENDED unless subdomaining is required.





            ABNF:
   key-t-tag        = %x74 [FWS] "=" [FWS]
                      key-t-tag-flag
                      0*( [FWS] ":" [FWS]
                      key-t-tag-flag )
   key-t-tag-flag   = "y" / "s" /
                      x-key-t-tag-flag
   x-key-t-tag-flag = hyphenated-word
                           ; for future extension


4.  Considerations

4.1.  Security Considerations {rfc4871bis-02 8, subset}

4.1.1.  Misuse of Content Length Limits ("l=" Tag)

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

4.1.1.1.  Addition of New MIME Parts to Multipart/*

   If the Content 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 Content part.  Depending on the details of the
   MIME type and the implementation of the Consumer, this could allow an
   attacker to change the information displayed to an end user from an
   apparently trusted source.



Crocker & Kucherawy       Expires July 18, 2011                [Page 16]


Internet-Draft                 RFC4871bis                   January 2011


   For example, if attackers can append information to a "text/html"
   Content part, they might 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" Content part, they might be able to add a new Content
   part that is preferred by the displaying MUA.

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

   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="http://www.ietf.org/images/ietflogo2e.gif"
        width=578 height=370> </div>

4.2.  IANA Considerations {rfc4871bis-02 7, subset}

   DKIM uses registries now assigned to DOSETA [I-D.Doseta].  This
   section specifies additions to the registries that were in the
   original DKIM Signing specification.  They are not part of the DOSETA
   specification, but are now specific to DKIM.

4.2.1.  DKIM-Signature Tag Specifications

   These values are added to the registry that is now defined in
   [I-D.Doseta]:

                  +------+------------------------------+
                  | TYPE | REFERENCE                    |
                  +------+------------------------------+
                  |   i  | (this document, Section 3.1) |
                  |   l  | (this document, Section 3.1) |
                  |   z  | (this document, Section 3.1) |
                  +------+------------------------------+

     Table 1: DKIM-Signature Tag Specification Registry Initial Values

4.2.2.  _domainkey DNS TXT Record Tag Specifications

   These values are added to the registry that is now defined in
   [I-D.Doseta]:





Crocker & Kucherawy       Expires July 18, 2011                [Page 17]


Internet-Draft                 RFC4871bis                   January 2011


                  +------+------------------------------+
                  | TYPE | REFERENCE                    |
                  +------+------------------------------+
                  |   g  | (this document, Section 3.3) |
                  |   h  | (this document, Section 3.3) |
                  |   s  | (this document, Section 3.3) |
                  |   t  | (this document, Section 3.3) |
                  +------+------------------------------+

         DKIT _domainkey DNS TXT Record Tag Specification Registry
                              Initial Values

4.2.3.  DKIM Service Types Registry

   The "s=" <key-s-tag> tag (specified in Section 3.3) provides for a
   list of service types to which this selector might apply.

   IANA has established the DKIM Service Types Registry for service
   types.

   The initial entries in the registry comprise:

             +-------+--------------------------------------+
             |  TYPE | REFERENCE                            |
             +-------+--------------------------------------+
             | email | (this document, Section 3.3, "s=")   |
             |   *   | (this document, , Section 3.3, "s=") |
             +-------+--------------------------------------+

                DKIM Service Types Registry Initial Values

4.2.4.  DKIM Service Flags Registry

   The "t=" <key-t-tag> tag (specified in Section 3.3) provides for a
   list of flags to modify interpretation of the selector.

   IANA has established the DKIM Selector Flags Registry for additional
   flags.

   The initial entries in the registry comprise:

               +------+------------------------------------+
               | TYPE | REFERENCE                          |
               +------+------------------------------------+
               |   y  | (this document, Section 3.3, "t=") |
               |   s  | (this document, Section 3.3, "t=") |
               +------+------------------------------------+




Crocker & Kucherawy       Expires July 18, 2011                [Page 18]


Internet-Draft                 RFC4871bis                   January 2011


                DKIM Service Flags Registry Initial Values

4.2.5.  DKIM-Signature Header Field

   IANA has added DKIM-Signature to the "Permanent Message Header
   Fields" registry (see [RFC3864]) for the "mail" protocol, using this
   document as the reference.


5.  References

5.1.  Normative References

   [I-D.Doseta]
              Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Security Tagging (DOSETA)",
              I-D draft-ietf-DKIM-DOSETA, 2010.

   [RFC1034]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
              RFC 1034, November 1987.

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

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

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

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

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

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

5.2.  Informative References

   [RFC1847]  Galvin, J., Murphy, S., Crocker, S., and N. Freed,
              "Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted", RFC 1847, October 1995.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration



Crocker & Kucherawy       Expires July 18, 2011                [Page 19]


Internet-Draft                 RFC4871bis                   January 2011


              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

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

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

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

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

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


Appendix A.  MUA Considerations {rfc4871bis-02 D}

   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 SDID, in an attempt to show the user
   the identity that is claiming responsibility for the message.  An MUA
   might do this with visual cues such as graphics, 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.



Crocker & Kucherawy       Expires July 18, 2011                [Page 20]


Internet-Draft                 RFC4871bis                   January 2011


Appendix B.  End-to-End Scenario Example {rfc4871bis-02 A}

   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 [I-D.Doseta],
   "Creating a Public Key".

B.1.  The User Composes an Email

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

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

                   Figure 1: The User Composes an Email

B.2.  The Email is Signed



























Crocker & Kucherawy       Expires July 18, 2011                [Page 21]


Internet-Draft                 RFC4871bis                   January 2011


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

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

                            The Email is Signed

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

B.3.  The Email Signature is Verified

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

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



Crocker & Kucherawy       Expires July 18, 2011                [Page 22]


Internet-Draft                 RFC4871bis                   January 2011


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

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

                          Successful verification


Appendix C.  Types of Use {rfc4871bis-02 B}

   DOSETA 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 DOSETA can be used, given
      particular constraints and needs.  In no case are these examples
      intended to be taken as providing explanation or guidance
      concerning DOSETA specification details, when creating an
      implementation.








Crocker & Kucherawy       Expires July 18, 2011                [Page 23]


Internet-Draft                 RFC4871bis                   January 2011


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

C.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.  DOSETA selectors (the "s=" signature
   tag) facilitate this kind of restricted authorization.  Examples of
   these outsourced business functions are legitimate email marketing
   providers and corporate benefits providers.

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

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

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

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




Crocker & Kucherawy       Expires July 18, 2011                [Page 24]


Internet-Draft                 RFC4871bis                   January 2011


C.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, jdoe@example.com, 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 jdoe@example.com by the administrator of the
   example.com domain, and appropriate software to sign messages, John
   could sign the message on the device itself before transmission
   through the outgoing network of the access service provider.

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

C.1.4.  Independent (Kiosk) Message Submission

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

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



Crocker & Kucherawy       Expires July 18, 2011                [Page 25]


Internet-Draft                 RFC4871bis                   January 2011


   initial submission email role.

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

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

C.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 DOSETA, affinity domains could use the Web application to allow
   users to register per-user keys to be used to sign messages on behalf
   of their affinity address.  The user would take away the secret half
   of the key pair for signing, and the affinity domain would publish
   the public half in DNS for access by verifiers.

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



Crocker & Kucherawy       Expires July 18, 2011                [Page 26]


Internet-Draft                 RFC4871bis                   January 2011


   blocking the relevant TCP ports used for mail submission.

C.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
   DOSETA is able to validate the message signature.

C.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 (for example,
   mailing-list-name@example.net).  Since (re-)signing is taking
   responsibility for the data, these signing forwarders are likely to
   be selective, and forward or re-sign a message only if it is received
   with a valid signature or if they have some other basis for knowing
   that the message is not spoofed.

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



Crocker & Kucherawy       Expires July 18, 2011                [Page 27]


Internet-Draft                 RFC4871bis                   January 2011


Appendix D.  Acknowledgements

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

   That specification was the result of an extended, collaborative
   effort, including participation by: Russ Allbery, Edwin Aoki, Claus
   Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve
   Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis
   Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark
   Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur
   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 Spamhaus.org team, Malte S. Stretz, Robert
   Sanders, Rand Wacker, Sam Weiler, and Dan Wing.

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


Authors' Addresses

   D. Crocker (editor)
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale
   USA

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


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

   Email: msk@cloudmark.com




Crocker & Kucherawy       Expires July 18, 2011                [Page 28]