]> Yahoo

rclayton@yahooinc.com

Internet-Draft DomainKeys Identified Mail v2 (DKIM2) requires any modifications made to email messages by intermediaries to be recorded in "recipes". Some originators wish to request that only very limited modifications be made to their messages so that the recipient of the message can have some assurance that the modifications were benign. This document introduces the CanModify header field into which originator requests may be placed. It then sets out a small set of modifications that are commonly applied by intermediaries and assesses how benign they may actually be.

Introduction DomainKeys Identified Mail v2 (DKIM2) requires any modifications made to email messages by intermediaries to be recorded in "recipes" (see ). Some originators wish to request that only very limited modifications be made to their messages so that the recipient of the message can have some assurance that the modifications were benign.

Terminology and definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. DKIM2 is designed to operate within the Internet Mail service, as defined in . Basic email terminology is taken from that specification. Syntax descriptions use Augmented BNF (ABNF) , together with the %s"..." notation for case-sensitive strings defined in .

Whitespace There are two forms of whitespace used in this specification: WSP represents simple whitespace, i.e. a space or a tab character (formal definition in ). FWS is folding whitespace. It allows multiple lines separated by CRLF followed by at least one whitespace, to be joined. The formal ABNF for these are (WSP given for information only):

The definition of FWS is identical to that in except for the exclusion of obs-FWS. Other tokens not defined herein are imported from . These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc.

The CanModify header field A CanModify header field holds a comma-separated list of types of modification that an email originator is content that intermediaries can do to a message. Types can appear in any order, and SHOULD only appear once. Unrecognized types are ignored. The request is not valid if a message contains more than one CanModify header field or the CanModify header field is not in conformance with this specification. The request is not valid if the current CanModify header field in the message is not identical to any CanModify header field covered by the i= DKIM2-Signature header field (viz it was not added at origination, or has been added, removed or modified since). Alterations will be apparent from inspecting the DKIM2 header recipes in the message. The request is not valid if a message is not a Fully Verified DKIM2 Message (see for how this is determined). An absence of a CanModify header field means that no originator request is being made. If the request is for no modifications whatsoever then use "CanModify: none". It is entirely a matter of local policy whether or not a receiver (or an intermediary) takes any notice of requests, what it does when it can determine that another system has modified the message in a way that an originator has not permitted, and what action is taken when there is an invalid request in the message. ABNF:

The "none" modification request If used, "none" MUST be the only request made. It expresses a request by an email originator for no modifications to be made to a message.

The "bodywrap" modification If used, "bodywrap" indicates that the originator is content for the original message to be delivered as MIME part, optionally preceded or succeeded by other MIME parts that provide headers or footers. This is a benign change provided that the "header" and "footer" contain simple text and URLs. A later version of this document will try and tie this down more precisely.

The "subjectprefix" modification If used, "subjectprefix" indicates that the originator is content for the Subject header field of the original message to be preceded by up to 32 ASCII characters (e.g. "[EXTERNAL]" or "[MAILINGLISTNAME]"). This is a benign change provided that the receiver is viewing enough characters from the original Subject header field to comprehend what it originally said, and that important semantic information does not appear towards the end of the Subject header field.

The "alterfrom" modification If used, "alterfrom" indicates that the originator is content for the From header field of the original message to be replaced by a different From header field. This is benign if the receiver displays the original From header field, and because DKIM2 insists that From header fields are Authentic there are limits as to how inventive an intermediary could be in misleading a recipient.

IANA Considerations TBA

Security Considerations DKIM2 will sign the CanModify header field so it cannot be removed or modified without leaving evidence of this having occurred. The CanModify merely specifies a request by a message originator. Receivers are free to determine what to do if this request cannot be honored, or it is found that an intermediary has not honored it.

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] 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 extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. Yahoo Google Fastmail Pty Ltd DomainKeys Identified Mail v2 (DKIM2) permits the owner of a signing domain to document that they have handled an email message by associating their domain with the message. This is achieved by providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient, systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a "chain" that receivers can validate. This permits verifiers to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changes. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

Changes from Earlier Versions RFC Editor: please remove this section before publication.

draft-clayton-dkim-canmodify-00 Initial version.