be7a wrote: > Michael Collette wrote: >> Normally this buggy behavior doesn't occur, but a recent virus called >> BadTrans attempts via HTML to launch a still attached virii. > > I have several comments: > > 1) I don't understand how HTML has the capability to launch /anything/.
I once looked over the HTML with BadTrans briefly. It was doing something clever with <iframe> tags trying to embed the executable attachment into the web page, thus trying to get that bugger to launch. I imagine the effect here is to get that certain percentage of the population that doesn't read dialog boxes to click on something. Seems that most of the virii infections I've personally dealt with resulted from a user trying to go through their mail quickly. Speed facilitates the accidental clicking on "Yes" rather than the wiser "No" answer. > 2) Norton has an option called, "Exclude selected files and folders". > I would assume other major utilities do too. Why can't a warning > go into the release notes that tells the user to exclude the mozilla > mail directory? This option would involve far less effort and > development risk. Might be a tough sell. The bulk of the public has some notion that E-Mail propogates virii. That same bulk of folks don't have a clue about the mechanics of these things. I only base this opinion on the notion that if they did, we wouldn't have problems with virii! Telling folks that they should check everything but E-Mail folders flies in the face of what they've been getting told up to the point. I'm not saying that your approach to AV settings is wrong, just that I don't think it would be understood. > 3) I don't believe Mozilla could ever handle attachments right if it > were to transcribe them into files. There are several complexities: > a) Mozilla should handle every variant of the MIME standard, > including the complexity of nested attachments that may contain > alternative media types for the same component. Alternative media > types require human intervention to choose the alternative when disk > space is tight. > b) When an attachment is large and disk space is tight, having the > attachment in the mbox file while Mozilla automatically transcribes it > to a separate file is undesireable when the disk runs out of space. > Mozilla has to handle the exception case that requires additional > complexity. If the concern is disk space, then decoding them attachments on the way in actually saves quite a bit. Uuencoding tends to bulk up the file size somewhere from 10-20% (shooting from the hip here) of the original file. Without testing it personally, I'd guess that double or triple embedding makes matters worse on actual disk space used. I honestly don't know how Eudora handles nested encoding. I would imagine that it would have to decode everything from the lowest level on up and save all the files out. It is a good point, and one that would need to be looked at very closely. > 4) Improving MIME handling is something I see as necessary in any > case, and it does solve the issues enumerated in (3) above. > >> 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. > > I agree with you. Manipulating attachments doesn't address the AV > utility problem. I recommend using release notes to address problems > with external interactions like a lot of other software does. I would agree that release notes are the appropriate place for letting the user know about possible interaction problems resulting in crashes, or just not getting along with other apps. For a problem resulting in critical dataloss in something as important as E-Mail I don't believe that approaches an adequate solution. Anyone who actually reads release notes probably doesn't have much in the way of virus problems in the first place. It's them folks that don't read documentation that are the concern, and I'd guess that them folks are probably in the vast majority. > Automatically transcribing attachments into local files has the > potential to cause more problems than it solves, and it's an > /expensive/ way to solve the problem. I strongly believe the Right > Way to handle attachments is to better support MIME within the mbox > file. Adding a feature to transcribe attachments to disk seems > superfluous, undesireable, and error-prone. When you do click on an attachment, the client must deal with what to do at that point. In every case the file is then saved to some location. It's gotta do that, or you'd never be able to get an attachment out of a mail at all. The primary difference in what I'm suggesting is that this process occurs before anything is written to the mbox file. 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
