Pete Resnick wrote:
On 5/19/11 12:50 PM, Murray S. Kucherawy wrote:
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in
RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage
is so high when sending 8-bit data that DKIM almost becomes pointless
without the upgrade.
Not advocating for this to be changed in --bis (yet), but someone's
asking me for the history behind that decision.
I can't speak directly to the history of why the WG *thought* they were
putting in the SHOULD, but Michael, Wietse, Scott, and Hector seemed to
have missed the point of why the SHOULD is absolutely appropriate:
In RFC 2119 (the document that defines MUST, SHOULD, etc.), "MUST" does
not mean "vitally important" and "SHOULD" does not mean "really really
important, but less important than MUST". "MUST" means "you have to do
this or you're not going to interoperate." "SHOULD" means, "there are
ways to not do this which will still interoperate, but you had better
know what those ways are and you better be sure to do them, and if you
don't, then you MUST NOT do this." That is, "SHOULD" is equivalent to
"MUST unless you know exactly what you are doing."
In this case, the spec says that you MUST downgrade prior to signing
*unless you know that the end-to-end path is 8-bit clean and will not
downgrade later*. That's what SHOULD downgrade means. If there is an
implementation that doesn't downgrade and sends a message without
knowing that the path is end-to-end 8-bit clean, then it is in violation
of the spec. Changing it to MUST doesn't change anything for such an
implementation; it is already in full violation.
pr
Pete, it isn't that complicated:
MUST is a "throw in your face" requirement - don't follow, expect
things to break and not match up with your peers - shame on you - a bug.
SHOULD is an optional requirement - Its a recommendation for the
better, but things will not break things for your peers if you don't
follow it. You may be shamed but the person shaming you is the one
wrong if they depended on a SHOULD operation as a MUST and his
software broke.
SHOULD is appropriate here IMV because it approves things (for DKIM),
but it can't be enforced for common sense historical reasons.
Primarily, it can't enforce change. Going to 8-bit MIME was an
expensive and complex endeavor and now asking people they should
downgrade and worst, tamper with passthru mail is hard to swallow.
In fact, I may even support a change to a MAY, simple because there is
a natural expectation for non-tampering passthru mail and more and
more systems are using 8 bit communications.
The problem isn't 8bit, the problem is DKIM and this topic is yet
another example of the many WG contradictions. Before we attempt to
force change for the sake of DKIM verification, it might be a good
idea to renew our focus on the serious repercussions for the already
existing relaxations and marginally errors we have accepted for DKIM
verification failures
If we change this downgrade to a MUST, then we must also fix the C14N
problem we forgot about the extra <CRLF> possible at the top the
message possible in IETF streams like IETF-SMTP. Can't have it both
ways: its important here, but not there.
--
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