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 <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html