[ietf-dkim] Re: Concerns about DKIM and mailiing lists, etc.
leiba at watson.ibm.com
Thu Mar 16 11:44:29 PST 2006
Let me try to pull this discussion back a bit...
> >> The verifier then simply replaces the subject text with the value
> >> from z= that was signed. That's one way of solving the mailing list
> >> subject munging problem.
> > This goes far beyond the specification. While it might be useful, it
> > is really a heuristic and it is not part of the draft that is seeking
> > standardization.
On the Cisco discussion:
My understanding (Mike, please correct me if I misrepresent this) is
that Cisco is primarily using DKIM, at least for now, to verify that
mail purporting to be from cisco.com (and is TO cisco.com) is, indeed,
from cisco.com. To that end, when you look at an incoming "cisco.com"
message, you see one of these cases:
1. It has a valid cisco.com sig.
2. It has a failed cisco.com sig.
3. It has no cisco.com sig.
For case 1, you're done, but see below.
For case 2, you check SSP and see that cisco.com signs all mail, and you
have to decide what to do with it (again, see below).
For case 3, you check SSP and see that cisco.com signs all mail, and
since this isn't signed, you toss it (or place it under other scrutiny).
This is "below":
To minimize the incidents of case 2, you use the z= tag in the
signature, so that you can verify the sig with the ORIGINAL headers.
You can then see WHICH headers changed in transit, and take action based
on that. Now, z= was in IIM for that purpose, but in forming the DKIM
spec we decided to label it for diagnostic/tracing purposes, and not for
signature verification purposes. Of course, any implementation is free
So some of the "case 2" cases now become "case 1" cases. For case 1,
you have what amounts to a "reputation DB" that says "cisco.com is
good." (Alternative interpretation, see next paragraph.)
In any case, you can show mail with verified sigs to the users in some
way that tells them that the "sending domain" (sorry Dave; we never did
close on terminology here) has been verified. Whether or not you've
done something special with "cisco.com" in the previous paragraph, the
end user can look at "cisco.com" and "verified", and be happy. The user
can also look at "nastyspammer.com" and "verified", and it's up to the
user whether she's happy or not. In this case, the user's brain is
providing the "reputation DB".
Is that relatively close to what's happening?
Now there's the question of whether using z= for the purpose that Cisco
(and, if the option is turned on, Alt-N) is using it for is "OK". The
DKIM spec does not say that that's what it for. Moreover, the DKIM spec
gives a clear and well defined method for verifying sigs, and the use of
z= is not part of it. So I'd say (as a participant, not in any "chair"
capacity) that this doesn't meet the spec; that is, it isn't "compliant".
That may be perfectly OK -- every implementation, as I said above, is
free to implement. In Cisco's case, if this implementation is an
internal thing, does anyone else care if it's "non-compliant"? In
Alt-N's case, I'd think it ought to be clear that if the option to use
z= is turned on, it deviates from compliance with the DKIM spec.
Arvel, I'm curious: how do you explain that option to the administrator?
Barry Leiba, Pervasive Computing Technology (leiba at watson.ibm.com)
More information about the ietf-dkim