be7a wrote: > Let me attempt to simplify this issue.��There�are�three�alternatives > under consideration: continue using the mbox format, change to using > separate attachment files, or change to a combination of both.��Let's > try to separate things a bit.
Mostly my fault I know, but it's not really an mbox or not mbox. For what I'm talking about we absolutely retain mbox for the storage of messages. To summarize what I'm suggesting let's start with a message on a server with an attachment. User is accessing via a POP3 account. 1. Mozilla downloads the entire message. 2. The attachment is decoded and stored on the hard drive in a directory underneath /Mail called /Attach. 3. Where the attachment was in the original message a text link is placed instead pointing to the once attached file. The link is relative to the /Mail directory. Very nearly any E-Mail client can recognize a "file//" link as this is fairly standard. If the links are kept relative to the /Mail folder this should work across platforms and mail clients. This thread was prompted due to dataloss associated with two major AV apps causing significant dataloss in the Mozilla client due to two factors. First, these AV apps have a horrid bug in them. Secondly, since attached virii are permanently a part of messages in Mozilla the AV apps go after the file with the virus, the mbox in question. Normally this buggy behavior doesn't occur, but a recent virus called BadTrans attempts via HTML to launch a still attached virii. Thankfully, this type of virus is still pretty rare in the wild. This attempt to launch from the still attached file causes the AV app to either erase or move the mbox file to "protect" the user. The real question is really down to 2 roads: 1. Mozilla removes the attachments from the mail as it's coming in, so the AV apps don't even attempt to muck with the mbox. 2. Take Bug 116443 and downgrade it's status to an evang bug and pray the AV vendors all fix their bugs. Need all their customers to patch or upgrade the AV software they're using as well. This may seem narrow minded, but additional functionality in regards to manipulating attachments isn't the solution, as it doesn't address the problem. The root problem is dataloss due to program interaction. be7a, don't mean to be flaming you here. I was getting to think it was about time to summarize this discussion into simpler elements myself. I whole heartedly agree with your attempts to do so. I just don't agree with where you simplification went is all. Later on, -- "Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read." - Groucho Marx
