Michael Deutschmann wrote:
On Thu, 19 May 2011, Murray S. Kucherawy wrote:
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.
One suggestion for compromise, from another "outsider" (myself):
Specify MUST, but clarify that this is just for now and may be revisited
at a later time -- for example, if the SMTP protcol design community ever
backs down and accepts DJB's approach to the 8-bit message problem
(<http://cr.yp.to/smtp/8bitmime.html>, essentially that it is OK to break
any remaining 7-bit enforcing servers). They probably won't ever, but
just in case...
-1
The only reason for a MUST would be to enforce a change in software
and to move it in into a positive direction. In situations where
this is known to create interoperability problems, you can only do
this MUST if there is a technical fallback mechanism.
Case in point: For SMTP, HELO vs EHLO (extended HELO)
By RFC2119, EHLO should of been written as a SHOULD, but we wanted the
market to move towards Extended SMTP operations and since SMTP was
built with a
"500 COMMAND NOT UNDERSTOOD"
the SMTP state machine was still capable of falling back to a standard
SMTP operation using the HELO command. In other words:
- Client MUST always been with EHLO
- Client MUST always fallback to HELO if EHLO is not supported by
server.
The issue with 8bit downloads is that DKIM does not have that fallback
client/server state machine capability.
So if you make this a MUST, then you MUST have a fallback. If you make
this (keep it as) a SHOULD, then you SHOULD have a fallback.
At the end of the day, you have to look at the realities there exist
non-8BITMIME ready systems, so you won't get the conversions DKIM is
looking for. The better DKIM spec language would of been one related
to "DKIM Input Validation Contracts."
http://www.google.com/search?q=Validation+Contracts
IOW, input requirements would be isolated to DKIM itself:
DKIM signing components SHOULD|MUST have 8bit downgrading. The idea
of whether MSA/MTA perform this conversion is OUT OF SCOPE.
SHOULD is my preference. MUST is selected if that is what we want the
DKIM MARKET to move to, but it MUST always have a fallback.
What will happen Michael if this is may a MUST is that systems will
look for the fallback or skipping:
if mail is 8bit then SKIP signing mail
but it could be done with downlink target/path knowledge:
if mail is 8bit then
if target path does destroy 8bit then convert
sign mail
While that may be a functional description of a fallback, we don't
have the automated technical capability to define it reliably.
--
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