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(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html