On Jan 23, 2008, at 10:11 PM, Jim Fenton wrote:
Ned Freed wrote:
I would really love it if we could get past the meta-discussion of
"is the multiple From: case important?" to the proposals that have
been made to address the issue. These include:
1. Perform SSP checks on the domains of all From addresses in the
message, with the exception of addresses having valid Author
Signatures. If any of the checks result in a Non-Compliant
(formerly Suspicious) result, then the message is considered Non-
Compliant.
or
2. In the case of multiple From: addresses in the message, and the
domain part of one of the addresses matches the domain part of the
Sender address, then perform an SSP check on that address unless
it has a valid Author Signature. If the Sender header field does
not match the domain of one of the from address or is missing
[violating 2822], revert to alternative #1.
This is an interesting, even novel approach. I'm still trying to
evaluate it. One question I have is how it would interact with what
headers are covered by the author signature. In particular, does
the Sender: field in this case have to be covered by the signature?
It might need to be, but I have a bigger concern about alternative
2. The Sender address and From address(es) have different
meanings. Just because a particular author happens to be the sender
of the message, should that affect which domains' signing policies
apply? I can't see why it should, which is why I favor alternative
1 given that we're not going to do something arbitrary in the
multiple-From case.
Jim,
The Author's email-address is not contained within the Sender header.
When a message is not complaint with policy, the signing domain MUST
NOT apply their signature. SSP confirms the policy of the signing
domain when policy is not already apparent via their signature. SSP
is not about the policy or identity of the author as you seem to
suggest.
Ned accurately said when a signing domain is also authoritative for
From address domain in question, then this email-address can be
considered signed as well. The signature's hash for some identity
within the signature's domain MUST include all From email-addresses.
When the signature's domain is authoritative for the From's email-
address's domain, (unless by a g= restricted key) the message MUST BE
assumed to meet the signing domain's policies.
There are some concerns this conclusion creates:
1) Is the header containing the matching identity included within the
signature's hash?
2) When a header contains a matching identity not contained within the
signature's hash:
a) this message should be considered SSP non-compliant (rejected)
b) require caution when displaying information not included within the
signature's hash
c) both a and b
3) Must a signature's matching identity be found within either a From
or Sender header?
DKIM is not about identifying the identity of the Author or that of
the entity introducing the message as denoted by From, Sender, or
Resent-* headers. The identity included within a signature is not
relevant with respect to signing policy. Any display of signed
identities must ensure any additional information based upon the
identity parameter (i=) must also be included within the signature's
hash.
RFC 4871 has some dangerous gaps within the specification. A g=
restricted key can be used to sign on-behalf-of any header. The
identity contained within the signature might match that of some
header, however this header is not required to have been included
within the signature's hash.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html