Folks,
G'day.
One requirement for moving a specification from Proposed to Draft status is to
supply an Implementation Report:
<http://www.ietf.org/IESG/implementation.html>
<http://tools.ietf.org/html/draft-dusseault-impl-reports-04>
I've put together survey forms -- one for signers and one for verifiers -- that
should supply us with some raw field data, to make it possible to assemble a
detailed report.
* If you run a DKIM signing and/or verifying operation, please complete the
appropriate survey questionnaire and return it to me.
* If you know of others operate DKIM signing and/or verifying services --
such as your customers -- please forward this to them and request that
they complete a version, returning it to me.
Because the report seeks information about interoperability, it does not ask
about the capabilities of software, but rather looks for actual usage. It is
information about /interaction/ between software that is important, not merely
what code exists. This is why real field data is sought, rather than a report
from developers.
I'm hoping we can get a useful set of responses by the time of the IETF meeting,
so that we can start considering the feedback.
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Report: RFC4871 - DKIM Signatures
Implementation Report Form -- SIGNING
Please obtain responses directly from
operators of DKIM installations
Report Date:
Report Author Name:
Report Organization:
Report Author Email:
Purpose:
This solicits detailed information about your organization's direct
use of an individual implementation of DKIM signing and its
interoperability with other implementations doing DKIM validating. The
purpose of the questionnaire is to asertain what features of DKIM are
being used.
Besides a basic history of success and failure with signature
validation, it requests details concerning the use of individual DKIM
tags in DNS records and in the DKIM-Signature: header field. In
addition to the question of whether tags are set with a value please
indicate whether they are set with different values for different uses
or whether a single, constant value is used.
Some information is best obtained directly from the software or its
manuals. Other information is obtained from local policies or service
logs.
Implementation name:
Implementation author or source:
Implementation contact address:
Implementation operational first fielded on (date):
Interoperability summary:
(Please provide a basic statement about use of the implementation in
fielded operations, concerning successes and failures and how DKIM is
used. This summary will satisfy the basic question of whether the core
function of signature validation is interoperable.)
DNS TXT record tags -- ranges set, if at all:
(For each tag, please explain whether your use of the implementation
chooses particular values for the tag and, if so, with what range of
values and according to what rules.)
(The tags v=, p=, n= need not be reported.)
g -- Granularity of the key:
h -- Acceptable hash algorithms:
k -- Key type:
s -- Service type:
t=y -- Domain is testing DKIM:
t=s: Require that domain in i= and d= are the same:
DKIM-Signature header field tags -- ranges set, if at all:
(For each tag, please explain whether your use of the implementation
chooses particular values for the tag and, if so, with what range of
values and according to what rules.)
(The tags b=, bh=, d=, s=, v= need not be reported.)
a -- The algorithm used to generate the signature:
c -- Message canonicalization:
h -- List of header fields that are signed:
t -- Signature timestamp:
q -- List of query methods (maybe - see notes):
i -- Additional information about the identity of the user or agent
for which this message was signed:
x -- Signature expiration:
l -- Body length count:
z -- Copied header fields:
Report: RFC4871 - DKIM Signatures
Implementation Report Form -- VERIFYING
Please obtain responses directly from
operators of DKIM installations
Report Date:
Report Author Name:
Report Organization:
Report Author Email:
Purpose:
This solicits detailed information about your organization's direct
use of an individual implementation of DKIM verifying and its
interoperability with other implementations doing DKIM signing. The
purpose of the questionnaire is to asertain what features of DKIM are
being used.
Besides a basic history of success and failure with signature
validation, it requests details concerning the use of individual DKIM
tags in DNS records and in the DKIM-Signature: header field. In
addition to the question of whether tags are set with a value please
indicate whether they are set with different values for different uses
or whether a single, constant value is used.
The core question for verifiers is whether they are seeing different
tag values and whether these are handled differentially by the verify or
by a module taking output from the verifier.
Some information is best obtained directly from the software or its
manuals. Other information is obtained from local policies or service
logs.
Implementation name:
Implementation author or source:
Implementation contact address:
Implementation operational first fielded on (date):
Interoperability summary:
(Please provide a basic statement about use of the implementation in
fielded operations, concerning successes and failures and how DKIM is
used. This summary will satisfy the basic question of whether the core
function of signature validation is interoperable.)
DNS TXT record tags -- ranges seen, if at all:
(For each tag, please explain whether the implementation sees
occurrences of the tag and, if so, with what range of values and how
these are handled by the verifying implementation.)
(The tags v=, p=, n= need not be reported.)
g -- Granularity of the key:
h -- Acceptable hash algorithms:
k -- Key type:
s -- Service type:
t=y -- Domain is testing DKIM:
t=s -- Require that domain in i= and d= are the same:
DKIM-Signature header field tags -- ranges seen, if at all:
(For each tag, please explain whether the implementation sees
occurrences of the tag and, if so, with what range of values and how
these are handled by the verifying implementation.)
(The tags b=, bh=, d=, s=, v= need not be reported.)
a -- The algorithm used to generate the signature:
c -- Message canonicalization:
h -- List of header fields that are signed:
t -- Signature timestamp:
q -- List of query methods (maybe - see notes):
i -- Additional information about the identity of the user or agent
for which this message was signed:
x -- Signature expiration:
l -- Body length count:
z -- Copied header fields:
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html