> -----Original Message----- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, May 06, 2011 11:43 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output > > >>> +----------+--------------+ > >>> | count(*) | mailing_list | > >>> +----------+--------------+ > >>> | 77246 | 0 | > >>> | 78853 | 1 | > >>> +----------+--------------+ > >> > >> That's just strange. Most of the l= signatures don't cover the whole > >> body, and half of those didn't go through a mailing list? > > > I suspect it's use of "l=" by a signer without regard to whether or not > > the mail is heading to an MLM. For example, OpenDKIM's antecedent had > > that as an option; only the evolution to OpenDKIM allowed you to be more > > specific. > > Except that doesn't explain why l= doesn't cover the entire body. > > Signing or verifying bug? Clever spammer replaying signed mail and > getting away with it? Forwarders of some sort that add a footer but > otherwise don't look like mailing lists?
My guess is the third one. The specification for what we decide is a mailing list submission isn't bulletproof, but is listed as: - has a "Precedence: list" field - has a "List-Id: field - has a "List-Post:" field - has a "List-Unsubscribe:" field - has a "Mailing-List:" field If there are other metrics that are easily detected, I could add monitoring for them and then cut off future reports at today's date, or something like that. There's also the whole thing about "l=" is the post-canonicalization body count, not the actual full message byte count. I'll double-check on that logic. This won't change the "l=" use information though, just the pass/fail reporting accuracy. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html