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