Alexey Shumkin <alex.crez...@gmail.com> writes: > This function is used to determine "broken" (non-ASCII) headers (to be encode > them) > The problem is if "Subject" is not broken, but message body contains > non-ASCII chars, > subject is marked as broken and encoded again.
I think that is not a "problem" but is a mere symptom. The remainder of the codeflow of send-email, AFAICS (it's not my code), is not prepared to deal with multipart messages at all. In order to handle multi-part properly, you may still have to fix broken Subject: of the whole thing, and you may also want to fix broken headers inside one part while keeping correctly formatted part intact. Your patch just stops an early error checking that is meant for a non multi-part message that happens to trigger on a multi-part message in your test case from triggering (i.e. masking a symptom) and let the remaining lines of the multi-part message to codepath that does not do anything special to handle multi-part messages correctly, letting it do whatever it happens to do to a message assuming it is not a multi-part message, no? In other words, making send-email capable of handling a multi-part might be a worthy thing to do, but I do not think your patch is a good first step for doing so. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
