AFAIK the only reason upconversion would ever break content-md5
my guess is that it breaks content-md5 for the case where
bare CR or bare LF appears in the canonical form, and this
same character is coincidentally the line ending for the stored
form of the message at some point following upconversion.
This is specific case one of the possibilities I described: Upconversion to a
CTE that cannot properly represent the content. 7bit or 8bit CTEs cannot
represent such content, so upconverting such content to them breaks things.
Note that it isn't enough to have knowledge of the content type, you also have
to have knowledge of the actual content you are dealing with. (Although the
content type often tells you whether or not it is worth bothering with
upconversion.) For example, if you're upconverting text/plain you need to know
the maximum line length used by the content and what characters are present in
order to know whether a 7bit, 8bit, or binary CTE is appropriate.
basically, converting a body part that is end-to-end transparent
for all octet values to one which is not end-to-end transparent
for all octet values can cause MD5 to fail. no surprise there.
True, but the question is also what steps need to be taken to insure success.
Ned