Jim Fenton wrote:
Arvel Hathcock wrote:
hi Jim (and everyone)!
> I'm still missing a suggestion for what we use when the Sender header
> field does not match any of the addresses in the From. Do we then
> revert to First Author? All Authors?
The idea of checking SSP on up to N From: domains is the only
suggestion I've seen so far and I can't think of anything better.
So, if the SSP algorithm returns Suspicious for any one of the domains
found in From: then let that be the final SSP result (in fact, further
SSP checks could be skipped at this point). In other words, if even
one of the domains listed on the From: requires a verifiable signature
and that signature is NOT present then the message is Suspicious even
if the result of SSP for one or more of the other domains is
non-Suspicious.
Would this work?
It could.
Let me summarize what I think we have consensus on (chairs, please
correct me if I'm incorrect because this is your call):
If a message has multiple From addresses, and the Sender address matches
one of the From addresses, then the SSP of the Sender address domain is
queried. (change from the first From address in the current draft)
What we have left to answer:
If a message has multiple From addresses, and the Sender address does
not match one of the From addresses, then I have seen three
possibilities proposed:
1. Use the domain of the first From address
2. Use the domain of the Sender address
3. Use the domains of all From addresses, and if the message is
Suspicious (SSP non-compliant) according to the SSP of any of the From
address domains, the message is considered Suspicious (SSP non-compliant).
Note that when I say "Sender address matches..." that means the entire
addr-spec of the address (including the local-part, but not the
display-name). If you think it should be something else (such as just
the domain part) that should be compared, please say so now.
Arvel's suggestion above is #3. I believe Hector earlier favored #2.
After reviewing this, I think we have no choice but to lookup all the
co-author's domains, regardless of the presence of sender. At best,
Sender can be use to change the lookup order.
Examples:
#1: sender matching domain
From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com
Sender: p4 @ b.com
#2: sender no matching domain
From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com
Sender: p4 @ d.com
#3: no sender
From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com
I think #2 and #3 is the same situation, so therefore we need the
logic for handling no-sender header situations as it was a non-matching
situation as well.
We have no choice but to look at each co-author domain.
IMO, there is only one thing we are looking for here - a restricted policy:
dkim=all
dkim=strict
I think if any one co-author domain is restrictive, then in order to
provide protocol consistency and fail-safe transactions, the message
must be deemed non-compliant.
This is preferable for the (rare) situations where maybe the primary
author with DKIM signing potential is given the responsibility to
distribute mail for co-authors who are not capable of signing, hence no
SSP record.
The only place I see Sender helping is as a "helper" to help avoid
lookup overhead and redundancy. Like in #1, if a sender header exist,
and its domain matches one of the co-authors, then possibly it can be
used as the FIRST domain to lookup.
In other words, when there is no sender, the look up order would be:
A.COM
B.COM
C.COM
but with a matching sender (B.COM), the lookup order could be:
B.COM
A.COM
C.COM
But regardless of the lookup order, I believe we have no choice but to
lookup all the unique domains in the From: field. If B.COM comes back
as SSP DKIM=UNKNOWN, you still need to lookup A.COM and C.COM for any
restrictive policies.
The only time a Sender domain lookup is meaningful, is when the policy
is restrictive, thus short-circuiting any further lookup.
Make sense?
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html