Alexey Shumkin <> 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
More majordomo info at

Reply via email to