John R Levine wrote:
Which handy local list of signers is that? Where do I find Cisco's?
Beats me. If Cisco doesn't expect to be able to tell what signatures are
worth using, I can't tell what problem you expect to solve and I would be
most interested to hear what use you plan to make of DKIM. Really.
In particular, experience with SPF suggests that the majority of mail with
valid signatures will in fact be spam, signed by the spammers. Surely
you're not planning to put gold stars next to mail just because it has a
signature that matches the From: line. Or are you?
This was all explained at the DKIM summit, whose slide I believe are
available on dkim.org. We are concerned about phishing attacks against
Cisco employees via spoofs purporting to come from Cisco itself. This
is a real life business affecting problem, and quite frankly it's
pretty frightening because the it's extremely difficult to tell what
is a bone-headed outsourced marketing scheme, and what is really trying
to steal your credentials, etc. This costs our Infosec people a great
deal of time and money sifting through the false positives that we
generate.
By signing all our mail and having a policy that we sign all our mail,
we can be reasonably certain that mail without a valid signature isn't
from Cisco and annotate the message accordingly. This works just fine
with the exception of mailing lists. What I'm trying to get a handle on
right now is to what _extent_ -- given our use of l= and z= -- it is a
problem. From what I can tell right now, for the "typical" mailing list,
it's going to validate. There is no question that some manglers will
never validate, and that there will be occassional blips on lists that
normally validate, but that seems acceptable given the threat we're
addressing. But we'll see.
Other companies -- who undoubtably use external mailing lists far,
far less than Cisco may never even perceive this as being a problem,
and just nuke the "spoofs" at the border. That's why I say that when
push comes to shove, mailing lists will almost certainly be the loser
unless we collectively come to some reasonable accommodation that
doesn't involve inventing a huge amount of work for the IT department
with "handy local lists".
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html