[GitHub] [incubator-ponymail-foal] sbp opened a new issue #45: DKIM-ID may be broken by downstream MTAs

[GitBox <gi...@apache.org>]

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:
users@infra.apache.org

[GitHub] [incubator-ponymail-foal] Humbedooh commented on issue #45: DKIM-ID may be broken by downstream MTAs

[GitBox <gi...@apache.org>]

Humbedooh commented on issue #45:
URL: https://github.com/apache/incubator-ponymail-foal/issues/45#issuecomment-857668627


   Could this also be worked around by not having the DKIM-Signature header in the list of headers to base the DKIMID on? The DKIM-Signature verifies who sent the email, but adds nothing to the actual contents of the email itself, thus it could in theory be safely ignored as any attempt to override would override with the exact same contents, only the dkim signature could differ (do we care?)


-- 
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:
users@infra.apache.org

[GitHub] [incubator-ponymail-foal] sbp commented on issue #45: DKIM-ID may be broken by downstream MTAs

[GitBox <gi...@apache.org>]

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:
users@infra.apache.org

[GitHub] [incubator-ponymail-foal] sebbASF commented on issue #45: DKIM-ID may be broken by downstream MTAs

[GitBox <gi...@apache.org>]

sebbASF commented on issue #45:
URL: https://github.com/apache/incubator-ponymail-foal/issues/45#issuecomment-939572738


   Does this apply to the case where PonyMail operates as a subscriber to an email list?
   In such a case, surely the email is not transported any further?


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

To unsubscribe, e-mail: issues-unsubscribe@ponymail.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-ponymail-foal] sbp commented on issue #45: DKIM-ID may be broken by downstream MTAs

[GitBox <gi...@apache.org>]

sbp commented on issue #45:
URL: https://github.com/apache/incubator-ponymail-foal/issues/45#issuecomment-857615126


   It may be worth noting that [RFC 8617 § 4.1.2](https://datatracker.ietf.org/doc/html/rfc8617#section-4.1.2) says:
   
   > To preserve the ability to verify the integrity of a message, the
   > signature of the AMS header field SHOULD include any DKIM-Signature
   > header fields already present in the message.
   
   Which means that if an ARC hop adds its own `dkim-signature` this would be detectable if it follows the advice of the ARC RFC. Furthermore, each hop must use an incremented instance tag, defined in [§ 4.2.1](https://datatracker.ietf.org/doc/html/rfc8617#section-4.2.1) _ibid._ as follows:
   
   > Instance tag values are integers that begin at 1 and are incremented
   > by each addition of an ARC Set.  Through the incremental values of
   > instance tags, an ARC Validator can determine the order in which ARC
   > Sets were added to a message.
   
   In conjunction, these two points mean that it should be possible to determine which DKIM and ARC headers were added on each ARC hop, but only when the advice to include the `dkim-signature` header to the `arc-message-signature` was taken. Also this applies only for ARC hops, and not when DKIM is added without ARC.
   
   It should be possible to write code which, when the original mailing list manager signing identity is known, determines a message compatible with the one used by the mailing list manager for DKIM-ID generation.
   


-- 
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:
users@infra.apache.org