>Ah, okay ... yeah, THAT is what's happening. But that seems wrong to me; >what should happen is what happens to other text when processed by mhbuild >(namely, it's encoded with q-p and marked with the right character set).
Alright, I took a look at that code. Right now what happens is the attachment code splits up the message and uses the suffixes to determine what the content type will be ... and the body filename is determined by m_mktemp(). If there's no matching suffix the data will be read, and if it's all ASCII it will be assumed to be text/plain and if NOT, then it's application/octet-stream. So clearly Steve's issue was that his message body contained at least one non-ASCII character. Seems to me the right solution is to make it so you can pass in a content type to make_mime_composition_file_entry() that overrides the algorithm that chooses the MIME type, and make it so the body text is always set to text/plain; in that case, mhbuild will make sure the right thing happens. That will make sure that things work right for our international users as well. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
