Murray S. Kucherawy wrote:
Such conversion is outside the scope of DKIM; the actual
message SHOULD be converted to 7-bit MIME by an MUA or MSA
prior to presentation to the DKIM
I read that (in the context of the paragraph containing it, of course)
to mean the particular selection of a conversion method is out of scope
for DKIM.
In the context of the entire section, the main requirements are
RFC5322 and RFC5321 readiness and the general requirement to make sure
the DKIM signing output is RFC5322 ready for receivers and that
includes WYSIWYG goals.
But that does not mean the issue of whether or not conversion is
necessary or advisable is also out of scope. If it's okay for us
to discuss things like header field reordering and spacing changes
that might affect validation of DKIM signatures, it certainly seems
to me that this is a valid topic as well.
Sure, thats a boundary layer issue and valid RFC5322 input requirement.
So I don't even know why we are talking about this.
The presented argument, which comes from an IETF outsider involved
with MTA development, is whether or not that SHOULD is worthy of a
MUST because failing to do it in the vast majority of cases will
result in a downgrade somewhere on the path that will invalidate
the signature. The question, then, is why we didn't do MUST in the
first place. It's a perfectly legitimate question.
As with any new software development, you always have the luxury to do
everything that is new but it is naive to believe everyone else is new
too, up-to-par and there don't exist legacy or just plain old
standard requirements operations.
The answer is twofold: One, explain what SHOULD and MUST
really mean, especially in context. Two, list the options
(downgrade and sign, don't downgrade and sign, don't sign) and
the effects of each.
The SHOULD is enough for him to handle his needs for his own MTA/MSA,
DKIM signing and distribution. This issue is no different than all
the general overall concerns regarding losing mail integrity and
increasing realization that DKIM deployment needs to include
target/path knowledge to minimize these
issues.
Providing a solid and helpful answer, rather than a dismissive
or hostile one, promotes understanding from people that weren't
involved, who are the ones that get to implement and deploy
what we've specified. That's certainly my preference.
First, I wasn't dismissive nor hostile and take offense to the on-going
continued labeling me as such. Please stop the hostility towards me.
What I strongly and passionately disagree with is two folds; 1) the
perpetual contradictions with the justifications used for one thing
and not equally applied to others, including the ignorance of DKIM
failures for one thing and not something else; and 2) it is unfair to
be questioning in 2011 all wisdoms gained from all the WG-MAN-YEARS
and the entire 40+ years history known with mail systems behaviors to
come up with that SHOULD in 2005.
You asked for a reason. It was provided by multiple posters, but then
it turned into into something where each poster was labeled of not
understanding RFC2119 to justify a change to a MUST. Talk about being
hostile.
The direction is to be 8 bit compliant in mail, intermediary are
expected not to tamper mail. There is even a greater reason today why
it should remain a SHOULD. If you do this as a MUST, then we lose the
payload binary transparency aspect of communications when we force
MTAs to downgrade 8bit.
How do we know it will break if its not downgraded? Unless there is
full knowledge that a node on the path will do break things, you
don't. This is the same thing with MLMs and the IETF-SMTP extra
<CRLF> issue.
Why don't we care about that? Thats a real live scenario today. How
about this idea for section 5.3? Add this paragraph before the last one:
Mail intermediaries MUST make sure they don't an extra line
after the header and before the beginning of the body content.
See the slippery slope?
What do we expect will happen in the future when the MLMs are more
DKIM aware, and the 8bit streams are not altered to the extent that
DKIM faults are negligible and this MUST is now doing needless
alterations? Are we changing it back to a SHOULD recommendation or
even a MAY?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html