On 19 May 2011, at 22:53, Pete Resnick wrote:
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.
Downgrading is undesirable, especially given the increasing popularity of
mobile clients.
In theory, the signature could be added at SMTP time, with downgrading
occurring dependent upon whether 8bitmime is advertised by the recipient's MTA.
Of course, there's a risk that the message will then require downgrading when
forwarded by the recipient's MTA, but that risk should decrease with time (for
example, Exim's developers have 8bitmime development as a priority now). And,
it's also an option for the recipient's MTA to add a new signature (whatever
that's worth).
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html