I had just sort-of jury-rigged my own very local and very idiosyncratic
mechanism for dealing with the problem/issue some years ago, and I have
been just trying to struggle along with it for all this time because
I just haven't had the time to find a proper fix... which I've always
assumed is burred in the documentation someplace. But if there really
is no good solution in the case of nmh, then I guess that eventually...
and proabbly sooner rather than later... I'm going to have to switch
mail clients at long last, although I sure will miss some of the nicer
Geez, I thought we handled that pretty well.
For base64 emails, we should handle that fine for display, full stop.
If you are building from source, _if_ you have one of the common text-based
HTML browsers available (I use w3m, but we also support lynx and elinks),
then show(1) does the right thing, and pretty reasonably I would say. If
you are installing from an OS package ... well, what happens there varies.
At least for MacOS X, it will use w3m (this all is configured at install
time). But if you've put your own entry in for mhshow-show-text/html, then
you wouldn't see that. We've done that since 1.6 (released in 2014).
As for repl(1), we've shipped with replyfilter in $(DOCDIR)/contrib
since 1.5 (released in 2012), and I use it on every message. I won't
say it's perfect, but 95% of the time it does the right thing for me,
and handles HTML and base64 email just fine. Unfortunately without a
complete rewrite of mhl it was hard to put it in there transparently, so
it does require extra configuration (see the comments at the top of
replyfilter). We talked about this a LOT on the mailing list during it's
development, and here's the snippet from the NEWS file:
- Preliminary support for improved MIME handling when replying to messages!
Yes, a long requested feature has a solution. A perl script
called replyfilter is available; it is designed to act as a mhl
external filter to process MIME messages in a more logical way.
It is available in $(srcdir)/docs/contrib/replyfilter or is
typically installed as $(prefix)/share/doc/nmh/contrib/replyfilter.
See the comments at the top of replyfilter for usage information;
it will likely require some adjustment for your site. replyfilter
requires the MIME-Tools and MailTools perl modules.
So, I hope it doesn't seem like I'm crapping on you, because you're
not the first person who is unaware of replyfilter (you can search the
mailing list archives for people who have asked this question before,
and I can write this email in my sleep now). I thought we did a pretty
good job of putting this information out there, but clearly in the 7
years since 1.5 has come out everyone hasn't gotten the word yet. So my
question to YOU is ... what could we have done better to let you know?
(Yes, in a perfect world 'repl' would just do the right thing automatically
without any extra configuration, but that's a heavy lift).