On Thu, 4 Jan 2007, John L wrote:
Can you describe the algorithm to distinguish the cases where the original
value is fine from the cases where it's not?
You took one line without additional context where I gave an example of
users who have processing script to find mail lists based on subject tags.
We all have scripts like that. What do they have to do with DKIM signature
It goes along what you asked about when modifying header data to restore
an original value and validating signature after that might be a problem.
Current text says that "z" value can not be used for signature validation.
So lets imagine an implementor who actually takes it literally but still
wants to do it but also be able to comply with text. Did someone say its
impossible? Not at all! All you have to do is verify the signature once
and find that it did not validate (a trace header text could even be
added saying that). Then you pass it from your right hand [signature
verifier system] to left [message processing system not doing signature
verification and thus not subject to "standard" text] that takes
the message and does same thing that was done to it before and modifies
its header data based on "z" part of the signature. Then left hand passes
it back to the right which does another signature validation this time
on a "new message" with restored header data. The signature passes and
everyone is happy :)
BTW - The above assumes that implementors actually always do according
to standards text in the first place.. Despite efforts by many people in
IETF that is not at all what happens in real world and if implementors
find it easier to "bypass" certain parts of the standard based on certain
requirements or for better customer experience they in fact do just that.
BTW - Did you notice that we are talking about email cases where message
passed through processing system that thought its ok to make modifications
to the originator's header data before further delivery. So is the question
you're asking when its ok to make further modifications to the same
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.
By using the original values and doing new signature verification.
The question again goes back as to if its ok from recipient point
of view to trust header data added by original sender. In my view
it always is! The only issues are that some recipients do additional
processing that is operationally use these modifications.
I think that we all agree that if the intermediate system re-signed the
message and we trust that signature, the message is OK.
Actually I don't agree with that at all. Plus this also requires level
of agreement between the recipient and "re-signer" that is not based
on message sender as would be presented to the user.
But the discussion in progress is, as far as I can tell, about messages
where an intermediate system modified but did not re-sign.
Both. In my view having resigner's signature is helpful in determining
ultimate delivery status of the message, but it is not paramount. I'd
rather see use original user signature if it can be validated even if
additional signatures exist.
NOTE WELL: This list operates according to