March 24, 2019

There but for the Grace of Bill.... - page 2

Getting Down to that Crazy Nero Beat

  • May 5, 2000
  • By Scott Courtney

We're all familiar with how Web pages that contain Java applets, client-side scripts (JavaScript or VBScript), or Microsoft CaptiveX components execute automatically when the page is downloaded. Control over these things can be maintained using the browser settings, proxy-based content filters, or the security features of the technology itself (e.g., the Java runtime's "sandbox").

E-mail is a different story, though. A plain-text, RFC822-compliant message simply can't hurt your system, no matter what it contains. I can put a script to format the hard drive right into a text message, send it to the world, and the only way anyone loses data is if they are stupid enough to manually copy the message to a script file on the hard drive and then run it, on purpose. In that case, they deserve what they get!

Real e-mail problems can only happen in attachments or in HTML formatted mail. An attachment, as you are probably aware, is a separate file that is embedded inside an e-mail. The MIME headers mark the boundaries of the file, which is often Base64 encoded to avoid problems with some mail relays. The headers also indicate the file type, which may be something as benign as "image/jpeg" or "text/plain" or as mysterious as the generic "application/octet-stream" type.

HTML e-mail is an atrocity of its own, at least the way it's currently implemented in Netscape and in Outlook. In both cases, the e-mail software displays an HTML view of the message by embedding the browser's page-rendering engine right into the e-mail window. That's an excellent reuse of complex code, and very friendly to the user. Unfortunately, neither program allows you to set separate security limits on HTML e-mails. When you download a Web page that may contain scripts or active content, you typically set security depending on the source of the page (at least, in the Microsoft world). For e-mail, though, which zone applies? Personally, I would trust HTML from a spammer even less than I trust a generic Web site. When it comes to Web sites, I for the most part choose what sites I visit, and I don't visit sites I don't trust.

What's worse is that there is almost no way of avoiding opening HTML e-mail, at least in Netscape Messenger. The preview pane has already opened the page as soon as you select the incoming message with the mouse. Maybe you know it's spam, and you want to delete it. Just selecting it with the mouse to drag over to the trash folder momentarily opens the HTML page. If you deleted the message ahead of it (after reading it), Netscape opens the HTML message automatically as the "next" message in line. The only way I've found to delete a message without opening it is to select it with Control-Click after first selecting another message, then drag them together to the trash folder or select Delete from the menu.

So HTML mail has some ugly side effects, and they are largely the same on Linux as they are in Windows. The only difference is that Windows users have more choices of active content that can be sent inside an HTML message; the underlying problem is the same. Now let's move on to MIME-based file attachments.

When a MIME attachment arrives with an e-mail message (actually, within the message), it is up to the e-mail software and the user what to do with it. In Linux, those who use a graphical e-mail client are used to seeing the attachment as an icon, with menu options to save it to disk, delete it, or open it. Nothing happens without our deliberate action as a user. That's what protects most Linux users against malicious e-mail attachments: we're not dumb enough to open them unless we know what they are.

Most Popular LinuxPlanet Stories