Network Working Group S. Nurpmeso, Ed. Internet-Draft 3 August 2026 Updates: 6376 (if approved) Intended status: Informational Expires: 4 February 2027 DKIM Access Control and Differential Changes draft-nurpmeso-dkim-access-control-diff-changes-12 Abstract This document specifies a DKIM (RFC 6376) iteration that allows cryptographical verification of SMTP (RFC 5321) envelope data, and of any signature along the message path, even beyond IMF (RFC 5322) message content changes. It addresses existing security glitches, and introduces active mitigations to embrace collateral damage effects of email solutions of the younger past by a standardized solution, also by moving complexity away from lower network protocol layers, where problems cannot be solved. It updates DKIM in certain aspects that reality has proven to be superfluous, incomplete, or obsoleted. 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 4 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Nurpmeso Expires 4 February 2027 [Page 1] Internet-Draft DKIM Access Control and Differential Cha August 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 2. DKIM Vivid Adjustments . . . . . . . . . . . . . . . . . . . 3 3. DKIM/ACDC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. The DKIX-Store header field . . . . . . . . . . . . . . . . . 18 5. Access Control . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. The DKIX-AC header field . . . . . . . . . . . . . . . . 19 5.2. The _dkimacdc.DOMAIN DNS TXT RR . . . . . . . . . . . . . 21 6. Differential Changes . . . . . . . . . . . . . . . . . . . . 21 6.1. The DKIX-DC header field . . . . . . . . . . . . . . . . 21 6.2. Preparing patch creation . . . . . . . . . . . . . . . . 22 6.2.1. Patch content . . . . . . . . . . . . . . . . . . . . 23 6.2.2. BSDiff patch content adaption . . . . . . . . . . . . 24 6.2.3. An example algorithm . . . . . . . . . . . . . . . . 24 6.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Mitigations for Future . . . . . . . . . . . . . . . . . . . 27 7.1. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 28 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 11. Normative References . . . . . . . . . . . . . . . . . . . . 34 12. Informative References . . . . . . . . . . . . . . . . . . . 34 Appendix A. Header field database . . . . . . . . . . . . . . . 36 A.1. Example code for managing "hfdb-bits" . . . . . . . . . . 38 Appendix B. Further DKIM Updates . . . . . . . . . . . . . . . . 40 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction 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. Whereas DKIM[RFC6376] includes a rudimentary approach to inspect IMF[RFC5322] header field modifications (the "z=" tag content; also to point to the "l=" tag), the overall design was agreed in not to survive them (compare [RFC6377]). Nurpmeso Expires 4 February 2027 [Page 2] Internet-Draft DKIM Access Control and Differential Cha August 2026 | The resulting paradigm is "as long as one signature can be | successfully verified, DKIM verification will succeed". It is a | context-free "take it and accept it" approach. 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 complicated the situation, in that false attribution may now technically be avoidable, but mitigations of practice like "user A via B" will still be attributed to "A" by a human for one, and then, moreover, anything is valid, if just one signature is. ([RFC9057] elaborates more context.) Potentially many signatures may exist in a message. DKIM[RFC6376] gives hints on how verification can be performed, but in practice mitigations are applied: elder, especially broken signatures are removed, or renamed, as changes are performed on message content. Especially mailing-lists, or, in general, hops that cross the [RFC3461] definition of a _"final delivery for the message"_ act like this. A standardized approach to guide hops down the message path to avoid excessive network traffic and other resources during message verification would be beneficial. 1.1. Conventions and Terminology This document uses the terminology of The Open Group Standard Base Specifications, Issue 8, Volume 1, Chapter 1.6, Terminology, addended by Part A, A.1.6 Terminology. The term "FOSS" refers to Free and Open Source Software. The term "privately encrypt" is used to denote that the software should take appropriate steps to ensure data encryption and key security. 2. DKIM Vivid Adjustments This document obsoletes certain unused or incomplete aspects of DKIM[RFC6376], and adjusts vivid parts as follows. The full context of the changes will become clear as the remains of this document unfold. | _Informative remark:_ The protocol changes apply only to | signatures signalling compliance with the iterated variant | presented in this document. Nurpmeso Expires 4 February 2027 [Page 3] Internet-Draft DKIM Access Control and Differential Cha August 2026 * Temporary errors encountered during DNS record lookups shall be passed through to the SMTP[RFC5321] layer as such via a 451 or 455 reply code; with enhanced SMTP status codes[RFC3463] 4.4.3 ("routing server failure") or 4.7.5 ("cryptographic failure"), as appropriate, shall be used. | _Informative remark:_ Verification and creation of | cryptographic signatures becomes crucial, therefore DNS | failures can no longer be subject of local policy. Among | others the DKIM sections 4.2 "Interpretation", 6.3. "Interpret | Results/Apply Local Policy" and 8.15. "Attacks Involving Extra | Header Fields" are declared "changed" in meaning to stand back | behind this paradigm. * Obsoletes usage of "simple" canonicalization for header fields, and of "relaxed" canonicalization for bodies. Header fields shall only be canonicalized with the "relaxed" algorithm, and bodies only with the "simple" algorithm. | _Informative remark:_ Due to DKIM/ACDC's, as below, tracking of | differential changes, being able to easily handle potentially | large message bodies with minimal most effort and potentially | shared resources is important. Likewise it is beneficial to | minimize whitespace (folding) fuzz of header fields. * It is herewith clarified that during "relaxed" canonicalization of header fields any encountered carriage-return CR or line feed LF shall be ignored. This to make official the approach taken by existing implementations to deal with compatibility issues required by IMF (RFC 5322). | _Informative remark:_ The milter protocol in widespread use for | implementing SMTP extensions or support, like DKIM, does not | pass CRLF during header processing, but uses LF. Also because | DKIM processing is byte-based, and does not know about "quoted- | pair" at all, the specification was in at least theoretical | friction with reality. * The signature expiration tag "x=" is no longer optional: it shall be used to place a signature lifetime constraint. The valid maximum "t=" to "x=" delta is 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), or 172800 seconds (two days: Exim MTA). Nurpmeso Expires 4 February 2027 [Page 4] Internet-Draft DKIM Access Control and Differential Cha August 2026 | _Informative remark:_ The DKIM section 5.2 defined "reasonable | validation interval before [keys are] being removed from the | key server" is being pointed to in that respect. | _Informative remark:_ For "ingress" signatures with the DKIM/ | ACDC "I" flag, as below, this limit does not apply: local | policy can support delayed verification of validation results | as desired, heeding the DKIM "12 digit" (section 3.5, "t=" tag | description) limit. * A "t=" older than the allowed maximum "t=" to "x=" delta, or more than 84421 seconds in the future, shall cause signatures to be ignored, or the message to be rejected in case the signature "is vivid"; in the latter case the reply code 550 is to be used; with enhanced SMTP status codes[RFC3463] 5.4.7 ("delivery time expired") shall be used. (A DKIX-Sig:, as below, with the highest "sequence" is "vivid".) * The AUID (DKIM, section 3.5, "i=" tag description) should be used, and enable the signer to identify the originator for whom the signature is created. The value need not hinder obfuscation, for example hiding real address(es) for the purpose of cryptographically protecting email[RFC9788] in an end-to-end security scenario[RFC9787]. * Configuration directives to verify that for locally created messages the SMTP[RFC5321] envelope MAIL FROM matches the originator (a sole address of the IMF[RFC5322] From: header field, or the address of the Sender: header field, if From: contains multiple addresses), may be offered. | _Informative remark:_ Offering an easily accessible constraint | to ensure matching identities of envelope and message data for | messages newly injected into the email system prevents an | entire type of attack, which is not easy to counteract | otherwise. | _Informative remark:_ Local policy may allow mismatches if the | domain of the originator does not match the current (signing) | domain. Alternative approaches, like databases of allowed | "aliases", may exist. * DKIM section 3.7 defines how "Computing the Message Hashes" has to be performed. Different to the RSA algorithm (RFC 8017) solely defined for DKIM at the time section 3.7 was written, modern algorithms (may) include (a) checksumming step(s) themselves. It may make sense to avoid calculating a "prehash" to feed it into the signature algorithm, but to yield this step entirely to the Nurpmeso Expires 4 February 2027 [Page 5] Internet-Draft DKIM Access Control and Differential Cha August 2026 signature algorithm. Section 3.7 is herewith modified in that the input to "sig-alg", the "data-hash", can adapt to standardized algorithms as appropriate. If an algorithm chooses adaption, "hash-alg" is only used to produce the "body-hash", whereas the input formerly used to create the "data-hash" is fed in full into "sig-alg", instead of to "hash-alg". More formally, the new pseudo-code for the signature algorithm is: body-hash = hash-alg (canon-body) data-hash = hash-alg (h-headers, D-SIG) signature = sig-alg (d-domain, selector, data-hash / (h-headers, D-SIG)) | _Informative remark:_ An algorithm that exists in "adopted" and | "non-adopted" variants shall be treated as a single algorithm. | For example, a constraint like "one X per algorithm" would not | allow both variants to be used. | _Informative remark:_ For hybrid algorithms, which consist of | multiple individual "sub-algorithms", the algorithm is said to | use adaption if at least one "sub-algorithm" chooses that | approach. To support such mixed-mode algorithms | implementations shall be capable to make available both, "data- | hash" as well as "(h-headers, D-SIG)". 3. DKIM/ACDC The DKIM[RFC6376] iteration Access Control and Differential Changes: * Changes paradigm: there is absolute trust in public key cryptography. | _Informative remark:_ A correct cryptographic signature is the | only known way to safely ensure message validity. A failing | integrity check is described by [RFC3463] from 2003 as _"the | message was corrupted or altered"_, meaning the system is | _"unable to validate the message"_. Furtherly processing and | delegating such a message is misguided, not only in a world in | which not even communication handshakes succeed in an identical | situation. * Introduces new header fields: DKIX-Sig: is the signature, DKIX-DC: covers differential changes, as necessary, and DKIX-AC: constitutes a access-control signature. There is also a "temporary" DKIX-Store: header field. These header fields shall be treated like trace headers, just like DKIM-Signature:. Nurpmeso Expires 4 February 2027 [Page 6] Internet-Draft DKIM Access Control and Differential Cha August 2026 | _Informative remark:_ DKIM/ACDC treats the DKIM-Signature: | header field as actively maintained legacy that is left alone, | except that any such field generated by DKIM/ACDC aware | software links to its corresponding DKIX-Sig: successor via the | new "w=" tag, and may (will) be removed by later DKIM/ACDC | aware hops as part of active mitigations (Section 7): the DKIM | section 4.2 "Interpretation" is cleared away in this respect. * Introduces a legacy flag second: all DKIM legacy items, like DKIM- Signature:, become obsolete after "t=" 2021161080 (0x78787878 hexadecimal), which corresponds to ISO 8601 2034-01-18T01:38:00Z. DKIM/ACDC aware software shall not generate nor interpret legacy items when the "t=" tag denotes a larger timestamp. It may have configuration options to do so much earlier, in general, or for certain network communication partners. * Places signatures in an ordered, numbered, random-accessible sequence which' state correlate. (Signatures generated at the same hop share a sequence number.) | _Informative remark:_ With DKIM/ACDC it can be, and usually is, | sufficient to verify only the cheaply detectable highest | numbered signature. * Adds reversible data difference tracking, and as such supports cryptographical content verification of any (DKIM/ACDC aware) intermediate message state, up to the initial variant as sent by the author (ideally reflected by the Author: header field). * Introduces access control by cryptographically protecting the SMTP[RFC5321] envelope, that is, RCPT TO addresses as well as the MAIL FROM address. Message replay and backscatter bounces become detectable. * The advices of DKIM section 5.4 and 5.4.1, "Determine the Header Fields to Sign" and "Recommended signature content", respectively, are replaced with a dedicated header field database (Appendix A), the members of which shall be signed. Database members are not announced via the "h=" tag. Instead DKIX-Sig: uses a "visualized" bitset that is stored in the "hfdb-bits" subtag of the "acdc=" tag. | _Informative remark:_ For DKIX-Sig: "h=" becomes an optional | tag that is only used to denote header fields uncovered by the | database. Nurpmeso Expires 4 February 2027 [Page 7] Internet-Draft DKIM Access Control and Differential Cha August 2026 | _Informative remark:_ The DKIM saying of section 3.5, "h=" tag | description, to _"sign fields not present at the time of | signing"_, is implicit in that header field injection is | impossible: each hop signs the message state it sees, content | changes are recorded via DKIX-DC: differential changes. | _Side note:_ It is not up to DKIM(/ACDC) to decide upon the | validity of changes. With DKIM/ACDC it is just like today, but | in a standardized fashion: each hop "mitigates away" elder | message instances to create a valid signature environment for | hops further down the message path. Different to today, | however, these hops can cryptographically verify and inspect | elder instances up the path, back to the message author. | Without content changes nothing is mitigated, with changes | mitigations can be unrolled. * Due to a sequential state machine approach certain flagged conditions (along the message path) can be recognized only by looking at the highest numbered signature. * Introduces new signature algorithms, which shall be used exclusively. As of now the hybrid "Key Type" (DKIM section 7.6) "EDDAPQ-SHA3-256" is introduced: the hash variant is SHA3-256[FIPS202], the non post-quantum part is the PureEdDSA variant Ed25519[RFC8032] using the standardized ASN.1 encoding[RFC8410] for its keys; the post-quantum part of "EDDAPQ" uses the "data-hash" adaption introduced above. The post-quantum part of this key type will be chosen from algorithms that will be proofed by the 2027 NIST consideration. Until a later document addendum defines that quantum algorithm, the ED25519 key part shall be used alone and exclusively, and the "Q" and "q" flags, as below, shall be set in the "acdc=" tag. Once an algorithm is defined in variants for security levels 1 and 3, usage of the flags "Q" and "q" (as appropriate, see there) is declared obsolete. | _Informative remark:_ After a transition period that ends with | the post-quantum flag second "t=" 1903260017 (0x71717171 | hexadecimal), which corresponds to ISO 8601 | 2030-04-24T11:20:17Z, the conditions "Q" and "q" flag shall | cause verification failure with SMTP[RFC5321] reply code 550; | with enhanced SMTP status codes[RFC3463] 5.7.6 ("cryptographic | algorithm not supported") shall be used. Nurpmeso Expires 4 February 2027 [Page 8] Internet-Draft DKIM Access Control and Differential Cha August 2026 The hybrid of the DNS-announced public key, as well as the signature, shall be the concatenation of the public keys / the signature results of both parts of the algorithm. (That is a simple whitespace ignoring concatenation of the base64[RFC4648] data of the PEM content / of the signature outcome.) The actual level of the post-quantum algorithm can be derived from the lengths of the public key and algorithm, which shall match. The (ASN.1 wrapped) ED25519 public key alone is 44 bytes (base64 encoded: 60 bytes), its signature is 64 bytes (base64 encoded: 88 bytes). | _Informative remark:_ Of the 2027 NIST consideration round the | algorithms FAEST and MQOM appear to be the most attractive for | DKIM/ACDC. For FAEST it would likely be the variants EM-128s | and EM-192s with the security levels 1 and 3, the public key | sizes 32 and 48, and the signature sizes 3906 and 9340, all | respectively. (Signing and verification taking about 3ms and | 14ms, respectively, on a 12th Gen i7 processor.) For MQOM the | picture with its many more variants is even better, with faster | execution times and smaller signature sizes; the public keys | tend to be a few bytes larger, but even the largest level 3 | variant has a 120 bytes public key, and creates a 8548 bytes | signature. (With signing and verification taking about 4ms for | level 3 on a 12th Gen i7 processor.) Even pre-quantum implementations shall verify that the public key of the quantum part is 160 bytes at maximum, and that the signature of the quantum part is 10000 bytes at maximum. (Plus base64 encoding overhead.) | _Informative remark:_ If a legacy DKIM-Signature: header field | is generated, it may, or, for maximum compatibility, should be | generated with the RSA algorithm. It shall not be generated | with a new key type. * All DKIX header fields shall not have FWS surrounding the "=" separator in key/value lists. More formally, this specification obsoletes the use of FWS in "ag-spec". (DKIM/ACDC "reverts" back to "original policies" as used by MIME[RFC2045].) The DKIM[RFC6376] iteration Access Control and Differential Changes creates DKIX-Sig: signature header fields, which are identical to DKIM-Signature: header fields except for the new "acdc=" and "dch=" tags, the missing "c=", "v=" as well as "l=" and "z=" tags, and the changed semantics of the now optional "h=" tag. Nurpmeso Expires 4 February 2027 [Page 9] Internet-Draft DKIM Access Control and Differential Cha August 2026 The "dch=" tag holds the checksum of the canonicalized data of all existing DKIX-DC: header fields, each header field concluded with a CRLF, sorted in reverse header stack order as defined by DKIM[RFC6376] section 5.4.2, "Signatures Involving Multiple Instances of a Field" (which should be equal the reverse "sequence" order), with the DKIX-DC: header created for this signature, if any, last (at the top of the stack). The "acdc=" tag consists of multiple subtags separated with colon (U+003A, :). It should be placed early, before tags like the new "dch=", but also "bh=", and "h=", for example. * The tag starts with the "sequence" subtag, a decimal number starting at 1, or incremented by 1 from the highest DKIM/ACDC "sequence" encountered in the message; the maximum value is 99, which seems sufficiently high in hindsight to SMTP section 6.3 "Loop Detection": if incrementing would result in overflow, the message shall be rejected; detected sequence holes shall 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 shall be used. Multiple signature header fields with the same "sequence" may be generated by a domain, in which case each field shall use a different "s=" selector, and maximally one selector per algorithm shall be used. | _Informative remark:_ Signatures with the same "sequence" shall | be identical in respect to the tags "acdc=", "h=", "dch=" and | "bh=", as well as "d=", "i=", "t=" and "x=". * The second subtag after "sequence" is "hfdb-bits", a "visualized" (base 36) bitset that stores 5 bits per byte (exemplary C code exists in Appendix A.1), and records presence of header fields which are part of the header field database (Appendix A). (Standard conforming messages always have multiple header fields, but "hfdb-bits" shall at least be "0".) | _Informative remark:_ The optional "h=" tag is only used for | header fields which are not included in the database. An empty | "h=" tag shall not be generated. * The third subtag contains a list of flags that announce state and conditions of the message at its current point in the message path. If a flag is said to be necessary, all flags that it implies must also be set, even if not explicitly mentioned. Flag description is normative. (Again: note the missing FWS separators around "="!) ABNF[RFC5234]: Nurpmeso Expires 4 February 2027 [Page 10] Internet-Draft DKIM Access Control and Differential Cha August 2026 # DKIX-Sig: acdc-tag = %x61 %x63 %x64 %x63 "=" sequence ":" hfdb-bits ":" 1*flag [ ":" id ] sequence = 1*2DIGIT; DIGIT from RFC 5234 hfdb-bits = 1*9(%x30-39 / %x41-56 / %x61-76) flag = "A" / "C" / "D" / "E" / "I" / "L" / "N" / "O" / "P" / "Q" / "q" / "R" / "S" / "s" / "T" / "t" / "U" / "V" / "v" / "X" / "x" / "Y" / "y" / "Z" / "z" id = *(base64string / "-"); base64string from RFC 6376 dch-tag = %x64 %x63 %x68 "=" base64string; from RFC 6376 # DKIX-DC:, DKIX-AC:, [DKIM-Signature:] link-tag = %x77 "=" sequence A (_anything-checked_) Alongside the "V" flag (see there) only: all existing signatures were verified. C (_data-collection_) The hop signals interest in collection and (periodical) report of statistical informations regarding (this) message(s). The exact semantics are out of scope for this document. As an example of what this could be DMARC aggregate reporting (RFC 9990) may be mentioned. D (_differential-changes_) The message content was modified at this hop, differential changes were generated, and are stored in a DKIX-DC: header field. The "Y" flag has to be set. E (_envelope-changed_) The SMTP[RFC5321] envelope (MAIL FROM and/ or RCPT TO) was modified. The "O" or "N" flag has to be set if the MAIL FROM changed. The "y" flag has to be set. But for "I"ngress signatures a new access control (Section 5) evaluation has been performed. Existing DKIX-AC: header fields shall be removed. I (_ingress-results_) This signature header field was generated at ingress. Special rules apply to these signatures, for example unlimited "x=" tag expiration. | _Informative remark:_ Such fields offer a cryptographically | verifiable message state authentication contract: for as | long as the ("local") "s=" selector announced key is Nurpmeso Expires 4 February 2027 [Page 11] Internet-Draft DKIM Access Control and Differential Cha August 2026 | available, the message state at the time it entered the | "local" email processing system is assurable by for example | user interfaces. All signature instances with this flag set shall be removed when messages enter and leave the email system. This is meant as simple: if the flag is set, remove the field. | _Informative remark:_ If a local "I" message is removed on | egress, the newly generated DKIX-Sig: overtakes its logical | flag subset. L (_layer-security_) This hop announces that it supports the SMTP[RFC5321] extension STARTTLS[RFC3207]. The flag shall only be set if any incoming SMTP connection (to the domain announced in the "d=" tag) will reach a TLS-enabled endpoint. _(Author remark: "Dies mein Abendgruss folgend dem SRV DNSSEC Blues" / "here my evening greeting following the SRV dnssec cheatin'".)_ N (_nack_) The hop detected an unprotected or "irregulary changed" SMTP envelope (compare the mutual exclusive "O" flag), but the message will be accepted, necessarily alongside the "Z" flag. Some non DKIM/ACDC aware hop changed the SMTP envelope. If there is a DKIX-AC: header field, the access control (Section 5) check shall instead fail if (at least the domain of) the MAIL FROM is unchanged. The "E" flag has to be set. | _Informative remark:_ Except for messages with "sequence" 1 | the "N" state is usually mitigated (Section 7.1), causing | the "O" flag condition. O (_origin_) 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 sole address of the From: header field, or the sole address of the Sender: header field, if From: contains multiple mailboxes, and the "sequence" is 1. Or it means 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. Nurpmeso Expires 4 February 2027 [Page 12] Internet-Draft DKIM Access Control and Differential Cha August 2026 P (_postmaster_) Postmaster mode. With this flag set the behavior of DKIM/ACDC borders test mode in that rejections must not occur (due to DKIM/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 the "sequence" 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 the only SMTP[RFC5321] RCPT TO recipient, then the "P" flag has to be set. Once set, all future DKIM/ACDC signatures must copy it. It shall, however, be removed when in conjunction with the "E" flag the according SMTP envelope conditions are no longer satisfied. Q (_no-quantum-ingress_) The software is not post-quantum capable, or it did not detect, but anyway did not verify the post-quantum portion(s) of the signature(s) on ingress, if any. It verified the length limits of a possibly existing quantum part, as documented above ("eddapq-sha3-256" key definition). Use of this flag, and the conditions it signals, shall cause message rejection if the "t=" tag denotes a time after the post-quantum flag second, as above. q (_no-quantum-egress_) The software is not post-quantum capable, and it ignored a possibly existing quantum part of the key indicated by the "s=" selector. Use of this flag, and the conditions it signals, shall cause message rejection if the "t=" tag denotes a time after the post-quantum flag second, as above. | _Informative remark:_ Users may forget to change the | selector when they upgrade to PQ. Explicitly signal the PQ | state of the signer to avoid that malicious hops extend a | non-PQ "b=" with data that would be treated as the PQ part | of a hybrid key by verifiers otherwise. R (_reputation_) Reputation check to collect organizational trust ([RFC5863], section 2.5) along the signature chain was performed. Nurpmeso Expires 4 February 2027 [Page 13] Internet-Draft DKIM Access Control and Differential Cha August 2026 On top of the "V" (and possibly "A") flag(s) this means that all differential changes have been applied, and all signatures (at least one per "sequence") along the chain have been verified, and the entire chain validated correctly. Only in signatures with a "sequence" greater than 1, and without the "z" flag. | _Informative remark:_ The presence of "R" reveals local | state publically; however, in a chain of trust this seems | desirable even. The use of organizational trust may for | example mean to perform full reputation checks more and more | sparingly, the higher the trust, falling back to only random | checks. (For a more complete example, see [RFC5863], | section 2.5.) S and s Only in conjunction with the "I" flag: upon ingress the SPF[RFC7208] state was, or was not, respectively, successfully verified. | _Informative remark:_ From DKIM/ACDC's point of view SPF is | legacy, and it actively mitigates (Section 7.1) it to | transpose trust to DKIX-AC: (also see the "N" flag). With | DKIM/ACDC SPF users can announce the strict -all mode that | allows SPF verifiers to apply policy. T (_trust-required_) This hop requires complete trust to be put into its signature. In general all DKIX-DC: header fields were removed, or at least their "h=" and "b=" tags erased, applying changes for verification of elder signatures is therefore impossible. Corresponding additional flags have to be set, like "Z". Please read about the "t" and "U" flags. t (_trust-wanted_) This is like "T", except that DKIX-DC: header fields are not (yet) removed, so that elder signatures (to the extend as indicated by the usual DKIM/ACDC flag machinery) can be verified. | _Informative remark:_ the "T" and "t" flags, as well as the | "U" flag, are meant to adapt to operational reality. There | "trusted proof points" are hired to handle email, to apply | all the necessary checks for, and removal of spam, | malicious, dangerous, or otherwise undesired message (MIME | part) content, before passing the results further to their | real recipients. As of today only the "equivalent of T" is | a known mode of operation; DKIM/ACDC, however, allows for a | new business model via "t": the "trusted proof point" | readily prepares messages just like today, but also creates Nurpmeso Expires 4 February 2027 [Page 14] Internet-Draft DKIM Access Control and Differential Cha August 2026 | and includes a DKIX-DC: header field to undo these | modifications, as well as keeping all elder DKIX-DC: header | fields intact. (Read: simply through the normal DKIM/ACDC | mode of operation, except for setting the "t" flag in | addition.) Turning a "t" message into a "T" message | practically means nothing but removing the DKIX-DC: header | fields, or at least erasing their "h=" and "b=" tags: an | operation that can fastly and safely be performed by | simplemost command line utilities or scripting languages, | thanks to the plain-text nature of SMTP[RFC5321], of | IMF[RFC5322] messages. DKIM/ACDC aware software may also | offer a mode which removes DKIX-DC: header fields, or at | least erase their "h=" and "b=" tags, after the signature | verification step (and creation of an "I" signature) for | messages tagged "t" coming from a configurable "trusted | proof point". | _Informative remark:_ because DKIX-DC: header fields are | covered by the "dch=" hash, removing them still allows for | successful signature verification, simply by trusting the | original "dch=" checksum. DKIM/ACDC's "t" flag allows | customers to perform a complete "R" reputation check on data | delivered by "trusted proof points". (To be written or | extended message access software could also be allowed to | access more portions via DKIX-DC:.) It is only their users | verifying "I" ingress signatures who have no option but | putting trust into "dch=" hashes. U (_unfused-trust_) The hop notifies that the next hop is allowed to modify the content of the message without mitigating (Section 7.1) away the user and domain; that is to say that it is legitimized to impersonate for this hop, that changes applied by the next hop in regard to this hop are to be trusted. It does not affect the flag machinery, but only the mitigations. Also see the "T" and "t" flags. This flag shall only be set in conjunction with the "O" flag. | _Informative remark:_ For example if an organization routes | its email through some service provider that ensures format | and visual style of messages, that ensures URL validity, | including possible rewrite to certain cloud storage | locations, etc. It then could set "U" to flag that the "T" | (or "t") flags that the service provider will set are | expected. | _Informative remark:_ As of the time of this writing the | infrastructure likely will not allow this "U" mode of | operation, since SPF would still cause the SMTP envelope Nurpmeso Expires 4 February 2027 [Page 15] Internet-Draft DKIM Access Control and Differential Cha August 2026 | check to fail, and DMARC would still cause the IMF content | check to fail. But even in the hostile environment of today | "U" can legitimize a "T" or "t" set by the next hop, | mitigations notwithstanding. | _Warning:_ This flag is dangerous as potentially a hop X can | set "U", and rise trust awreness for hop Y, where X and Y | belong, and have malicious intent. V (_verified_) DKIM/ACDC signatures verified successfully. The message and access-control signatures with the highest "sequence" have been verified correctly, the (otherwise untested) DKIM/ACDC signature chain is complete, and their flags make sense (in the sequence). In conjunction with the flag "R" even deeper inspection was performed. If multiple signatures with the same highest "sequence" exist, the verifier behavior is unspecified in that "V" signals success: at least one signature was checked, and all tested signatures verified successfully. If however all signatures were verified, the "A" flag can be set; in single-signature cases the "A" flag may be omitted. Only in signatures with a "sequence" greater than 1. v (_verified-legacy_) DKIM signature verified successfully. (Mutual exclusive with "V".) In signatures with "sequence" 1, then missing the "O", but with the "N" flag, it means the message originated at a non DKIM/ ACDC aware hop, and normal DKIM processing was performed and succeeded. If the signature covering "RFC5322.From" verified the "Z" flag must be set, otherwise "z". In messages with a higher "sequence" it comes alongside the "X" flag: necessarily the DKIM/ACDC chain was broken, and the message changed, by an intermediate non DKIM/ACDC aware hop. The "z" flag must be set. X (_x-rated_) DKIM/ACDC verification failed. Also see "v" and "x" flags. The "z" flag must be set. x (_x-rated-legacy_) "Plain old DKIM verification" failed, or there was no (more) signature to verify. Nurpmeso Expires 4 February 2027 [Page 16] Internet-Draft DKIM Access Control and Differential Cha August 2026 In signatures with "sequence" 1, then missing the "O", but with the "N" flag, it means the message originated at a non DKIM/ ACDC aware hop, and normal DKIM processing was performed and failed. The "z" flag must be set. Otherwise, with an existing DKIM/ACDC chain, it comes alongside the "X" flag: necessarily the chain was broken, and the message changed, by an intermediate non DKIM/ACDC aware hop. The "z" flag must be set. Y (_yikes-imf_) The message has seen IMF[RFC5322] modifications: somewhere along the chain the message data was modified. Once set, all future DKIM/ACDC signatures must copy it. y (_yikes-env_) The message has seen SMTP[RFC5321] envelope modifications: somewhere along the chain the envelope was modified. Once set, all future DKIM/ACDC signatures must copy it. Z (_zealed_) Announces the DKIM/ACDC chain is incomplete. The message was processed by DKIM/ACDC unaware hops. However, the message verifies correctly and seems to have never been modified non-reversibly. Once set, all future DKIM/ACDC signatures must copy it, unless later downgraded to the "z" flag. z (_zapped_) The message has seen non-reversible modifications, and cannot be cryptographically verified back to its origin. Once set, all future DKIM/ACDC signatures must copy it. When a message newly enters, or "reenters", the "z" state, all existing DKIX-DC: header fields, or at least their "h=" and "b=" tags shall be removed. | _Informative remark:_ Often "z" signals a condition that | shall cause message rejection, for example in conjunction | with the "x" flag. Local policy may behave differently for | certain conditions, but should not, as the flag combination | may reduce the hops' organizational trust ([RFC5863], | section 2.5). "id" The optional "message and bounce identifier". It is content-wise capable of storing Universally Unique IDentifiers[RFC9562]. | _Informative remark:_ It may be generated to help sending | domains to uniquely identify messages within the "t=" and | "x=" time delta, as well as to ensure that successively sent Nurpmeso Expires 4 February 2027 [Page 17] Internet-Draft DKIM Access Control and Differential Cha August 2026 | identical messages are not detected as being the same. It | shall be generated if the signature does not cover a | Message-ID: header field, and it should be used if the | uniqueness of the "msg-id" is dubious. | _Informative remark:_ Receiving domains cannot use this | identifier due to the denial of service attack surface, | regardless of collected organizational trust. Unknown flags shall be ignored. Invalid flag combinations and flag misuse, as far as detectable, and false "hfdb-bits" specifications shall result in rejection with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 shall be used. 4. The DKIX-Store header field The DKIX-Store: header field has no meaning in the email system. The sole purpose of mentioning it is to announce that it shall be removed when messages enter and leave the email system. It could for example be temporarily created and used by non- integrated mail solutions that consist of otherwise unrelated software, to pass informational data in between the "ingress" and the "egress" processing side. To address possible software bugs and configuration errors this specification enforces removal of all occurrences. | _Informative remark:_ In order to achieve locality it is suggested | to "privately encrypt" data passed around in this temporary header | field. 5. Access Control SMTP[RFC5321] delivers messages to individual domains. With DKIM/ ACDC, whenever a SMTP envelope is created or changed, all distinct domain-names found within the list of intended SMTP envelope RCPT TO addressees are collected, because messages need to be actively forged on this individual domain base: DKIM/ACDC will create and include DKIX-AC: header fields covering SMTP envelopes as messages are sent out. The domains' _dkimacdc DNS entries, as below, are queried. Dependent upon the detected state the DKIX-AC: header fields will either contain exact envelope info (DKIM/ACDC supported), or only domain names. Nurpmeso Expires 4 February 2027 [Page 18] Internet-Draft DKIM Access Control and Differential Cha August 2026 In any case the completely prepared message, including the readily prepared signatures, is forged, (a) DKIX-AC: header field(s) is/are generated which cover(s) the logical recipient subset, and the resulting message is then sent. | _Informative remark:_ "MTA-integrated" DKIM/ACDC implementations | can create _perfect fit_ DKIX-AC: header fields only for | recipients truly accepted by the receiving MTA (not hindering even | SMTP pipelining[RFC2920]), and, as necessary and possible, use | successive transmissions until all recipients have been worked. DKIM/ACDC aware recipient domains are expected to manage a DKIX-AC: identity cache to mitigate replay attacks. | _Informative remark:_ The now mandatory and constrained "x=" tag | allows for finite identity cache sizes. (A verified DKIX-AC: | signature seems like a natural cache key source.) A DKIM/ACDC aware hop that receives a message that contains at least one DKIM/ACDC enabled signature, and that does not contain a DKIX-AC: header field shall reject it with SMTP reply code 550; if enhanced status codes[RFC3463] are used, 5.5.4 shall be used. It shall reject messages which fail the signature check of a DKIX-AC: or signature header field, or the condition and flag check verification, with SMTP reply code 550; the enhanced status code shall be 5.7.7 ("message integrity failure"). It shall likewise fail if the DKIX-AC: header field does not correspond to the SMTP envelope data, with exceptions as documented for the "N" flag of the "acdc=" tag of DKIX-Sig:natures. It shall test for a superset of recipients, and only fail if an envelope recipient is not included in the DKIX-AC: header field. DKIX-AC: header fields with an "ec=" tag are treated specially. Senders may use Delivery Status Notifications[RFC3461] to fine-tune the resulting behavior. 5.1. The DKIX-AC header field The syntax of this header field is the usual semicolon separated list of DKIM-style tags of unspecified order; unknown tags shall be ignored. It is used to cryptographically link the SMTP envelope to the sent IMF[RFC5322] mail message. Nurpmeso Expires 4 February 2027 [Page 19] Internet-Draft DKIM Access Control and Differential Cha August 2026 The "w=" tag is the linked DKIX-Sig: "sequence", best placed early. Multiple signatures with the same "sequence", but different algorithms, may exist, and so may DKIX-AC: header fields. The selector of the linked signature is given by the "s=" tag, the used algorithm can be deduced from there. The "o=" tag is the domain of the SMTP[RFC5321] MAIL FROM, the "f=" tag denotes the base64 encoded "local-part". | _Informative remark:_ In conjunction with the "acdc=" "N" flag | these do not correspond to the "local email system". The "d=" tag value is the recipient domain, with one to multiple "t=" tag(s) for the base64 encoded "local-part"s of the RCPT TOs. | _Warning:_ The "d=" tag may have an empty value alongside | "P"ostmaster mode! | _Informative remark:_ Because SMTP[RFC5321] address "local-part"s | permit "quoted-string"s base64[RFC4648] encoding is used for the | "f=" and any "t=" tag in order to avoid parser complications in | and for DKIX- header fields. In case the recipient domain for a particular message forge has not announced support for DKIM/ACDC, and to strengthen SMTP envelope anonymity in permanent IMF[RFC5322] message data, the tag "f=", as well as any "t=" tag shall be omitted, and instead a "privately encrypted" "ec=" tag shall be placed: the content of this tag is base64[RFC4648] encoded, and shall correlate to the hidden "f=" and "t=" tags. | _Informative remark:_ The SMTP envelope domains are | cryptographically fixated even in the minimal variant of DKIX-AC:, | protecting users of DKIM/ACDC aware hops against replay. The | security enhancement was considered worth the resulting | unfortunate leakage of these minimal DKIX-AC: header fields to | permanent storage. Mirroring DKIM-Signature: the tag list is concluded with the "b=" tag that is the cryptographic signature data of the DKIX-AC: header field. To ensure proper linkage fixation of the DKIX-AC: signature to the signed message content the reassembled (see DKIM[RFC6376] section 3.5) "b=" value of the linked DKIX-Sig: signature is "temporarily assigned" to "b=" when creating the signature; Thereafter the "b=" tag is assigned its own value. Nurpmeso Expires 4 February 2027 [Page 20] Internet-Draft DKIM Access Control and Differential Cha August 2026 All instances of DKIX-AC: header fields shall be removed by DKIM/ACDC aware software as soon as possible: they shall not be delivered by local delivery agents as part of the message. They shall, however, exist in rejected, bouncing 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 shall neither remove the "current" DKIX-AC: header field(s), nor shall it generate (a) new one(s). 5.2. The _dkimacdc.DOMAIN DNS TXT RR The syntax of this DNS resource record is the usual semicolon separated list of DKIM-style tags of unspecified order; unknown tags shall be ignored. DNS CNAME chains shall be followed when looking up this DNS RR. The optional tag "c=" (%x64 "=") shall have the value "n" (%x6E). It announces that the DKIM-Signature: legacy header field need not be generated for messages sent to this host. Senders may follow this advise; they should follow it if they can ensure that the message will not pass intermediate hops. The optional tag "a=" (%x61 "=") represents a colon-separated list of supported algorithm names, interpreted case-insensitively. Unknown list entries shall be ignored. The entry "eddapq-sha3-256" is implied. 6. Differential Changes Whenever a DKIM/ACDC enabled domain detects during signature creation that the canonicalized representation of a message, whether header fields and/or body data, was modified, a new DKIX-DC: header field has to be created. 6.1. The DKIX-DC header field The syntax of this header field is the usual semicolon separated list of DKIM-style tags of unspecified order; unknown tags shall be ignored. The "w=" tag is the linked DKIX-Sig: ACDC "sequence", best placed early. Nurpmeso Expires 4 February 2027 [Page 21] Internet-Draft DKIM Access Control and Differential Cha August 2026 The "h=" tag is used to store differential data for header fields, "b=" that for body content. Both tags are optional, but at least one shall exist in a valid DKIX-DC: header field, and a given one shall not have an empty value. The differential data is stored in the patch format as below, which is first compressed with ZLIB[RFC1950], and then base64[RFC4648] encoded. The optional "s=" tag stores only the Sender:, whereas the "f=" tag stores only the From: header field value, which shall not be empty. Both values represent the canonicalized original (ingress) data, base64[RFC4648] encoded. | _Informative remark:_ These tags exist because active mitigations | (Section 7) of the From: (and Sender:) header fields are not | allowed to overwrite an existing Reply-To: header field, but MUAs | may want to offer users possibilities to reply to whatever was in | From: along the message path. Accessing the tags does not require | application of the differential algorithm, but only base64 | decoding. 6.2. Preparing patch creation The differential changes are created with canonicalized header fields and body data, respectively, as seen on egress, alongside the equally canonicalized data present before modifications took place, that is, on ingress. All header fields covered by the header field database Appendix A shall be included. All header fields covered by former signatures of the DKIM/ACDC chain shall be included. DKIM/ACDC enabled signatures, any other "DKIX-" header field, DKIM-Signature:, Authentication- Results: (RFC 7001), any ARC (RFC 8617) related header field, and any (other) trace header shall not be included. The header fields shall remain unchanged in the (reverse) header stack order defined by DKIM[RFC6376] section 5.4.2, "Signatures Involving Multiple Instances of a Field". | _Informative remark:_ Elder versions of this specification applied | an alphabetical header field name sorting step in an attempt to | address differential data bloat emerging by header resorting. Differential changes are then expressed with the patch content as below. Nurpmeso Expires 4 February 2027 [Page 22] Internet-Draft DKIM Access Control and Differential Cha August 2026 6.2.1. Patch content The patch format is an adopted variant of the BSDiff algorithm patch format, as below. Overall it consists of a header, followed by control data. Thereafter the two byte (8-bit octet) streams of differential data (in reverse order) and extra data conclude the patch. Erroneous patch data shall cause rejection. The header and the control data consist of 32-bit signed integers, stored in network byte order (MSF; most significant byte first). The header consists of four values denoting the length of the control data tuple block in bytes, the length of the differential data block in bytes, the length of the extra data block in bytes, concluded by the length of the original "data target" in bytes; The sum of the first three values must be one less than the maximum positive 32-bit signed integer. The number of control data tuples shall not excess the length of the original "data source" (in bytes) plus one. The control data is a stream of tuples of three values each. The first denotes the length of differential data to join in in bytes, or 0. Differential data is joined in by adding "the current" differential byte to "the current" byte of the "data source", then storing the addition result byte in the "data target". The read positions within the differential data and the "data source" move forward accordingly. The write position in the "data target" moves forward accordingly. | _Informative remark:_ Differential data is not simply copied to | the "data target", but instead joined with bytes from the | correctly positioned "data source". This allows sophisticated | differential algorithms to be used, for example ones involving | string suffix sorting, like BSDiff. Simple algorithms like the | exemplary one described below (Section 6.2.3) can store (highly | compressible) zero (NUL, U+0000) bytes as differential data to | exclusively take over data from "data source". The second value denotes the length of extra data to copy in bytes, or 0. The read position within extra data move forward accordingly. The write position in the "data target" moves forward accordingly. All tuples are worked in order, and within each tuple first the differential data, if any, then the extra data, if any, is worked. The last value of control data tuples denotes the number of bytes to seek relatively in the "data source" before the next tuple is worked. Of all the values, only this one may be negative. The overall offset within the "data source" shall not become negative after the seek. Nurpmeso Expires 4 February 2027 [Page 23] Internet-Draft DKIM Access Control and Differential Cha August 2026 | _Informative remark:_ Of all control data tuples only the first | may only perform seek adjustments without also storing data in | "data target". Even if it is otherwise ignored the seek value of | the last control data tuple must result in a valid offset. (0 is | always valid.) Other conditions shall be treated as errors. 6.2.2. BSDiff patch content adaption * 32-bit integers are used for length and offset values. This almost halves memory usage, and produces smaller patch control data. It is deemed sufficient for email purposes. * Data is stored in big endian (network; MSF; most significant byte first) instead of little endian (LSF; least significant byte first) byte order. * In order to allow for memory usage reduction during patch generation the adaption uses a shared memory region for differential and extra data: the former is therefore stored in reversed order, top down. (Reduces memory usage by the size of the target data set.) * The entire, readily prepared patch is passed through a compressor. (The original uses three separate bzip2 streams to serialize control, differential and extra data.) * The original header did not contain the size of the extra data, which was stored last, with its size implicitly extending to the end of the patch. The adaption includes the extra data size in the header, allowing more verification tests to be applied with only the header being readily parsed. This also enables the I/O layer to allocate perfectly sized memory with only the header data being available. 6.2.3. An example algorithm A very fast and simple algorithm that processes data linewise is presented here. | _Informative remark:_ Like SMTP DKIM does not know about MIME, it | treats the body (and the header fields, in that respect) as CRLF | terminated lines of bytes, with at most certain byte-based | canonicalizations applied on top. MIME reencoding (may) happen | along the message path: the MIME content-transfer-encoding type, | its line length(s), as well as character sets, and more, can | theoretically be in flux. With the advent of tracking of | differential changes it is expected that software becomes smarter, | by adapting more to what exists in messages, instead of performing Nurpmeso Expires 4 February 2027 [Page 24] Internet-Draft DKIM Access Control and Differential Cha August 2026 | "brute force modifications". For example, a service provider that | rewrites URIs within messages can ensure that the line lengths of | a base64 formatted input are preserved after the rewrite, as | base64, and with the underlaying character set being unchanged, | and that, where modifications took place, the lengths of only the | modified lines are adjusted so to keep the differential changes as | minimal as possible. In such a world a very fast linewise | algorithm is sufficient. Initialize a "list of lines" that can be iterated over uni- directionally to 0. While there is still input data from the target (egress) data set: * Search for LF line feed. If found, advance over it, otherwise use the entire remaining input. * Verify the resulting data length fits into 31-bit, minus 1. * Create a hash of the data that is proof against complexity attacks. * Put the data at the end of the "list of lines". Initialize a "hashmap" to 0. If any, store all members of the "list of lines" therein, indexed by their hashes. Initialize an "absolute position", a "current length of differences", and a "current length of extra data" to 0. Initialize a "former line" to 0. Also initialize an "overall length of differences", and an "overall length of extra data" to 0. While there is still input data from the source (ingress) data set: * Search for LF line feed. If found, advance over it, otherwise use the entire remaining input. * Verify the resulting data length fits into 31-bit, minus 1. * If the "hashmap" is not 0: - Create a hash of the data (with the same algorithm as above). - If the "former line" is not 0, check whether its next line (in the "list of lines"), if any, matches the current data. If so, make the next line the "former line", verify the resulting "overall length of differences" will fit in 31-bit, minus 1; Add that many bytes to the "absolute position", add that many bytes to the "current length of differences", add that many zero (NUL, U+0000) bytes to "differences". Nurpmeso Expires 4 February 2027 [Page 25] Internet-Draft DKIM Access Control and Differential Cha August 2026 - Otherwise search "hashmap" for the hash. (Ensure an exact data match if hashes are not unique.) If a match is found, then if either the "current length of differences" is not 0, or the "current length of extra data" is not 0, or if no control tuple has yet been dumped, then dump a control tuple first, and set the "current length of extra data" to 0; Make it the "former line", verify the resulting "overall length of differences" will fit in 31-bit, minus 1; If the offset of the start of the "former line" (within the target (egress) data set) does not equal the "absolute position", ensure the relative seek of the formerly dumped control tuple is set to the subtraction of the start of the "former line" and the "absolute position"; Set the "current length of differences" to that many bytes, set the "absolute position" to the start of the "former line" plus that many bytes, add that many zero (NUL, U+0000) bytes to "differences". (Optimization: dumping an otherwise "empty" initial control tuple is not necessary if no relative seek is to be applied.) * Otherwise the line is extra data. Verify the resulting "overall length of extra data" will fit in 31-bit, minus 1; Add that many bytes to the "current length of extra data", copy that many bytes to "extra data". After all the data has been worked, then if either the "current length of differences" is not 0, or the "current length of extra data" is not 0, then dump a control tuple. Ensure the relative seek of the last control tuple, if any, is 0. Here exemplary results of the FOSS [BSDIPA] plug-and-play ISO C99 and perl reference implementation that generates the above patch format with either the (string suffix sort based) BSDiff algorithm of Colin Percival, or the above textual variant: Nurpmeso Expires 4 February 2027 [Page 26] Internet-Draft DKIM Access Control and Differential Cha August 2026 # Email, sent to/received reencoded from ML (4621 vs 5309 bytes): $ diff -e .S1 .S2 | wc -c 2326 # BSDiff: data: ctrl=216 (18 entries) diff=3554 extra=1067 # 857 result bytes; Code 0:001 secs, ZLIB I/O 0:000 secs # (BZ2 950 / 0:001, XZ 884 / 0:126, ZSTD 875 / 0:107) # Textual: data: ctrl=108 (9 entries) diff=3043 extra=1578 # 1089 result bytes; Code 0:000 secs, ZLIB I/O 0:000 secs # (BZ2 1260 / 0:001, XZ 1144 / 0:127, ZSTD 1116 / 0:126) # Large roff manual (428420 vs rewritten 390770 bytes) $ diff -e .B1 .B2 | wc -c 241233 # BSDiff: data: ctrl=54816 (4568 entries) diff=304307 extra=124113 # 74830 result bytes; Code 0:198 secs, ZLIB I/O 0:122 secs # (BZ2 67368 / 0:022, XZ 65216 / 0:137, ZSTD 69444 / 0:144) # Textual: data: ctrl=54456 (4538 entries) diff=202309 extra=226111 # 97355 result bytes; Code 0:004 secs, ZLIB I/O 0:098 secs # (BZ2 81943 / 0:053, XZ 82364 / 0:253, ZSTD 86767 / 0:213) 6.3. Rationale Differences are included to allow DKIM verifiers to restore previous message content for the purpose of cryptographically verifying elder signatures. This for example allows for collecting trustworthy statistics of organizational trust ([RFC5863], section 2.5) in an automated fashion. Alternatively or in addition per-user decisions for certain message paths, involving certain modifications per path hop, are made possible, and can be taken into account. | For example, user interfaces could use traffic light semantics | that unfold on click to traffic light semantics of all message | versions, which would (with precautions) visualize differences. | This can empower users to make decisions on the trustworthiness of | intermediates, and, for example, request display of the From: and | Sender: header fields as created by the original message sender | for a message path that crosses a mailing-list. (As in, _"yes, i | accept this hop modifies the message and mitigates originator | fields, it is a mailing list"_.) 7. Mitigations for Future At the time of this writing the email infrastructure is deeply penetrated by mitigation code that circumvents problems incurred by standards like DMARC and SPF, driven by the desire to keep existing infrastructures (configurations) in a usable state. Nurpmeso Expires 4 February 2027 [Page 27] Internet-Draft DKIM Access Control and Differential Cha August 2026 For example, SPF will not survive a single hop, which means that alias expansion, a widely used core feature of the email infrastructure, does no longer easily work. The IETF has no solution for this problem, but the software world has created a "Sender Rewriting Scheme", involving dedicated software to implement mitigations, so that aliases can be used regardless. As another example, DMARC causes a lot of mailing-lists to apply mitigations of various form and style: old signatures are removed, or renamed, often the From: header field is rewritten in a "User A via List B" style, and the Reply-To: header field will announce the real sender, unless that was already set. The introduction of this _requirement of blind trust_ into "A via B" displays seems like a devastating psychological failure. 7.1. Mitigations This memo suggests to apply mitigations actively as part of DKIM processing, at minimum temporarily, until, at some future time, the email infrastructure has adapted to a new reality. Future engineers can then decide how to proceed further. In any case it seems wise to move decisions on actual content changes away from the SMTP layer, to reduce failures to cryptographical signature failures, and let users and/or algorithms on a higher layer decide whether a certain content change or applied mitigation is "acceptable", or not. * Remove existing DKIM/ACDC announcing DKIM-Signature: header fields. This mitigation shall be applied. The mitigation may be applied to non DKIM/ACDC linked DKIM-Signatures: as well. In case no mitigations have yet been applied to "RFC5322.From", and no such mitigation will be applied, as below, the signature linked to "sequence" 1 is an exception. | _Informative remark:_ Before the legacy flag second DKIM/ACDC | may create a single DKIM-Signature: that will verify correctly. * Mitigate non-local MAIL FROM envelopes. Because a possible SPF check will fail on the next hop (in situations with a strict SPF policy that applies a policy), if a message that does not originate locally leaves the email system on egress, with a SMTP envelope MAIL FROM of a foreign domain, mitigate such addresses, so that the current hop becomes the, quoting [RFC3461], _"final delivery for the [original] message"_. Nurpmeso Expires 4 February 2027 [Page 28] Internet-Draft DKIM Access Control and Differential Cha August 2026 DKIM/ACDC software may offer options to exclude certain domains from these mitigations. This mitigation need not be applied if the former hop legitimized this condition by setting the "U" flag (see there). To mitigate, synthesize for example an address of the local domain with a "local-part" starting with DKIX=, followed by at least 16 bytes of the base64[RFC4648] encoded HMAC[RFC2104] of a dedicated cryptographic private key, and the original MAIL FROM. Alternatively, using a dedicated subdomain is an approach that avoids any possible "local-part" ambiguities. Then for example the IETF mailing-list From: header field DMARC mitigation approach could be used, which decomposes the original MAIL FROM by replacing the commercial at (U+0040, @) with its "hexadecimal value in quoted-printable notation" to end with "local- part=40domain", followed by the domains of the mitigating host: local-part=40domain@subdomain.domain. | _Informative remark:_ the SMTP size limit of "local-part" is 64 | octets, however the overall "reverse-path" limit of RFC 821 and | RFC 2821 was 256 octets. The synthesized address shall be linkable to the original MAIL FROM for at least 864000 seconds (ten days: to reach into the next working week). It should be linkable only by Delivery Status Notifications[RFC3461] or (other) message bounces. If the bounce transports enough message data content this may be furtherly constrained to verifiable signatures of the local domain, even the exact message for which the address was synthesized. The optional message and bounce identifier "id" may be usable for this purpose. | _Informative remark:_ Except for linking purposes to the | original envelope the synthesized address is otherwise | "transparent", and should appear as if it does not exist: DKIM/ | ACDC software is expected to cause appropriate rejection (or | discardment) on SMTP level at the earliest possible time. * Mitigate From: and Sender: originator header fields, if necessary. When a message was changed in between ingress and egress, so that the DKIM signature (not only: related to the From: and Sender: header fields) will no longer verify. Then, if the From: and Sender: header field were not already locally mitigated (by for example mailing-list software), actively mitigate these originator header fields, so that the current hop becomes the, quoting [RFC3461], _"final delivery for the [original] message"_ in respect to the IMF[RFC5322] message that is visible to recipients. Nurpmeso Expires 4 February 2027 [Page 29] Internet-Draft DKIM Access Control and Differential Cha August 2026 DKIM/ACDC software may offer options to exclude certain domains from these mitigations. This mitigation need not be applied if the former hop legitimized that by setting the "U" flag (see there). To mitigate, place the original "name-addr" of each "mailbox" of the From: header field in the Reply-To: header field, unless that already exists. Replace the From: header field, and the Sender: header field, as necessary, with synthesized content. The examples of non-local MAIL FROM envelope mitigation apply also here in respect to "addr-spec"; yet, the dedicated subdomain approach results in visually more appealing header field content. For the "display-name" a "From: X via " notation may be used, where "X" denotes the original "display-name". For example, if the original From: header field content was "Forename Surname " then the mitigation could be "Forename Surname via" . Without dedicated subdomains a variant of the widely known construct "Forename Surname " via may be used. Whatever mitigation approach is taken, shall messages addressing the mitigated address arrive the implementation is expected to either (1) forward to the original address(es), or (2) reject with a notice to honour Reply-To: or Author: header fields. It may accept messages if the rewriting was performed on messages which addressed a mailing-list, for example. 8. Example An example that shows the flow of a single message with multiple different recipients, including mailing-lists and aliases. It assumes all recipients announced DKIM/ACDC support. The term B64/x denotes base64[RFC4648] encoded data, the unencoded value optionally follows a solidus for the informational purposes of this example. Originator (yet forged for recipient domain f.g): MAIL FROM: RCPT TO: RCPT TO: ... DKIX-AC: w=1; s=K1PQ; o=b.c; f=B64/a; d=f.g; t=B64/d; t=B64/e; b=.. DKIM-Signature: w=1; s=K1; d=b.c .. DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a@b.c Nurpmeso Expires 4 February 2027 [Page 30] Internet-Draft DKIM Access Control and Differential Cha August 2026 To: d@f.g, e@f.g, x@y.z, u@v.w, r@s.t, o@p.q ... f.g, local delivery (to d@ and e@): ... DKIX-Sig: acdc=2:N0C:AIV; s=K2PQ; d=f.g .. DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a@b.c ... x@y.z -- a mailing-list! It redistributes after RFC 2369 and RFC 2919 additions, in-message unsubscribe footer, and From: mitigated (in best RFC 3461 manner): MAIL FROM: RCPT TO: ... DKIX-AC: w=2; s=K2PQ; o=y.z; f=B64/x; d=m.n; t=B64/l; b=.. DKIM-Signature: w=2; s=K2; .. DKIX-Sig: acdc=2:V0C0U3:ADEOVYy; s=K2PQ; d=y.z; dch=.. DKIX-DC: w=2; f=B64; h=B64; b=B64 DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a(AT)b(DOT)c via Reply-To: a@b.c ... List-Unsubscribe: bla u@v.w -- an expanded alias! The hop honours RFC 3461, and changes MAIL FROM; it keeps DKIM-Signature: w=1 for DMARC compatibility: MAIL FROM: RCPT TO: ... DKIX-AC: w=2; s=K2PQ; o=v.w; f=B64/u; d=Xv.Xw; t=B64/Xu; b=.. DKIM-Signature: w=2; s=K2; d=v.w .. DKIX-Sig: acdc=2:N0C:EOVy; s=K2PQ; d=v.w .. DKIM-Signature: w=1; s=K1; d=b.c .. DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a@b.c ... r@s.t -- an expanded alias! Note: *INVALID* DKIM/ACDC, misuse of o=b.c, and no "N" flag; also because of no MAIL FROM update, will later fail SPF; it keeps DKIM-Signature: w=1 for DMARC compatibility: Nurpmeso Expires 4 February 2027 [Page 31] Internet-Draft DKIM Access Control and Differential Cha August 2026 MAIL FROM: RCPT TO: ... DKIX-AC: w=2; s=K2PQ; o=b.c; f=B64/a; d=Xs.Xt; t=B64/Xr; b=.. DKIM-Signature: w=2; s=K2; d=s.t .. DKIX-Sig: acdc=2:N0C:EVy; s=K2PQ; d=s.t .. DKIM-Signature: w=1; s=K1; d=b.c .. DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a@b.c ... ... the same, but DKIM/ACDC compliant: MAIL FROM: RCPT TO: ... DKIX-AC: w=2; s=K2PQ; o=s.t; f=B64/DKIX=a=40b.c; .. DKIM-Signature: w=2; s=K2; d=s.t .. DKIX-Sig: acdc=2:N0C:EOVy; s=K2PQ; d=s.t .. DKIM-Signature: w=1; s=K1; d=b.c .. DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a@b.c ... o@p.q -- a mailing-list! Note: *INVALID* DKIM/ACDC, because no From: mitigation, c/would later fail DMARC; it redistributes after RFC 2369 and RFC 2919 additions, and in-message unsubscribe footer. MAIL FROM: RCPT TO: ... DKIX-AC: w=2; s=K2PQ; o=p.q; f=B64/o; d=X.X; t=B64/X; b=.. DKIM-Signature: w=2; s=K2; d=p.q .. DKIX-Sig: acdc=2:V0C0U3:DEOVYy; s=K2PQ; d=p.q; dch=.. DKIX-DC: w=2; h=B64; b=B64 DKIX-Sig: acdc=1:NOC:O; s=K1PQ; .. From: a@b.c ... List-Unsubscribe: bla ... the same, but DKIM/ACDC compliant (using a dedicated mitigation subdomain): MAIL FROM: RCPT TO: ... Nurpmeso Expires 4 February 2027 [Page 32] Internet-Draft DKIM Access Control and Differential Cha August 2026 DKIX-AC: w=2; s=K2PQ; o=p.q; f=B64/o; d=X.X; t=B64/X; b=.. DKIM-Signature: w=2; s=K2; d=dkix.p.q; .. DKIX-Sig: acdc=2:V0C0U3:DEOVYy; s=K2PQ; d=dkix.p.q; dch=.. DKIX-DC: w=2; f=B64; h=B64; b=B64 DKIX-Sig: acdc=1:N0C:O; s=K1PQ; .. From: "a@b.c" via Reply-To: a@b.c ... List-Unsubscribe: bla l@m.n (recipient of x@y.z mailing-list), local delivery: ... DKIX-Sig: acdc=3:V0C0U3:IVYy; s=..; d=..; dch=.. DKIX-Sig: acdc=2:V0C0U3:ADEOVYy; s=K2PQ; d=y.z; dch=.. DKIX-DC: w=2; f=B64; h=B64; b=B64 DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a(AT)b(DOT)c via ... Xr@Xs.Xt (expanded alias target), local delivery: ... DKIX-Sig: acdc=3:N0C:IVy; s=..; d=.. DKIX-Sig: acdc=2:N0C:EOVy; s=K2PQ; d=s.t .. DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: a@b.c ... X@X.X ("X" recipient of o@p.q mailing list), local delivery: ... DKIX-Sig: acdc=3:V0C0U3:IVYy; s=..; d=..; dch=.. DKIX-Sig: acdc=2:V0C0U3:DEOVYy; s=K2PQ; d=dkix.p.q; dch=.. DKIX-DC: w=2; f=B64; h=B64; b=B64 DKIX-Sig: acdc=1:N0C:O; s=K1PQ; d=b.c .. From: "a@b.c" via ... 9. IANA Considerations IANA is asked to add the header fields DKIX-Sig:, DKIX-AC:, DKIX-DC:, and DKIX-Store: to the "Permanent Message Header Field Names" registry. IANA is asked to add "eddapq" to the "DKIM Key Type" registry. IANA is asked to add the tag "w=" to the "DKIM-Signature Tag Specifications" registry. Nurpmeso Expires 4 February 2027 [Page 33] Internet-Draft DKIM Access Control and Differential Cha August 2026 10. Security Considerations 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. 11. Normative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, . [FIPS202] National Institute of Standards and Technology (NIST), "SHA-3 Standard", August 2015, . 12. Informative References [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC1950] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, . Nurpmeso Expires 4 February 2027 [Page 34] Internet-Draft DKIM Access Control and Differential Cha August 2026 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, September 2000, . [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, DOI 10.17487/RFC5863, May 2010, . Nurpmeso Expires 4 February 2027 [Page 35] Internet-Draft DKIM Access Control and Differential Cha August 2026 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC9057] Crocker, D., "Email Author Header Field", RFC 9057, DOI 10.17487/RFC9057, June 2021, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [RFC9787] Gillmor, D. K., Ed., Melnikov, A., Ed., and B. Hoeneisen, Ed., "Guidance on End-to-End Email Security", RFC 9787, DOI 10.17487/RFC9787, August 2025, . [RFC9788] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header Protection for Cryptographically Protected Email", RFC 9788, DOI 10.17487/RFC9788, August 2025, . [BSDIPA] "BSDIPA, a mutation of BSDiff", . Appendix A. Header field database The database of header fields, in an automatically extractable form. Lines starting with EQUALS SIGN U+003D form start and, with a following SOLIDUS U+002F, end tags. The tag "HFDB" encloses the entire database. The header fields are case-insensitive, followed by whitespace, followed by its assigned bit number. Lines starting with NUMBER SIGN U+0023 are comments. =HFDB # sorted for normal 4, list 6 # RFC 5322, 3.6 / 5322-bis, I. from 0 sender 1 reply-to 2 date 3 to 4 cc 5 Nurpmeso Expires 4 February 2027 [Page 36] Internet-Draft DKIM Access Control and Differential Cha August 2026 bcc 6 message-id 7 in-reply-to 8 references 9 subject 10 # RFC 9057 author 11 # RFC 2045 mime-version 12 content-type 13 content-transfer-encoding 14 # (rest usually not in main header) content-id 15 content-description 16 # RFC 1806 content-disposition 17 # RFC 9788 hp-outer 18 # draft-ietf-drums-mail-followup-to mail-followup-to 19 # draft-josefsson-openpgp-mailnews-header openpgp 20 # RFC 2369 list-id 21 list-help 22 list-subscribe 23 list-unsubscribe 24 list-post 25 list-owner 26 list-archive 27 # RFC 5064 archived-at 28 # draft-ietf-sml-structured-email content-purpose 29 # RFC 5322, 3.6 / 5322-bis, II. resent-from 30 resent-sender 31 resent-to 32 resent-cc 33 resent-date 34 resent-message-id 35 resent-bcc 36 #comments keywords 37 # RFCs 3282 / 4021 content-language 38 # RFC 5703 Nurpmeso Expires 4 February 2027 [Page 37] Internet-Draft DKIM Access Control and Differential Cha August 2026 original-from 39 original-subject 40 # RFC 4021 / draft-ietf-mailmaint-expires expires 41 # RFC 8058 (last) list-unsubscribe-post 42 =/HFDB A.1. Example code for managing "hfdb-bits" Example C code to interpret and create the DKIM/ACDC "hfdb-bits" tag. #include #include /* 0-based */ #define HFDB_ENTRIES (42 +1) #define HFDB_STORE_BITS ((HFDB_ENTRIES + (8 - 1)) & ~(8 - 1)) #define HFDB_STORE_SIZE (HFDB_STORE_BITS / 8) #define HFDB_STORE_C2OFF(C) ((hfdb_u8)(C) / 8) #define HFDB_STORE_C2BIT(C) ((hfdb_u8)(C) & (8 - 1)) #define HFDB_STORE_SET(SP,BIT) \ ((SP)->s_dat[HFDB_STORE_C2OFF(BIT)] |= \ (1u << HFDB_STORE_C2BIT(BIT))) #define HFDB_STORE_CLEAR(SP,BIT) \ ((SP)->s_dat[HFDB_STORE_C2OFF(BIT)] &= \ ~(1u << HFDB_STORE_C2BIT(BIT))) #define HFDB_STORE_TEST(SP,BIT) \ ((SP)->s_dat[HFDB_STORE_C2OFF(BIT)] & \ (1u << HFDB_STORE_C2BIT(BIT))) #define HFDB_STRING_SIZE (HFDB_STORE_BITS / 5) typedef unsigned char hfdb_u8; struct hfdb_store{ hfdb_u8 s_max; /* Max bit set in .s_dat, +1 */ hfdb_u8 s_dat[HFDB_STORE_SIZE]; }; /* Number of bits set/characters stored, -1 on error */ static int hfdb_from_cp(struct hfdb_store *sp, char const *cp); static int hfdb_to_cp(struct hfdb_store *sp, char cp[HFDB_STRING_SIZE +1]); static int Nurpmeso Expires 4 February 2027 [Page 38] Internet-Draft DKIM Access Control and Differential Cha August 2026 hfdb_from_cp(struct hfdb_store *sp, char const *cp){ int rv, addbits; memset(sp, 0, sizeof(*sp)); rv = 0; for(addbits = 0; *cp != '\0'; addbits += 5, ++cp){ int bs; bs = (int)(unsigned)*cp; /* Support case-insensitivity */ if(bs >= 'a') bs -= 'a' - 'A'; /* 5 bits/char: 0b11111: 36#V: 0-9A-V */ if(bs > 'V' || bs < '0') break; bs -= '0'; /* "atoi" */ if(bs > 9){ bs -= 7; /* ..but ASCII U+003A..U+0040 not allowed */ if(bs <= 9) break; } for(; bs != 0; ++rv){ int b; b = ffs(bs); --b; bs ^= 1 << b; b += addbits; if(b >= HFDB_ENTRIES) goto jleave; HFDB_STORE_SET(sp, b); sp->s_max = ++b; } } jleave: return (*cp == '\0' ? rv : -1); } static int hfdb_to_cp(struct hfdb_store *sp, char cp[HFDB_STRING_SIZE +1]){ int xmax, addbits; char *cursor, *lx; lx = cursor = cp; Nurpmeso Expires 4 February 2027 [Page 39] Internet-Draft DKIM Access Control and Differential Cha August 2026 xmax = (sp->s_max <= HFDB_ENTRIES) ? sp->s_max : HFDB_ENTRIES; for(addbits = 0; addbits < xmax; addbits += 5){ int c, b; b = 5; c = xmax - addbits; if(b > c) b = c; for(c = 0; b > 0;){ int bx; bx = addbits + --b; if(HFDB_STORE_TEST(sp, bx)) c |= 1u << b; } *cursor++ = "0123456789ABCDEFGHIJKLMNOPQRSTUV"[c]; if(c != 0) lx = cursor; } *lx = '\0'; return (int)(lx - cp); } Appendix B. Further DKIM Updates * This specification obsoletes the DKIM "l=" tag that restricts the number of DKIM covered bytes of the message body. It shall not be used by DKIM/ACDC compatible software, and all the message body shall always be used to create the body hash. _Rationale:_ "l=" has always been insufficient to deal with message changes caused by mailing-lists etc, but effectively includes the security risk that message parts which are not covered by the signature appear as "valid content" to users looking at a DKIM verified message. The DKIM/ACDC differential changes offer a better approach to deal with message changes, while completely covered message bodies ensure content validity. * For the "i=" tag this specification obsoletes the possible use of DKIM-Quoted-Printable for the optional "Local-part". _Rationale:_ because the syntax is "a standard email address where the local-part may be omitted", quoted-printable encoding is not necessary for representation. Nurpmeso Expires 4 February 2027 [Page 40] Internet-Draft DKIM Access Control and Differential Cha August 2026 * This specification obsoletes the DKIM "z=" tag that was defined "for diagnostic use" to copy a freely defined set of header fields and their values present during signature creation. It shall not be used by DKIM/ACDC compatible software. _Rationale:_ the DKIM/ACDC differential changes provide access to the same information. * For the "q=" tag this specification obsoletes the possible use of DKIM-Quoted-Printable for the optional "x-sig-q-tag-args" of possibly introduced future query types. _Rationale:_ shall ever a new type become standardized beside the dns/txt that is with DKIM from the very start, that standard can very well give meaning to a "hyphenated-word" proxy identifier without making use of byte values which would require encoding. * This specification obsoletes the DKIM key representation tag "n=" that was meant to include "notes that might be of interest to a human", "intended for use by administrators, not end users", and which "should be used sparingly". _Rationale:_ no use case has been encountered in the DNS, let alone serious such; if future space unconstrained key providers other than DNS should ever exist and be used to distribute DKIM keys, it is likely that they support inclusion of strings via some method that need not be included in the DKIM key representation itself. * Because above changes remove all use cases for the "dkim-quoted- printable" encoding defined in RFC 6376 2.11, this specification obsoletes the DKIM-Quoted-Printable encoding. Appendix C. Acknowledgements Thanks to, in the order of appearance, Jesse Thompson, Richard Clayton for arguments against reliance on header field stacks, and pro the numbering scheme, base64 encoding of envelope local-parts (and more mailboxes); Douglas Foster; the late Michael Thomas for explicit man-in-the-middle replay addressing; Alessandro Vesely inspired the explicitness of the E flag, Bron Gondwana for the inspiration to split up binary differences of headers and body, as well as the IANA registry revision; the (successor of the) Kaiser- Wilhelm-Gesellschaft for finally convining me of simple canonicalization for message bodies; Lasse Collin for LZMA2 (and clarification vs XZ), and Julian Seward for bzip2. A big acknowledgment is due to Murray S. Kucherawy. Thanks also to the member of the DKIM WG who inspired the "U" flag. Special thanks to Nurpmeso Expires 4 February 2027 [Page 41] Internet-Draft DKIM Access Control and Differential Cha August 2026 Klaus Schulze, Manuel Goettsching, both also as Ash Ra Tempel, Laeuten der Seele, Laurent Garnier, John Dowland, as well as the Sleeping Environmental Bot broadcast. Author's Address Steffen Nurpmeso (editor) Email: steffen@sdaoden.eu Nurpmeso Expires 4 February 2027 [Page 42]