[ietf-dkim] Re: Concerns about DKIM and mailiing lists, etc.

[Barry Leiba]

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 
to implement.

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

--
Barry Leiba, Pervasive Computing Technology  (leiba at watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam