Hello Richard,
Thank you for your explanations. That makes a lot of sense, and in that
light the behaviour of PhoenixDKIM is indeed draconian.
The suggestion of an algorithm change, or an
I-can't-verify-your-algorithm, are good ones that I hadn't thought of.
In the latter case, would it be correct to then verify the one-below
instance's hashes against the message as it stands? If there were no
changes, this should verify; if it doesn't verify, an undocumented
change occurred?
If that is the right reading, then that is the behaviour I'll move to: A
missing recipe becomes "no change asserted" rather than an error,
checked against the message as it stands, and only a genuine hash
mismatch fails.
Of course, a signature sitting below a recipe-less change becomes
unverifiable. The result is, I suppose, a more targeted fail where the
chain can no longer be verified, rather than a blanket PERMERROR.
Does this sound about right?
Kind regards,
Edmund
On 2026/07/05 17:15, Richard Clayton wrote:
In message <[email protected]>, Mauro De
Gennaro <[email protected]> writes
That last detail is what trips PhoenixDKIM when the producer is the Go or
Python
tool. On a transparent re-sign, those two add a fresh Message-Instance (m>=2)
with no recipe, and PhoenixDKIM's verifier rejects any non-first Message-
Instance that carries no recipe, with:
PERMERROR: Message-Instance m=N carries no recipe
It failed on all 14 multi-hop combinations where a relaying (non-originator)
hop
was produced by Go or Python. For what it is worth, I think PhoenixDKIM's
verifier is on reasonable ground here, and mail-auth agrees with you in spirit.
Section 9.1 says a forwarder that leaves the hashes unchanged SHOULD NOT add a
new Message-Instance at all.
hmm ... rejecting a message because an earlier hop did not obey a SHOULD
NOT is fairly draconian. Albeit as pointed out in another message #9.1.3
has a MUST (which by context only) doesn't apply to i=1.
The text was meant to put across to implementers "don't add unnecessary
Message-Instance fields it just wastes time and energy"... but it isn't
an interop issue so MUST NOT was rejected in favour of SHOULD NOT and
the MUST in #9.1.3 probably needs rephrasing.
Now ... people may feel that recipes are a MUST and the spec should be
changed in that direction. But what if the Message-Instance was added in
order to provide a hash value that used a new (more preferred) algorithm
or because a forwarder did not have code for one of the hash algorithms
and felt that passing on a value it was unsure about was unwise ??
I have not changed spec-04 in this area, since more discussion is needed
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Edmund Lodewijks <[email protected]>
TZ: UTC+2 / GMT+2
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
