On 1/25/25 10:10 AM, Richard Clayton wrote:
> There are additional needs. They are new. Or, at least, they were not
> previously a priority. Since they were not needs when DKIM was
developed, they
> are not 'shortcomings'.
they may not have been perceived to be shortcomings then -- they are
now, which is why a number of people wish to improve things for the
people whose email they handle
Fwiw, mailing list traversal was always a shortcoming of DKIM from the
very beginning. That some people dismissed it at the time doesn't alter
the fact that it was -- and is -- a shortcoming. Our original intent at
Cisco was to address the internal spear-phishing problem for us, but
given Cisco's widespread use of mailing lists -- both internal and
external -- that made it a hard goal to achieve. z= and l= were an
attempt to be "good enough" on my part even though there was a lot of
hostility at the time (they actually worked pretty well in practice).
That's especially true of l= since the objection was that it was
"insecure", but any new mechanism which records what changes an
intermediary made has the exact same "insecurity" in that the message
will differ from the originating signature's signed canonical text whose
changes may or may not be benign. Frankly, that's up for the receiver to
figure out which I think they are capable given spam/scam filters, etc
and the reputation that you can assess from the intermediaries making
the mutations. I even wrote a patent app about that which I don't think
was issued probably because it was too obvious.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
