Re: mpack/munpack, text/* base64 decode?

[Karl Berry]

Hi Sergey! Thanks much for the quick reply.

    -n (post the message to NNTP groups).

Agreed that there's no sense spending time that. Skeptical about -m for
splitsize, too. Nowadays the problem is more usually getting things not
to be split.

    Decoding is governed by the part's content-type and the action assigned
    to that type in mailcap file.
    ...
    Another utility available for manipulating MIME files is mhn from the
    mh sub-package.

Thanks. Looking at those, my sense is that they are (understandably)
oriented toward saving or otherwise acting on each mime part
individually, as a mail reader would want to do.

This is how everything I've found so far wants to work, including
libraries like Perl's MIME::Parser, Email::MIME, and so on. As opposed
to "filtering" a message -- take msg as input, merely decode some of the
parts, output the msg again as a whole. Clearly this could be written
using the basic libraries, which is what I was going to embark on until
your reply :), but I'm a bit surprised that it doesn't exist
already. (grepmail doesn't even decode the mime parts.)

    propose something working by the end of this week, I guess.

That would be fantastic. To (perhaps) clarify, my goal is to run a
command like
  fixtext64 oldmbox >newmbox
and have the base64 text/* parts turned into actual text. So I can grep them.

Ideally ... optionally also decode quoted-printable. Optionally also run
them through fmt, and who knows what else. So maybe the most general
approach would be to send the text of each decoded part as standard
input to a specified external command, and insert the resulting standard
output in the result instead of the original encoded text. If no command
is specified, just output the decoded text of the relevant parts in
place of the original encoded text.

It would also be highly desirable to decode any =?utf-8? (or whatever)
text in Subject:, From:, etc. Headers.

It would be fine for the mime-aware tool to operate on a single message,
if it matters, since mboxes can be easily split apart with
formail. OTOH, I suppose mailutils must already have all that code, and
it would be convenient to support a whole mbox. Either way.

    Looking at that page I think I'd be better off redirecting
    it to https://mailutils.org instead.  It doesn't say anything new and
    maintaining both versions is a waste of time.  What do you think?

1) Certainly I agree there's no sense maintaining two versions.
2) mailutils.org is also overriding my font choice, though overall it
looks nicer.
3) I know rms has a preference that the "real" home page for GNU
packages be www.gnu.org/software/PKG, although clearly many packages
do not do that.

If it were me, for the sake of uniformity I would probably start from
the boilerplate
https://www.gnu.org/server/standards/boilerplate-source.html merge the
content from the two versions, put the real version at gnu.org, and make
mailutils.org redirect there. But that's easy for me to say when I don't
have to do any of the work :). --thanks, karl.