As is explored further in Chapter 15, "Internet E-Mail: Gateways," one of the prime advantages of the Internet is almost universal electronic mail (e-mail) access. Any computer network, BBS, service, or e-mail company that wants to can hook into the Internet and allow e-mail to and from anyone else who is connected to the Internet directly or indirectly.
This chapter covers the basic concepts of Internet mail. After this chapter, read Chapter 13, "Internet E-Mail: UNIX," if you are using a UNIX machine to read and send your e-mail (skip the UNIX chapter if your mail is on a microcomputer). If you are using a PC or Mac to read and send your e-mail, read Chapter 14, "Internet E-Mail: DOS, Windows, and Macintosh." One exception, however, is if you are using PINE on a PC; if that is true, read the PINE section in Chapter 13 because PC PINE is almost identical to UNIX PINE.
Before getting into specifics, you should read about a few fundamental concepts.
E-mail consists of two basic parts: the control information and the content. The control information contains information about the message: who it came from, where it's going, when it was sent, what it's about, and whether it's regular or extra crispy. The content is the actual message being sent (which is usually considered the important part).
On the Internet, the control information is referred to as the header; the content is referred to as the body or text of the message.
When you send snail mail (through the postal service), you place both your address and the recipient's address in the "control" part of the letter—the outside of the envelope. Both you and the post office are using an agreed-on address standard: name, street address, city, state, and ZIP code. There are some variations to this standard, but that's basically it.
But what if you want to send e-mail to Joe Blow on his computer at Cyberdine Systems? If you think about it, you'll realize that you need something similar. First, your mail has to get to Joe's computer system; then it has to get to Joe.
The form of addressing you see most often on the Internet is known simply as Internet addressing; it looks like this:
localname@domain
Both sides are extendable. The domain portion should get you to a machine, and the localname portion should get you to the user you want. The domain, which is read from right to left, specifies a series of encapsulated logical domains. Here's an example:
tadpole@booboo.marketing.gigantico.com
The far-right domain, com, indicates that this is a commercial site; the gigantico specifies the name of the company or entity; marketing further specifies a department in gigantico; booboo is a specific computer in the marketing department; and the user on that machine is tadpole.
This is what is known as a fully qualified domain name—you have given complete instructions on how to reach tadpole, down to the very machine he reads mail on. In many cases, this much detail is not necessary. For example, the gigantico mail computer should know where tadpole's mail is located—unless it's a very primitive computer—and should get his mail to him correctly after it's inside the company. In this case, tadpole@gigantico.com would be sufficient. Generally, the domain contains two to four parts.
By Internet convention, the domain is case insensitive. That is, any machine routing mail from one place to another should realize that gigantico.com, GigantiCo.Com, and GIGANTICO.COM are all the same site.
The right part of the domain name is known as the top-level domain. The most common top-level domains are com (commercial site), edu (educational site), gov (government site), net (networking organizations) and mil (military site). Actually, these are usually U.S. sites. Other countries' top-level domains usually start with the two-letter ISO code for that country—for example, ca for Canada or de for Germany. However, that rule of thumb is not foolproof because there are sites in Canada with edu or com top-level domains and the us domain also exists for the United States.
The localname, on the other side of that @, is usually just the user's mail ID. It can be the user's name, the user's initials, random numbers, or anything else the site decides on. Although the localname should be case insensitive, this is not required, so mail to Tadpole@gigantico.com may not reach tadpole@gigantico.com. Most sites assume case insensitive addresses, but a few don't.
When mail travels from the Internet to another network (or vice versa), it's common to see very strange Internet addresses, with all sorts of odd characters involved. In this case, you may see some addressing for the other network tacked on to the Internet address. For example, you may see billy%untvaxb.bitnet@cunyvm.cuny.edu (we won't cover the explanation of this because it gets complex and confusing).
Sending e-mail involves several layers of protocols. Starting from the bottom in a crude layering are the following layers:
Using e-mail involves a few concepts, but if you look carefully, you will realize that almost all of them originally came from the Postal System or memos. It is not hard to grasp them.
First, you can Carbon Copy (cc) e-mail messages just like you can with a letter. In addition, there is a Blind Carbon Copy (bcc) feature in most e-mail systems that allows you to secretly send a copy of the letter to a person just as you can with paper letters.
When you have a lot of paper mail, you end up filing it into file folders in your filing cabinet. The same applies to e-mail. You can file your messages into folders. With some e-mail packages, this feature is called the mailbox.
Instead of a Rolodex or a little black book, you may have an address book. Some e-mail packages allow you to have multiple address books so that you can put your friends in one address book and your work associates in another. Finally, you may have an e-mail system that has workgroup or global address books. These are usually maintained by the system administrator and contain a large number of commonly used addresses. At a company, this address book may contain the e-mail addresses of all employees who work there.
It would be nice to ignore Mail Transport Agents altogether, but they are an important factor in the design of User Agents. Obviously, standards for sending e-mail from one place to another are necessary. But what standards?
Standards on the Internet are created in a wonderfully anarchic manner. Any person (or group) who thinks he or she has a good idea prepares an RFC (Request For Comment) detailing the proposal. If other people think the idea is good, it is implemented. If not, it will languish, unused.
RFCs are actually a little more general than this—in addition to standards, there are commentary RFCs. This type of RFC can be a specific commentary on another RFC, a commentary on the general direction of the Internet, meeting minutes, or whatever the person felt was important enough to turn into an RFC. For example, RFC 146 (each RFC is given a unique number) is "Views on issues relevant to data sharing on computer networks."
For those interested in e-mail, the two most important RFCs are RFC 821, "Simple Mail Transfer Protocol," and RFC 822, "Standard for the format of ARPA Internet text messages." There are also other fascinating documents in the list.
If you have a WAIS (Wide Area Information Server) client or Telnet available, you can use the WAIS servers to find RFCs. You can find them at telnet://ds.internic.net/wais/; you want the rfcs database.
FTP is what most users probably end up using; it's superior to WAIS in some ways and definitely more convenient than using one of the mail servers. The RFCs are stored at ftp://ds.internic.net/rfc/. For an index, retrieve rfc-index.txt. For help with FTP, see Chapter 22, "FTP: Fetching Files from Everywhere."
If you don't have FTP access, you can send mail to the Internet address mailserv@ds.internic.net and include one or more of the following commands in the body of the message:
document-by-name rfcnnnn
file /ftp/rfc/rfc-index.txt
help
Replace the nnnn in the first command with the number of the RFC you want to retrieve. The second command retrieves an index. Keep in mind that some of these documents are very large—hundreds of thousands of bytes. The index itself is 200,000 bytes. Don't accidentally swamp your mailbox.
Simple Mail Transfer Protocol (SMTP) is the underlying transmission mechanism for almost all the mail on the Internet. The standard was published in August 1982 by J.B. Postel. Although some extensions have been added, it's still used pretty much as it was proposed.
SMTP is a simple peer-to-peer model. Each host that wants to receive mail sets up an SMTP server. When the host wants to send mail to another host, it contacts that host's SMTP server as an SMTP sender. When another host wants to send mail to your host, that host contacts your SMTP server, which then acts as an SMTP receiver.
RFC 822 is actually "Standard for the format of ARPA Internet text messages," but few people have referred to the Internet as ARPAnet for a long time. This standard has been updated a few times, but everyone still refers to the RFC 822 format.
Anyway, RFC 822 describes the format that the Internet uses to transfer messages. It is useful to understand the format because you need it when you are trying to figure out why e-mail bounced, why you cannot reply to a message, or when you have some other problem. If you think this will never happen to you, you are in for a surprise.
RFC 821 and RFC 822 specified (although they didn't invent) a mail addressing format discussed earlier in this chapter. All addresses are of this form:
localname@domain
The basic format for a message is simple: multiple header lines, a blank line, and then the mes-sage text (body). Each header line contains information about the message and uses the form keyword: value. The keyword should be only a single word, but the value can be multiple words (it depends on what the keyword accepts). A header can stretch over several lines; every continuation line should start with a space or tab. The term header can refer to either the entire header or a single item of the header.
Here are some examples:
From: dr_zachary@lost.inspace.com
Subject: This is a subject line. Note how it breaks over
two lines whereas the start of headers are flush left.
To: crow@mst3k.com
Tabs and spaces are both treated as generic, word-separation characters. If a keyword requires a one-word value, and the value you want to use includes spaces, surround everything with quotation marks. As an example, the address rdippold@bozos.edu is perfectly valid and can be given as follows:
From: rdippold@bozos.edu
However, the address Bob Smith@wubba.com includes a space, which can confuse mailers, so it must be given as follows:
From: "Bob Smith"@wubba.com
For this reason, it is rare that such an address is given. Generally, this address would be assigned as Bob_Smith@wubba.com (or wubba.com would automatically translate between the two) because it is simpler.
The only header absolutely required for a message you want to send is the To header:
To: address
However, the mailer usually adds other headers. Generally, you'll also want to add a Subject header so that the receiver can see what the message is about:
Subject: message subject
You may also want to add a From header so that the receiver can reply to your mail:
From: your_address
Here's a simple message:
From: mickj
To: keithr
Subject: Where's the sugar?
Me bag of cane sugar is missing, Keef. I don't suppose you might
know something about it, eh?
The mailer at your site adds some other headers (such as the date); any machines along the way add their own information.
The easiest way to learn about the other headers is to look at a real message header. Only the names and addresses have been changed to protect the guilty:
From jeff@mathcs.amour.edu Thu Mar 30 07:49:44 1995
Received: from tofu.com by happy.tofu.com; id HAA04319
sendmail 8.6.4/QC-client-2.0 via ESMTP
Thu, 30 Mar 1995 07:49:42 -0800 for <rdippold@happy.tofu.com>
Received: from amour.mathcs.amour.edu by tofu.com; id HAA28169
sendmail 8.6.4/QC-main-2.2 via SMTP
Thu, 30 Mar 1995 07:49:40 -0800 for <rdippold@tofu.com>
Received: from cssun.mathcs.amour.edu by
amour.mathcs.amour.edu (5.65/Amour_mathcs.3.4.15) via SMTP
id AA28633 ; Thu, 30 Mar 95 10:49:38 -0500
From: jeff@mathcs.amour.edu (Jeff Budd {guest - asst uucpMC})
Sender: jeff@ee.amour.edu
Message-Id: <9503301549.AA28633@amour.mathcs.amour.edu>
Subject: sci.physics results
To: rdippold@tofu.com (Ron Dippold)
Date: Thu, 30 Mar 1995 10:49:37 -0500 (EST)
Reply-To: jeff@mathcs.amour.edu, jeff@hobbit.moth.com
X-Mailer: <PC Eudora Version 2.0>
Cc: group-advice@uunet.UU.NET
Cc: aleff@ux1.cso.uiuc.edu (Hans-Jorg Aleff)
In-Reply-To: <CMM.0.90.0.755815603.rdippold@happy.tofu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 20432
This is a message from Jeff to me regarding the Usenet group sci.physics. From the top:
From jeff@mathcs.amour.edu Thu Mar 30 07:49:44 1995
This is the line my mail program uses to separate one message in the mail file from another.
Received: from tofu.com by happy.tofu.com; id HAA04319
sendmail 8.6.4/QC-client-2.0 via ESMTP
Thu, 30 Mar 1995 07:49:42 -0800 for <rdippold@happy.tofu.com>
This section is interesting; it's the last machine-to-machine mail transfer (each transfer adds a Received line at the top of the message, so the first listed is the last that occurred). In this case, the machine happy.tofu.com received the message from the machine tofu.com (the central e-mail machine for tofu.com). The transfer was done with sendmail 8.6.4, and the protocol used was ESMTP, which is an extended version of SMTP. The date and time of the transfer are given, as is the address of the intended recipient.
Received: from amour.mathcs.amour.edu by tofu.com; id HAA28169
sendmail 8.6.4/QC-main-2.2 via SMTP
Thu, 30 Mar 1995 07:49:40 -0800 for <rdippold@tofu.com>
This portion of the header is the mail transfer that actually got the e-mail to tofu.com. In this case, the machine amour.matchs.amour.edu sent the message with SMTP using sendmail to tofu.com at the time given.
Received: from cssun.mathcs.amour.edu by
amour.mathcs.amour.edu (5.65/Amour_mathcs.3.4.15) via SMTP
id AA28633 ; Thu, 30 Mar 95 10:49:38 -0500
This portion is the first mail transfer. The machine cssun.mathcs.amour.edu (where the message presumably originated) sent it to amour.mathcs.amour.edu, which is presumably the central e-mail gateway for amour.edu. The message was sent with SMTP at the time given.
From: jeff@mathcs.amour.edu (Jeff Budd {guest - asst uucpMC})
The person who sent the message is Jeff Budd. His address, in case I want to reply, is jeff@mathcs.amour.edu
Sender: jeff@ee.amour.edu
The Sender header is the identity of the person sending the message. In most cases, it should be the same as the From field and can be left out. However, it is used when secretaries send mail in the names of the people they work for, or if a single member of the group specified in From sends the message. In this case, Jeff used the ee machine to send the mail rather than the mathcs machine he gave in his From address. Therefore, the mail program added the Sender field so that I would know where the message "really" came from. Not a big deal here, but if the From and Sender fields are radically different, the message might be a forgery.
Message-Id: <9503301549.AA28633@amour.mathcs.amour.edu>
The Message-Id header is used for tracking down errors; every message has a unique Message-Id header. There should never be another message with this Message-Id.
The following line is the subject of the message:
Subject: Re: sci.physics results
When my mail program shows me the overview of the message, it shows me who the message is from, the date, and the subject. The Re indicates that it's a reply to a previous message.
To: rdippold@tofu.com (Ron Dippold)
This is who the message is for (me, in this case).
Date: Thu, 30 Mar1995 10:49:37 -0500 (EST)
This line gives the date the message was sent. You'll read more about date formats later.
Reply-To: jeff@mathcs.amour.edu, jeff@hobbit.moth.com
If the sender does not want a reply to be sent to the address given in the From line, he or she inserts a Reply-To line; any replies should be sent to this address. In this case, my answer to this message will go to two separate addresses: jeff@mathcs.amour.edu and jeff@hobbit.moth.com. The amour address is faster, but it's unreliable, so Jeff likes to have replies go to both addresses. Normally, Reply-To is used only on special occasions, but it can also be used if the address given in your From line is incorrect and you can't fix it for some reason (because of a lazy administrator, for example).
X-Mailer: <PC Eudora Version 2.0>
Keywords starting with X- are special. You can create any such X- keyword with whatever you think is important and use it as a header. In this case, the mailing software that was used to send the message (PC Eudora) inserted its own ID in a little bit of self-promotion.
Cc: group-stuff@xxnet.XX.NET
Cc: jones@ux1.cso.krill.edu (Josef Jones)
The message was also sent (carbon copied) to the addresses group-stuff@xxnet.XX.NET and jones@ux1.cso.krill.edu. This information could also have been specified in a single Cc line by separating the addresses with a comma.
In-Reply-To: <CMM.0.90.0.755815603.rdippold@happy.tofu.com>
The message is in reply to a message I sent with this Message-Id.
Mime-Version: 1.0
This line deals with something to be discussed later: MIME message format.
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
These MIME headers indicate that the contents of the mail are simple text with no high ASCII characters, such as PC graphics characters. If any machine along the way cares to send only 7 bits of each character, the message should still transfer okay.
Content-Length: 20432
The length of the body of the message is 20,432 bytes.
Bcc: recipient
The Bcc (blind carbon copy) field is like the Cc field, except that those whose addresses appear in the Cc or From fields don't see the Bcc header.
Keywords: keyword, keyword
This header specifies keywords that relate to the message. These keywords are sometimes used by the e-mail program to do searches, but this is totally dependent on the program.
Comments: comments
This header allows comments on the message to be sent without disturbing the body of the message.
Encrypted: software keyhelp
This header indicates that the message body is encrypted with the encryption software software, and the optional keyhelp helps select the key to decode with. Note that the header itself cannot be encrypted, because it contains vital routing information.
Dates used in RFC 822 headers are of the following form:
Mon, 27 Mar 95 15:34 -800
The day of week is optional. The time is given as 24-hour format (00:00 through 23:59) local time. The last field is the time zone in one of several formats:
Format |
Meaning |
|
UT or GMT |
Universal/Greenwich mean time |
|
EST or EDT |
Eastern time zone |
|
CST or CDT |
Central time zone |
|
MST or MDT |
Mountain time zone |
|
PST or PDT |
Pacific time zone |
|
—HHMM |
HH hours and MM minutes earlier than UT |
|
+HHMM |
HH hours and MM minutes later than UT |
|
Z |
Universal time |
|
A |
UT minus 1 hour |
|
M |
UT minus 12 hours |
|
N |
UT plus 1 hour |
|
Y |
UT plus 12 hours |
The —HHMM format is probably the least confusing. In my opinion, -0800 makes it much easier to translate the time to local time than PST does. The Z through Y zones are military codes.
Another common form of addressing used by many of the big commercial e-mail providers such as AT&T, Sprint, and MCI is X.400. There exist gateways between these systems and the Internet, but X.400 is much more restrictive than RFC 822 about which characters are allowed in addresses. Because X.400 addressing is complex and cumbersome, it is not covered here. See Chapter 15, "Internet E-Mail: Gateways," for more information (alternatively, read RFC 1327).
MIME (Multipurpose Internet Mail Extensions) addresses a giant limitation in Internet message standards. Generally, messages are assumed to be all low-bit ASCII text (ASCII values 0 through 127). This situation makes it tough to send information such as sounds, videos, programs, or even some non-English character sets in an Internet message. Much of this type of information is probably altered, assuming that it doesn't break the mailers first. There are ways around this problem, such as preprocessing all the information to 7 bits and then reconstructing it on the receiving end (see the discussion of uuencode, later in this chapter). Both the sender and receiver must agree on a format and have programs to deal with it. It's also inconvenient when X.400 messages (which allow encapsulated data) must be passed through a section of the Internet—it would be extremely helpful if the message that reentered the X.400 network contained the same encapsulated data.
A MIME message allows this sort of data to be passed through in a consistent manner. The header fields you need to look for are MIME-Version and Content-Type. These are the Content-Types defined in RFC 1521:
Content-Type |
Description |
|
text |
Plain text information. A subtype, richtext, is defined in RFC 1341. |
|
multipart |
For messages consisting of multiple independent data parts. |
|
message |
An encapsulated message, which can be all or part of a full RFC 822 message. There is a partial option to the message Content-Type for partial messages, which allows one message to be divided into several smaller parts. There also is an external-body option that allows a reference to an external source, such as a file on an FTP site. |
|
image |
Still-image data that can be sent to a graphical display, fax machine, printer, and so on. The two initial subtypes are the common JPEG and GIF image formats. |
|
audio |
Audio data, which requires a speaker of some sort to listen to the contents. |
|
video |
Moving picture data. The initial subtype for this is the MPEG standard. |
|
application |
Some other data to be processed by the mail application. The primary subtype, octet-stream, is used for a stream of simple binary data. In most cases, the recommended action is to write the data to a file for the user. This file is what is used to send a program by mail. Another subtype, PostScript, is defined for sending PostScript documents. |
The Content-Type you see on most messages for now is this one:
text/plain; charset=us-ascii
This Content-Type just means plain text with a U.S. ASCII character set. In fact, MIME-aware mailers that don't find the Content-Type field assume this value.
The other important header is the Content-Transfer-Encoding field, which tells how the data is encoded. If you want to send binary (8-bit) data over channels that assume 7 bits (most Internet mail servers), you still must encode that data down to 7 bits.
Those interested in further information should read the RFC or FTP to ftp.netcom.com and get the document pub/mdg/mime.txt, a MIME overview by Mark Grand. If you want to see some sample MIME messages, FTP to thumper.bellcore.com and look in the directory pub/nsb/samples. For those with Usenet access, the group comp.mail.mime discusses this subject.
MIME hasn't completely arrived by most practical standards. Although a lot of people are interested and programs are starting to support MIME, it's not yet universal. Carnegie Mellon's huge Andrew system handles MIME. The Gopher client for NextStep 3.0 has MIME support. The WWW (World Wide Web) uses MIME messages for transferring information. Metamail is a useful program that other mail programs can call to display MIME messages. The PINE mail program (discussed in the next chapter) and the Eudora mail program (discussed in Chap-ter 14, "Internet E-Mail: DOS, Windows, and Macintosh"), among others, offer some support for MIME. New Content-Types and subtypes are being registered all the time.
The POP (Post Office Protocol) protocol comes in multiple versions, such as POP2 and POP3. Following is a general discussion because both protocols are in widespread use. Suppose that you want to use a PC or Mac to read your e-mail, but you only dial up the Internet every once in a while. POP or IMAP (Interactive Mail Access Protocol, discussed in the following section) is the solution to your problems.
With POP, your incoming e-mail spools onto a server machine, usually UNIX based, somewhere. When your computer connects to that server, it downloads the e-mail to your computer. You do all your e-mail processing on your computer.
POP is supported by numerous e-mail packages including Eudora, Pegasus Mail, and Z-Mail.
One situation POP does not resolve is if you have a computer at home and one at work; you want to read your e-mail with a package on your home microcomputer but you also want to read it when you are at work. You also want to be able to access all your folders. IMAP is the solution to your problems.
IMAP's proponents see no reason that POP should continue to exist since IMAP has arrived. IMAP is supported by several e-mail packages including PINE, ECSMail, and Mailstrom.
You can find other standards by reading the RFCs. In fact, any two sites that want to talk to each other can use any protocol they agree on, such as L'il Joe's Own Protocol. The trick is to make sure that other sites can still handle the mail after they've processed it.
Wow, all that to send a simple message. Don't let it get you down. In most cases, all you have to remember is this:
From: me
To: them
Subject: description
Message body here.
You've seen how SMTP can be used to send mail (you can even SMTP yourself), but you don't really want to do that every time you send mail. And how do you read mail? Read on, MacDuff.
Earlier, you read that a Mail Transfer Agent (MTA) routes e-mail. Normally, only the system administrators worry about the details of the MTA and how it works. I mention MTAs here only so that you will be familiar with the terminology when you run across it.
The most famous MTA is sendmail, which comes with almost all UNIX machines. Although it is a very mature, robust product, it is most well known because of the periodic security holes people find. Other well-known MTAs you may run across include MMDF, PMDF, and smail.
When you start getting a lot of e-mail, you begin to wonder whether you can filter and sort that e-mail before you begin to read it. Others have had the same idea.
Some mail packages, such as Pegasus Mail, include a filtering and sorting function as an integral part of the mail program itself. On other systems, especially UNIX-based systems, there are separate mail-filtering programs. The UNIX filtering programs are discussed briefly in the next chapter.
The major functions of mail filtering generally are filing, trashing, and marking. In filing, the incoming message is placed in a folder you have specified. A good use of this is when you want to read a mailing list but you do not want it mixed up with your other e-mail. Trashing is what it sounds like: getting rid of messages you don't want to see. This is useful when you do not want to read messages from a certain person. Finally, marking is the ability to mark important messages as being such.
I should point out that filtering has its limitations. With many filtering systems, you can only filter based on who the message is from and the subject. Even more advanced filtering packages that search the entire message cannot understand the actual meaning of the message and can only look for particular words in the text.
There's one last introductory subject to cover. In the absence of MIME, how do you send programs and data through e-mail? Because there are so many people who don't have FTP access, yet do have e-mail access, it's guaranteed that this problem would be addressed. Indeed, there are several solutions, but the most widespread is the use of uuencode and uudecode.
Uuencode takes an 8-bit (that is, a binary) file and encodes it as 6-bit printable characters. Because all Internet mail sites pass normal ASCII printable characters unmodified, the data should make it through to the other side. Some Mac users use a similar program (called BinHex) which serves the same purpose but is not compatible with uuencode.
NOTE The uuencoded file is about 35 percent larger than the original file; 33 percent of that comes from converting 8-bit bytes to 6-bit bytes, and the rest comes from control information in the encoding, like the end-of-line markers.
Versions of uuencode exist for almost every platform there is. The next chapter discusses uuencode on UNIX (the original version of the program).
What if you want to send a 200,000-byte file? If you use uuencode, you add 35 percent for a 270,000-byte file after encoding. That's a hefty message by any estimation. Although you usually don't run into any problem with normal messages, some sites have a limit on message size—usually around 64,000 bytes. If you send your file as one big chunk, only a fourth of it might get there. And unlike a hologram, the entire thing is needed to reconstruct the file. You must split the file into smaller chunks. A UNIX split program is described in the next chapter; similar programs exist for other platforms.
New Internet users tend to think that e-mail is secure and private. This is a mistake. There is no postal service that protects your e-mail.
The first problem is that it is relatively easy to forge a mail message to make it look like it came from a certain person. E-mail experts can almost always detect forged e-mail messages by looking at the headers. A good defense you can use is to look at the style of the message. Does it sound like something the sender would say? If not, then be suspicious.
Another problem is that—although there are some laws against it—people can intercept e-mail messages during transit without you knowing it. Your own system administrator most likely can look at your e-mail and may even be able to do it legally, especially if he or she is investigating a security leak.
The solution to the forgery problem is known as a digital signature. It is possible to include a digital signature on e-mail messages so that you can validate whether the sender is who he or she says it is. However, if the sender has his or her password stolen, someone may be able to still forge a message in his or her name.
You can also encrypt e-mail messages. Remember how, as a kid, you encoded messages with your secret decoder ring? Encoding e-mail messages is like that, but it's an automatic process and is much, much more secure.
Using the latest algorithms, it is virtually impossible for someone besides the recipient to decrypt your messages.
Two major software systems for e-mail encryption and digital signatures control most of the market. They are PEM (Privacy Enhanced Mail) and PGP (Pretty Good Privacy). PEM is a purely commercial effort that depends on heavily centralized control mechanisms. In other words, PEM-based solutions tend to be expensive and require a complex infrastructure to be put in place.
The alternative PGP is based on the efforts of one person, Phil Zimmerman. PGP is free to individuals and educational institutions (others must pay for the software). PGP is based on the concept of a web of trust. You validate that you know your friends. Your friends validate that they know their friends. You assign a value to how much you trust your friends to validate their friends; this value tells PGP how much you trust their friends. The good thing about PGP is that it is easy for friends to start exchanging encrypted e-mail. The bad news is that it still requires an infrastructure to make it a good global solution.
Unfortunately, the support in e-mail packages for PGP and PEM are minimal at this point. Also, the standards for using these encryption systems with MIME are still being developed. We are at least a couple of years away from widespread deployment of e-mail encryption.
NOTE Chapter 13, "Internet E-Mail: UNIX," discusses UNIX e-mail packages; continue your reading with this chapter if you are using a UNIX-based Internet service provider. Chapter 14, "Internet E-Mail: DOS, Windows, and Macintosh," is about PC and Mac e-mail packages; read this one if your e-mail package runs directly on your microcomputer.