Murray and All,
someone downloaded libopendkim and zdkimfilter from Gentoo, and
noticed a segmentation fault on every received email, with the kernel
logging:
[2329247.997445] zdkimfilter[12231]: segfault at eip 00007f41ffb36411 sp 00007fff9d08ce00 error 4 in libopendkim.so.9.0.1[7f41ffb25000+20000]
The reason of the misbehavior was apparent from a log line saying:
WARN: zfilter: zdkimfilter[27853]:Mismatched library versions: compile=0X2020200 link=0X2080400
Reporting of both log lines can be found here:
http://www.mail-archive.com/courier-users_at_lists.sourceforge.net/msg36681.html
A difference between those two versions is the number of arguments
taken by dkim_policy(), a change done in December 2010. Perhaps the
relevant commit is related to feature-msk-sf3074290: I found this
diff:
extern DKIM_STAT dkim_policy __P((DKIM *dkim, dkim_policy_t *pcode,
- DKIM_PSTATE *pstate));
+ u_int *pflags, DKIM_PSTATE *pstate));
at this url:
http://sourceforge.net/p/opendkim/git/ci/f209b9b7ad1f541fbcd69876b62ad2c3395d7505/tree/libopendkim/dkim.h?diff=46de99c341305036a0af4d60d1c2612007115eec
Now we're looking for the proper place to report that bug...
Ale
On Fri 10/Dec/2010 22:50:44 +0100 Murray S. Kucherawy wrote:
> 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 Thu Jul 25 2013 - 09:05:51 PST