With any service that transfers data around, there are three main risks:
If you're trying to protect mail in a situation where you don't control the servers, the clients, and the mail routing between them, this sort of encryption isn't going to do you any good. You can't guarantee that all the servers involved will use it. You can't even guarantee that you'll be able to authenticate the servers that you need to exchange mail with (you might want to exchange mail with any server on the Internet, and there is currently no infrastructure that allows you to authenticate arbitrary servers).
When you're trying to pass information along a path you don't control, you have to encrypt the message data, instead of using encrypted links. There are a number of systems for doing this; many mail user agents offer encryption features. Most systems require that the sender and the receiver have compatible software, and that they have some way to exchange keys outside of electronic mail. The systems that best address these problems are S/MIME and OpenPGP, discussed later, which are implemented by a number of different user agents and use public key cryptography.
People occasionally advocate the use of self-decrypting archives. To make a self-decrypting archive, you take the file you want to encrypt and use a program that embeds your file into another program. You mail this new program to your correspondent; when it is run, it asks for a password, and if the password is correct, it produces the original file. This removes the need for the recipient to have the decryption program (although not the need for a way to safely communicate the key). Unfortunately, it requires the recipient to have a computer that can run the executable and to be willing to run an unknown executable received in unauthenticated electronic mail. As we discuss later, people should not run executables they get in electronic mail. In addition, it is quite difficult to produce a secure program that will make self-decrypting archives of a reasonable size. Since most security experts are unwilling to have anything to do with self-decrypting archives, finding it unethical to encourage people to associate security with running random unauthenticated executables, it's reasonable to assume that self-decrypting archives are not just a bad idea; they're also insecure.
Thus, if you run an Internet-attached mail server, you have three concerns about this kind of mail:
Note that these three goals, while they're related, require quite different approaches. When you're evaluating mail servers, you need to pay attention to exactly what sort of protections they offer you; many "anti-spam" features are actually anti-relaying features, designed to prevent outsiders from using your mail server to relay mail to other people. These are useful and important features to have, but they won't be of any immediate use in emptying your mailbox of advertisements for golf balls, pictures of naked people, and completely legal ways to make a million dollars without doing any work.
Furthermore, you don't want to open something just because you know who it comes from, even if you can authenticate the mail. Some programs replicate by reading an infected user's address book and mailing themselves to the addresses in it. They'll appear as perfectly valid mail sent by somebody you know.
Worse yet, you may have to specially configure your mail reader to keep it from executing code automatically. As we discussed in Chapter 15, "The World Wide Web", some mail readers that are integrated with web browsers will run code in web extension languages even when it is embedded in mail messages. You will want to disable this functionality.
All of this makes it extremely difficult to control hostile mail at the client end. Years of education have not succeeded in getting people to think twice before forwarding chain letters, and they're not going to succeed in the much more difficult task of training people not to even open files to read them. It's therefore a very good idea to do some content filtering of incoming electronic mail to remove known hostile code. You will also need to do the training and filtering on the client end; content filtering on the mail server will not protect you from the many other sources of hostile code; the server is easily deceived by encrypting or otherwise changing the code, and it can detect only known attacks. However, it provides you a single point of control where you can get rid of current problems with one intervention, which can make all the difference in dealing with crises.
If you filter incoming mail, it is both wise and polite to filter your outgoing mail as well. Obviously, it's polite to avoid infecting other people, but it's also a useful way to diagnose and get rid of internal problems; if you're sending out hostile code, you have either infected machines or hostile users, and you want to get rid of them before they do damage to you.
Setting up filtering will depend on the details of your mail server configuration. Virus filters are available for almost all mail servers, as commercial or freely available products. In general, virus filters are most effective when they are running on the same platform they are trying to protect (that is, the Windows NT-based filters are better than the Unix-based filters at protecting icrosoft machines), but it is possible to provide basic protections for any machine from any mail server.
So-called "rich text" messages (messages containing formatted text, with different fonts and so on, rather than simple single-font unformatted text)
The MIME standards define certain basic data types, such as plain text, formatted text, standard audio, and so on. MIME is designed to be extensible, so that new data types can be added as necessary. IME-capable mail clients generally understand certain data types (often only multipart messages and plain text) and rely on other programs to handle other data types (for example, graphics programs to display images, and sound programs to play audio clips). The clients generally have a list of external programs to run for particular types of data; this list can be extended or modified by the user.
The issues for email clients are much the same as the issues for web browsers, which are discussed in Chapter 15, "The World Wide Web". Since you are running additional programs, you are vulnerable to security problems in those programs as well as any security problems that may be present in your mail client.
One difference between MIME support in email clients and web browsers is how data is obtained. With a web browser, the user chooses what data to access; with email, the user accesses whatever anybody sends. In theory, email clients are more vulnerable because you can't control what other people send you by email. In practice, however, the difference isn't that important because it's fairly easy to lure web users into accessing whatever you want them to access. Either way, you need to carefully control what data types your clients understand and how they process that data.
S/MIME version 3 and OpenPGP are being developed as Internet standards, and both require the implementation of strong encryption. Neither requires a license for using patented encryption technology in a commercial environment. There are multiple implementations of both S/MIME and OpenPGP; commercial products typically implement S/MIME, and freely available software tends to implement OpenPGP.
|15.8. Gopher and WAIS||16.2. Simple Mail Transfer Protocol|
Copyright © 2002 O'Reilly & Associates. All rights reserved.