Subject: Re: [ietf-dkim] who's using l=

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Jun 2009 11:23:51 -0400

John says...
> Related question: whether or not you sign with l=, does anyone have
> any software that does anything with l= other than use it to decide
> how much of the body to check?  Anyone seen an MUA that uses it to
> manage message display?  A spam filter that uses l= in its secret
> sauce?  Any use of l= at all?

I think this is an important question for us to answer as we decide
what to do with it in 4871bis work, and I'd like to see some answers
either way (including "We don't sign with it.")  I'd especially like
to hear what verifiers do if it's present and it doesn't cover the
whole message: what do you do with the part of the message past the
specified length?

So, please, don't be silent on this thread.  But also, please only
talk about what implementations *are doing*, not what they might
hypothetically do.  Thanks.

Barry, as chair

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Jun 2009 08:56:01 -0700

> hypothetically do.  Thanks.

If we see a message that's signed with l= then we treat it as unsigned
right now.

If l= usage becomes common we'll probably treat the case where
l= the actual length of the message as validly signed and any
other l= value as unsigned.

We're not doing anything particularly clever with DKIM identities,
though, just using them as a key to a domain based whitelist to
enable some automated handling of inbound email (FBL handling,
primarily) and enabling rendering email with risky renderers (html,
pdf) by default

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 01 Jun 2009 09:04:22 -0700

> primarily) and enabling rendering email with risky renderers (html,

uhhh.  hmmmm...

that doesn't qualify as clever?

well, ok, maybe not /particularly/ clever, but still...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 1 Jun 2009 12:08:02 -0400

> well, ok, maybe not /particularly/ clever, but still...

Steve, what do your dkim identities look like?

-- 
Jeff Macdonald
Ayer, MA

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Jun 2009 09:38:03 -0700

> Steve, what do your dkim identities look like?

"example.com". We don't pay any attention to any details
beyond "is this domain on our whitelist?". If it's validly
signed, and it's on the domain whitelist, then we treat
it just the same as mail received from an IP on the IP
whitelist. (Which is to say that we trust the content not
to be hostile, and that's about it.)

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 May 2009 03:45:04 -0700

> hypothetically do.  Thanks.
For about the 100th time...

At Cisco, our implementation was built to be able to detect "spear phishing"
attacks. That is, mail that is forged that purports to come from 
internal sources
with the object of tricking people into giving proprietary information.

To accomplish this, we mandated that all mail from Cisco would be
signed, and that we'd annotate any mail incoming to Cisco whose message
did not verify ("Danger Will Robinson!").

Mailing lists in particular would generate lots of false positives and 
pretty
much make the whole scheme useless. However, with the use of l= and
other methods our mailing list verify rate was >90% which was acceptable.

We justified and built the entire DKIM effort at Cisco based on this use.
If you remove l= and other options, you will destroy this use of DKIM. I'll
add that this is a *direct* tangible benefit of DKIM that you'll be 
destroying.

       Mike