Re: [Nmh-workers] message rewrite/fix up

[David Levine]

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