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]:
draft-allman-dkim-ssp-01.txt
draft-ietf-dkim-base-01.txt
draft-ietf-dkim-threats-02.txt
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
http://mipassoc.org/dkim/deploy/index.htm. 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
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops