Subject: [ietf-dkim] l= summary, as I see it

From: Eliot Lear <[email-masked]>
Date: Fri, 22 May 2009 15:53:32 +0200

l= provides a benefit when the SIGNERS sign, and mailing lists DON'T 
DISTURB.  This does happen, although we can debate how often.  The key 
point is that if the mailing lists employ an anti-spam check and resign, 
there is probably no need for l=.  This to me means that l= should be 
viewed as a Time To Market function to have more valid signatures out 
there, and is best obviated by deployment of DKIM in mailing list 
software.  That's happened in some place, but not enough.

I stand by my point that it is perfectly feasible to mitigate any risks 
that l= introduces.  But.  Those risks DO have to be mitigated.

So here's where I come down: nuke l=, but get the mailing list software 
people to sign.  The big one I would want to tackle is MailMan.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 May 2009 09:34:22 -0700

On May 22, 2009, at 6:53 AM, Eliot Lear wrote:
> DISTURB.  This does happen, although we can debate how often.  The  
> key point is that if the mailing lists employ an anti-spam check and  
> resign, there is probably no need for l=.  This to me means that l=  
> should be viewed as a Time To Market function to have more valid  
> signatures out there, and is best obviated by deployment of DKIM in  
> mailing list software.  That's happened in some place, but not enough.
>
> I stand by my point that it is perfectly feasible to mitigate any  
> risks that l= introduces.  But.  Those risks DO have to be mitigated.
>
> So here's where I come down: nuke l=, but get the mailing list  
> software people to sign.  The big one I would want to tackle is  
> MailMan.

Why limit the l= discussion to messages being changed made mailing  
lists???

Mailing lists will not affect often phished transactional email where  
retaining valid signatures is far more important.  It is too soon to  
conclude how DKIM is best used.  Many recipients will receive messages  
with various bits of text added, such as ads which may unsafe,  
especially when iFRAMEs are commonly inserted into websites.  Removing  
the l= parameter will ensure DKIM is unable to cope with this  
situation and DKIM signatures will fail to provide the desired  
protection.  People may even expect DKIM signatures to fail whenever a  
notice is added.  This creates an obvious mode for phishing by adding  
fake notices.

Not all providers check DKIM signatures.  To improve DKIM coverage, it  
could become important for MUAs to remain able to bridge protection  
gaps and deal with typical environments, and indicate appended  
information.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 22 May 2009 11:01:42 -0600

> people to sign.  The big one I would want to tackle is MailMan.

+1 to nuking l=, and +1 to evangelizing DKIM to open source mailing list 
software development teams.

MailMan is covered, though -- it can already be configured to strip specific 
headers from incoming messages, and uses the local MTA to send.  I recently 
built a fresh Debian box with MailMan, Sendmail, and the DKIM milter -- all 
from packages.  I created the keys I wanted, put them in the right places on 
the filesystem and in DNS, and every message is signed.

(This message will be signed, too, with a different key on the same box.)

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 22 May 2009 12:39:33 -0600

J.D. Falk wrote:

> MailMan is covered, though
  [ . . . ]
> (This message will be signed, too, with a different key on the same box.)

Even better!  The MIPAssoc server (also running MailMan) swapped my 
signature for Authentication-Results, and signed the new message.

I love it when FUD is so easily overridden by operational reality.

---

From: Doug Otis <[email-masked]>
Date: Fri, 22 May 2009 12:33:19 -0700

On May 22, 2009, at 11:39 AM, J.D. Falk wrote:

>  love it when FUD is so easily overridden by operational reality.

Not all recipients will have use of the latest version of Sendmail.   
The concern regarding the l= parameter is not limited to mailing  
list,  as John suggests.

Providers insert ads into the messages.   Who is user be required to  
trust, and how will they know who generated the link?  It is not  
uncommon to find providers, in pursuit of revenue, post ads  
referencing websites that become compromised due to lax security and  
end up containing IFRAMEs that load malware.  It would not be good to  
name names, but this is not uncommon.  Once followed, the recipient's  
system is compromised without any intervention or outward indication.   
Often a user never knows their system was compromised.  The number of  
compromised systems and web servers is shockingly high.  This is not  
FUD, this is fact.  Knowing the origination of EVERY link is  
critically important.

