(Note: part3 of the reply)
On Wed, 13 Jul 2005, Jim Fenton wrote:
5. Header field reordering:
From section 3.5 -
"The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in section 3.6 of [RFC2822], and hence
SHOULD NOT be reordered and SHOULD be kept in blocks prepended to the
message. In particular, the DKIM-Signature header field SHOULD precede
the original email header fields presented to the canonicalization and
signature algorithms."
First of all these SHOULD may well have to be MUST consider that you
have quite a bit depending on that reordering does not happen. Second
RFC2822 really does not say that trace fields should proceed other
fields and should not be reordered. The only thing it says is that
trace fields should not be reordered in relation TO EACH OTHER and
that is different statement - that should be mentioned if you're
comparing to RFC2822 defined trace fields
There are two separate issues here:
1. The suggestion that the DKIM-Signature be treated as a trace header
field needs to be a suggestion because it's hard to retroactively rule
a previously-unknown header field is a trace header field. This
suggestion is made in order to minimize breakage when multiple
DKIM-Signatures are present, and all that is being asked is that they
not be reordered with respect to each other. This allows
DKIM-Signatures to potentially sign other DKIM-Signatures, although
we haven't precisely defined how that should or could work.
I know what you're asking, but as have been pointed out there is no
procedure to define new fields and have all existing systems automaticly
seen them as trace fields. So there is no guarantee that DKIM-Signature
fields would not be reordered in respect to each other.
Personally however I don't think this is going to be any kind of serious
problem.
In other respects, the order of signing headers is defined by the ordering of
the tags in the h= value, and in the case of duplicate headers, the
"bottom-up" rule (in section 5.2.2) applies. The only ambiguity occurs when
a non-standard header field is signed which occurs more than once at the
Like say "Authentication-Results"?
recipient, since these can be reordered. Section 5.2.2 also recommends
against signing such header fields.
Its pretty useful to be able to sign Authentication-Results ...
7. Use of copied haeders "z" tag
Use of copied headers that are in "z" tag is not specified very well
and the syntax for using "z" tag maybe problematic (I'll discuss this
later most likely). The particular issue is that "h" how says that
header fields that appear more then once now have to be explicitely
listed one by one (i.e. h= Resent-From : Resent-From : ...). Would
that also mean that each one of the above "Resent-From" would have
to be present in "z" and in the right order? If not then how do you
deterimine which one was copied?
There should probably be a "bottom-up" rule for copied headers, I
suspect.
You have not answered the question on if use of any one header field
in z would require that that all such named header fields also be in z
(almost certainly the only way to deal with this).
The transformation of the data for copied header fields is kind of
"crude" and "messy", I can see problems if header is complex something
like DKIM-Signature for example :) My suggestion is to again look at
my proposal to just go ahead and copy the header all together and
put it as separate "Saved-XXXXX-From: ..." trace field and just
directly refer to that in the 'h' list. Plus using this sytem also
means that header field does not need to be copied every time (for
multiple MTAs in email path) and can be copied once and future
signing system can reuse and reference existing field.
By putting the copied header fields in the DKIM-Signature header field, it is
guaranteed that the copies are signed (since DKIM-Signature is self-signed).
Same as when you reference Saved field in "h" (its then signed as part of
DKIM hash).
Otherwise, a lot of new requirements about the DKIM-Signature signing
particular other header fields need to be created, and this seems cleaner.
By the way it looks, its not, 'z' looks really bad. Checking Saved field
to be the same as original is very simple operation also - simpler then
what is required to decode "z".
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net