i first killed a tree with the mime spec in 1991. i filed it away and read mail with /bin/cat and later sam. but since mime is here to stay and quoted-printable and base64 (not to mention rfc2047) are really annoying to read via /bin/cat, i broke down and wrote something.
it would be nice if mime could be just a wire format. but, there's a lot of information there that would be hard to put into just files. just dropping the Content-Transfer-Encoding on the floor might be a Good Thing. but what about the Content-Type. especially the charset=. you might not have a suitable charset convert handy when you get the mail. and some of them are screwed up. if you have the mime headers you might be able to figure it out. i got "8859-15" receintly. they wanted "ISO-8859-15". do you want to keep that with the email? how do you tell multipart/alt from multipart/mixed without some sort of guide file? maybe i'm overreacting to the problem, but i'm afraid that "just piling it into the fs" will result in reinventing mime in a different sort of way. i am a big fan of how upas mounts the email. maybe an additional set of tools like, e.g., mcat, mimedesc, xheader might just as easy? maybe the best idea would be to leave the original email, 1 per file on disk and let the mail program present a directory structure for each. -- erik Russ Cox <[EMAIL PROTECTED]> writes | | i think that in the mime and huge mail box | world, splitting mail out into one message per file | with attachments as separate files themselves | actually makes a lot of sense. it's easier on the | dump, it's easier for the programmer, it's easier | on the users, etc. best of all, mime becomes a wire | format instead of a storage format. users needn't | ever worry about it. | | you could still use one lock file to lock the entire | directory. or not, since you get atomic create for | free. | | russ