By having the l= parameter available, senders wishing to retain trust  
can differentiate their message from that of a recipient's provider.   
The l= parameter can mitigate the bad practices of some providers, and  
ensure the DKIM signature remains reliable and trustworthy.  This  
concern needs to be viewed from more than just an email provider's  
perspective.

Why are providers bent on preventing recipients from knowing _who_ is  
responsible for message content?  While a recipient may trust their  
financial institution, they may be less inclined to trust a provider  
whose main revenue might be based upon ad revenue from who knows who.

Taking away the l= parameter significantly limits the protections DKIM  
is able to offer.  Once again, this concern is NOT about messages from  
mailing lists!  This is about ensuring recipients remain informed  
about the origination of messages where they might be told that it  
came from someone else.  That is simply wrong!

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Fri, 22 May 2009 15:37:01 -0400 (EDT)

J.D. Falk:
> DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k00001;
> 	t=1243013748; bh=KKzdl+Xw6IloZrUtOCIjcoI2bG8=; h=Message-ID:Date:
> 	 From:MIME-Version:To:References:In-Reply-To:Subject:List-Id:
> 	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
> 	 Content-Type:Content-Transfer-Encoding:Sender; b=If3rAwfKN03nqJhjL
> 	EqKR6+0izu3ujK8ak0Oa4AMAuTwZtofkhfGqH6V11/OmvVIPclZ45L0zTsbmYT8XoXN
> 	5c66LqkE9t/leS246vbssPyoNF3SBhrhFmhuSWno5S5YGLFb3bYto06u8dRLhmakafg
> 	1MvoT6tUnSj5aHo+uCOI=
> Received: from ocelope.disgruntled.net (ocelope.disgruntled.net
> 	[97.107.131.76])
> 	by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4MHZLXK017726
> 	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
> 	for <[email-masked]>; Fri, 22 May 2009 10:35:27 -0700
> Authentication-Results: sbh17.songbird.com;
> 	dkim=pass (1024-bit key) header.i=@cybernothing.org
> 

+1 on the motion to kill and six-feet-under the l= option.

As for evangelizing, perhaps the DKIM website can put up (pointers
to) HOWTO guidance for stripping DKIM headers and re-signing
submissions as in the above example.

	Wietse

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 22 May 2009 12:50:45 -0700

> submissions as in the above example.

as soon as someone sends me a credible url, i'll add it/them.

d/

-- 

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

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 22 May 2009 14:00:38 -0600

Doug Otis wrote:

> trust, and how will they know who generated the link? It is not uncommon
> to find providers, in pursuit of revenue, post ads referencing websites
> that become compromised due to lax security and end up containing
> IFRAMEs that load malware.

Sounds like an argument /against/ allowing part of a message to be signed, 
and part not.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 May 2009 16:40:51 -0700

Eliot Lear wrote:
> DISTURB.  This does happen, although we can debate how often.  

About 95% of the time at Cisco. There's nothing to debate because we had 
hard
evidence.
> The key 

FWIW: I tried to do exactly that -- I had a Python DKIM signer ready to go
with buy-in from the Mailman folks, but Cisco legal failed. However..

Mailing list software developers have exactly zero control over whether 
people
sign messages or not.  Whether mailing list software has the ability to 
sign or
not isn't the major impediment. Indeed, putting it in the mailing list 
software --
or any other independent mail generator -- just leads to administrative 
hassles.

       Mike

---

From: Doug Otis <[email-masked]>
Date: Fri, 22 May 2009 14:38:26 -0700

On May 22, 2009, at 1:00 PM, J.D. Falk wrote:

>> referencing websites that become compromised due to lax security  
>> and end up containing IFRAMEs that load malware.
>
> Sounds like an argument /against/ allowing part of a message to be  
> signed, and part not.

