Steven wrote: > So do I, which suggests that there's something in the content of the > specific message I'm working with.
As Robert and Ken pointed out, one explanation could be that the content is converted twice, the second time incorrectly. I don't see at this point how mhfixmsg could do that but this needs more investigation. We can continue this way, or if you want to send me a sanitized excerpt of the message, I'd be glad to work with it. > $ mhfixmsg -decodetext 8bit -decodetypes text -textcharset UTF-8 -reformat \ > -fixcte -fixboundary -noreplacetextplain \ > -fixtype application/octet-stream -verbose -file - \ > -outfile $destination < $source > mhfixmsg: /home/smw/Mail/mhfixmsgnss3pI part 2, decode text/plain; > charset=iso-8859-1 > mhfixmsg: /home/smw/Mail/mhfixmsgnss3pI part 1, decode text/html; > charset=iso-8859-1 > mhfixmsg: /home/smw/Mail/mhfixmsgnss3pI part 2, convert UTF-8 to UTF-8 > > ...which is interesting for more than one reason, including that there's > apparently no conversion of iso-8859-1 to UTF-8, That's strange, unless $source had already been run through mhfixmsg. Conversion to the same charset is a no-op, I'll look into removing the verbose output in that case. > and that in fact it's > part 1 rather than part 2 that gets converted improperly The part numbers are reversed because that's the order used for display. Part 2 is the text/plain part, that's the one that got converted. > ; part 2 still has > > Content-Type: text/html; charset=iso-8859-1 Right, mhfixmsg didn't touch it. The text parts are in a multipart/alternative and that text/html part has a corresponding text/plain part. Even if it didn't, mhfixmsg wouldn't convert the text/html part. It would insert a new text/plain part. David
