On Thursday 04 January 2007 12:24, John L wrote:
Actually, that's not at all what I was talking about. I was asking how a
recipient system can algorithmically distinguish an upstream modification
that broke the signature but was "ok" from one that wasn't.
This is, I think, the key point. All this post-processing we are discussing
is about this point and I don't see any value in standardizing additional
uncertainty about will a signature validate or not.
I think that we all agree that if the intermediate system re-signed the
message and we trust that signature, the message is OK. But the
discussion in progress is, as far as I can tell, about messages where an
intermediate system modified but did not re-sign.
Agreed.
While there is certainly nothing an RFC can do to prevent receivers from
attempting to do the kind of message reverse engineering being discussed, the
current MUST NOT wording makes it clear that the results of that processing
are not part of the protocol. Receivers can guess all they want, but don't
call the result of that effort a DKIM result.
I believe that having a clear line in the sand, as the current specification
does, is a good thing. Once we start down this slippery slope, where does it
end? IIRC, this is what the specification says what it says.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html