Internet-Draft | DKIM Access Control and Differential Cha | July 2025 |
Nurpmeso | Expires 8 January 2026 | [Page] |
This document specifies a DKIM (RFC 6376) extension that allows cryptographic verification of SMTP (RFC 5321) envelope data, and of DKIM signatures prior to IMF (RFC 5322) message content changes along the message path, addressing thus security glitches, and offering a new world of email solutions that move complexity away from lower network layers, where problems cannot be solved. It updates DKIM to obsolete certain aspects that reality has proven to be superfluous, incomplete, or obsoleted. It is the future of email for email of the future.¶
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 8 January 2026.¶
Copyright (c) 2025 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 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.¶
DKIM[RFC6376] was not designed to cover SMTP[RFC5321] envelope data, allowing replay of valid, verifiable messages to an infinite set of recipients by malicious third parties, undetectable by sender and recipients. (To aid SMTP delivery to recipients in various conditions the optional "x=" expiration tag timestamp must be chosen so far in the future that malicious players have plenty of time to misuse messages.)¶
Whereas DKIM[RFC6376] standardized rudimentary, incomplete approaches to undo modifications of IMF[RFC5322] message content that happen along the message path, the overall design was agreed in not to survive them (compare, for example, [RFC6377]). The resulting paradigm of DKIM is "as long as one signature can be verified cryptographically, DKIM verification will succeed". This is problematic as message content changes may be falsely attributed to (the) address(es) in the IMF originator field(s). (Later policy-enforcing standards effectively complicated the situation, in that false attribution may now technically be avoidable, but mitigations like "user A via B" will still be attributed to "A" by a human for one, and, in short, anything is valid if one DKIM signature is.)¶
Potentially many DKIM signatures may exist in a message. DKIM[RFC6376] gives hints on how verification can be performed, but, in practice, mitigations are applied in order to reduce excessive and useless verifications on hops down the message path: elder signatures are removed, or renamed, as changes are performed on message content, for example, by mailing-lists. An approach to avoid excessive network traffic and CPU work during message verification mitigates careless configurations.¶
The presented ACDC extension addresses these and more issues, backward and forward compatible, easy adoptable, and easy integratable into the current, existing infrastucture.¶
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.¶
When in the below message "REJECT"ion is said, implementations may choose to instead move messages into a spam or quarantine state.¶
The term "FOSS" refers to Free and Open Source Software.¶
The DKIM[RFC6376] extension Access Control and Differential Changes:¶
RCPT TO
addresses
as well as the
MAIL FROM
address.
Replay of valid messages to initially not addressed recipients,
as well as backscatter bounces to random addresses instead of
the originator, become detectable.¶
The DKIM[RFC6376] extension Access Control and Differential Changes is announced by adding an "acdc=" tag to the DKIM-Signature. (For efficiency reasons it SHOULD be placed early, before tags like "h=", "bh=" and "b=", for example.)¶
The tag starts with "sequence", a decimal number starting at 1, or incremented by 1 from the highest ACDC sequence number encountered in the message; the maximum value is 999: if incrementing would result in overflow, the message MUST be rejected; detected sequence holes MUST also cause rejection (but see below); in both cases SMTP[RFC5321] reply code 550 is to be used; with enhanced SMTP status codes[RFC3463] 5.5.4 MUST be used.¶
Flag description is normative.
(Note the missing FWS
separators around =
.)
ABNF[RFC5234]:¶
acdc = %x61 %x63 %x64 %x63 = sequence ":" 1*(flag) ":" [id] ":" sequence = 1*3DIGIT; DIGIT from RFC 5234 flag = "D" / "E" / "I" / "O" / "P" / "R" / "S" / "s" / "V" / "v" / "X" / "x" / "Y" / "y" / "Z" / "z" id = *42(ALPHA / DIGIT / "+" / "-"); optional (bounce) identifier¶
The message was modified at this hop, ACDC differential changes were generated, and are stored in a DKIM-Diff: header field.¶
The "Y" flag has to be set.¶
The
SMTP[RFC5321]
envelope (MAIL FROM
and/or RCPT TO
)
was modified.
A new "Access Control" (see there) evaluation has been performed.¶
The "O" flag has to be set if the MAIL FROM
changed.
The "y" flag has to be set.¶
This DKIM-Signature: header field was generated at ingress: shall the message leave the host again via egress, it will be removed. The purpose of such a field is that its flags can be used to query the verification state of the message. (Also see the "R", "S", "s", "V" and "v" flags.)¶
This hop claims the message origin.¶
This either means that the message originated at this hop, in which case the signature (usually, DKIM-typical) refers to the first address of the From header field, and the sequence number is 1.¶
It can also mean that the current hop was the, quoting
[RFC3461],
"final delivery for the [original] message",
that the message got a "new envelope return address",
that is, the MAIL FROM
of the SMTP envelope was changed.
In this case the "E" flag has to be set¶
A new "Access Control" (see there) evaluation has been performed.¶
Postmaster mode. With this flag set the behaviour of ACDC borders test mode in that rejections must not occur (due to ACDC). This is to allow for a communication possibility window in a situation where messages would always be rejected, due to misconfigurations et cetera, and as such reflects SMTP[RFC5321] section 4.5.1 Minimum Implementation.¶
(If, due to some failure, the sequence number would be excessed by such a message, the sequence increment shall not be performed, even if it makes the message "more invalid". Implementations necessarily count the number of ACDC instances, and may imply an absolute maximum in order to avoid endless message wandering aka "loops" nonetheless.)¶
If the sequence number is 1,
message recipients have to be inspected.
If the
IMF[RFC5322]
header fields To: and Cc: only contain a single addressee with
the local part
postmaster[RFC1123],
and if the same "postmaster" is addressed as a
SMTP[RFC5321]
RCPT TO
recipient,
and if no more than two RCPT TO
recipients exist in
total,
then the "P" flag has to be set.¶
Once set, all future DKIMACDC signatures must copy it. (It may be removed by a signature which claims a new message origin by setting the "O" flag.)¶
Reputation check to collect organizational trust ([RFC5863], section 2.5) along the signature chain was performed.¶
On top of the "V" flag this means that all differential changes have been applied, and all signatures along the chain have been verified, and the entire chain validated correctly.¶
Only in signatures with sequence numbers greater than 1, and without the "Z" or "z" flags (in earlier signatures).¶
Only in conjunction with the "I" flag. Upon ingress the SPF[RFC7208] state was successfully verified.¶
Only in conjunction with the "I" flag. Upon ingress the SPF[RFC7208] verification failed.¶
ACDC signature verified successfully.¶
This means that the signature with the highest sequence number has been verified correctly, that the sequence of ACDC signatures is complete, and their flags make sense (in the sequence). In conjunction with the flag "R" even deeper inspection was performed.¶
Only in signatures with sequence numbers greater than 1.¶
DKIM signature verified successfully.¶
In signatures with sequence number 1, then missing the "O" flag, it means the message originated at a non-ACDC-aware host, and normal DKIM processing was performed and succeeded. Unless DKIM processing succeeded for the DKIM signature which covered the messages' From: header field address, the "Z" flag must be set, otherwise the "z" flag.¶
In messages with higher sequence numbers it comes alongside the "X" flag: necessarily the ACDC chain was broken, and the message changed, by an intermediate non-ACDC-aware hop. The "z" flag must be set.¶
DKIMACDC verification failed; however, the normal DKIM signature verification was performed, and succeeded.¶
The "z" flag must be set.¶
DKIM verification failed.¶
In signatures with sequence number 1, then missing the "O" flag, it means the message originated at a non-ACDC-aware host, and normal DKIM processing was performed and failed. The "z" flag must be set.¶
In messages with higher sequence numbers it comes alongside the "X" flag: necessarily the ACDC chain was broken, and the message changed, by an intermediate non-ACDC-aware hop. The "z" flag must be set.¶
The message has seen IMF[RFC5322] modifications: somewhere along the chain the original message data was modified. Once set, all future ACDC signatures must copy it.¶
The message has seen SMTP[RFC5321] envelope modifications: somewhere along the chain the original envelope was modified. Once set, all future ACDC signatures must copy it.¶
Announces the ACDC chain is incomplete. The message was processed by ACDC unaware hops. However, the message verifies correctly and seems to have never been modified non-reversibly. Once set, all future DKIMACDC signatures must copy it, unless later downgraded to the "z" flag.¶
The message has seen non-reversible modifications, and cannot be cryptographically verified back to its origin. Once set, all future DKIMACDC signatures must copy it.¶
If this flag is set ACDC looses its decisive meaning and "degrades" to normal DKIM: no more differential data is generated, and messages are distributed further / accepted if just any DKIM(ACDC) signature verifies. (Software configuration MAY allow otherwise.)¶
The optional "bounce identifier" offers enough room to store Universally Unique IDentifiers[RFC9562].¶
It MAY be generated to help sending domains to uniquely identify messages within the DKIM "t=" and "x=" time delta, as well as to ensure that successively sent identical messages are not detected as the same.¶
Receiving domains should not use this identifier due to the denial of service attack surface, regardless of collected organizational trust (see R flag).¶
Unknown flags MUST be ignored. Invalid flag combinations and flag misuse MUST result in rejection with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 MUST be used. (This includes the "P" flag upon incorrect use.)¶
The DKIM-Store header field has no meaning in the email system. The sole purpose of mentioning it is to announce that it MUST be removed when messages enter and leave the email system. It could for example be temporarily created and used by non-integrated mail filter (milter) software to pass informational data in between the "ingress" and the "egress" processing side. To aid in software bugs and possible configuration errors this specification enforces removal of all occurrences. It is suggested to encrypt data passed around in this temporary header field with a key internal to the "local" email processing system in order to achieve locality.¶
SMTP delivers messages to individual domains.
With ACDC, when a SMTP envelope was created or changed,
all distinct domain-names found within the list of intended
SMTP RCPT TO
addressees are collected,
as the message needs to be forged on this individual domain base:
ACDC will create DKIM-AC: header fields covering SMTP envelopes,
and include them as messages are sent to individual domains.¶
The domains _dkimacdc DNS entries, as below, are queried. Any domain that announces ACDC support can be served by a single message for all recipients (possible limits aside). For other domains, to guarantee anonymity, it is necessary to differentiate in between public recipients in the To: and Cc: header fields, and private recipients in the Bcc: header field. Remarks: quality-of-service: for simplicity messages may always be forged on a single recipient base, individually.¶
In any case the completely prepared message, including the readily prepared DKIM-Signature(s), is forged, a DKIM-AC: header field is generated which covers the logical recipient subset, and the resulting message is then sent.¶
ACDC aware recipient domains are expected to manage a message DKIM-AC: identity cache to mitigate replay attacks. (Hint: the DKIM-AC: signature seems like a natural cache key source, see below.)¶
The DKIM "x=" tag MUST be used to place a lifetime constraint when creating signatures, to allow finite identity cache sizes. The maximum "t=" to "x=" delta MUST NOT be greater than 864000 seconds (ten days: to reach into the next working week). Example delta values for tag auto-generation may be the bounce defaults 432000 seconds (five days: used for example by the Mailman2 and mlmmj mailing-list managers and the postfix MTA), 345600 seconds (four days: OpenSMTPD MTA), 172800 seconds (two days: Exim MTA).¶
To keep the identity cache a write-once data structure, ACDC senders MUST NOT generate DKIM-AC: header fields with more than half of the 100 recipients that SMTP[RFC5321] section 4.5.3.1.8 guarantees as a minimum, unless a DNSSEC[RFC4033][RFC4034][RFC4035]. protected _dkimacdc DNS entry, as below, announced a limit. If more recipients need to be addressed on a single domain, multiple message forges with recipient subsets must be generated: like this each message forge is "atomic", and the DKIM-AC: header field covers all the SMTP envelope. SMTP MTAs of domains which announce ACDC MUST support at least half the minimum limit required by SMTP[RFC5321] (section 4.5.3.1.8).¶
Informative remark: Implementations MAY offer configuration options to specify other (higher, lower) recipient limits. Like this the much higher limits in actual use (for example, the Exim MTA default is 50000) can be utilized.¶
An ACDC aware recipient domain that receives an "acdc=" tagged message without a DKIM-AC: header field MUST reject the message with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 MUST be used. It MUST likewise fail if the DKIM-AC: header field does not cover the SMTP envelope data. (It SHOULD test for a superset of recipients, and only fail if an envelope recipient is not included in the DKIM-AC: header field.) It MUST reject messages which fail the signature check of a DKIM-AC: or DKIM-Signature: header field, or the condition and flag check verification, with SMTP reply code 550; the enhanced status code MUST be 5.7.7. Senders MAY use Delivery Status Notifications[RFC3461] to fine-tune the resulting behaviour.¶
The syntax of this header field is the usual semicolon
separated list of DKIM-style tags of unspecified order;
unknown tags MUST be ignored.
It is used to cryptographically link the SMTP envelope
to the sent IMF mail message.
The "sn=" tag is the linked DKIM-Signature sequence number,
best placed early.
Multiple signatures with the same sequence number,
but different algorithm may exist,
and so may DKIM-AC header fields.
The selector of the linked signature is given by the "s=" tag,
the used algorithm can be deduced from there.
The "dr=" tag value is the recipient domain.
The "mf=" tag is the
SMTP[RFC5321]
MAIL FROM
of the covered message, the complete addr-spec,
whereas "rt=" tag(s) contain only the local-parts of
RCPT TO
s.
(Warning:
SMTP[RFC5321]
address local-parts permit quoted-strings.)
Mirroring DKIM-Signature the tag list is concluded with the
"b=" tag that is the cryptographic signature data of the
DKIM-AC: header field.
However, the reassembled (see
DKIM[RFC6376],
section 3.5) "b=" value of the linked DKIM-Signature is
"virtually assigned", and included when creating the
cryptographic signature;
thereafter the "b=" tag is assigned its own value.¶
All instances of DKIM-AC: header fields MUST be removed by ACDC-aware software as soon as possible; they MUST NOT be delivered by local delivery agents as part of the message, and MUST NOT be part of rejected messages. However, if a domain is only an intermediate, which was neither directly addressed nor which originated the mail, and which does not modify the SMTP envelope either, then it MUST NOT remove the "current" DKIM-AC: header field, and it MUST NOT generate a new one.¶
The syntax of this DNS resource record is the usual semicolon
separated list of DKIM-style tags of unspecified order;
unknown tags MUST be ignored.
However, FWS
separation of tag, equal sign, and value
is not allowed.
The optional tag "rl=" contains an unsigned integer that asserts
the guaranteed minimum number of recipients that may be used as
RCPT TO
s in a single transaction;
it may be as small as 1.
A value of 0 equals 1.
The tag "v=" and "a=" mirror their DKIM tags,
however, "v=" is optional,
and none to multiple "a=" tags MAY exist:
they indicate, in descending order, the most desirable
algorithms for this domain.
Senders SHOULD try to honour the first fit,
and exclusively so if the algorithm is a well established one.
(For example, at the time of this writing, only RSA-SHA256 meets
this requirement, ED25519-SHA256 does not.)
DNS CNAME chains MUST be followed when looking
up this DNS RR.¶
Whenever an ACDC enabled domain detects during DKIM-Signature creation that the relaxed representation of a message was modified along its flight from ingress to egress, for example, when it was processed by a mailing-list which tagged the subject and added a message footer, a DKIM-Diff: header field has to be created.¶
Informative remark: In an unbroken chain of ACDC signatures the DKIM-Diff: covered changes can be applied in reverse order of creation in order to cryptographically verify all intermediate DKIM signatures, back to the original version as sent by the sender.¶
The syntax of this header field is the usual semicolon separated list of DKIM-style tags of unspecified order; unknown tags MUST be ignored. The "sn=" tag is the linked DKIM-Signature sequence number, best placed early. The "c=" tag identifies the compression method used for the data in "hd=" and/or "bd="; the value "z" means ZLIB[RFC1950], whereas "xz" means [LZMA2]. ZLIB MUST be supported by signers and verifiers, LZMA2 MUST only be supported by verifiers. (FOSS implementations of all compression types are available.) The "hd=" tag is used to store differential data for header fields, "bd=" that for body content. Both tags are optional, but at least one exists. The data is the results of the BSDiff differential algorithm, as below, compressed with the method given in "c=", then BASE64[RFC4648] encoded.¶
Informative remark: The higher cost of using [LZMA2] for compression could be amortized by lesser necessary I/O. When using the [BSDIPA] implementation as below, inspecting header data can aid choosing an appropriate compression algorithm.¶
All header fields covered by the DKIM-Signature MUST be included, as MUST be all MIME[RFC2045] related header fields, regardless of their presence in the DKIM-Signature. All ACDC enabled DKIM-Signature: and DKIM-Diff: header fields MUST be included. Other than that the advice of DKIM[RFC6376], section 5.4.1, on recommended signature content, still applies, but is hereby extended with the Author Header Field[RFC9057].¶
ACDC aware software is urged to "oversign" aka "seal" aka sign fields that are not present at the time of signing, how DKIM calls it, in order to protect message modifications. Since only the newest DKIM-Signature is checked, and modifications can be undone, messages should be protected as much as possible.¶
The differential changes are created with the DKIM "relaxed" normalized header field and body data, respectively, as seen on egress, alongside the equally normalized data present before modifications took place, that is, on ingress.¶
Informative remark: For non-integrated systems like mail filters for example the DKIM-Store: header field can be used to pass around the necessary data in between the ingress side that sees the original message, and the egress side which will dispatch the modified variant.¶
The header fields MUST be sorted byte-wise by-value by-name, the formed subgroups MUST remain in the header stack order defined by DKIM[RFC6376] section 5.4.2, Signatures Involving Multiple Instances of a Field.¶
The BSDiff algorithm of Colin Percival, which has excellent characteristics, is then used to create a binary delta of the header or body lines.¶
There is a FOSS [BSDIPA] plug-and-play ISO C99 and perl implementation available that iterated the FreeBSD operating system implementation of BSDiff, and includes further references on the algorithm.¶
Overall, the patch consists of the header, followed by the control data. Thereafter the two byte (8-bit octet) streams of differential data (in reverse order) and extra data conclude the patch.¶
The header and the control data consist of 32-bit signed integers, stored in big endian byte order (as above).¶
The control data is a stream of tuples of three values each, the first denoting the length of differential data to copy in bytes, the second that of extra data to copy; the read positions within the differential and extra data move by the same amount of bytes. The last value denotes the number of bytes to seek relatively in the data source after the copying has taken place: of all the values, only this one may be negative.¶
The header consists of four values denoting the length of the control block in bytes, the length of the difference data block, the length of the extra data block, concluded by the length of the original data source; The sum of the first three values must be one less than the maximum positive 32-bit signed integer. It follows that control data copy instructions also do not exceed this value.¶
Differences are included to allow DKIM verifiers to restore previous message content for the purpose of cryptographically verifying elder DKIM-Signature: header fields.¶
This for example allows for collecting trustworthy statistics of organizational trust ([RFC5863], section 2.5). Or user interfaces may visually restore an initial From: header field when messages come from a known mailing-list.¶
For example, user interfaces could use traffic light semantics that unfold on click to traffic light semantics of all message versions, which would visualize differences (with precautions): this can empower users to make decisions on the trustworthiness of intermediates, and to, for example, enable the above mentioned From: header field restoration.¶
However, the data exists in the DKIM "relaxed" normalized variant, former states are not meant to be usable messages by themselves. For example some embedded OpenPGP signature and text couple would likely fail to verify, dependent upon the original MIME transfer encoding).¶
Informative remark: This was deemed acceptable because of the purpose of including differential changes, and because a visualization of the DKIM covered message should still be sufficient to allow users making responsible decisions.¶
Finally, the given example will likely verify as part of the complete received message, unless altered along the SMTP path: ACDC can ideally say where (and exactly what, in an unbroken ACDC chain).¶
This sections is in intermediate state¶
As of the time of this writing the email infrastructure is deeply divided due to standards like DMARC and SPF, which require mitigations to be applied in order to keep existing infrastructures in a usable state.¶
For example, SPF will not survive a single hop, which means that alias expansion will no longer work. The IETF has no solution for this problem, but the FOSS scene has created a "Sender Rewriting Scheme" so that aliases can be used regardless.¶
As another example, DMARC caused a lot of mailing-lists to apply mitigations in that either old DKIM signatures are removed, or renamed, and that the From: header field is rewritten in a "User A via List B" style.¶
This memo suggests to apply active mitigations as part of DKIM processing, temporarily, until, at some future time, the email infrastructure has adapted to a new reality.¶
MAIL FROM
SMTP envelope changed in addition,
use a "From: via MAIL FROM" notation
(as in "display-name (local-part (AT) domain) via MAIL FROM").
If that is impossible the author suggests a hypothetic and
artificial dkim__mitigate__25 local address, which ACDC aware
DKIM software detects on ingress, to treat is specially.
One could think about a special tag that holds the former real
address.
It could also be configurable.
This likely applies to mailing-lists only, which normally have
a dedicated local address that could be used, anyway.
They often do the mitigation themselves.
But it could also apply to "holiday-alias-forwards",
or when company footers etc where added to a message that
passes along the local mail system.¶
MAIL FROM
.
If a message that does not originate locally leaves the
email system on egress, with a SMTP envelope MAIL FROM
of a foreign domain, the SPF check will fail on the next hop.
The FOSS community has invented the "Sender Rewriting Scheme"
to allow the decade old and established email alias
infrastructure to continue to exist.
It would be easy to create a cache entry that maps a
synthesized local address to the non-local MAIL FROM
,
HMAC and private key protected to avoid misuse to the maximum
extend possible, that lives for say ten days, in an equal way
to "SRS", in order to let SPF tests pass, and also to be able
to undo the address rewrite when bounces are to be handled.¶
The author suggests creating a registry of header fields that shall be cryptographically be covered by DKIM/ACDC. This memo extends the list mentioned by DKIM[RFC6376] with the Author Header Field[RFC9057].¶
Public-key cryptography is the safest approach to identification of counterparts and verification of data. This specification enables DKIM to cryptographically verify SMTP envelopes, and to cryptographically verify all message transitions back to the original message sender.¶
FWS
in ag-spec.
Second its use was never encountered by the author.
But first of all
MIME[RFC2045]
introduced parameters in ABNF as
parameter := attribute "=" value
without FWS
,
and its presence complicates parsers and hinders parser code reuse.
The "acdc=" tag is defined without FWS
support.¶
This document contains a citation of Dave Crocker. Thanks to, in the order of appearance, Jesse Thompson, Richard Clayton for arguments against reliance on header field stacks, and pro the numbering scheme, and especially for noticing the partial transaction replay attack problem, Douglas Foster, Michael Thomas for explicit man-in-the-middle replay addressing; Alessandro Vesely inspired the explicitness of the E flag, and Bron Gondwana for the inspiration to split up binary differences of headers and body. A big fat acknowledgment is due to Murray S. Kucherawy. Special thanks to Klaus Schulze, Manuel Goettsching, both also as Ash Ra Tempel, Laeuten der Seele, Laurent Garnier, as well as the Sleeping Environmental Bot broadcast.¶