[ietf-dkim] Base issue: multiple linked signatures

[william(at)elan.net]

On Wed, 3 Jan 2007, John R Levine wrote:

>> No. What you'd want to do is to rename modified header field into some
>> sort of trace data and copy the original data in its place. Displaying
>> modification would then be up to the MUA which could display small
>> icon allowing user to see what the modification was as an option.
>
> That's one approach, but hardly the only possible one.  Most of the users
> I know would find it completely baffling if their mail program showed them
> multiple versions of headers and asked whether they liked them.

That's why I said its better not to display it and only show icon for 
those adventurous folks that care. But how it is really shown/not shown
in MUA should be entirely up to MUA implementors.

>> For most cases original value would be just fine ...
>
> 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.

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 message?
[you see the irony here, right?]

> I hope we agree that we do
> not want to spec a verification system that uses heuristics that vary from
> one implementation to another.

Standards documents are there to provide common way how something is
done as seen from outside so that other programs/utilities/etc that 
depend/use program implementing standardized protocol know about it.
As such the issue is exactly that community would not want different 
implementations doing it different ways.

That is not to say that each implementation should be modifying header 
fields to make signature match (if this is done or not depends on 
implementations and possibly on setup on particular location), but
it would be good that when it is done, what is done is documented
(i.e. list of header fields that were changed) and reported in standard 
way as well as values that were there before modifications are available 
for additional use by either pre-delivery processing programs/scripts
or post-delivery programs that display email data to the user.

-- 
William Leibzon
Elan Networks
william at elan.net