On Thu 25/Aug/2022 01:36:21 +0200 Wei Chuang wrote:
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 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.
Either you allow forwarding or require a strict SPF match. In the former
case, you also allow replaying. There is no way to distinguish the
original from the copy, unless they're forced to come from or arrive to a
fixed host.
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?
It becomes a bit tricky in some cases, but for "classic" mailing list
(Mailman and similar tools) it works fine. I describe it in a draft:
https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
There is no interest about it either.
Do you know if anyone tried implementing draft-kucherawy-dkim-list-canon-01?
And what were the results?
Nope.
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.
ARC is used by big players to ascribe reputation correctly. It doesn't
work fr mailing lists because changing From: puts determination of the
original author in jeopardy. It would be enough to add an Author: field to
fix the latter.
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.
It still suffers the same limitation, unless you impose to receive the
message directly from the 2nd signer.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
