[ietf-dkim] Proposal for new text about multiple header issues
vesely at tana.it
Sat Oct 30 03:39:51 PDT 2010
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
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?
More information about the ietf-dkim