Permitted modifications to DKIM2 messages
draft-clayton-dkim-canmodify-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Richard Clayton | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-clayton-dkim-canmodify-00
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, <https://datatracker.ietf.org/doc/html/draft-ietf-
dkim-dkim2-spec-09>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/rfc/rfc5322>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
STD 68, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/rfc/rfc7405>.
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, <https://www.rfc-editor.org/rfc/rfc8174>.
6.2. Informative References
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/rfc/rfc5598>.
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]