Hi Daniel,
On 01/Aug/10 09:08, Daniel Black wrote:
> As a token of my excitement of another product using libopendkim I've added it
> to the gentoo distribution. Thankyou for enabling courier users to participate
> in the brave new dkim world. Personally I'm stretched getting a handle on
> milter applications so I'm glad you've found and make OpenDKIM useful for the
> courier users.
> http://packages.gentoo.org/package/mail-filter/zdkimfilter
Thank you for the link!
> I've noticed your build goes to a lot of effort regarding libopendkim library
> detection. I suspect part of the complexity is the large amount of changes
> since libopendkim-1.2.2. Sorry about that - I'm hope its getting better. For a
> while we've provided a pkg-config file that you've partually used. I susect a
> macro like the following may assist you to gain the required libraries
> quicker.
> PKG_CHECK_MODULES([OPENDKIM], [opendkim>= 1.2.2], [ ..... ] , [ ....])
Thanks, I'll try that on the next occasion. IIRC, two issues I had in
detecting the library are as follows:
* zdkimfilter code is not multithreaded, so I don't want to have
flags that require useless threading code, and
* if libopendkim is built as a static library, I have to check
further libraries separately.
> We'd like the libopendkim to be as usuable as possible so please let us know
> if anything is packaged wrong or there are features/changes you'd like.
The multithreaded flag was (is?) probably unnecessary. I plan to
upgrade to 2.2.0 (as it'll contain a function that will allow writing
header.from --see
http://sourceforge.net/tracker/?func=detail&aid=3026287&group_id=269812&atid=1147704)
> Some quick suggestions/questions about your own product while i've been
> looking:
>
> http://www.tana.it/sw/zdkimfilter/#install
> Is the static recommendation really only related to opendkim-1*?
In part. I haven't yet coded a runtime check that library and include
versions match :-/ OTOH, for most of the time zdkimfilter is the only
linked executable, so the benefits of sharing it seem very small. See
e.g.
http://www.mail-archive.com/linux-kernel_at_vger.kernel.org/msg127835.html
> I recommend you do some form of check to see if opendkim reputation is built
> in as part of your configure.ac.
Noted. I thought I could go away with the stub function.
> http://www.tana.it/sw/zdkimfilter/#keys
> * Next release is going to rename opendkim-genkey.sh to opendkim-genkey.
> * The instructions related to keys are going to be in opendkim/README as of
> next release (too much was in INSTALL)
You mean next=2.2.0?
> Murray's starting a statistics gathering excercise for the IETF. Wondering if
> you could code in some statistics gathering that's compatible:
> http://lists.opendkim.org/archive/opendkim/users/2010/07/0410.html and the
> stats directory of the opendkim.
Zdkimfilter currently uses no DB library, and I still have to work out
what to do here. Courier is designed to use either bdb or gdbm, which
it can afford as it doesn't need concurrent write access; however, if
I'll design to use bdb only, I'd probably exclude gdbm users.
Thanks again for your interest in zdkimfilter.
Received on Sun Aug 01 2010 - 13:26:21 PST