DomainKeys library and tools News

A general purpose set of tools, C library and CPAN modules to help DomainKeys developers. The goal is that these tools and library can be easily adopted by all MTAs, LDAs and possibly MUAs. This project is about conforming to the DomainKeys standard,

Here is a maintenance release. Nothing major, just some old patches that were sent in and a fix for a policy bug.

Changed from 0.68 to 0.69:
API:
o Added dk_granularity() to retrieve the value of (g=) tag in DNS lookup (called after dk_end)
o Added DK_STAT_GRANULARITY status enumeration
o Fixed dktest.c to check for DK_STAT_GRANULARITY... read more

This library is a minor change to 0.67 - the main feature is a python wrapper.

The 0.67 library has just been submitted to Sourceforge. This is a bugfix release. Apart from bugfixes, the next release will be DKIM compatible, once that standard settles down a bit. This project provides a general purpose set of tools, C library and CPAN modules to help DomainKeys developers. The goal is that these tools and library can be easily adopted by all MTAs, LDAs and possibly MUAs. This project is about conforming to the DomainKeys standard.... read more

New releases to support the DomainKey-Trace header to assist in diagnosing verification errors.

0.66 libdomainkeys
0.2 CPAN
0.2 commands

Documentation of the trace header syntax can be found here:

http://sourceforge.net/docman/display_doc.php?docid=29004&group_id=107680

Enjoy.

Changes from 0.64 to 0.65:
API:
o No incompatible changes made.
o Added dk_remdupe() to turn on/off ignoring hashing in duplicate headers when signing
o Added -h option to dktest to add h= tag when signing
o Added -r option to dktest to enable ignoring duplicate headers when signing (implies -h)

Internal:
o Win32 and Unixware compatability
o dk_headers() now reports accurate length of h= list and preserves duplicate headers
o Fixed dkheaders_header() to properly handle h= tags when verifying, handles duplicate headers proper
ly
o Fixed simple canon, no longer unfolds headers when in simple canon
o Fixed nofws canon when an embedded \r is in the body of a message
o Fixed dk_from() to properly report the senders domain when the message is not signed
o Fixed dk_policy() to use dk_from(), not value in dk->from
o Fixed handling of messages when verifying and more than one DK-Sig header is found, now uses the fir
st DK-Sig found properly
o Fixed handling of messages when signing and there is an existing DK-Sig (Sender: before DK-Sig), pre
-existing DK-Sig is ignored

I'd like to welcome Anthony to our developers group. Anthony did an excellent job with the first DomainKeys CPAN module and he's agreed to take on the uneviable job of whipping my perl into shape.

As with everyone on this group, his help is much appreciated and I hope everyone will make him feel welcome.

Mark.

Two new file releases have been made to this project. The first is a tentative CPAN module structure, the second is a set of command line tools that can be used to verify/sign the various DK data structures (email, selectors and so on).

This is definitely pre-alpha stuff. It can't hurt to play with it, but the docs are minimalist.

A torture test suite that can be used to check other implementations of DK is available for download. At this stage it just tests canonicalization, but verification and signing is coming RSN.

http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-02.txt is now available. Mostly this is a tidy-up release and a keep-alive release. For implementors, the primary change of interest is the transition from the DomainKeys-Status: header to the Authentication-Results: header.

The current version of qmail, compatible with the current release of libdomainkeys (0.63) is now available at:
http://qmail.org/qmail-1.03-dk-0.53.patch .

A qmail-queue replacement program is now available from http://qmail.org/qmail-1.03-qdk-0.50.patch . It gets executed in place of qmail-queue and signs or verifies messages as directed by the presence of environment variables.

We plan to commence this project within a couple of days of the first release of the corresponding Internet Draft. We expect that to occur early May2004.