[ietf-dkim] Introducing myself
johnl at iecc.com
Fri Nov 3 18:03:38 PST 2006
>>> writing headers in UTF-8. ...
>> No, because we want DKIM to work with 7-bit-clean mail. We want broad,
>> fast deployment and that means working with old systems.
>Sure, but that is no reason for making it _not_ work with new systems.
It's still an open question how Unicode is going to show up in mail
headers, with 8 bit UTF8 being only one of multiple possibilities.
More likely there will be some kludge to smoosh it into 7 bits so it
can transit through old MTAs. I don't think anyone is opposed to DKIM
handling whatever happens, but I also don't think it's productive to
try to guess at this point which way it'll turn out.
>>>> l= Body length count
>So I see, and a very sternly worded remark ("NOTE WELL: ...") it is. So
>why do you want to even suggest that is would be legitimate for verifiers
>(or their policy modules) to chop it out?
This has been very contentious. Personally, I will never put an l=
into a signature, but there are some vocal people who insist that it's
important for signtures to survive (some) mailing list software, so
it's there if they want it.
>See my reply to Eliot for this, and the similar wordings for hash and
>encryption algorithms. I think you have misunderstood the point of my
>concern. If it had said that signers SHOULD use dns/ext, ... rsa, ...
>sha-256, etc, (at least when the application is DKIM) then that would
>have been OK.
The MUST is quite deliberate so that DKIM implementations will
interoperate. You're welcome to do whatever you want to exchange
messages with your friends, but for mail to everyone else, you have
to use SHA-256 and dns/ext because that's what you know they'll be
able to handle.
>You say "signers SHOULD convert the message to a suitable MIME
>content transfer encoding such as quoted-printable or base64". That
>sounds to me like a pretty strong discouragement to continue using
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".
You can sign whatever you want, but if the message is 7bit, your
signature is more likely to survive transit to the verifier.
>And it is not as if this was a difficult problem to solve. All you have to
>do is to decode any Q-P or Base64 encountered during the canonicalization
DKIM doesn't understand MIME. If DKIM signers and verifiers had to
unpack MIME parts they would be orders of magnitude more complicated.
In practice, I think that nearly everyone uses the simple body canon
More information about the ietf-dkim