Scott Kitterman wrote:
So I have tended to view the dual-reference approach as a means of
communicating to folks that they do not have to worry about old-vs-new
specifications for message syntax/semantics.
d/
OK. I may have mis-remembered, but I thought that one aspect of the naked CR
discussion (which a spun this thread off of) was that a naked CR is allowed
by 822, but not 2822. So I think there is something that cares.
Also, I think what you are saying is different than what Barry is saying. To
paraphrase:
Barry - Design requirement is to support 2822, but we will try to deal with
what is out there are much as we reasonably can (including 822).
Dave - Design requirement is to support 2822 and there aren't any 822/2822
differences that matter, so by supporting 2822, we also support 822.
I think we need to have clarity on this point and it doesn't seem to me that
we have it at this time.
Indeed.
First, I apologize. I was being entirely too cavalier in considering this
issue. Second, I've gone back over the bare-CR discussion and I now think there
is indeed a difference between 822 and 2822 that is quite important for DKIM,
and that we need to deal with it explicitly.
Here's what I take from the discussion:
1) RFC 2822 generates text that is less subject to in-transit distortion than
RFC 822, by virtue of it's greater strictness about CR and LF.
2) There is no way to create a canonicalization algorithm that is completely
robust against in-transit distortions, and defining one that attempts to be
highly robust is likely to have the dual problems of excessive complexity and
inadequate robustness. Complexity leads to errors and lack of robustness means
that the goal being used to justify the complexity is not attained. Hence,
simpler algorithms are strongly preferred.
3) Adopting DKIM takes software modification, so we might as well include the
requirement that the message that is being signed be in a form that is less
subject to distortion. To the extent that the message needs to be transformed,
that is the job of the 'local' system, prior to signing.
In sum:
We should require that DKIM signers only sign messages that are RFC 2822
conformant. (We will need a small amount of text that explains why.)
Comments?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html