-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBakp1B2HfC/FfW545EQL5fgCdG985jLdVsPzXxK5rsxSHOWGxo+YAoIPL
MGep/0OkxpLtfjkrsUtfwxy5
=h5Ty
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
