sbp commented on issue #45: URL: https://github.com/apache/incubator-ponymail-foal/issues/45#issuecomment-859504587
There is a problem with not using DKIM headers in DKIM-ID generation. If a message is sent either without DKIM headers or with forged but invalid DKIM headers, then only the version with missing or forged DKIM headers would be made available even if a later message with legitimate DKIM headers were subsequently received. The "missing first" scenario would most likely arise due to misconfiguration. The "forged first" scenario is almost impossible as it requires access to a sent message in early transit, but could be performed by powerful actors. A similar situation applies to ARC headers. The other potential scenarios are the converse, that a message with legitimate DKIM headers is sent first, and then one with missing or forged but invalid headers is sent later. In these cases it would probably be best to deduplicate since the later message can only be a mistake or attack in "missing after" and an attack in "forged after". The "forged after" scenario is much easier to produce than "forged first", but has no detrimental effect if DKIM headers are not included in DKIM-ID generation. Since the "missing first" and "forged first" scenarios are so unlikely, and since downstream additions of DKIM and ARC headers are so likely, this suggests that DKIM and ARC headers should not be included in DKIM-ID generation. It would still probably be a good idea for mailing list managers to add an `X-Archived-DKIM-ID` or `Archived-DKIM-ID` header though. Resent headers signify that a message has been "deliberately reintroduced into the transport system", as RFC 2822 puts it. Since this is a deliberate action, and since the very purpose of the headers is to make the action known, such messages should presumably generate different DKIM-IDs. Analysis indicates that Resent headers are rare, but were at least historically sometimes added by mailing list software, such as in the case of the [spi-general mailing list archives](http://lists.spi-inc.org/pipermail/spi-general.mbox/spi-general.mbox). In the [alife-announce mailing list archives](http://lists.idyll.org/pipermail/alife-announce.mbox/alife-announce.mbox) the Resent headers are for one sender used to indicate an alias, but for others seem to indicate only extra hops. This Resent header analysis indicates that downstream addition of Resent headers is extremely unlikely, as all discovered instances were added by sending MTAs before the mailing list manager, or by the mailing list manager itself. -- 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]
