On Tue, Aug 23, 2022 at 11:07 AM Alessandro Vesely <ves...@tana.it> wrote:
> 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. > Two of the approaches (first and second) would likely just involve tweaking ARC, so the real cost is adopting ARC IMO. The third proposal is a step up in implementation cost, as it likely involves extending SMTP. Regarding better supporting mailing lists: 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. > I wonder if some of that could be handled by stronger specification? It would be lighter weight though less interoperable. In practice did you see lots of re-ordering on legitimate traffic? How much of the 50% benefit was found due to better supporting the features in the draft? 1) subject 2) footer 3) mime transformations 4) new mime-part? Do you know if anyone tried implementing draft-kucherawy-dkim-list-canon-01? And what were the results? > 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. > Agreed ARC doesn't fully solve support From modification that some mailing lists do, and needs something like the above draft-kucherawy-dkim-transform draft. > Also, cannot use ARC to fix the path through mailing list and forwarding > scenarios. That was attempted by draft-levine-dkim-conditional[†]. > Also agree this approach of describing the sending path by the sender can help with replay scenarios. -Wei > > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
