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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
