sbp opened a new issue #45: URL: https://github.com/apache/incubator-ponymail-foal/issues/45
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
