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?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html