Dave Crocker wrote:
John Levine wrote:
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.)
I'd be inclined to say that messages to be signed SHOULD conform to
2822. There are some 822 MTAs that produce nice clean messages that
pass through relays with little trouble, such as the one I'm using.
Fair point. Offhand I cannot think of a downside, by using SHOULD rather than
MUST.
The SHOULD asserts the importance quite clearly, and it is not as if doing 822
rather than 2822 can cause damage anywhere but to the verification of the
particular message.
I still have lingering worries about this naked CR problem. Since a lot of
it is due to windows file system thing considerations, you get a lot of
sequences
like:
line^M^M^J
which will get transformed into:
line^M^J
^M^J
Will that transformation cause things to break? One thing for certain:
consumers
of these messages are all of the sudden going to be seeing double spaced
lines;
maybe just an annoyance, maybe worse. Who knows? Likewise if you instead
deleted naked CR's. Will it cause problems? Who knows?
The thing is that this was perfectly legitimate 822 even if it wasn't
entirely
anticiapated back then. And there's a lot of legacy out there that stopped
evolving in the 90's or maybe even earlier. Taking too cavalier an attitude
that 2822 is the answer seems to run into the same problems that Ned wrote
about: the email world is a wacky place, and we shouldn't be surprised
about being surprised. So not being accommodating of the pre-2822 world
seems like it has a pretty large risk of getting it wrong regardless of
whether
we're "right". That bothers me.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
