Chapter 16. Electronic Mail and News
From a user's point of view, electronic mail is one of the most crucial Internet services. Mail, along with news, provides a way for people to hold discussions with other people, singly or in groups. This chapter discusses the security issues related to electronic mail and news protocols, including SMTP, POP, IMAP, MIME, and NNTP.
Simple Mail Transfer Protocol (SMTP)
Other Mail Transfer Protocols
Lotus Notes and Domino
Post Office Protocol (POP)
Internet Message Access Protocol (IMAP)
Microsoft Messaging API (MAPI)
Network News Transfer Protocol (NNTP)
16.1. Electronic MailTraditionally, a mail system has three parts, which may be implemented by different programs or by the same program, in any combination:
Figure 16-1. The parts of a mail systemEach of these parts is vulnerable for a different reason:
With any service that transfers data around, there are three main risks:
16.1.1. Keeping Mail SecretMost protocols that transfer information use relatively direct connections; the server and the client that talk to each other are usually the original source and final destination of the transfer. That's not true for mail, where messages usually pass through multiple servers between the source and the destination. Figure 16-2 shows a typical mail path.
Figure 16-2. A typical path for a mail messageIn this situation, protocols that make encrypted connections between a client and a server don't do much good. There are some cases where encryption helps; if you know what route mail follows, and only one part of it is unprotected, and you control the clients and servers on both ends of that link, you can encrypt just that link. For instance, if you are trying to protect internal mail that's being read by a user on the Internet, it's just the last link between the user and your mail server that you're worried about, and you can protect it. If you're trying to securely transfer mail between your company and a subsidiary, you can set up the mail systems so that you know mail goes directly between their server and yours and encrypt that connection. As usual, you can use either an encrypted protocol (ESMTP with STARTTLS or Secure POP, for instance; both of them are discussed later in this chapter) or a virtual private network to protect the connection.
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.
16.1.2. Undesirable MailThere are two main kinds of undesirable mail: mail that's merely annoying and mail that's actively hostile.
220.127.116.11. Junk mailThese days, the most frequent problems with mail servers has to do with something called by a number of names, including the serious "Unsolicited Commercial Email" (UCE) and the frivolous "spam" (which is not a computer-originated acronym, but a reference to a Monty Python skit in which the Hormel meat-product SPAM is undesirable but unavoidable). By any name, this is junk email -- advertisements flooding in electronically. This phenomenon arouses great hostility, as well as putting substantial load on the network, so people who create it tend to spread out both the load and the repercussions by routing it through third parties.
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.
18.104.22.168. Viruses and other hostilitiesWhile junk mail is annoying, some mail goes further and actually contains attacks on your machines. This may be because the person the mail seems to come from is trying to attack you, but more likely, it's the fault of some third party who has either forged the mail or tricked the mail's sender. The most important way to control these things is to avoid any situation where you execute code from an electronic mail message without having good authentication (don't accept programs from strangers). This is much more difficult than it sounds.
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.
16.1.3. Multimedia Internet Mail Extensions (MIME)MIME is a set of extensions to the basic Internet electronic mail message format supporting things like:
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.
16.1.4. S/MIME and OpenPGPS/MIME and OpenPGP are extensions to MIME that support encryption and digital signatures (for indentifying the sender of a message or for protecting it from unauthorized modifications). Both S/MIME and OpenPGP are implemented as special MIME data types that use public key encryption to digitally sign and encrypt messages. S/MIME can include certificate information to help senders and receivers establish trust relationships. OpenPGP uses a "web of trust" model, which requires that you have independent access to certificate information. This significantly reduces the overhead added to messages. See Appendix C, "Cryptography", for more information about public key encryption and certificates. There are several versions of S/MIME; those prior to version 3 do not necessarily provide very strong encryption.
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.
Copyright © 2002 O'Reilly & Associates. All rights reserved.