I encourage users of dkim-milter to reply to Dave directly at 
[email protected].  This is useful data when deciding what the next steps are 
for DKIM in the IETF standards process.  Specifically, if you are using 
particular features of the DKIM specification, that's an argument for keeping 
them; if there are some you're not using, they're candidates for being dropped 
when and if the spec gets revised.  The idea is that features nobody's using 
can be removed, simplifying the specification and thus making it harder for new 
implementations to get it wrong.  If they become useful features later, they 
can always be re-added by publishing a revision or a new spec that describes an 
extension.

dkim-milter implements the entire DKIM specification as well as adding a few 
useful features of its own.  You have to be somewhat familiar with the 
specification itself to complete this survey (and thus know the difference 
between the add-ons and the core stuff), but I suspect a decent percentage of 
this list's readership fits that description.  To those of you that do, your 
feedback would be valuable here.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On 
Behalf Of Dave CROCKER
Sent: Sunday, July 12, 2009 10:50 AM
To: DKIM IETF WG
Subject: [ietf-dkim] DKIM field usage survey

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
------------------------------------------------------------------------------
_______________________________________________
dkim-milter-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss

Reply via email to