ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] 8bit downgrades

2011-05-23 06:57:04

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