DKIM-ID may be broken by downstream MTAs

The DKIM-ID generator currently includes the DKIM and ARC authentication headers `dkim-signature`, `arc-authentication-results`, `arc-message-signature`, and `arc-seal`. These headers were specifically designed to be added by downstream MTAs in order to give their seal of approval to messages that they modify. This means that a mailing list manager could send out a message for which it has generated a DKIM-ID, and then its downstream MTAs could add some of these headers. The messages that mailing list subscribers then receive would have different DKIM-IDs to the messages stored by the Foal archiver.

For similar reasons, the "resent" headers `resent-date`, `resent-from`, `resent-sender`, `resent-to`, `resent-cc`, and `resent-message-id` presently included in DKIM-ID generation could also be problematic. [RFC 2822 § 3.6.6](https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.6) says that such headers are "used to identify a message as having been reintroduced into the transport system by a user", and such reintroduction could occur after the mailing list manager has sent out a message.

It's not clear how likely either class of modification may be. The [primary use cases of ARC](https://dmarc.org/presentations/ARC-Overview-2016Q3-v01.pdf) are forwarding, mailing lists, and filtering. Forwarding doesn't really apply here, and the DKIM-ID is generated by the mailing list manager itself which means that it will see its own ARC headers. The third case, filtering, seems the most likely ARC scenario relevant to this issue, but it's not clear specifically what such filtering could mean nor how common it would be. There does not seem to have been much uptake of ARC yet. In the case of the "resent" headers, it is not clear what it means in practice nor how common it is.

The tradeoff in general is between adequately distinguishing messages that the archiver receives, and incurring the potential that the DKIM-ID of messages received by mailing list subscribers is broken. One potential solution is to simply remove the offending headers, either the DKIM and ARC authentication headers, or the "resent" headers, or both, from DKIM-ID generation. Another potential solution is for the mailing list manager to add an `x-dkim-id` header that supplies the generated DKIM-ID. This header could even be signed by the mailing list manager for authenticity.

Start by locating the DKIM-ID generator and reviewing how the listed DKIM, ARC, and resent headers are included. Read RFC 2822 § 3.6.6 and the linked ARC overview to assess downstream changes. Done requires a decided policy for those headers or an x-dkim-id approach, with corresponding implementation and coverage.

Written by the indexing model from the issue text.