> -----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

Reply via email to