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