Re: [9fans] store 9p session-only values using lib9p

["Francisco J Ballesteros" <nemo@lsub.org>]

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 <quanstro@quanstro.net> 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
>
>
>