Re: [Nmh-workers] cruddy X-MH-Attach behavior

[rader]

 > >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
--