Subject: Re: [ietf-dkim] Collecting statistics

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Mar 2010 15:48:53 -0700

Maybe, or at least partly.  It depends on your reputation scheme’s secret sauce.

But reputation in particular is out of scope for this working group.

From: Franck Martin [mailto:[email-masked]]
Sent: Thursday, March 25, 2010 3:42 PM
To: Murray S. Kucherawy
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] Collecting statistics

May be stupid question: Would these stats help to build a reputation on the domain?

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "IETF-DKIM" <[email-masked]>
Sent: Friday, 26 March, 2010 10:25:33 AM
Subject: [ietf-dkim] Collecting statistics

I’ve got as a task for the next major OpenDKIM release a reworking of our statistics collection component.  This is something that’s off by default; one must specifically enable it both at compile time and at run time.

What I’m considering is a change to the code so that it collects a larger set of interesting things instead of just pass/fail counts, which canonicalizations are in use, what signing algorithm is in use, whether or not “l=” is in use, and the date/time a domain was last seen.  Some of the data I’m looking at collecting include:

-          On failure, whether or not the “bh” matched (so you can tell whether it was a body change or a header change that broke it)

-          On failure, if “z=” was present, record the name of the header(s) that were changed

-          Use of g=, t= in keys

-          Use of x=, t=, z=, l= in signatures

-          If l= was used, how often extra data was present

-          Count of times t= was used and contained a future timestamp

-          Count of retrieved key records that contained a syntax error

-          Count of signatures referencing nonexistent keys

-          ADSP statistics

-          Count of third-party signatures

-          Count of messages containing multiple signatures

For those of you thinking about statistics regarding DKIM, have I missed any that might be useful to the working group?

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

---

From: Franck Martin <[email-masked]>
Date: Fri, 26 Mar 2010 11:41:37 +1300 (NZDT)

----- Original Message ----- 
From: "Murray S. Kucherawy" <[email-masked]> 
To: "IETF-DKIM" <[email-masked]> 
Sent: Friday, 26 March, 2010 10:25:33 AM 
Subject: [ietf-dkim] Collecting statistics 

- Use of g=, t= in keys 

- ADSP statistics

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 25 Mar 2010 16:54:15 -0700

> May be stupid question: Would these stats help to build a reputation on the domain?

These particular statistics would be far less interesting to a reputation system than the recipients' perspective of the mail they're receiving -- same as with IP reputation.

(Which pushes it even further out of scope, I believe.)

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Mark Martinec <[email-masked]>
Date: Fri, 26 Mar 2010 01:29:10 +0100

> For those of you thinking about statistics regarding DKIM, have I missed any 
> that might be useful to the working group?

Some ideas (some may be a duplicate from your list):

- number of all message signed by this milter
- number of all messages checked for signatures
- number of messages containing any signature (valid or not)
- number of messages containing a valid author domain signature
- number of messages containing a valid third-party signature
- number of messages coming from a mailing list containing
  any signature but not any valid signature
- number of messages NOT coming from a mailing list containing
  any signature but not any valid signature

Distinguishing broken signatures in direct mail vs mailing list
mail provides much better indication of the quality of signatures.
A mailing list recognition may be just a good estimate,
like checking for presence of any of:
  Precedence: list
  List-Id:...
  List-Post:...
  List-Unsubscribe:...
  Mailing-List:...
  From matching /^[^\@]+-(request|bounces|owner)/ or /^owner-[^\@]+/

Mark