Murray S. Kucherawy wrote: > +1, and I would go even further to say that we should have an errata item > against RFC4871 which says we should add that DKIM presumes a properly-formed > RFC2822-style message, and that its application to other messages produces > undefined results.
Let's think about this for a moment. While it's unlikely that such an erratum would do any damage, I'm bothered by the implication that the DKIM spec is somehow deficient in this regard. Certainly the spec does not have an explicit and simple statement that it operates on RFC 2822-compliant messages. Certainly a number of wrinkles in the spec would have been smoothed out by its containing a more explicit input/output section. But the idea that anyone would think that a signing mechanism designed to operate on RFC 2822 messages would somehow be expected to operate successfully on non-conformant messages really bothers me. In particular, the idea that any changes to the spec, about this, would count as an erratum seem, ummm, erroneous. Besides that, I think that one could argue that, at the least: > 5.3 Normalize the Message to Prevent Transport Conversions ... > If the message is submitted to the signer with any local encoding that will > be modified before transmission, that modification to canonical [RFC2822] > form MUST be done before signing. In Carries the rather strong implication that DKIM only works on compliant messages. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
