The existing code takes a non-ASCII message body and sends it as an
of type application/octet-stream.
Your patch changes this behavior so that it is sent as type text/plain with
appropriately chosen character set.
You know .... I'm all for backwards compatibility and everything, but
I'm wondering ... did the previous behavior actually make sense? Can
people argue that it was desirable or correct? Or was the previous
behavior actually wrong, and this is really fixing a long-standing
bug? Because if we decide that the previous behavior is a bug, then
I don't think an explicit enable option for this chance makes sense; I'd
prefer that the new behavior be the default.
(I am personally on the fence regarding whether or not the previous
behavior is a bug).
Don't disagree with you. The current behavior was the best idea that I had
at the time and nobody has said anything about it until recently. I don't
mind it changing, but I don't want to all of a sudden get complaints from
people who were counting on this behavior. Maybe that number is 0, but I
have no way of knowing. I don't care that much, so if you think compability
isn't an issue here that's fine with me.
If the defalt behavior was to change I would add a "binary" flag to
make_mime_composition_file_entry() so that the body didn't have to be
scanned for non-ASCII characters twice.
Nmh-workers mailing list