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

[Ken Hornstein]

>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