• places DKIM signatures in a random-accessible ordered sequence which' state correlate.
• adds reversible data difference tracking, and as such supports cryptographical content verification of (potentially) any intermediate message representation, up to the initial variant as sent by the originator. (Potentially allowing user interfaces to, also partially or in configurable dose, undo modifications that the email system introduced along the message path. For example, mailing-list specific mutations: it could show the original From address line, not the DKIM/DMARC mitigation caused mailing-list address; but see below. This, of course, is only necessary due to the reluctance of email implementations to support the Author Header Field.)
• takes, on mutual agreement with receiver domains, cryptographically verifiable precautions to ensure that only initially addressed "mailbox local-part"s can be used as SMTP RCPT TO addressees, as well as to ensure that the SMTP MAIL FROM mailbox is identifieable; the latter avoids that receivers can be fooled by man-in-the-middle to send backscatter bounces to random addresses.

Informative remark: 999 is both a constraint and a very high limit, dependent upon which type of processing is actually involved. In todays' DKIM use several signatures per actual hop are not uncommon, also in the sense that per-hop processing pipelines involve several processing steps that each create DKIM signatures. Since DKIMACDC is meant as a transparent upgrade path it seems unwise to introduce a limit too low thus. On the other hand a high limit creates a D(enial) O(f) S(ervice) attack surface. DKIMACDC allows for rather cheap and easy detection (and testing) of the highest numbered signature, which can be sufficient for intermediate hops given the DKIM paradigm that "a single successful verification is sufficient for validation". (For example, no From header parsing might be necessary.) With DKIMACDC certain detectable conditions allow for quick rejection in a broken chain of trust. DKIMACDC allows for pretty certain collection of statistics of organizational trust (, section 2.5), in turn improving the mentioned "detectable conditions".

A

Access control is active; DKIM-Access-Control header(s), as below, are included. Once set, necessarily in combination with the O flag, all future DKIMACDC signatures must copy it; however, it may be removed by a signature which claims a new message origin by setting the O flag.

a

Access control is not active.

D

The message was modified at this hop, DKIMACDC differential changes were generated, and are stored in a DKIM-Diff header. (Not in combination with the O flag, except if the sequence number is greater than 1.)

O

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, and the sequence number is 1. It can also mean that an intermediate hop performed modifications, or for other reasons claims "ownership" of the message. For example, a mailing-list received a message, and is now re-distributing it to its members. At the time of this writing this usually comes in conjunction with From header munging for DMARC mitigation, but also to notify message changes performed by the list. The sequence number is greater than one, the SMTP MAIL FROM is adjusted to refer to the domain that claims ownership, etc. Any formerly present DKIM-Access-Control header was removed. Access control headers are only generated for messages with the O flag set.

P

Postmaster mode. With this flag set the behaviour of DKIMACDC borders test mode in that rejections must not occur (due to DKIMACDC). This is to allow for a communication possibility window in a situation where usually messages would always be rejected, may it be due to misconfigurations, etc. (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 DKIMACDC instances, and may imply an absolute maximum in order to avoid endless message wandering aka "loops" nonetheless.) If the sequence number will be 1 message receivers have to be inspected. If the IMF headers To and Cc only contain a single addressee with the local part postmaster, and if the same "postmaster" is addressed as a SMTP RCPT receiver, and if no more than two RCPT receivers exist in total, then the P flag has to be set. Once set, all future DKIMACDC signatures must copy it.

R

Reputation check to collect organizational trust (, 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).

V

DKIMACDC signature verified successfully. This means that the signature with the highest sequence number has been verified correctly, that the sequence of DKIMACDC 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.

v

DKIM signature verified successfully. In signatures with sequence number 1, then missing the O flag, it means the message originated at a non-DKIMACDC-aware host, and normal DKIM processing was performed and succeeded. Unless DKIM processing succeeded for the DKIM signature which covered the messages' From header 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 DKIMACDC chain was broken, and the message changed, by an intermediate non-DKIMACDC-aware hop. The z flag must be set.

X

DKIMACDC verification failed; however, the normal DKIM signature verification was performed, and succeeded. The z flag must be set.

x

DKIM verification failed. In signatures with sequence number 1, then missing the O flag, it means the message originated at a non-DKIMACDC-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 DKIMACDC chain was broken, and the message changed, by an intermediate non-DKIMACDC-aware hop. The z flag must be set.

Z

Announces the DKIMACDC chain is incomplete. The message was processed by DKIMACDC 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.

z

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 DKIMACDC 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.)

Informative remark: Dedicated DKIM-Signatures are necessary: if the message is also sent to a domain which does not support DKIMACDC, but which forwards the message to a domain which does, that destination would otherwise falsely assume the presence of access control; To simplify per-receiver-domain message creation the DKIM-Signature header(s) can be readily prepared except for toggling the single flag byte a to A, and, of course, creation of the cryptographic signature itself.

Informative remark: It follows that the "changes cause a new message" paradigm of today's DKIM/DMARC usage stays intact. It is deemed correct behaviour: Note that a message sent to a mailing list is addressed to a mailing list. It is not addressed to the 'final' recipients. That additional addressing is done by the mailing list, not the original author. This is a rather stark demonstration that the intermediary has taken delivery and then re-posted the message. However, DKIMACDC allows for cryptographically verifying the original message, and therefore can overcome the trust problem incurred by those "correct" changes, which of course break the DKIM signature of the original message.

Informative remark: Today many mailing-list instances re-encode message data for policy reasons, needlessly: for example from some 7-bit clean content-transfer-encoding to 8-bit, or anything into base64 (as below). This policy usually causes enlargening of the differential changes on at least the first level (which for one is most often the only one involved, and second it depends on the content of the original message). This negative impact can thus easily vanish, upon policy change.