I think that what the wording should say is that messages must be valid
RFC2822 (or maybe RFC822) messages. This came up in connection with
what to do with messages with bare CR or LF characters, with the answer
being "don't do that".
This implies DKIM cannot be used with 8bitmime or binarymime.
The "don't do that" was in the context of trying to kludge around MTAs
that will change bare CR to something else such as CR LF. 8bitmime has
the same problem, since I gather that some MTAs that will re-code it to
7bit on the fly if they find they're speaking to another MTA that doesn't
support 8bitmime. DKIM works fine if the transmission path doesn't change
the message much, for an extremely ill-defined definition of "much".
I presume we all agree that we do not want to go down the rathole of
trying to survive all the re-coding tricks that MTAs and gateways do.
Perhaps we should add language to the effect that you can sign whatever
you want, and if your transmission path is sufficiently clean, it'll work.
This also suggests that we should ditch the relaxed body encoding, since
the kinds of munging it tolerates is such a tiny fraction of the things
that actually happen to messages.
Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for
Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html