[ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms

[Murray S. Kucherawy]

> Disagree.  This feature is about better informing recipients as to the
> status of the signature.

For the sake of enumerating implementations, the current libdkim implementation does make a distinction between a signature that failed to verify and one that couldn't be verified because the key's approved hashes and the signature's methods don't line up and one that simply failed DKIM verification.

So if I am to apply my earlier arguments, I have to support your point because it puts more information in the hands of the assessor.

However, unlike x= and l=, I don't see any possible benefit in making the distinction.  For example, how can you tell an attacker that created a signing algorithm of "rsa-whatever" from a site that accidentally posted a public key with "h=watever"?  Are you sure you want to consider those as equivalent and apply the maximum punishment rather than just treat the message as unsigned in both cases?