> >Ah, okay ... yeah, THAT is what's happening. Confirmed: the msg had a utf8 single quote.
> >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). That'd be nice. > 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. Sounds like an itty-bitty job for you, Ken? steve -- _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
