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
