ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-10-30 05:42:30
On 25/Oct/10 06:54, Steve Atkins wrote:
On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote:
3) For any header field listed in Section 3.6 of [MAIL] as having
an upper bound on the number of times it can appear, include the
name of that field one extra time in the “h=” portion of the
signature to prevent addition of fraudulent instances.  Any
attachment of such fields after signing would thus invalidate the
signature (see Section 3.5 and 5.4 for further discussion).

This works, and is definitely on the right track as it's looking at
the specific problem rather than broad 5322 compliance, but feels
like a hack workaround by the signer for a problem that's simpler
for the receiver to deal with directly.

Implementations, e.g. OpenDKIM, may be configured with a list of 
fields-to-sign, rather than the exact content of the h= tag.  Thus, 
such a signer can double the occurrence of singleton fields as part of 
DKIM-Signature creation. Or it can slightly improve its configuration 
grammar in order to let the user specify when fields are to be bounded 
by adding an extra instance of their name in the h= tag.  We can 
sprinkle any amount of syntactic sugar on that...

I think that, although it may seem simpler to deal with the problem at 
the receiver's, we've seen it actually is not simpler at all.

It is something we can encourage that's strictly within the bounds
of a DKIM spec, but that doesn't make it the ideal solution to the
problem.

Why it's not ideal?

Even having to specify "From" may be felt as a nuisance, since it's 
mandatory already.  Kay Engert's serendipitous reinvention of DKIM, 
http://kuix.de/spamsalt/, provides for a fixed set of signed header 
fields: does that make spamsalt less hacky than DKIM?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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