Michael Collette wrote: > The following is based on some initial usability bug reports that has later > spawned new dataloss concerns. The purpose of this posting is to discuss > the issue of attachments in so far as how they relate to security. > > For reference: > ------------------- > Delete attachment from msg in folder > http://bugzilla.mozilla.org/show_bug.cgi?id=2920 > > RFE: Ability to Edit/delete attachments in mail/news > http://bugzilla.mozilla.org/show_bug.cgi?id=121728 > > Security impact by mozilla automatically attempting to download mail parts > http://bugzilla.mozilla.org/show_bug.cgi?id=109249 > > Deleted inbox after receiving virus infected mail > http://bugzilla.mozilla.org/show_bug.cgi?id=116443 > > The first two bugs here deal with usability, where the second two have > serious security and data integrity issues. All of these are related in > how Mozilla deals with E-Mail attachments in general. > > Positions Thus Far: > -------------------- > Mozilla stores mail in what is called the mbox format, which is a common > means for doing so under Unix. This allows for maximum flexibility in > between platforms. The entirety of all the messages in a folder, to > include attachments, is stored in a single file. > > One suggestion, that I am in favor of, is to strip the attachments from > incoming E-mail to a directory underneath /Mail prior to storing the body > to the InBox. This is not consistent with the mbox format, and is > considerably different from how Mozilla handles mail today. The best > example of an app doing this is Eudora. The advantages to this approach > have to do with both living in harmony with the wide variety of anti-virus > software out there, and allowing users to keep the text potions of E-mail > while being able to remove large attachments. > > The main counterpoint to this is that it is important to maintain the > integrity of the mbox format for backups and portability. By changing to a > different way of handling things would overly complicate portability > between OS's and mail clients. Dataloss involving AV apps should be should > be considered the responsiblity of the AV vendors. Attachments are part of > the E-Mail message, and should remain as such unless the entire message is > deleted. > (note: I hope I'm fairly representing this) > > Along side of these two points of discussion also resides how much > automation should be allowed for E-Mail messages. Bug #109249 has a > discussion running on this. I've included this as it relates to security > of handling attachments. > > Discussion: > --------------------- > Which of these points is best for Mozilla in the long run? Are there > alternative methods to be considered? What are the pros and cons of the > various approaches?
Opera also stores mail in the mbox format. When I decided to switch to IMAP (not supported by Opera), it was very easy to upload my mboxes to the server. No file conversion was necessary. All I had to do was rename them. By using an open standard, Opera made my life easier. I would like to see more applications adopt open standards. In my experience, this approach protects user data more than it endangers it. To veer away from standards to support buggy programs is a step in the wrong direction. The fact that AV software is deleting important files (isn't that what viruses do?) is clearly a flaw in the software, and should not be tolerated by any user. For mozilla to change its standards compliance to support these dangerous programs does not solve the problem for other users of other programs in any way. If any lessons have been learned from Netscape's past, it's that proprietary formats have the potential to make a product unusable (JSSS, anyone?). With that said, it's true that I would selectively use a feature that allowed me to strip an attachment. It would certainly help me to manage the size of my IMAP folders. I would like it to take the message out of the inbox, extract the attachment, add a header describing the action, then prompt to save or delete the attachment, and append the revised message to the mbox. I am also not against allowing the user to automate this functionality, either globally or on selected mailboxes. As long as this is not the default configuration, it seems like it would be a very powerful feature. It should also be noted that this functionality could be added to the AV software. At the very least, AV scanners should default to a defanging behavior that prevents a virus from launching, while still allowing the user to reverse the changes made to a file. This approach would have prevented the worst case scenarios brought up by this issue, while still providing the same level of protection.
