On Sun, 7 Nov 2004, Jim Fenton wrote:
At 07:51 PM 11/4/2004 -0800, william(at)elan.net wrote:
So lets say we want to make sure the signature survives if Subject and From
are changed, then we copy the headers into "Duplicated-Subject:" and
"Duplicated-From:" in these are not "normal" headers but are considered
trace headers, like Received - so they are not to be modified by subsequent
systems. Now its a lot easier for email signature standard because all its
need to do is to create hash of all trace headers rather then creating
specific list of headers to be signed.
By making new headers out of the duplicates, doesn't that introduce a
requirement that the ordering of these headers be maintained? Otherwise
the order of headers into the hash will be ambiguous.
Duplicate headers are to be considered trace headers. And for trace
headers there is a requrement that their order be maintained. Also
order of "unknown" header is supposed to be preserved as well and
in particular because these headers appear between "received". I dont
think any "stupid" software is going to touch them even now.
Also, aren't there conversions that can happen (i.e., conversion per
RFC 2047 for non-ASCII text) that can occur even for non-standard
headers? I suppose this particular one can be gotten around by
requiring RFC 2047 conversion prior to signing, which is likely what
we'll need to do with IIM as well.
Good thing about duplication is that you dont do it, you just copy it as
is and new Duplicate-* or Original-* headers would by their definition
have the same structure the the original header they are based on.
Also for conversion, they are not supposed to be subject to that as
trace headers not supposed to be modified by subsequent systems.
There is also a requirement (not always followed) that all headers
continue to use 7-bit ASCII encoding so that they don't change between
7-BIT and 8-BIT conversion. Now that is true that are some cases when
you see a header with 8-bit data (Subject most often) but in this case
sender is not compliant with standards to begin with and its not our job
to account for every non-compliant case - here education about IETF
standard will help fix the problem on the sender's side.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net