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

[Paul Vixie]

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