By having a body length parameter as part of the DKIM protocol,  
whenever offered by the signer, users can employ MUAs that properly  
indicate which portions of a message originated by the signer, and  
which did not.  This might be done by distinctively enclosing the  
included portions.  Often appended comments mess up page formatting  
whenever lines extend beyond the edge of a page.  Don't you hate  
that?  Currently, use of RFC 5451 allows providers to include anything  
they wish, while still purporting the entire message to have been  
originated by the signer.  This is wrong, regardless of any number of  
providers demanding MTA that offer such a dubious feature. :^(

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 May 2009 11:38:30 +0100

> Received: from ocelope.disgruntled.net (ocelope.disgruntled.net

But it wasn't. The FUD was actually increased, because the DKIM-Signature  
that was added doesn't cover the Authentication-Results header.

So, being of a suspicious disposition, I shall assume that the  
Authentication-Results was a bogus addition by some subsequent Bad Guy  
(who was smart enouth to fix the Received headers properly), and I shall  
accuse MIPAssoc of deliberately colluding with the Bad Guy by removine  
whatever signature has originally been present (or should have been, given  
some advertised policy of songbird :-) .

Half fixing a security issue is worse than not fixing it at all!

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 25 May 2009 13:05:50 -0000

>that was added doesn't cover the Authentication-Results header.

Chaining signatures with Authentication-Results is unlikely to work,
since with two or more levels of chaining, there is no reliable way to
tell which A-R header goes with which signature.

But since it is a Fundamentally Bad Idea, it doesn't matter, and there
is no security issue to fix.  If a message has one good signature and
a bunch of broken signatures, as will generally be the case here, you
ignore the broken ones and use the good one to evaluate the message.

Everybody I know filters list mail based on the identity of the list,
not the identity of the contributors, they have ever since there has
been mail filtering, and there is no reason to expect that to change
in the future.  I am baffled that people have wasted so much effort on
broken non-solutions to a non-existent problem.

A-R can be useful in some very narrow circumstances, where the channel
between the agent that applies the header and the agent that uses it
is secure.  The most likely setup is that it's applied as the message
is dropped into a mailbox on a server, and it's used by a MUA or local
filtering proxy that picks up the message via POP or IMAP.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 May 2009 12:23:06 -0400

> tell which A-R header goes with which signature.

Chaining isn't the point.  And mailing lists aren't the only
forwarders (I agree with what you say about mailing lists).

My address, at computer.org, is a forwarder.  When the mail gets to my
real mail server, it doesn't filter based on computer.org, but based
on the original sender, of course.  Now, computer.org won't break any
DKIM sig that's already there, so there's no worry.  But suppose it
did.

The model is this:

If you're going to send a message on and are not going to break the
signature, you do one of these:
1. do nothing to A-R or DKIM-Sig records that are there, and do not
sign yourself, OR
2. do nothing to A-R or DKIM-Sig records that are there, and add your
own sig.  Your sig does NOT cover A-R.

If you're going to send a message on and ARE going to break the
signature, you do this:
1. verify all previous sigs, creating your own A-R in the process, then
2. remove all previous sigs AND all previous A-R, then
3. put in your own A-R, then
4. DKIM-sign the message, having the sig cover your A-R.

If the process works like that, the verifier has exactly one signature
that covers the authentication results, so it knows where they came
from.  It can use that extra information or not, as it chooses.

We can argue about whether the information is useful in that case, but
it's the verifier's choice.  And it means that you don't leave
signatures around that YOU broke, so if I get "one good signature and
a bunch of broken signatures", it means the signatures were broken for
some other reason.  (I probably don't care about that, I'm just
saying....)

> filtering proxy that picks up the message via POP or IMAP.

As I describe things above, A-R can be useful in more situations than
that.  If you (the verifier, the MUA, whatever) trusts the signer that
signed the A-R, you have information you can use.

Barry, as participant

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 May 2009 12:28:26 -0400

I'm going to make one attempt here, and then give this topic up:

On Fri, May 22, 2009 at 5:38 PM, Doug Otis <[email-masked]> wrote:
> which did not.

The point, Doug, is that WITHOUT l=, the portions of the message
originated by the signer are [all], and the portions that were not are
[none].  So your problem is covered.

The issue is whether it's useful to be able to HAVE a non-null portion
that "was not", which is what l= provides.  What everyone here is
saying is that it is NOT useful to have that, so we don't need l=.

If you're saying that you WANT to be able to have an unsigned portion
of the message, then you're the only one.  Everyone else thinks that
if such a thing exists, it should be considered evil and thrown away.

We put l= in there with the idea that it would be useful.  We
experimented with it.  We have the results of the experiment, and it
looks like we have consensus on this point.

Barry, as participant (for now)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Doug Otis <[email-masked]>
Date: Thu, 28 May 2009 12:30:02 -0700

On May 28, 2009, at 9:28 AM, Barry Leiba wrote:

> originated by the signer are [all], and the portions that were not  
> are [none].  So your problem is covered.

By specifying message body length, an MUA can better deal with A-R  
chaining.  A-R headers now permit mail-box delivery agents the freedom  
to insert notifications and/or ads into the message.  The A-R header  
will report "Domain X" had signed the message, while not providing any  
method to detect and isolate these possible mail-box delivery  
modifications.  Without the ability to determine the length of the  
original message signed, determining the locations of simple mail-box  
delivery modifications goes from being automatic to fairly cumbersome.

> The issue is whether it's useful to be able to HAVE a non-null  
> portion that "was not", which is what l= provides.  What everyone  
> here is saying is that it is NOT useful to have that, so we don't  
> need l=.

Some systems handle message attachments separately, and at times may  
exclude attachments.  Eventually, a practice similar to DKIM should be  
established to separately encapsulate attachments.  Once such a  
convention exists, separating message attachment hashes will better  
ensure textual portions of a message can be handled independently from  
that of message attachments.  Such separate handling should make the  
textual communication more robust.  Retaining the l= parameter ensures  
future body length conventions can enable the separate handling of  
message attachments without impairing non-refutable textual content.   
Such a feature requires that the unmodified message bodies be  
recoverable in a simple fashion.

> If you're saying that you WANT to be able to have an unsigned  
> portion of the message, then you're the only one.  Everyone else  
> thinks that if such a thing exists, it should be considered evil and  
> thrown away.

The desire is to retain an ability to treat attachments separately, in  
addition to locating mail-box delivery agent modifications.  Future  
conventions will likely become more cautious about the handling of  
attachments, while hopefully ensuring the textual portion of the  
message remains non-refutable.  To allow this to occur, demarcating  
the where the textual information associated with the message body  
ends and the attachments being become imperative.  While perhaps this  
is not an apparent need currently, DKIM has not really be used all  
that extensively.  In addition, use of the A-R process is also  
extremely new.  When signature hashes are commonly invalidated as a  
result of isolated attachments, phishers will also appear to have had  
their messages altered in this fashion.

> looks like we have consensus on this point.

DKIM has yet to deal extensively with A-R processing, so one might say  
that the l= experiment is not complete, nor should the timeframe be so  
brief, especially after such a profound change to the way DKIM will be  
handled.  It has been about 2 years since RFC4871 was completed.  It  
took 19 years before rfc821 was obsoleted and then another 8 years for  
minor updates that mostly addressed IPv6.   In addition, permanently  
dropping the body length creates greater exposure to the use of  
rainbow tables commonly used to defeat secure hashes.  Bad actors now  
exploit distributed file systems across millions of compromised  
computers to find hash matches.  When the body length is undefined,  
this enables a simple and rapid way to extend available hash values  
associated with different phish bodies.  The size and extent of this  
technique may place DKIM at greater risk, especially where providers  
may be reluctant to use more resource intensive hashes.  In addition,  
a provider's sensitivity to the DKIM resource issue can not be  
ameliorated by excluding large stand-alone attachments that can (and  
should) be separately confirmed prior to any use.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 May 2009 16:01:52 -0400

Just on one portion, here:

On Thu, May 28, 2009 at 3:30 PM, Doug Otis <[email-masked]> wrote:
> Some systems handle message attachments separately, and at times may exclude
> attachments.  Eventually, a practice similar to DKIM should be established
> to separately encapsulate attachments.  Once such a convention exists,
> separating message attachment hashes will better ensure textual portions of
> a message can be handled independently from that of message attachments.

Hm.
I should think that the DKIM way to handle the removal of attachments
would be for the agent that remove the attachments to re-sign the
message after it does so.

Barry

---

From: "John R. Levine" <[email-masked]>
Date: Thu, 28 May 2009 22:34:28 +0100 (BST)

> signature, you do one of these:

Sign or don't sign, it works fine either way.

> If you're going to send a message on and ARE going to break the

You're a mailing list, so filter, sign and earn your own reputation.

DKIM is too complicated as it is, and it strikes me as an extremely poor 
idea to add yet more cruft to work around perverse situations that are as 
yet (and probably always) entirely hypothetical.

How likely is it that a mail setup that break signatures will add all 
sorts of code to support DKIM, check incoming signatures, add A-R headers, 
and resign them, but won't filter and sign like a mailing list does? 
This is the kind of arcane situation for which the correct advice is 
"don't do that."

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 28 May 2009 18:00:51 -0600

Barry Leiba wrote:
> On Thu, May 28, 2009 at 3:30 PM, Doug Otis<[email-masked]>  wrote:

Agreed.  No matter which MIME part was affected, it's still a modification 
of the original message and thus invalidates the assertions inherent in the 
original signature.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 May 2009 18:20:34 -0700

On May 28, 2009, at 5:00 PM, J.D. Falk wrote:

>>> Some systems handle message attachments separately, and at times  
>>> may exclude attachments.  Eventually, a practice similar to DKIM  
>>> should be established to separately encapsulate attachments.  Once  
>>> such a convention exists, separating message attachment hashes  
>>> will better ensure textual portions of a message can be handled  
>>> independently from that of message attachments.
>>
>> Hm.
>> I should think that the DKIM way to handle the removal of  
>> attachments would be for the agent that remove the attachments to  
>> re-sign the message after it does so.
>
> Agreed.  No matter which MIME part was affected, it's still a  
> modification of the original message and thus invalidates the  
> assertions inherent in the original signature.

I don't agree.   Information can be contained within a message that  
indicates the existence of the attachments, and even, after extracted  
from some repository, what their hash results should be.  I also agree  
with John about providers being unlikely to go to any additional  
effort.   It not in their nature, but of course only time will tell.   
We should take the time to discover how DKIM and A-R will be abused or  
misused.

One thing is fairly certain.  The l= parameter might greatly assist  
MUAs in isolating cruft added by a provider.  Unfortunately, when the  
debate is about security, or what a provider can get away with,  
security always is at the short end of the stick.

When a reputation service bases a recommendation upon the DKIM signer,  
an MUA finding the original signature and a broken hash due to some  
notice or ad, could still utilize the l= parameter to differentiate  
what had been appended or prefixed by some third-party.  It will be  
exceedingly difficult to establish fully independent two-way  
reputations.  The reputation of the signer, and that of the provider  
which might include some unknown fly-by-night ad links.  The recipient  
is likely to think they are trusting big-bank endorsed by the  
reputation check, only to find the link contains an iFRAME that  
installs malware because the ad server was improperly secured.  Only  
when an MUA carefully annotates what is the signed content, can the  
reputation be based upon the source of the message, independent of  
notices that may have been included.  Needing a single reputation  
result rather than two makes resolving the l= issue well worth the  
effort.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 May 2009 09:36:44 -0400

> yet (and probably always) entirely hypothetical.

I don't understand what "cruft" you think I'm talking about.  Nothing
in my message needs anything added to DKIM, and no one is suggesting
removing anything from DKIM that will invalidate what my message said.

Barry

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 May 2009 10:21:35 -0700

> removing anything from DKIM that will invalidate what my message said.

Anybody who says that "DKIM is too complicated" has no perspective
on internet protocols. SMTP, SIP, IKEv1 qualify as "too complicated".
Would that all internet protocols were as "complicated" as DKIM.

		Mike

---

From: Tony Hansen <[email-masked]>
Date: Fri, 29 May 2009 15:04:57 -0400

Are people signing messages using l=?

To move to Draft Standard, a feature needs 1) to be used, and 2) to be
interoperable.

