This mail with a reply inlined would be msgdir/ msgdir/text msgdir/raw If, the reply was inlined. Anyone wanting to use the original can go use raw. But the nice thing is that you can edit text, copy attachments in/out, remove them, etc. etc.
Compatibility in my case is achieved by leaving upas et al. as they are; I convert just my mail once it entered the system. On Thu, Jun 12, 2008 at 2:25 PM, erik quanstrom <[EMAIL PROTECTED]> wrote: >> Funny, I've done the same in a different way. >> see mail2fs in contrib/nemo. >> Also, I have some proposal, skip to the end of the mail and let me know >> what you think :) >> >> In any case, I'd love to see/try your version of upas/fs et al. > > /n/sources/contrib/quanstro/src/nupas. cavet emptor. > > nupas/fs is fully compatable with upas/*. > > i have been using the mdir format for about 18 months. but i have > just recently added the bits to reduce memory footprint. > > i'm currently spending quite a bit of time on this so details may change. > > i would appreciate any feedback. > >> Instead of adapting upas/fs, I use a mail2fs program that uses >> upas to convert mail into an "unpacked" form. Each mail is a directory. >> A "text" file contains the message text right as you would see it in a mail >> reader (including relative paths for attachments). Each attach is decoded >> and kept in the mail's directory ready to be copied, printed, etc.; if >> possible, >> using the same file name reported by the attachment. > > it's hard denying that this is some allure to this idea and i definately > considered it. however, we get quite a bit of three-part email containing > the mime parent a 150 byte message and the 400 (with headers) byte > replyed-to message. depending on the details of your format, this > could require 3 directories + 3 files or 6 blocks of storage for a > smaller-than 1 block message. (assuming 8kb blocks.) it also could > result in quite a bit more seeking when scanning a number of messages. > > in addition, this format is not compatable with any of the existing > tools. in mdir format, each file looks like a mailbox of exactly one > message. in addition, in mdir format each message is self-contained. > i can just cp it. > > finally, a number of email security standards (so-called spf2.0 and > s/mime) require the original email. it's not clear to me that one can > reconstruct an original mime message from processed parts without > leaving some breadcrumbs behind. there's no requirement not to > base64-encode us-ascii, for example. > > - erik > > >
