"mhfixmsg rewrites MIME messages, applying specific transformations such as
decoding of MIME-encoded message parts and repairing invalid MIME headers" It
would be interesting to hear some background on why these repairs are needed.
msg 3677 is from yahoo email. I assume some email clients are worse than
others / which ones?
I'm not running mhfixmsg on each message, so I have to remember this workaround.
>mhstore is not decoding the filename:
> $ mhstore -auto -part 2 storing message 3677 part 2 as file
Unfortunately, RFC 2047 encoding is explicitly forbidden to be used for
MIME parameter values. There is a different standard for encoding MIME
parameter values (RFC 2231) that nmh supports. But it seems that a lot
of MUAs still get this wrong. I'd rather leave it that mhfixmsg will
correct this instead of natively decoding it.
> It would be interesting to hear some background on why these repairs are needed.
Ken already mentioned the RFCs, but let me point out:
mhfixmsg applies two transformations unconditionally. The
first removes an extraneous trailing semicolon from the
parameter lists of MIME header field values. The second
replaces RFC 2047 encoding with RFC 2231 encoding of name and
filename parameters in Content-Type and Content-Disposition
header field values, respectively.
> msg 3677 is from yahoo email. I assume some email clients are worse than
> others / which ones?
I usually don't identify specific email clients: the fixes apply to a message from any client.
Ralph, I'll fix the extra newlines, thanks. As far as the warning about the missing semicolon goes, I don't think it's necessary or even correct. If I'm reading the RFCs correctly now, parameters are optional for Content-Type and Content-Disposition.