>From the interop tests, I know that various implementations are able to
verify signatures that were signed with l=. So it *is* interoperable.

However, if no one has deployed with l= signatures, then it can be
safely removed *because* no one is using it.

But if *anyone* is signing with it, then it cannot be safely removed as
part of moving to Draft Standard. Then such a change would require
recycling back at Proposed Standard.

	Tony Hansen
	[email-masked]

Barry Leiba wrote:
> I'm going to make one attempt here, and then give this topic up: ...

---

From: "John R. Levine" <[email-masked]>
Date: Fri, 29 May 2009 22:22:11 +0100 (BST)

> I don't understand what "cruft" you think I'm talking about.

Telling people that it is reasonable to add a chain of A-R headers to 
messages with broken signatures, and expecting recipients to apply some 
ill defined algorithm to decide how much they believe each level of 
alleged signature.

I would really like to remove l= from DKIM to make it clear that it is not 
a good idea to even try to guess the history of a message based on 
signatures that don't verify and cover the whole messag.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 23 May 2009 20:48:49 -0700

> recycling back at Proposed Standard.

Cisco does. I'm pretty sure that the sendmail milter has the ability to 
also, so who
knows how many people use it.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 May 2009 16:59:37 -0700

On May 29, 2009, at 2:22 PM, John R. Levine wrote:
> Telling people that it is reasonable to add a chain of A-R headers  
> to messages with broken signatures, and expecting recipients to  
> apply some ill defined algorithm to decide how much they believe  
> each level of alleged signature.

