John Levine wrote:
The output of DKIM verification is considerably more than that:
there are a great many values, such as the list of signed header
fields, that may be useful to an assessor and that must be made
available to the assessor if the verifier is to be as interoperable
with as many assessors as possible.
We seem to have a fairly basic disconnect here. As far as I'm
concerned, an assessor has better things to worry about than the
internal details of the signature. Trying to reverse engineer or guess
what the signer had in mind would be a hopeless swamp even if it were
desirable.
Sure, it's possible to put on a worthless signature that leaves out
crucial headers, but signers who do so won't get a very good
reputation so the problem should be self-limiting. There's no
existing installed base of inept signers we have to work around, and
it would be a poor idea do anything that would allow crummy signatures
to appear to work.
If assessors can't be bothered, then how will reputation systems know the
difference? You really can't have it both ways.
In any case, this is a false dilemma; it's not just "crummy signatures"
at issue.
And what you call a "hopeless swamp," I call "RFC 4871."
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html