> I would support some gentler language that permits use of z= in > verification, with particular attention paid to ensuring that a new > security vulnerability is not introduced.
My recollection is that we had no idea what the security vulnerabilities would be, nor did we have any proposals for a metric of deciding when a modified header is "close enough". An obvious example is how algorithmically one might purport to tell a subject addition of [ietf-dkim] from an addition of [v1agra-at-www.sleazy.biz] So I still think our decision to stay away from the whole thing was correct. Either it's the same message and the signature verifies, or it's not. I suppose we could tell people that it's OK to use z= as part of the process of deciding what to do with a message whose signature didn't verify, but that process is outside the scope of the spec. > My solution would be for the modifier to sign the message after > modification. Yes indeed. Any time someone proposes something more complicated than this, they really need to explain why. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
