ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

2011-04-07 18:10:09
Murray S. Kucherawy wrote:

3) Should we better get DKIM to sign a 5322 header because a) any DKIM
implementation can do it b) for senders it is easy to add a header when
the email is created and then sign it on the way out, than to figure
what type of email it is on the way out during signing. c) for
receivers a signed header is easy to process likewise.

To summarize my current feelings on that question: 
Data about a message belongs in a header field; data about 
a signer belongs in the signature.

Yet a message header hash bound to a signer signature is a natural 
DKIM design concept for message::signer associations binding the two 
"layers" I believe your feelings attempts to delegate or imply exist 
as separate needs.

The main point is that the current spec functional design requirements 
breeds implementation models expected to allow for extra headers 
signature bindings regardless of its content and context.   AFAIK, the 
specs do not have any similar semantics about extra signature tags 
which may explain why at least two APIs did not implement this 
functionality.

Developer to Developer, looking at how to extend the ALT-N LibDKIM API 
to support adding tags to the DKIM-Signature, off hand, its not as 
easy as it may sound.   There would be three models for this:

   1) A simple optional flat list of predefined tags=values that would
      easily added to the DKIM-Signature prior to the hash computation.

   2) A flat list with tag=value items where value is extracted from
      other part using perhaps a macro expansion concept:

      st={54322.FROM}

   3) DKIM Signer Extension Plug-in Model which calls some vendor
      specific embedded code concept, ACL, MILTER, WCX or some other
      scripted method called from the DKIM SIGNER component.

The easier implementation is #1 and maybe with limited #2 would work.

So to answer to this question, yes, it is better to use headers if 
only because it would be the only way to currently maximize the 
probability of support without a need for software change.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>