Network Working Group R. Clayton Internet-Draft Yahoo Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 Permitted modifications to DKIM2 messages draft-clayton-dkim-canmodify-00 Abstract 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. 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 https://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 6 May 2027. Copyright Notice Copyright (c) 2026 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 Provisions Relating to IETF Documents (https://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 Clayton Expires 6 May 2027 [Page 1] Internet-Draft DKIM2 CanModify November 2026 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and definitions . . . . . . . . . . . . . . . . . 2 2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 3 3. The CanModify header field . . . . . . . . . . . . . . . . . 3 3.1. The "none" modification request . . . . . . . . . . . . . 4 3.2. The "bodywrap" modification . . . . . . . . . . . . . . . 4 3.3. The "subjectprefix" modification . . . . . . . . . . . . 4 3.4. The "alterfrom" modification . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Changes from Earlier Versions . . . . . . . . . . . . . . . . . . 6 draft-clayton-dkim-canmodify-00 . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction DomainKeys Identified Mail v2 (DKIM2) requires any modifications made to email messages by intermediaries to be recorded in "recipes" (see [DKIM2SPEC]). 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. 2. 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 [RFC2119] [RFC8174] 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 [RFC5598]. Basic email terminology is taken from that specification. Syntax descriptions use Augmented BNF (ABNF) [RFC5234], together with the %s"..." notation for case-sensitive strings defined in [RFC7405]. Clayton Expires 6 May 2027 [Page 2] Internet-Draft DKIM2 CanModify November 2026 2.1. 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 [RFC5234]). * 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): WSP = SP / HTAB FWS = [*WSP CRLF] 1*WSP The definition of FWS is identical to that in [RFC5322] except for the exclusion of obs-FWS. Other tokens not defined herein are imported from [RFC5234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc. 3. 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 [DKIM2SPEC] 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". Clayton Expires 6 May 2027 [Page 3] Internet-Draft DKIM2 CanModify November 2026 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: cm-field = "CanModify:" [FWS] cm-request *( [FWS] "," [FWS] cm-request ) cm-request = %s"none" / %s"bodywrap" / %s"subjectprefix" / %s"alterfrom" / x-cm-request x-cm-request = 1*( ALPHA / DIGIT / "-" / "_" ) ; for future additions 3.1. 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. 3.2. 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. 3.3. 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. 3.4. 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. Clayton Expires 6 May 2027 [Page 4] Internet-Draft DKIM2 CanModify November 2026 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. 4. IANA Considerations TBA 5. 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. 6. References 6.1. Normative References [DKIM2SPEC] Clayton, R., Chuang, W., and B. Gondwana, "DomainKeys Identified Mail Signatures v2 (DKIM2)", Work in Progress, Internet-Draft, draft-ietf-dkim-dkim2-spec-09, 1 November 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", STD 68, RFC 7405, DOI 10.17487/RFC7405, December 2014, . Clayton Expires 6 May 2027 [Page 5] Internet-Draft DKIM2 CanModify November 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . Changes from Earlier Versions RFC Editor: please remove this section before publication. draft-clayton-dkim-canmodify-00 * Initial version. Author's Address Richard Clayton Yahoo Email: rclayton@yahooinc.com Clayton Expires 6 May 2027 [Page 6]