[Top] [All Lists]

[dkim-ops] Test Results for various reflectors

2006-06-08 17:44:22
Sliced-and-diced from the dkim-ops archive...

At Thu Jun 8 16:37:34 PDT 2006, "Dan Mahoney, System Admin" wrote:
By the way -- can you tell WHY? I was signing using ietf-base-01, but am about to switch over to the allman one shortly, it's had SLIGHTLY more success than the others. (This message should be signed with it.) Which method are you using to verify?

The Allman drafts are older and eventually won't be supported. You should be using the IETF drafts. base-02 is current, and we can probably expect a base-03 draft within a month.

These are the files included with [the dkim-milter tarball]:


Which one of them is supposed to represent allman-base-00?

None of them (obviously).  The tarball only contains the current drafts.

I've looked (and looked) and I can't find an easy COMPARISON about what one spec has and the other does not, how they are similar, how one spec can be interepreted to be backwards compatible with another...or even which spec is newer, and whather it supersedes any other and is considered more or less acceptable. (As much as a "draft" standard can be).

There's a section at the end of at least the "base" drafts which itemizes the major changes between each version. However if you're looking for something more "diff"-like, I don't think such a thing has ever existed.

(I agree such a thing would be nice, but it's often fruitless as when a paragraph gets one word changed but re-wraps, the diff is large.)

Mostly we (being the working group) consider the most current version of each draft to be the one we're supporting, while including as much backward compatibility for prior versions as possible as well. Eventually support for earlier versions will be dropped, especially as we progress toward an actual RFC being published.

The milter library claims that "The underlying library will adapt itself to deal with signatures from any version of the specification as much as possible" however I would have to assume this is with the assumption that the library itself KNOWS about all the specs that exist -- obviously some libraries which are in use now can pre-date some specs, which since they all use the same header could cause failure.

The library (libdkim, to be clear) does, because it has been in development since the allman-base-00 version was published as an Internet Draft. As newer versions have come out the code has been revised to support the newer specifications, but as much backward compatibility has been included as possible to allow older formats to continue to be verified. This is why dkim-filter has the option to sign with a format defined by the older draft even though the library supports (and defaults to) the newer formats.

> >* Can anyone post contact addresses for issues with these
> >reflectors? Ideally we need more info, such as: what testing method
> >they're using, contact address, what standards they support.

The deployed implementations are listed at While that's not a list of the autoresponders, it does give some indication of which versions are supported by which implementations. They should be fairly current.

You can post dkim-milter questions to the dkim-milter mailing list. I'm copying this email to you as the one you receive from this list will fail verification.

That wasn't a milter question, but some of the above ARE, and I'll be mentioning that on those mailing lists shortly. DKIM seems like a cool idea, but most of the documentation seems to be SERIOUSLY lacking.

As this has all been experimental and the draft process is not yet completed, it's kind of a moving target so documentation on very specific or uncommon issues can be hard to find. List archives are also a good place to hunt around for answers to the more common problems.

In particular regarding dkim-milter, if you have questions or are finding things aren't verifying, the lists are the right places to go. If there are specific bugs, the SourceForge trackers are there for you to query or update.

dkim-milter has some pretty comprehensive tools for tracking down verification failures. If the various README and INSTALL files in the source tree don't help, feel free to post your questions here (if they're specific to DKIM itself) or to the dkim-milter-discuss(_at_)lists(_dot_)sourceforge(_dot_)net list (if they're specific to the dkim-milter package).
dkim-ops mailing list