Re: [Nmh-workers] mime-aware filtering?

[Jon Steinhart]

Paul Vixie writes:
> On 6/25/2012 10:43 PM, Tethys wrote:
> > Ken Hornstein writes:
> >
> >>> A possible way to solve the access to MIME parts problem
> >>> might be to store the parts as messageNumber.partNumber*
> >>> Creation of these parts would be optional, and eat space,
> >>> but it would make indexing/grepping easy.
> >> You know ... given that & Norm's comments, that actually might work.
> >> Thoughts? 
> 
> i'm opposed. what should be in the file system is what SMTP received and
> handed to /var/mail or whatever.
> 
> > My only thought is that MIME is more than just the linear list of
> > attachments that many seem to believe, and we need to come up with
> > a naming convention capable of representing that. And even then,
> > deciding what to store as content for a given part isn't necessarily
> > straightforward. For example, if you have a multipart/alternative
> > part, how do you represent that in the filesystem? We've briefly
> > touched on some of this before:
> >
> >     http://lists.nongnu.org/archive/html/nmh-workers/2012-02/msg00088.html
> >
> > But whatever we do, it needs careful thought to cover the edge cases
> > that are increasingly becoming the common case in mail I'm being sent.
> 
> thus my proposal which is to provide shell level commands that can
> expose the message structure (as "msg.part{.subpart ...}") and something
> like mhpath that will make you a /var/tmp file from the specified
> part/subpart without any encoding, and then update the rest of the
> command set to be able to accept a msg.part{.subpart ...} specifier
> wherever it makes sense. as in, rmm would not make sense, but show would
> make sense.
> 
> mhparts as the structure-exposer and mhpart as the tmp-file-maker would
> be fine. or someone else will have a better idea. mhpart (or whatever)
> would need a -clean option to get rid of the /var/tmp files it has made
> for you in this session.
> 
> but i do not think we should pollute the Mail subdirectory hierarchy
> with permanent copies of parts.
> 
> paul

This goes back to the project that I want to do when time permits and
someone makes m_scan into something that I can hack without fear of
breaking old VAX stuff.

I'd like a "show parts" option to scan, and the ability to do show msg.part,
next -part, and prev -part.  In other words, the option to work on messages
as a whole or on the parts individually.

I don't support polluting the Mail subdirectory.  I use a separate program
for indexing which I'm presently slowly rewriting as real work calls but
will re-release when done.

Jon