On Mon 22/Aug/2022 23:53:16 +0200 Wei Chuang wrote:
All the while, using ARC as a framework may allow future support for
another long standing issue, which is working on message modification while
forwarding, in particular for mailing lists. The proposal
draft-kucherawy-dkim-list-canon-01
<https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon-01> provides
a framework for handling common mailing list modifications by identifying
those modifications. Putting it into ARC, may generalize this by
identifying who made the modifications and be able to tolerate multiple
such modifications such multiple mailing list expansions.
There doesn't seem to be interest in deeply reworking DKIM.
Another draft, draft-kucherawy-dkim-transform[*] proposed standard
modifications. I implemented (a variation of) it and it works about 50% of
cases. It fails when the original signature covers too many fields; for
example, if one signs a MIME-Version field with a different capitalization,
the mailing list will overwrite it and break the original signature for
good. Also, altering the order of To: or Cc: mailboxes breaks signatures
irrecoverably, unless saving Original-To:, Original-Cc:, and any other
signed field.
There are mailing lists that use ARC, but they also change From:. ARC was
thought for that case, but it is actually useful in different cases.
Also, cannot use ARC to fix the path through mailing list and forwarding
scenarios. That was attempted by draft-levine-dkim-conditional[†].
Best
Ale
--
[*] https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/
[†] https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
