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
