On Dec 28, 2006, at 6:19 AM, Michael Thomas wrote:
There's two ways to read this restriction: one is that you should
never do this under any conditions which ventures into silly
net.cop delusions of what the protocol document can mandate, and a
more innocent caution that the actual headers to be used for a dkim
verification are the outside headers, not the copied headers.
The latter is the only reasonable way to read this. I agree with
John that this is pretty well trod ground and that it's pretty much
hopeless that we'll agree on any particular approach -- including
what started this thread. Nor do I think we ought to since it's an
inherently driven by heuristics which involve risk/reward tradeoffs
for the receiver which a standard should not be trying to second
guess. Leaving some raw tools around like z= and letting receivers
decide for themselves is about all we need for now, IMO.
Header copies might become useful as an interim fix when resolving
issues created by "fix-ups" added by MDAs, which can be problematic
at this time. A hash value for the header would allow a faster
isolation of problematic headers. These issues should be resolved
when the "fix-ups" are discontinued, but that might be holding one's
breath for a while.
A more significant concern is related to the number of attempts
needed to resolve which signature goes with which email-address,
resulting from a missing link. Don't assume the signing-domain and
the email-address domain owners have exchanged private-keys or
delegated domains in some manner. That assumption represents a
substantial barrier for deployment.
DKIM differentiated itself from S/MIME and OpenPGP by ensuring the
signature remained _invisible_. Expecting recipients to recognize a
DKIM signing-domain assumes:
1) The signing-domain is somehow visible, which will likely confuse
more than enlighten.
2) The signing-domain and the email-address are directly related,
which is unrealistic in the general case.
Providing a means to link the email-address to the signature
dramatically reduces the overhead associated with searching for a
corresponding signature, assuming there are other means developed
that indicates an association that does not depend upon the exchange
of private-keys or zone delegations.
This linkage can be accomplished by making a rather minor change to
the 'd=' and 'i=' syntax within the base draft.
3.5 The DKIM-Signature header field (i=)
---'d='
Was:
This domain MUST be the same as or a parent domain of the "i=" tag
(the signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8
(Signing by Parent Domains). When presented with a signature that
does not meet these requirement, verifiers MUST consider the
signature invalid.
Change to:
This domain MUST the same as or a parent domain of the "i=" tag (the
signing identity, as described below) , or it MUST meet the
requirements for parent domain signing described in Section 3.8
(Signing by Parent Domains) for key record extensions ('g=' and 't=s'
to be valid). When presented with a signature not meeting these
requirements, other unspecified means to associate the email-address
domain with that of the signing domain are required, otherwise
verifiers MUST consider the signature invalid.
---'i='
Was:
Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty local-part followed by an "@" followed
by the domain from the "d=" tag). The syntax is a standard email
address where the local-part MAY be omitted. The domain part of the
address MUST be the same as or a subdomain of the value of the "d=" tag.
Change to:
Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty local-part followed by an "@" followed
by the domain from the "d=" tag). The syntax is a standard email
address where the local-part MAY be omitted. The domain part of the
address is not required to be same as or a subdomain of the value of
the "d=" tag.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
