Re: Another idea of a stat to track

On 13/Sep/10 21:29, Murray S. Kucherawy wrote:
> I'm pondering the way anonymizing is done. At the moment it's
> either done or not done when the stats are recorded, and then those
> records are sent as-is. Perhaps the better way is to record all
> stats in the clear, and then have an anonymizing tool that's used
> to submit the information. That way you could import your own copy
> of the clear data for whatever analysis you want to do, and then
> send us the anonymized data.

Yes, providing useful data is an incentive for using --enable-stats.
In this respect, I have to amend the summaries available using the -a
and -c options.

BTW, why don't we keep the full sender string, e.g. formatted as

   helo-name "(" [reverse-lookup] "[" dotted-decimal-IP "])"

like in Received header fields, instead of the bare dotted decimal
value in fields[3]? Such data may tell at a glance whether an ADSP
failure is a false positive or a true forgery, without requiring
further lookups. It is always easier to discard unneeded parts than
to rebuild or guess them. I'm not sure whether any of these requires
anonymization; in case, the extra strings should be removed before
hashing.

> And I like your idea of a controlled list of exceptions.

Yeah, I think there is no reason for anonymizing data about public
mailing lists, especially this one.

>> Using the h file above may ease further revisions, e.g. adding fields
>> to the stats --this thread's original subject. When it will be
>> included by opendkim-impotstats.c, if ever, then it will be probably
>> convenient that the OpenDKIM project maintains it, and that it gets
>> installed along with other library files. For the time being, a copy
>> of it might live in the contrib directory, perhaps; ditto for its C
>> companion.
>
> I presume this email grants us license to include it as our own then? :-)

Sure! At any rate, I've put an additional permission that is supposed
to reinstate full licenses compatibility, according to
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
Received on Tue Sep 14 2010 - 11:18:15 PST