Mark Delany wrote:
Um, there's user experience, which last I heard sort of trumps everything.
Can you say for absolute certain that the user experience of converting
compliant 822 messages into compliant 2822 messages won't cause trouble?
I sure can't. That at the very least ought to evoke some humility.
Sure. But a bucketload of such content is HTML now - of that I can
attest - all of which is entirely oblivious to stray whitespace.
The cases that I'm talking about most assuredly are not HTML. Again, it's
the user experience I worry about. If all of the sudden that changes for the
worse because you decided to turn on DKIM signing in your existing
deployment, who is going to get the blame? Who is going to have the onus
to deal with making the user experience right again? It's easy to say
that the
applications shouldn't be sending non-2822 compliant mail, but I can say for
certain that in our environment that I haven't even a clue what those
applications are, let alone who owns them, let alone the ability to change
them. That's sort of an untenable position we're putting people in from a
deployment standpoint.
And since the subject is "does DKIM support 822 or only 2822", I'd say
at this
point we'd have to say "only 2822".
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html