Numerous branches requiring review

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Fri, 10 Dec 2010 13:50:44 -0800

I've tackled a number of the open bug and feature requests for 2.3.0 and I'd like to start soliciting people to review and/or experiment with the various branches in order to start merging them back to "develop". There's no big hurry for this yet as it's still more than a month before I want to start a beta cycle, but there's enough there to start the work now.

The branches of interest:


- "develop" - various minor features and fixes since v2.2.2 (see RELEASE_NOTES)

- "feature-msk-sf3060152" - adds an odkim.replace_header() function in the final Lua script

- "feature-msk-sf3066104" - allows someone using the stats features to anonymize only certain domains (or all except certain domains)

- "feature-msk-sf3074290" - experimental support for Authorized Third-Party Signers

- "feature-msk-sf3081697" - option to specify that certain header fields should be "over-signed", i.e. added to the "h=" tag an extra time so that extra instances can't be added later (slightly different than "AlwaysSignHeaders" which we already have)

- "feature-msk-sf3087029" - a library flag that refuses to accept any message that doesn't conform to RFC5322 Section 3.6, which specifies minima and maxima for various known header fields

- "feature-msk-sf3096630" - add a generic RBL query facility to Lua

- "feature-msk-sf3105477" - VBR resolver improvements and a feature to force all trusted certifiers to be queried rather than the default "intersection" behavior

- "feature-msk-sf3106876" - add DNSSEC results to the output of opendkim-testkey

- "feature-msk-sf3109963" - allow constraints on the number of signatures to be evaluated to prevent DoS attacks

- "feature-msk-sf3125701" - add stats support for tracking "s=" values in key records

I still plan to tackle at least one more (3115073, detailed libar logging) before I take a break from coding up new stuff for 2.3.0. You're also invited to peruse the list of remaining unassigned feature requests and pick up one or more of your own, or vote on which one(s) should get higher or lower priorities assigned for future selection.

Thanks,
-MSK
Received on Fri Dec 10 2010 - 21:50:58 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:32:55 PST