[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] message rewrite/fix up
From: |
David Levine |
Subject: |
Re: [Nmh-workers] message rewrite/fix up |
Date: |
Sat, 09 Feb 2013 10:03:59 -0500 |
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
- Re: [Nmh-workers] message rewrite/fix up, (continued)
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/03
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/04
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/04
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/05
- Re: [Nmh-workers] message rewrite/fix up,
David Levine <=
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09