Barry Leiba wrote:
> 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).
We're actually not differentiating case 2 and 3 and we're never
tossing the mail, only annotating it as "unverified" (we haven't
actually had the debate about what precisely the annotation says,
but I'm sure it will be a long one).
> 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.
Right.
> 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.)
No, we're just using the SSP settings for the domain, and that's
it: if the DKIM signature works, no annotation. If it doesn't and
its SSP is set to o=!, you get annotation. As such, we're
doing this primarily for ourselves, but if -- oh say -- IBM were
to start signing their mail with o=! policy, IBM would be afforded
the same annotation on failures. This is sort of like what Yahoo!
is doing with their web interface, but much more crude -- but
hopefully not very intrusive on the other hand.
> 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.
Correct, though we only annotate in the negative sense, ie when
we think there's something wrong via -base and -ssp.
> In this case, the user's brain is
> providing the "reputation DB".
I'm not really sure I'd call it a reputation DB, per se, even in our
wetware. I guess it's mainly because of the negative sense of our
annotation. But this is probably just an issue of getting the
semantics right -- "reputation" leaves me feeling really disjoint
from that is actually going on.
> 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.
I'm not terribly hung up on whether something is "in" or "out"
of spec because this is completely a local decision whether to
do this sort of robustness/risk tradeoff. Nor do I think this
would be a good thing to put in the spec. As I've alluded to before,
I'm much more comfortable calling this an experiment and seeing
where the data leads us.
Mik
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html