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... So then there would be also a MUST that *incoming* 8-bit DKIM-signed messages be processed in the obvious way. This would never be used in the present, but allow future protocol designers some leeway. By the way, note that DKIM is not alone in this. S/MIME (RFC 1847) says, on page [4]: # In addition, if the multipart/signed object is EVER to be # transferred over the standard Internet SMTP infrastructure, the # resulting MIME body is constrained to 7 bits -- that is, the use # of material requiring either 8bit or binary # content-transfer-encoding is NOT allowed. Such 8bit or binary # material MUST be encoded using either the quoted-printable or # base64 encodings. ---- Michael Deutschmann <[email protected]> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
