]> Google, Inc.

weihaw@google.com

Independent Stream DKIM DKIM2 Headers The DKIM2 specification authenticates email messages with digital signatures, with additional metadata to recover the signature even when the message is forwarded and modified. This draft builds upon DKIM2 to support hashing and authentication of domain specific headers even when the message is forwarded and modified. Other trace-like headers may be supported as well. Authentication-Result header fields support documentation of authentication results as seen by receivers during the forwarding path. Receivers often delete older copies of Authentication-Results even though they may have forensic value. This draft provides a means to preserve those header fields despite those receiver actions.

Introduction The DKIM2 (draft-clayton-dkim2-spec) specification builds upon DKIM () to authenticate email messages with digital signatures, even when the message is forwarded and modified. It calls for a signature at the originator and each of the forwarder ADMDs with metadata to recover the earlier signature. This draft proposes an optional scheme to help publish and preserve proprietary and trace-like header fields. It calls for these header fields to be prefixed and labeled with an index to identify and protect them. They are authenticated by having the opt-in SMTP () senders hash these header fields and publish the hash in the DKIM2 Message-Instance header field as a new tag. Upon receiving such a message, the validation engine recomputes the hash. If the published and recomputed values mismatch, the message is rejected. Authentication-Result () header fields document authentication results as seen by SMTP receivers. When the message is forwarded, prior Authentication-Result header fields may be deleted to prevent confusion however they contain historic information that may be of value when messages are mis-delivered. The proposed scheme in this draft prevents confusion hence enables preserving forensic information to help debug delivery.

Terminology and Definitions 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 .

Localized Headers DKIM2 Localized Header Fields are identified by a prefix "DKIM2-" and preserve the value of domain specific content. DKIM2 senders and receivers MAY opt to handle these header fields using the following procedures to generate and validate them.

Syntax DKIM2 Localized Header Fields are identified by a field name starting with a prefix "DKIM2-" followed by a distinguishing field-name (), excluding "signature". The field name is separated by a local instance tag-value by a colon separator and the body by semi-colon. The local instance is designated by a tag "m" and value number whose value corresponds to the Message-Instance that it is created with. The unstructured field body as defined by SMTP email headers field syntax (). Because there will be no registry to disambiguate these field header names, each sender must use their judgement to find a distinguishing name. For example one strategy might be to use a domain specific name followed by another purpose name. To protect the DKIM2 Localized Header Fields headers, this specification introduces a new Message-Instance tag-value "l" followed by a hash value of DKIM2 Localized Header Fields headers.

Header Field Generation DKIM2 Localized Header Fields are generated typically at SMTP outbound. Before creating new headers, the header generator discovers the highest DKIM2 (draft-clayton-dkim2-spec) Message-Instance revision number tagged by "m". The generator increments this number to create the local instance value

Message-Instance Localized Header Field Hash When the DKIM2 signer generates a new Message-Instance header field on SMTP outbound, the signer needs to compute the hash of the DKIM2 Localized Header Fields. The signer calls up the hashing process described below and obtains a base64 hash. With this, the signer adds a "l' tag and the hash value to the Message-Instance header field.

Hashing As input to this process, it takes the revision number of the Message-Instance to be generated that acts as the limit. The hashing processor scans the headers from bottom up and finds all DKIM2 Localized Header Fields with revision numbers at the limit or lower, and provides them in the found order to the SHA256 hasher. The binary hashed output is base64 encoded () and returned.

Verification As part of the DKIM2 verification, when each Message-Instance header field is examined, the verifier may choose to validate the DKIM2 Localized Header Fields verifier as well. At the very minimum, verifiers choosing to validate the DKIM2 Localized Header Fields MUST verify the "l" hash of the Message-Instance with the highest numbered revision number. If header algebra indicates that DKIM2 Localized Header Fields have been restored at lowered numbered revision numbers, the verifier MAY re-verify "l" hash. To check "l" hash, the verifier computes the current hash by passing the revision number to the hashing procedure above to obtain a base64 hash. It does an exact comparison between the computed hash and the Message-Instance "l" hash. If they are different, this causes DKIM2 verification to fail. in addition results from the DKIM2 Localized Header Fields SHOULD NOT be used. Potentially the message SHOULD be rejected with SMTP PERMFAIL. If the hashes are the same, DKIM2 verification continues.

Authentication-Result One important application of DKIM2 Localized Header Fields to protect Authentication-Result, which can be converted as described above. Authentication-Result header fields are typically generated on SMTP inbound which is different from the above outbound SMTP handling context. To protect these headers, this procedure is to generate DKIM2 signatures on SMTP inbound assuming that they will be delivered to the inbox. For these signatures, the value of the "rt=" is left empty, and will fail the chain of custody validation if the message was replayed out of the inbox. If the messages are SMTP relayed, and signer SHOULD check the most recent DKIM2 signatures remains valid excluding the empty "rt=". The signer strips the top most DKIM2 signature, DKIM2 signs the message again at the same instance number, and sets the "rt=" tag to the recipient. The result of DKIM2 Localized Header Fields validation can be added to Authentication-Result (). This specifies a new method "lhf" that can take a result of "pass" or "fail".

Security Considerations This specification provides protection for DKIM2 Localized Headers. More considerations will be generated in the future.

IANA Considerations This document has no IANA actions yet.

Normative References 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 by 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. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes RFC 7601. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]