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
