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