Ah, sigh, one more.
Michael Thomas wrote in
<94158f8a-1578-4d52-8f9f-15635579f...@mtcc.com>:
|On 3/26/25 11:13 AM, Alessandro Vesely wrote:
|>> If you want to do forensics you can check more, but that's all that a
|>> receiver is likely to care about.
|>
|> It ought to be not very hard to check all signatures, reversing the
|> changes. There needs to be a way to tell what changes are tolerated.
|> For example, I'd accept a plain text footer of a few lines, but not
|> html inserts that could completely replace the original content in the
|> end recipient's eyes.
|>
|For all of the changes, I'd think that the right thing to do is run spam
|filters on the changed text with the reputation (if any) of the modifier
|in mind. Obviously some context would be good, but ultimately it's a
|matter of evaluating it on its own merits. This is why I thought that
|the l= hysteria was overblown and applies every bit the same to the
|mutations draft.
You are wrong and it is not that easy, as Richard Clayton said
beforehand. MIME structural changes never could have been
represented by l=. I talked about "templates" in the past
regarding ACDC, i was about to add additional M and m flags for
mailing-list specific changes, you know, as my DKIM signer
documents, for postfix,
#@ /etc/postfix/main.cf:
milter_default_action = accept
non_smtpd_milters = unix:private/dkim-sign
smtpd_milters = unix:private/dkim-sign
milter_macro_daemon_name = outwall
#@ /etc/postfix/master.cf:
smtp inet n - n - - smtpd
-o smtpd_tls_security_level=may
-o milter_macro_daemon_name=ingress
localhost:smtp inet n - n - - smtpd
-o syslog_name=localsmtp
#localhost:421 inet n - n - - smtpd
# -o syslog_name=lhlist
# -o smtpd_milters=unix:private/dkim-sign-list
dkim-sign unix - n n - - spawn
user=ANON-USR
argv=/usr/libexec/s-dkim-sign -R /etc/dkim-sign.rc
#dkim-sign-list unix - n n - - spawn
# user=ANON-USR
# argv=/usr/libexec/s-dkim-sign -R /etc/dkim-sign.rc --header-seal=+
ie specifically driving an instance for the mailing-lists, in
order to add the List-* headers to the list of headers to be
sealed. I similar spirit, it could then also enforce setting the
hypothetic "M" flag to indicate mailing-list specific changes.
Like that the DKIM verifier could apply according templates, but,
as Richard Clayton said, this *already* is *very* complex to
match, due to MIME structure changes, -part additions, -part
removals, -part content additions (removals?) header additions or
changes, and then it all, or at least in parts, you referred to
likely constant aka unchanged base64 encoding for certain parts,
like images, PDFs, etc etc, could be reencoded to 8bit or base64
or whatever.
Ie, already with a "M" hint, MIME structure needs to be analyzed,
encodings must be undone, part content must be compared as full
text. Only then you could say "yes, this seems to be
a mailing-list, and the changes comply to the according template".
So, likely, templates will exist which comply to say mlmmj
changes, Mailman2 changes, Mailman3 config 1 changes, etc etc, and
then a user could plug this together, and the verifier could ring
alarm if the template does not match.
*OR* a registry of changes would have to be created, with those
templates, and the ACDC or whatever you do would have to have
a change-id field to announce this as part of the signature. Then
the above config could choose the Mailman2/DMARC-mitigation ID,
and announce it as part of the signature to verifiers.
This is automatizable (to some extend), then.
But it needs a registry.
Other than that we are back at Dave Crockers words from last month
or so, where he said ~"ok, you can unroll then changes, and then
what?", or something in this spirit. He is of course right. But
then again even without all of the above, the cryptographically
verifiable path back to the original message is a tremendous
improvement, and user interfaces, or, heaven, AI (energy wise
a terrible thing), they can be used, the latter even
automatically. (I only mention AI because *YOU* (not you) surely
will come to that conclusion. *I* mention user interfaces.)
But now silent (by myself).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
