On 3/30/25 6:25 PM, Allen Robinson wrote:
On Sun, Mar 30, 2025, 8:33 p.m. Michael Thomas <m...@mtcc.com> wrote:
On 3/30/25 5:21 PM, John Levine wrote:
It appears that Michael Thomas<m...@mtcc.com> <mailto:m...@mtcc.com> said:
I seem to recall previous discussions have suggested that the "v" tag
shouldn't have been included in the first place; if things are so
different that you need to change the version, you may as well change
the name of the header field altogether.
Seems like six of one, half dozen of the other. The version change sort
of signals that it has a backward incompatible change, but everything
else will be the same. ...
The obvious reason to have a new header is that there's a new tag that the
evaluator has to understand. You can't do that in a backward compatible
way.
It doesn't "need" to understand it, any more than any new
extension "needs to be understood". Deployments are completely at
liberty to ignore any soi-disant "DKIM2" regardless of whether
it's a new header or an upgrade to DKIM. The authors can want it
to be deployed all they want, but it's not up to them.
I tried a couple of ways to kludge that in for my conditional chained
signature draft, none very satisfactory:
https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
Does this run on the assumption that DKIM isn't a trace header? I
keep asking and nobody will answer. Two different working groups,
two different bouts of silence.
I know of systems that don't add DKIM signatures for messages passing
through them, and systems that remove existing DKIM signatures from
messages prior to passing them along.
Indeed. IETF lists don't seem to. That's pretty embarrassing. If there's
no reason to believe that anybody at IETF will care with resigning
DKIM++, there is no reason to believe that the long tail will either. If
anybody is counting on that behavior, they'll have a rude awakening.
I'm not aware of any that reorder signatures or don't place their
signatures at the top of the header, but I don't know for sure that
any of the data I have access to would make such a distinction.
If DKIM is actually treated as a trace header, numbering them isn't an
issue. It might be a little more convenient, but that's just on the margins.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org