Re: [Nmh-workers] Wishlist: Extracting Attachments from Email.

[Jon Steinhart]

> 
> Hi,
> 
> Here's a wishlist item.  Not because I think there's someone with the
> time to work on it, but because I thought it worth making public;
> perhaps someone knows how to already do this.
> 
> I keep lots of old emails.  Some of those come with attachments, some
> large ones.  MIME-encoding isn't a space-efficient way to store a file,
> and it's worse if the author forgot to compress the file.
> 
> With an incremental backup system I suffer repeated backups of these
> overweight emails when a folder is packed, or they're sorted, etc.  I'd
> like a way to extract specific parts of a MIME email to, e.g.,
> ~/mail/attach/$msgid/foo.tar.bz2 and alter the email to have a reference
> to the extracted file instead.  The email's smaller and I don't mind so
> much its repeated appearance in the backups.
> 
> Optionally, the extracted file may be better compressed along the way,
> e.g. an embedded tar file becomes a reference tar.bz2 file if it's
> smaller.
> 
> mhstore and a little scripting gets me the first half, it's the editing
> the email to change the embedded file into a reference that's the issue.
> 
> Cheers,
> 
> 
> Ralph.

Funny that you should mention this.  I'm working on it, sort of.  Maybe what
I'm working on could be changed a little bit to do what you want too.

Some of you may recall that after improving attachment-sending in nmh, I've
had some wild ideas about how to improve attachment handling on the reading
end.  What I had been thinking about was to have scan listings report the
components of multipart messages on separate lines, so if message 100 had two
parts there would be a scan listing for 100.1 and 100.2 that could be accessed
separately via show.  Fear of m_getfld has kept me from trying this.

But, I had an aha a week ago on a simpler thing to do that's not quite as nice
(to me) but gets me 90% of the way there in a much simpler way.  I'm writing
a new utility, "mburst", which does to mime messages what burst does to
digests.  So it can be used to break a mime message up into separate messages,
each containing one part.  Combined with the overly complex options to suppress
mail header printing, this will allow the non-ascii parts to be cat'ed out and
piped to other programs for processing.   Note that I am thinking of addding a
simple option to (mh)show to suppress mail header printing.

Would this do it for you?

Jon