Michael Thomas wrote:
On 04/06/2011 08:48 AM, Steve Atkins wrote:
That sounds like a fragile way to extend things - leave a
little used feature around and hope someone who wants something
new hijacks that field in a non-conflicting way instead. (Which
may not be what you're suggesting, but it's an implication I've
seen in some comments about i=).
Outside of the information that is needed to validate the DKIM
signature (v, a, b, bh, c, d, h, l, q, s, t, x) there doesn't
seem to be any real need for information to be recorded in
the DKIM-Signature field at all. Rather, it can
use the 5322 extensibility to add a header containing the information
that needs to be included (with an understanding that the receiver should
require that header be covered by the DKIM signature).
There is something to be said about using tags in the signature
rather than signed headers. Signers don't have to have any
reason -- and none should be inferred -- for signing any given
header. There are no semantics associated with that. Putting
something in the signature on the other hand carries
the exact semantics of what the value means _in the context of
the DKIM signature_.
So unless we want to start making new headers have a presence
of a DKIM semantics requirement -- which would probably be
hopeless -- it's probably better to keep extensibility within
the narrow confines of the DKIM header itself.
Since DKIM provides mechanism for signers to achieve that authenticity
outcomes independent for their reasons for standard features or
extensions,
I think both points are valid but with a difference of one having a
higher or lower threshold for authenticity verification. So from this
aspect, I would tend to agree with you that it would be probably
better when extensions use the DKIM header.
Authenticity related to confining extensions to the DKIM header would
be easier to reach and "harder" to reach when using extra headers
because it presumes the extra headers will be persistent (passthru)
along the path, hence why we have a recommended set of commonly known
RFC 5322 headers to bind and expected to survive.
I hate to be anal about it, but all that made sense when Policy was a
principle focus and not Reputation because Policy allowed us to grasps
and deal with DKIM authenticity failures.
But now with reputation coming out of the closet as the WG accepted
primary focus and everything related to DKIM; the proposed standard
and helper RFC documents, its now only about assessing a positive
authenticity with a trusted signer domain identity source. The mindset
is now there is a lesser need to consider anything else.
In short, since reputation does not deal with authenticity failures,
domains should be wiser regarding raising authenticity complexity and
verification thresholds because reputation can't help you when things
go wrong.
The lack of concern for dealing with faults or authenticity failures,
makes it easier to consider removing or reducing the failure points
which appear to have no value.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html