By having the l= value defined,  the length of the message that was  
signed has been make explicit, where appended notices or ads can be  
omitted which is the intended use of this parameter.  In the case of A- 
R permitted cruft, the l= value allows rechecking the body hash as a  
simple process when the DKIM header contains both the length and the  
signed body hash.  MUAs annotating signed messages already must  
exclude portions of the message not included in the hash from being  
annotated as having been validated by a signature from the signing  
domain.  The MUA may also check the reputation of the signing domain  
and wish to assert a green/red bar.   Even with the A-R header,  
without some means to trim off appended messages, which is the  
original purpose of the l= feature, recipient may confuse which  
message content and reputation should this apply, that of the signer  
or that of the provider.  They may easily be confused as to who they  
are trusting.  Those purchasing ad space may even attempt to leverage  
the resulting confusion.  Perhaps this issue should be reviewed in a  
few years.  Making changes now would be based upon conjecture.

> I would really like to remove l= from DKIM to make it clear that it  
> is not a good idea to even try to guess the history of a message  
> based on signatures that don't verify and cover the whole message.

Without the l= feature, annotations based upon DKIM may prove  
uncertain whenever providers are lax at applying notifications or  
advertisements.  It is purely guesswork as to how this situation might  
be best resolved.  It seems appropriate to make statements about any  
attempt at message annotations covering all portions of a message  
based solely upon A-R headers.   I don't think there is any burning  
need to add additional cautions about the use of the l= parameter.  It  
seems such effort is aimed at allowing sloppy and likely dangerous  
annotation practices.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 30 May 2009 10:07:00 -0700

> recycling back at Proposed Standard.

Tony,

This is a much more stringent rule for Draft than I recall hearing before.

I've done a quick review of some IETF docs and can't find such a rule.  Can you 
point to anything about criteria for dropping features when going to Draft.  (In 
general, this appears to need MUCH better documentation than now exists, but 
perhaps I have forgotten some guidance that is already available.

While operational use is, of course, an issue, the premise behind dropping a 
feature is that there is not enough use to warrant retention.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 31 May 2009 00:04:30 -0000

>safely removed *because* no one is using it.

Looking through my log which now has over 13,000 DKIM signatures from
incoming mail, there's about 300 with l= and nearly all of those are
from Cisco.

Anyone from Cisco know whether you're doing anything with l= as
opposed to just putting it in the signature?

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?

R's,
John