We're mostly talking past each other. DKIM is intended to be 8 bit
clean, and you can sign whatever you want. If you sign 8 bit data and
the path your message takes is transparent to 8 bit data, great, you
win, if not, you lose. In what I expect is the common case that you
don't know what MTAs are going to handle your message, downcoding
everything to 7bit is a lot more robust. Perhaps you could suggest
wording to make that clearer.
l= Body length count
But the people who want it won't take kindly to having it deleted by
overly "helpful" verifier policy modules. Currently the draft suggests
that is a reasonable practice. It isn't, and the draft should not be
saying such things. By all means warn the user, and even provide the user
with tools to delete it. But don't chop bits out of his mail without his
approval.
I don't see any place in the draft where it says anything about who's
approving or not approving of any particular operations. If I were
one of the band of optimists who thinks that "l=" will be useful, I
expect I would heartily approve of my MTA chopping off the unsigned
bits in my incoming mail.
[ re sha1 vs sha256 ]
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.
But that is not what the draft says.
Our intent is that signers have to sign with sha256 and, for backward
compatibility, can also add a sha1 signature. Verifiers have to
handle either. If the wording doesn't say that, we need to fix it.
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
anyway.
Not at all. Going through the MIME structure of a message body and undoing
all Q-P or Bas64 encodings is fairly straightforward,
The people who have written DKIM signers and verifiers can comment on
how much complication would be involved if they had to add MIME
packers and unpackers to them.
And, moreover, I do not see why the 'simple' canonicalization is the
default (or even why it even exists at all, for both headers and bodies).
Can anybody suggest a scam or threat that would be facilitated if
"relaxed" rather than "simple" was used?
May I direct your attention to the lengthy discussions of these topics
in the list archives?
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html