Ken wrote:
[Lyndon wrote:]
FWIW, nedmail and friends on Plan9 punt in text/html by piping the
part through htmlfmt(1).
htmlfmt is a Plan 9 thingy, right? FWIW, for replyfilter I borrowed
a page from mha-mhedit and use w3m to translate HTML to plain text;
mhfixmsg builds on mhshow, so it obeys these kinds of profile
directives:
mhfixmsg-show-text/html: w3m -dump -T text/html -O utf-8 %F
It falls back to mhshow- if it can't find a suitable mhfixmsg-
directive. It gives up if it then can't find a mhshow-
directive, but both will be in mhn.defaults if something
suitable is found on the user's PATH. (Directives in the user's
profile have precedence over those in mhn.defaults.)
Ralph wrote:
# I'd like 8-bit UTF-8, i.e. change the charset too, for
# most usefulness at the command line.
The above example shows that for text/html. For other content
types, my only thought is to provide -part and -type options
like those of mhlist/mhstore. And I think that meets Paul F.'s
need:
+ i feel like i also get html mail that isn't (or isn't
+ properly) mime-encoded at all -- i have to manually
+ extract the entire body and run elinks or firefox on that.
+ of course i can't lay my hands on such a message right
+ now. so that would be similar to the above, without the
+ initial hint.
Valdis wrote:
^ Given that Sendmail (and possibly some other MTAs) is
^ known to convert between 7bit, 8bit, and Q-P encodings on
^ the fly, the concept of an "original" is fuzzy at best.
Yes, very important. Q-P and base64 are lossless so mhfixmsg
just decodes those parts in place. Content translation isn't,
so it adds a new alternative to the front of a multipart,
creating that if it didn't already exist. So, nothing is lost
from the received message.
When fixing an invalid C-T-E header in a multipart, it retains
the original:
Content-Type: MULTIPART/MIXED;
BOUNDARY="----=_NextPart_000_0000_00000000.00000000"
Nmh-REPLACED-INVALID-Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Transfer-Encoding: 8bit
So, that introduces a new
"Nmh-REPLACED-INVALID-Content-Transfer-Encoding" header field
name. But, that's for a received message that nmh wouldn't
otherwise be able to parse as MIME message.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers