Do the DomainKeys hook do DomainKeys signing?
I really want to simplify my configuration. I run five sendmail milters plus opendkim milter for the domains that I host. I would be great to consolidate to one milter that handles all signing decisions and signing.
Thanks,
/Chris Callegari
On Jun 7, 2011, at 1:28 AM, Steve Jenkins <stevejenkins_at_gmail.com> wrote:
> On Mon, Jun 6, 2011 at 9:34 AM, Murray S. Kucherawy <msk_at_opendkim.org> wrote:
>> The OpenDKIM project announces availability of OpenDKIM v2.4.0, now available
>> for download from SourceForge.
>>
>> This is primarily a new feature release, along with a few bug fixes.
>> Upgrading is not mandatory unless, of course, you want access to one of
>> the features described below. For most users it should be a direct binary
>> replacement.
>>
>> There is one backward compatibility issue, referring to the "BodyLengths"
>> setting which has been removed. Instead, see the documentation for
>> "BodyLengthDB".
>>
>> IMPORTANT NOTE: The 2.4.x line of OpenDKIM releases will be the last series
>> that contains support hooks for DomainKeys. As of 2.5.0 (late this year or
>> early next), that support will be discontinued.
>>
>> The full RELEASE_NOTES for this version:
>>
>> 2.4.0 2011/06/06
>> Feature request #SF3060140: Extension of odkim.sign() to include
>> maximum signed byte count.
>> Feature request #SF3171865: Add _FFR_LUA_GLOBALS, enabling a
>> mechanism to maintain state between Lua scripts.
>> Feature request #SF3241982: Optionally add an Authentication-Results
>> field for all signatures present, not just the first good
>> one.
>> Feature request #SF3256630: Add _FFR_RATE_LIMIT, enabling hooks for
>> post-verification rate controls.
>> Feature request #SF3290461: Add optional support for querying a
>> memcache daemon via libmemcached.
>> Feature request #SF3299041: Be tougher on use of the "l=" tag by
>> removing "BodyLengths", renaming "BodyLengthDBFile" to
>> "BodyLengthDB", and allowing pattern matches. This
>> effectively activates _FFR_BODYLENGTH_DB as well.
>> Feature request #SF3303911: Add "DisableADSP" setting.
>> In the stats recording code, only check for a domain match for
>> signatures that don't have errors (i.e., short circuit if
>> sigerror is not zero).
>> LIBOPENDKIM: Feature request #SF2969516: Teach dkim_chunk() about
>> DKIM_LIBFLAGS_FIXCRLF.
>> LIBOPENDKIM: Feature request #SF3123731: Extend FixCRLF to cover
>> header fields.
>> LIBOPENDKIM: Feature request #SF3151534: Extract DKIM reputation
>> support to its own library.
>> LIBOPENDKIM: Feature request #SF3279589: Add _FFR_XTAGS, adding
>> support for generic extension tags in signatures.
>> LIBOPENDKIM: Feature request #SF3300738: Add dkim_sig_getqueries()
>> and dkim_policy_getqueries() to assist API consumers that
>> have their own DNS mechanisms not directly adaptable to ours.
>> Requested by Heikki Gruner.
>> LIBOPENDKIM: Return an error from dkim_getsighdr() or
>> dkim_getsighdr_d() if called after a key load failure.
>> Problem noted by Heikki Gruner.
>> LIBAR: Check that the descriptor's write socket is writable before
>> calling ar_sendquery() when trying to identify open requests
>> that need retransmission.
>> STATS: Feature request #SF3066106: Add "opendkim-anonstats" tool.
>> CONTRIB: Paths in init/redhat/opendkim are now auto-generated.
>> Activate _FFR_MAXVERIFY.
>>
>> Please use the mailing lists at http://lists.opendkim.org/ to report problems.
>> Bug reports and feature requests can be made through the project trackers,
>> which can be found via http://www.opendkim.org.
>>
>> The OpenDKIM Project
>
> Nice job, Murray! Congrats on another release of what is
> unquestionably THE best DKIM signing and verifying tool on the plant.
> :)
>
> I've tested the new version on CentOS 5.6 and Fedora 12, 13, 14, and
> I've updated my blog with the new version's download links and
> included the updated flags in the ./configure command:
>
> http://stevejenkins.com/blog/2010/09/how-to-get-dkim-domainkeys-identified-mail-working-on-centos-5-5-and-postfix-using-opendkim/
>
> Keep up the great work!
>
> SteveJ
>
>
Received on Tue Jun 07 2011 - 10:46:57 PST