Addressing and Email


Before I can tell you about email, retrieving files via FTP, or much of anything else, I must discuss how email addresses and machine names are formed, where they come from, and that sort of thing. After that, I'll discuss the wide world of email in greater depth, relating some of the uses and customs that you encounter.


Addressing


A rose may be a rose by any other name, but the same is not true of an Internet computer. All Internet computers think of each other in terms of numbers (not surprisingly), and all people think of them in terms of names (also not surprisingly). The Internet uses the domain name system to make sense of the millions of machines that make up the Internet. In terms of the numbers, each machine's address is composed of four numbers, each less than 256. People are generally bad about remembering more than the seven digits of a phone number, so a domain name server was developed. The domain name server translates between the numeric addresses and the names that real people can remember and use.

Despite the fact that all Internet numeric addresses are always sets of four numbers, the corresponding name can have between two and five sets of words. After five, it gets out of hand, so although it's possible, it's not generally done. For instance, the machine I use now is called tidbits.com (two words), and the machine I used at Cornell was called cornella.cit.cornell.edu (four words). The domain style addresses may look daunting, but in fact they are quite easy to work with, especially when you consider the numeric equivalents. Each item in those addresses, separated by the periods, is called a domain, and in the following sections, you are going to look at them backward, or in terms of the largest domain to the smallest.

NOTE: A random aside for those of you who are students of classical rhetoric: The process of introducing topics A, B, and C, and then discussing them in the order C, B, and A is called chiasmus. This little-known fact is entirely unrelated to the Internet, except that after the first edition of this book I took a lot of good-natured ribbing on the Internet about my classical education, so I figured I should at least pretend to know something about the topic.


Top-Level Domains


In any machine name, the final word after the last dot is the top-level domain, and a limited number of them exist. Originally, and this shows the Internet's early Americo-centric view, six top-level domains indicated to what type of organization the machine belonged. Thus, we ended up with the following list:

That setup was all fine and nice for starters, but as the number of machines on the Internet began to grow at an amazing rate, a more all-encompassing solution became necessary. The new top-level domains are based on countries, so each country has its own two-letter domain. Thus, the United Kingdom's top-level domain is uk, Sweden's is se, Japan's is jp, Australia's is au, and so on. Every now and then another country comes on the Internet, and I see a domain code that totally throws me, as Iceland's is code did the first time. The United States has this system, too; so, for example, The Well, a popular commercial service with links to the Internet, is well.sf.ca.us. Unfortunately, because so many sites already existed with the old domain names, it made no sense to change them. Thus, we have both types of top-level domain names here in the U.S., and you just have to live with it.

You may see a couple of other top-level domains on occasion, bitnet and uucp, such as in listserv@bitnic.bitnet or ace@tidbits.uucp. In both of these cases, the top-level domain indicates that the machine is on one of the alternative networks and may not exist directly on the Internet (otherwise, it would have a normal top-level domain such as com or uk). This setup isn't a big deal these days because so many machines exist on two networks that your email gets through just fine in most cases. In the past, though, few connections existed between the Internet and BITNET or Usenet, so getting mail through one of the existing gateways was more difficult. Keep in mind that because a machine whose name ends with bitnet or uucp is not usually on the Internet, you cannot use Telnet or FTP with it.

My current machine name, tidbits.com, is as simple as it gets: a machine name and a top-level domain. Many other addresses are more complex because other domains are in the middle. Think of an address such as cornella.cit.cornell.edu as one of those nested Russian dolls (see figure 6.1). The outermost doll is the top-level domain, the next few dolls are the mid-level domains, and, if you go all the way in, the final doll is the userid (which I'll explain soon enough).

Figure 6.1: The Russian doll approach to Internet addresses.


Mid-Level Domains


What do these mid-level domains represent? It's hard to say precisely, because the answer can vary a bit. The machine I used at Cornell, known as cornella.cit.cornell.edu, represents one way the mid-level domains have been handled. As a recap, the machine name is cornella, and the top-level domain is edu, because Cornell claims all those undergraduates are there to get an education. The cit after cornella is the department, Cornell Information Technologies, that runs the machine known as cornella. The next part, cornell, is obvious; it's the name of the overall organization to which CIT belongs. So, for this machine anyway, the hierarchy of dolls is, in order, machine name, department name, organization name, and organization type.

In the machine name for The Well, well.sf.ca.us, you see a geographic use of mid-level domains. In this case, well is the machine name, sf is the city name (San Francisco), ca is the state name (California), and us is the country code for the United States.

Mid-level domains spread the work around. Obviously, the Internet can't have machines with the same name; otherwise, chaos would erupt. But because the domain name system allows for mid-level domains, the administrators for those mid-level domains must make sure that everyone below them stays unique. In other words, I could actually name my machine cornella.com because that name is completely different from cornella.cit.cornell.edu (though why I'd want to, I don't know). And, if they wanted, the administrators at CIT could put a new machine on the net and call it tidbits.cit.cornell.edu without any trouble, for the same reason. More importantly, the administrators don't need to bother anyone else if they want to make that change. They control the cit domain, and as long as all the machines within that domain have unique names, there aren't any problems. Of course, someone has to watch the top-level domains because it's all too likely that two people may want tidbits.com as a machine name (but I've already got it, so they can't have it). That task is handled by the Internet Network Information Center, or InterNIC. As a user, you shouldn't have to worry about naming problems, because everyone should have a system administrator who knows who to talk to, and you need the cooperation of your provider anyway -- you can't set up a domain on your own.

There is yet another way to handle the mid-level domains, this time in terms of intermediate computers. Before I got my current address, I had a feed from a machine called halcyon, whose full name was halcyon.com. My machine name was tidbits.halcyon.com. In this case, tidbits was my machine name, halcyon was the machine through which all of my mail was routed, and com indicated that the connection was through a commercial organization. I realize that this example is a bit confusing, but I mention it because it's one way that you can pretend to have an Internet address when you really have only a UUCP connection (a different sort of connection that transfers only email and news). All my mail and news came in via UUCP through halcyon, so by including halcyon in my address, I created an Internet-style address.

The other way of pretending that a UUCP connection is a real Internet connection for address purposes is to have your host set up an MX record (where MX stands for Mail Exchange). An MX record is a pointer on several true Internet machines to your site. That's what I use now, but because tidbits.com is actually a UUCP site, theoretically you also can reach me by sending email to ace@tidbits.uucp. Mail sent that way isn't as quick or reliable, however.

NOTE: This means that you cannot FTP to tidbits.com, something which confuses people who don't notice that my FTP site is a different machine, called ftp.tidbits.com.


Machine Name


The next part of my machine name is the machine itself, tidbits. People use all sorts of machines, and because the system administrators often are a punchy, overworked lot, they tend to give machines silly names. Large organizations with more centralized control lean more toward thoroughly boring names, like the machine at Cornell, which was called cornella (as opposed to cornellc and cornelld and cornellf). One of the reasons for boring names is that in the early days, machines on BITNET had to have names with between six and eight characters. Coming up with a meaningful unique name within that restriction became increasingly difficult. Usenet doesn't put a limit on the length of names but requires that the first six characters be unique.

If you remember that machines often exist on the Internet as well as on one of these other networks, thereby blurring the distinctions, you'll see the problem. Internet machine names can be longer than BITNET or Usenet names, so any alternative connections may dictate what names are acceptable. Although multiple names are possible (another machine at Cornell was called crnlvax5 on BITNET and vax5 on the Internet), most machines have only one name. This convention makes life easier.

There is one caveat to the multiple name issue: Often, special services keep their names even when they move to different machines or even different organizations. Because of this situation, a machine that runs a service may have two names, one that goes with the machine normally and one that points solely at that service. For instance, the anonymous FTP site that I use to store all the software I talk about in this book is called ftp.tidbits.com. But in fact, it runs on a machine called ftp.halcyon.com, and I could move it to any other machine while still retaining the ftp.tidbits.com name. This situation is not a big deal one way or another.

NOTE: One way for companies to save money is to purchase a single computer that acts as a host for a myriad of services. Yet, it is becoming more and more common to have host names actually describe the service. For example, the conjungi.com domain has both FTP and World Wide Web services running on the same machine, which has an IP address of 199.165.221.12. Both ftp.conjungi.com and www.conjungi.com point to that same machine.

To summarize, you can have multiple domains in an address, and the further you go to the right, the more general they become, often ending in the country code. Conversely, the further you go to the left, the more specific the domains become, ending in the userid because that part of the address is the most specific. And so it's time to talk about the userid.


Userid


Now that you've looked at the machine name, you can move on to the userid or username, which identifies a specific user on a machine. Both terms are equally correct (with two exceptions -- the commercial online service GEnie and the FirstClass BBS software both treat userids and usernames separately) and commonly used. If you set up your own machine, or work with a sufficiently flexible provider, you can choose your own username. Choosing your own name is good because then your correspondents can more easily remember your address, assuming of course that you choose a userid that makes sense and is easy to type. If I made my address ferdinand-the-bull@tidbits.com, people who typed the address slightly wrong and had their mail bounced back to them would become irritated at me.

Internet userids cannot have spaces in them, so convention dictates that you replace any potential spaces with underscores, dashes, or dots, or omit them entirely. Other reasonable userids that I could use (but don't) include adam_engst@tidbits.com or adam-engst@tidbits.com or adam.engst@tidbits.com or adamengst@tidbits.com. However, all of these names are more difficult to type than ace@tidbits.com, and because I have good initials, I stick with them.

Unfortunately, there are a limited number of possible userids, especially at a large site. So Cornell, for instance, with its thousands of students and staff, has opted for a system of using initials plus one or more digits (because initials aren't all that unique, either -- in fact, I once asked for my initials as a userid on one of Cornell's mainframes and was told that ACE was a reserved word in that machine's operating system, though no one could tell me what it was reserved for).

Microsoft uses a different scheme yet: first name and last initial (using more than one initial to keep the userids unique). As Microsoft has grown, common names such as David have been used up, so the company has started other schemes such as first initial and last name. Why am I telling you this? Because knowing an organization's scheme can prove useful at times if you're trying to figure out how to send mail to someone at that organization, and so that I can note a societal quirk. At places like Microsoft where people use email so heavily, many folks refer to each other by email names exclusively. When my wife, Tonya, worked at Microsoft, she had a problem with her username, tonyae (first name and last initial) because it looked more like TonyAe than TonyaE to most people.

The real problem with assigned userids comes when the scheme is ludicrously random. Some universities work student ID numbers into the userid, for instance, and CompuServe userids are mere strings of digits like 72511,306. I believe the scheme has something to do with octal numbers or some such technoweenie hoo-hah. I don't speak octal or septal or any such nonsense, and as a result, I can never remember CompuServe userids.

Remember that email addresses point at an individual, but when you're using Telnet or FTP, no individual is involved. You simply want to connect to that machine, and you have to connect sans userid. This restriction may seem obvious, but it often trips people up until they get used to it. For example, it seems that you could just FTP to anonymous@space.alien.com. The system doesn't work that way, though, and you FTP to space.alien.com, and once there, log in as anonymous. More about FTP in later chapters.


Punctuation


Enough about userids. What about all this punctuation? Better known as Shift-2 (on U.S. keyboards anyway), the @ symbol came into use, I imagine, because it's a single character that generally means "at" in traditional usage. The @ symbol is generally universal for Internet email, but not all types of networks have always used it. For instance, some BITNET machines once required you to spell out the word, as in the command TELL LISTSERV AT BITNIC HELP. Luckily, almost everything uses the @ symbol with no spaces these days, which reduces four characters to one, and probably has saved untold person-hours' worth of typing over the years.

As long as you're learning about special characters, look at the dot. It is, of course, the period character on the keyboard, and it serves to separate the domains in the address. For various reasons unknown to me, the periods have become universally known as dots in the context of addresses. When you tell someone your email address over the phone, you say (or rather I'd say because it's my address), "My email address is ace at tidbits dot com." The other person must know that "at" equals the @ symbol and that "dot" equals the period. If he's unsure, explain yourself.


Alternative Addresses


You may see two other styles of addressing mail on the Internet, both of which work to sites that aren't actually on the Internet itself. The first, and older, of the two is called bang addressing. It was born in the early days when there were relatively few machines using UUCP. Not every machine knew how to reach every other machine, so the trick was to get the mail out to a machine that knew about a machine that knew about a machine that knew about your machine. Talk about a friend of a friend! So, you could once have sent email to an address that looked like uunet!nwnexus!caladan!tidbits!ace. This address would have bounced the mail from uunet to nwnexus to caladan to tidbits and finally to my userid on tidbits. This approach assumes that your machine knows about the machine uunet (run by the commercial provider UUNET) and that all of the machines in the middle are up and running. All the exclamation points are called "bangs," appropriately enough, I suppose. On the whole, this style of addressing is slow and unreliable these days, but if you use a machine that speaks UUCP, you can occasionally use it to your advantage. For instance, every now and then, I try to send email to a machine that my UUCP host, nwnexus.wa.com, for some reason can't reach. By bang-routing the mail appropriately, I can make another Internet machine try to send the mail out, sometimes with greater success.

The other sort of special addressing is another way to get around the fact that your machine, or even your network, isn't connected to the Internet as such. In this case, you must provide two addresses: one to get to the machine that feeds your machine, and one to get to your machine. The problem here is that Internet addresses cannot have more than one @ symbol in them. You can replace the first @ symbol with a % symbol, and the mailers then try to translate the address properly. My old address, ace@tidbits.halcyon.com, could also have been ace%tidbits.uucp@halcyon.com. These tricks are ugly and awkward, but sometimes necessary. Luckily, as the Internet grows and standardizes, you need fewer and fewer of these addressing tricks.


Electronic Mail


Electronic mail is the most pervasive application on the Internet, and for good reason. What better way to communicate with so many people so quickly? But to use and understand email properly, I must show you how it's constructed, the relevant social mores and pitfalls, and the uses to which you can put it.


Email Construction


What makes up an email message? Most messages have two important parts, with a third part that doesn't have to appear. The first two parts are the header and the body of the message, and the third, nonessential part is the signature. For simplicity's sake, let's work backward.


Signature

Many email programs, including Eudora, which I've included on the disk, provide a facility for creating signatures. Signatures are just about what you'd expect -- some text that goes at the bottom of every message you send. Most people include their names (real or pretend) in their signatures; it's considered good form to include your preferred email address in your signature as well, just in case the address in the header isn't useful for some reason or another. After you get past the basics of name and email address, however, you can put anything you like in your signature. Many people lean toward clever quotations or manage to express some sporting partisanship of their favorite team, usually with an erudite "Go Weasels '95" or some such. It's hard to grunt in ASCII. I prefer clever quotations, especially so if changed once per day -- not that I have time or energy to think them up or type them in every day. Here is a signature that must have taken some time to create, because all the lines and dashes had to be typed in the right place:

/=====================================================================\
||   _                                                                ||
||  *  \          Sorry, a signature error has occurred.              ||
||     _|_                                                            ||
||   /     \      /============\          /===========\               ||
||  |       |     |    Resume   |         |   Restart |               ||
||   \ ___ /      \------------/          \----|\----/                ||
||                                             |  \                   ||
 \=============================================|   _\==================/
                                               |/\ \
                                                  \_\
Courtesy of A. Marsh Gardiner, gardin@harvarda.harvard.edu

Many people also use signatures to disclaim their messages. The signature acts as a disclaimer, usually stating that the opinions and facts stated in the preceding message have no relationship to the organization paying for the account or employing the individual. Disclaimers are important online because readers have no context in which to take postings. If Ferdinand the Bull posts a glowing review of specific species of cork tree, for example, he should also note at the bottom of his review that he is a paid consultant of Corking Good Times International and is therefore biased. More common are glowing reviews from users who "have no relationship with Corking Good Times International, other than as a satisfied customer." Disclaimers also serve to ensure that no one takes the words of a single employee as the policy of the entire organization. Marketing departments hate that. "But Joe said online that Microsoft was going to give free copies of Flight Simulator to everyone whose birthday falls on the second Tuesday of odd months this year." "Yeah, sure buddy."

One warning, though. Mailing lists that are published as digests -- that is, lists in which a moderator collects the day's messages and concatenates them into a single file -- frown on or even reject postings with multiple-line signatures. This suggestion makes sense, if you think about it. A large digest file can have 50 messages in it, and if every person has a four-line signature, the digest suddenly becomes 200 lines longer than necessary.


Body

What you put in the body of your letter is your business. I can recommend several practices, however. First, get in the habit of pressing the Enter key twice between paragraphs to insert a blank line between paragraphs; that additional white space makes email messages much easier to read. Nothing is harder to read than page after page of unbroken text.

Actually, something is worse than unbroken text, and that's page after page of unbroken text in capital letters. DON'T USE ALL CAPS BECAUSE IT LOOKS LIKE YOU'RE SHOUTING! No one uses all capital letters for long because everyone hates reading it and will tell you, nicely the first time, to stop.

I suppose now is a good time to talk about manners in terms of the sorts of things you should consider when writing email. Email differs from normal mail in many ways. Think of the difference between a short note to your mother, a memo at work, and a formal business letter. Most email falls somewhere between the short note and the memo, and seldom do you ever see an email message with the formality and rigidity of a business letter. Although I'm giving this information in the context of email, it applies equally as well to postings on Usenet; if you like, reread this section, substituting "posting" for "email" everywhere.

How do you start these messages? In many ways, email acts as the great equalizer. Most of the time, you know someone's name and email address when you send email to him or her, nothing more. joeschmoe@alien.com could be a janitor, a summer student intern, or the president of a Fortune 500 firm. Similarly, any address ending in edu can link to a student, some member of the staff, a world-renowned professor of underwater basket weaving, or the president of the university. You have no way of knowing, unless that fact somehow comes up in conversation.

Most people react to this lack of context by treating everyone with the same level of polite, but informal, respect. Seldom do people use their titles, so equally seldom do correspondents use those titles in email. Everyone is on a first-name basis. I once took a class with the astronomer and science advocate Carl Sagan while I was at Cornell, and the first day of class, an awed undergraduate (but braver than the rest of us) asked, "How should we address you, Dr. Sagan?" He replied, "You can call me Mr. Sagan, Professor Sagan, Dr. Sagan, or Herr Doktor Professor Sagan." He paused, "...or you can call me Carl." Carl it was then, and the class benefited greatly from that level of informality, just as the Internet does.

In light of this knowledge, when I started using email I thought about the differences between email and paper mail (hereafter called by its true name in the Internet community, snail mail). The standard salutation of "Dear" sounds inappropriately formal and stilted to my ears (apologies to Miss Manners). Since email more closely resembles spoken communication than written, I opted for the less formal and more colloquial "Hi," which has served me well. Some people forego the salutation completely, relying solely on the first name, but that approach feels abrupt to me, as if someone called me on the phone and stated my name without a "Hello" or so much as a questioning tone. Do what you like, though; no one has laid down rules on this matter.

What you say in the letter itself deserves more thought, however. Because email is so quick and it's so easy to respond without thinking, many people often reply hastily and less politely than they would had they taken a moment to consider. Remember, you want to achieve a certain effect with an email message, just as you do with any form of communication. If you simply whack your first thoughts into a message, it probably won't properly convey your true feelings. If you want information from someone, phrasing your request politely only increases your chances of getting that information, and if you wish to comment on someone else's words, doing so in a reasoned and level-headed manner ensures that that person won't immediately consider you a serious jerk.

You also must remember that informal though email may be, it lacks most of the nonverbal parts of communication that we seldom consider in normal speech. All inflection, body language, and facial expressions disappear, and it doesn't help one whit if you make them while composing the letter. Email is ASCII text only, and only two ways exist to convey inflections such as sarcasm or irony that would be obvious in spoken conversation. First, polish your writing skills. There is no substitute for clear and coherent writing. Many people find writing difficult, but I recommend that you don't think of composing email as writing, but as speaking to someone who sees your words but cannot see or hear you. Most people who claim they can't write have little trouble making themselves understood when speaking.

Second, utilize smileys, or as they are sometimes known, emoticons. Smileys are strings of punctuation characters meant to be viewed by tilting your head (which is usually easier than tilting your monitor) to the side. (If they still look wrong, try tilting your head to the other side.) People have come up with literally hundreds of different smileys, and you can find lists containing them on the Internet. Seth Godin has even compiled many of them into a book, The Smiley Dictionary, published by Peachpit Press (and there is at least one other book, published by O'Reilly & Associates, on the same somewhat silly topic). I take the view that only two, or maybe three, smileys are at all useful in normal email. The first is the happy face :-), which implies that what you just said was meant as humor or at least shouldn't be taken too seriously. I often use it to imply that I would have said that bit with a smile. A variant of the happy face uses the semicolon instead of the colon ;-) and (because of the wink) implies that the preceding sentence was somewhat sarcastic or ironic. Finally, the frowning face :-( implies that you aren't happy about whatever you just said.

I use smileys relatively heavily in email, where I don't have time to craft each letter as carefully as I would like. I miss not being able to use them (I could, but no one would understand) in snail mail occasionally, and I actively try to avoid using them in TidBITS, favoring instead words that convey my feelings without the smiley crutch. When in doubt, use smileys. If I say in email, "Well, that was a stupid thing to do," the message is much more offensive than if I say, "Well, that was a stupid thing to do. :-)" Believe me, it is.

I may have given the impression that the Internet is this utopia where everyone always behaves nicely and ne'er is heard a discouraging word. Unfortunately, that's not so, and in reality you see plenty of flaming on the nets. Flaming happens when, in a PC discussion list, you innocently mention that you like your Macintosh, and seventeen people immediately jump on you in email and pummel you within an inch of your electronic life for saying something so obviously stupid and incorrect when everyone knows that only weenies, wimps, and little wusses use those toy Macintosh computers, which are good only for paperweights -- and expensive paperweights at that, because you can buy three completely configured, top-of-the-line Pentium-based PCs for the same price as a used Macintosh Classic -- without a hard drive. And by the way, did I mention that your mother wears combat boots and your father wears ballet slippers? :-)

The preceding paragraph is flaming (except for the smiley, which I threw in to indicate that I was kidding about your parents' footwear), and if you must respond to an inflammatory message, which I don't recommend, do it in email. No one else wants to read your flames. Think before you lower yourself to flaming; it never solves anything. I have found in almost every case that replying calmly and clearly embarrasses anyone (assuming that person is normal and rational, which is not always a good assumption) so thoroughly that he or she immediately apologizes for being such a jerk. And yes, I know how hard it is not to just tee off on someone. Restrain yourself and rest assured that everyone who sees your restraint will think more highly of you for it.

NOTE: My favorite method of responding to long and vitriolic flames is to send back a single-line message reading, "You may be right. -Engst." I heard about this technique in an interview with Tom Brokaw, I think, and it works extremely well, confusing the recipient to no end and generally putting a stop to the flaming.

Often, people flame companies or large organizations that are doing stupid things. Various governments are favorite, though slow-moving and not very challenging, targets. This sort of flaming is more acceptable, although you may start a flame war if other people don't share your opinions on some major topic, such as whether Windows is better than a Mac. As a spectator, you may enjoy watching the occasional flame war, as I do, but again, they never solve anything, and they waste a huge amount of bandwidth (which is composed of transmission time, people time, and disk storage throughout the world).

NOTE: Actually, I've decided that in some respects a certain amount of flaming can be positive, because there are only three ways of ending an argument on the Internet: Agree to disagree, win your opponent over to your side, or stop from exhaustion. In no case does anyone get knifed or shot, and if participating in a flame war lets others blow off some steam, that's better than their going home and abusing their children. Everything is relative.

Keep in mind that no matter what you say, it may not be private. Always assume that gobs of people can and do read every message you send. These people include your coworkers, your system administrator, system administrators on other machines through which your email travels, random pimply-faced fools who like poking around in other people's email, and last, but certainly not least, the government, probably in the form of the CIA, FBI, Secret Service, or National Security Agency. I realize this sounds alarming, and it is most certainly not completely true, but the possibility exists for all of these people to read your email.

In reality, email carries significant privacy, but because you have no guarantee of that privacy, you should stay aware of what you're saying. This suggestion is especially true if you use email at work, where you could lose your job over ill-considered remarks in email. It's always a good idea to check on your employer's policy about email privacy.

NOTE: There have been a number of court cases regarding ownership of email (Does it belong to you? Does it belong to your employer?) at large companies like Epson and Borland, and as far as I know the issue has yet to be settled for good. Since it comes down to a matter of their lawyers being meaner than your lawyers, don't push it.

This lack of privacy carries over to mailing lists and Usenet news (where you want people to read your messages, but you may not want the government to keep tabs on your postings). In fact, some people have gone so far as to include inflammatory keywords in otherwise innocuous postings, just to trip up the rumored government computers scanning for terrorists, assassins, space aliens, nudists, vegetarians, people who like broccoli, and other possible undesirables.

I almost forgot about attachments. Many people like to send each other files in email, and although you can do this by simply encoding the file as MIME or uucode (which I'll talk about in a few chapters) and pasting it into the body of the message, modern email programs instead enable you to merely attach the file to the message with a specific command.

That's all fine and nice if your recipient also uses an email program that knows how to deal with the attachment, but if not, your friend sees the file, usually encoded in MIME or uucode, at the end of the message in the body (but before the signature). Large email files can be a pain to deal with unless your email program supports attachments.


Header

Okay, I admit it; I've been avoiding talking about the header so far. I did so because the message header generally looks like a lot of gobbledygook to the novice user, and in fact, it should. The header exists for the computers, not for the users, and you're lucky that you can read it as well as you can. In some programs you can see an abbreviated header, which is good, and in some you can ignore the header altogether, which can be a little dangerous because it may not be clear who receives a reply to that message.

As much as the header is technoweenie information that exists primarily for the computers to route mail to you, I recommend that you choose an abbreviated header display if you have one. An abbreviated header shows you information that can be useful, such as who sent the email to you, when it was sent, what the subject of the message is, and to whom it was sent (not always only you -- it's easy to send the same piece of email to multiple people).

Take a look at a typical header, culled just now from one of my archived pieces of email (see figure 6.2).

Figure 6.2: A sample header.

Let's take a spin through all the different parts of a typical header in a random piece of email, explaining each one along the way and starting with the glop at the top.

From TC.Cornell.EDU!baka!mha Mon Jul 19 07:08:08 1993
Received: by tidbits.com (uA-1.6v2); Mon, 19 Jul 93 11:04:17 PDT
Received: from THEORY.TC.CORNELL.EDU by nwnexus.wa.com with SMTP id AA18636
  (5.65c/IDA-1.4.4 for ); Mon, 19 Jul 1993 08:32:37 -0700
Received: from baka.UUCP by theory.TC.Cornell.EDU with UUCP id AA02180
  (5.65c/IDA-1.4.4 for ace@tidbits.com); Mon, 19 Jul 1993 11:32:32 -0400
Received: from BAKA (QM 2.6) by baka.ithaca.ny.us (UMCP\QM 2.1.3)
  id AA05891; Mon, 19 Jul 1993 11:32:36 EDT

The preceding lines are merely routing information that tell you where a message went and when it arrived there. You have to read it backwards to follow the flow, so this message traveled from a groupware mail server at BAKA Computers to the UMCP Bridge (baka.ithaca.ny.us), which acts as a gateway for mail messages destined for the Internet. From there it traveled to Cornell's Theory Center, theory.tc.cornell.edu, and from the Theory Center, the message went almost instantly to nwnexus.wa.com, which is my Internet host, and then several hours later to my machine, tidbits.com.

You generally can ignore this part of the header, although it can be fun to see where your message went at times. If your message bounces -- that is, if it fails to go through for some reason and comes back to you -- looking at this part in the header helps you determine how far it got and which machine didn't like it. More about how to handle bounces in a bit.

Message-Id: <00192.2825926356.5891@baka.ithaca.ny.us>

The Message-Id line uniquely identifies each message. It's generally of no use at all, and although it looks like an email address, it's not.

NOTE: Only once have I found the Message-Id information useful. For some reason, one of my hosts was duplicating some files that went out, and often the only difference between the messages was that at a certain point they started having different ids. Unfortunately, I never figured out how to solve the problem; I just switched to another host.

Organization: BAKA Computers Inc.
The Organization line identifies the organization of the sender, as you might suspect. Individuals often have a good time with this line because they don't have real organizations to put down and can thus include fake organizations like "Our Lady of the Vacant Lot Enterprises."
To: ace@tidbits.com (Adam C. Engst),
        Rick_Sutcliffe@faith.twu.ca (Rick Sutcliffe)
The To line can have one or more entries, and it specifies, reasonably enough, who the mail was sent to. The recipient may not be you because you might be the person mentioned in the Cc line or even the Bcc line (which you don't see because Bcc stands for Blind Carbon Copy). Most of the time you see a name before or after the email address, but it's not mandatory.
From: mha@baka.ithaca.ny.us (Mark Anbinder)
The From: line indicates who sent the email and is self-explanatory.

Date: Mon, 19 Jul 1993 11:08:08 EDT

The Date line lists the date that the email was sent originally, not the time you received it or read it, and should usually indicate the time zone in which the sender lives. Even then I find it difficult to keep track of what time it is in other countries. Do you know the local time in Turkey right now? Some messages use a number, either positive or negative, and the acronym GMT, which stands for Greenwich Mean Time. Unfortunately, this use requires that you know what time it is in Greenwich, England, and that you know how your local daylight savings time is involved. Date lines usually just confuse me.

Subject: Terminal Compromise

The Subject line should give a clear and concise description of the contents of the email message. In practice, this description often isn't true, especially as a discussion proceeds, changing topics occasionally, with everyone using the reply function to keep the Subject the same. After a while the Subject line bears no resemblance to the contents of the message, at which point it's time to change the line.

Cc: werner@rascal.ics.utexas.edu (Werner Uhrig)

The Cc line lists all the people who received copies of the message. There is no functional difference from being on the To line or the Cc line, but in theory if you receive only a copy, the message shouldn't concern you as much. In practice I notice little difference.

An abbreviated header probably just shows the last five lines and avoids displaying the routing information at the top of the header.

You also may see other lines in the header that identify which program mailed the message, to whom the recipients should reply, the type of data included in the message, how the data is encoded, and that sort of thing. In general, you don't have to worry about anything in the header very much, but it's worth taking a look every now and then to see if you can tell what's going on in there.

NOTE: If you've had Internet mail at your office for months and have never seen a header, don't despair. Many electronic mail gateways eliminate much of the header information and extract only the important parts (i.e., sender, recipient, date, etc.) when they are passed into the new mail system. While this may seem unfair and can sometimes cause confusion, it does cut down on the amount of disk space a message takes up -- which is often a concern for MIS departments.


Bounces

In a perfect world, all email would get through to its destination quickly and reliably. But just as with snail mail, which can take one to five days to appear, and which sometimes never appears at all, email isn't perfect, and sometimes will bounce back to you. Some of the time the machine that bounced the mail back to you will give you a hint as to what went wrong, but more often you're on your own.

The most common reason for a bounced message is a typo somewhere in the address. That's one reason that short email addresses are good -- they're easier to type and thus less likely to be mistyped. The first thing to do when you get a bounce is to look through the header of the original message (the full headers are usually returned to you) and make sure you typed the address properly. Everyone makes this mistake on occasion.

A common error message in bounced email is "User unknown." This means that the email arrived at the proper machine, which searched through its list of users and decided that it didn't have a user with the name you used. Again, this is most commonly due to a typo in the userid, although sometimes there are problems on the destination machine that have caused it to forget about a user, possibly temporarily. After checking the address, try resending the message, especially if you've gotten mail through to that address before.

Along with unknown users, you may see error messages complaining about "Host unknown." This is a more serious error that's more difficult to work around if it's not simply a typo. The basic problem is that for some reason one machine, perhaps your host machine or perhaps one further along in the path to the destination, was unable to contact the destination machine. There's not much you can do in this case other than try again a little later, in the hope that the machine you're mailing to has come back up.

One thing to watch out for is that sometimes the header provides an incorrect address to your email program, but the person includes the proper one in their signature. If you have trouble replying to a message, and the address you're replying to is different from an address listed in the signature, try using the signature address instead.

NOTE: I find this trick especially useful if the address in the signature is simple, whereas the address from the header is long and convoluted. Simple addresses seem to be more reliable, on the whole, although that's not a hard and fast rule.


Using Email Programs


All email programs share some basic features that you need in order to quickly and efficiently read, reply to, and store your email. However, after these basic commonalities, the differences between programs mount quickly, so I concentrate on those differences when I talk about each program later in the book. For the moment, though, look at what an email program must do at a minimum.


Reading Email

An email program should enable you to display and scroll through an email message easily. Because you're using Windows, you should be able to do all the standard Windows things to text in a window, such as copying and pasting into a different program, resizing the window to display more text, selecting all the text with a single command, and that sort of thing.

Although you usually can choose the font and size in which you view messages in Windows email programs, I recommend that you stick to a monospaced font such as Courier New. People on the Internet must format tables and graphics with spaces, and monospaced fonts such as Courier New display these tables and graphics properly. Proportionally spaced fonts such as Times New Roman and Arial don't work as well because the characters in these fonts can have different widths, with a lowercase i being thinner than an uppercase W. Few of these features are generally available with a Unix mail program; that's one of the major advantages of using Windows.

NOTE: Some email or communications programs come with special monospaced fonts that are supposedly easier to read than the standard Courier New. It's up to you to decide if you like them better.


Navigating and Managing Email

Another important feature of an email program is the manner in which it enables you to move between messages, save messages in different mailboxes, and delete unwanted messages after you've read them. Most email programs display a list of the messages in an In Box area, and some indicate which messages you have already read, replied to, or saved to disk. Opening a message usually opens a new window to display the message, and sometimes closing the window (with or without deleting the current message) opens the next unread message, a nice feature for those who receive a great deal of mail. Being able to sort the list of messages is useful on occasion, and you should be able to select multiple messages at once to move them to another mailbox or delete them.

Speaking of multiple mailboxes, all email programs should support them, though unfortunately not all do. Most people want to save some of the messages they receive, so a program should allow you to create your own mailboxes for filing away messages on different topics. Of course, if you can create a new mailbox, the email program should enable you to do everything you can do in your In Box to the messages stored in a personal mailbox.

While you're managing your email, you will undoubtedly want to delete many of the messages you receive. This area may seem straightforward, but the better email programs enable you to remove a file without actually immediately deleting it. The easier it is to delete a message (and it should be very easy since you're likely to eventually want to delete most of the mail you receive), the more likely you will eventually delete something accidentally. If the email program deletes immediately, your message is toast. The other advantage of the two-stage (where a message is put in a holding tank before being deleted later) or a delayed delete (where a message is marked as being deleted but isn't actually deleted until you close the mailbox) is that you then don't have to put up with an annoying confirmation dialog every time you delete a message.

Some of your messages may, in fact, contain programs or other files that you want to save to a normal file. A few email programs automatically detect attachments encoded in certain formats (more about file formats later, when I talk about FTP and other ways of receiving files) and decode such messages on their own. But one way or another, you need a simple way to save the message you're looking at without copying and pasting the entire thing into a word processor.


Replying to Email

Much of the mail you receive requires a reply of some sort, so an email program should make replying extremely easy, either with a command key shortcut or a single click on an icon. An email program should also facilitate quoting the original message, or prefixing each line with one or two special characters, usually a greater-than symbol and a space. Using quoting, you can easily include some of the message you're replying to so that the recipient has some context to know what you're talking about. A nice feature is the ability to select just a certain part of the original message and have the email program quote only that selected text in the reply and ignore the rest of the original message (see figure 6.3).

Figure 6.3: Original text and quoted text.

Because an email message may have originally been sent to several people, an email program should give you the option of replying only to the sender or to all the people to whom the message originally went. At the same time, it ideally should make sure that you see the salient lines in the header. I've spawned a couple of embarrassing scenes by forwarding a message to a friend, and when my friend replied to me, his email program saw that mine had included the original message's address in the Reply-To line in the header. So his reply, instead of going just to me, went back to the sender, which was a mailing list that went to thousands of people. Oops! Luckily, I didn't say anything embarrassing and neither did he, so we were safe, but that's a good example of how two computer professionals who know better could have been thoroughly embarrassed in public. Think of this situation as standing up in a crowded restaurant and shouting loudly that your underwear has holes. You get the idea.

More powerful email programs provide features that automatically can mark or reply to email based on the contents of the header or the body of the incoming message. They often generalize these features so that you can essentially run a mailserver, which sends out requested information automatically via email. You can also use this sort of feature to run a simple mailing list, which takes a message to a certain local address and forwards it automatically to a list of subscribers.

NOTE: To answer a frequently asked question on the nets, I know of no Windows program that enables you to run a full-fledged mailing list, complete with automated subscription and sign off features. Maybe someday soon, but until then you need a Unix machine at minimum. (See later discussion for information on the three main mailing list managers.)


New Email

Both when replying to email and when creating new mail, an email program should provide all the features you're used to when you're writing in a Windows word processor. In my opinion (which is by no means universal), the standard editors in the character-based Unix world stink (yeah, I know those are fighting words), and I spend so much time writing and editing my email that I couldn't possibly put up with anything other than a decent Windows editor. However, because every email program implements text entry and editing on its own, none of them compare to a full-fledged word processor.

I may be odd in this respect, but I think that any email program should make it easy to save a copy of everything you write, preferably automatically. I send more email than most people, often more than 1,000 messages per month, but I like to be able to go back on occasion and see what I said, forward a message to someone who lost it, or just browse through the thoughts that appeared in my writings at that time. Why bother to keep a diary if you're writing about most of what happens in your life in email to friends?

Finally, whenever you create email, your email program should enable you to send the mail to a nickname or alias, which is merely another, easier-to-remember form of an email address. So instead of typing ferdinand-the-bull@cork.tree.com every time you want to send that person email, you can type the shorter Bull. Be conservative with nicknames because it's easy to create more than you can easily remember, at which point they don't particularly help any more. Defining nicknames for everyone you might ever send email to is a waste of time; settle for defining a nickname only after you decide that you are likely to send that person email frequently.

NOTE: You want to be slightly careful with nicknames, because occasionally the recipient sees the nickname as well as the address. A friend once created a nickname "DA BOSS" for our supervisor, who thought it was funny when she saw it. I could think of some less humorous situations.


Finding People


Now you know how an email program should work and how to read email addresses when you see them littering up this book and the nets in general. But how do you find people to write to? Finding people to write to depends on what you're looking for. Hmm? What does he mean by that?

Assume that there are two types of people, those you already know and those you haven't yet met. The latter group makes up most of the world, and in some respects are the easiest to find and talk to because you don't really care who specifically you end up talking to. After all, you don't know any more about one stranger over another, so who you talk to makes no difference.


Friends

When I first started using the networks way back when, few of my friends had accounts, and of them, only my best friend from high school ever managed to send me email more than once. I think I got a total of three messages from him. I tried to convince them, but I just couldn't get my friends to use email. Finally, I decided they all truly hated me (a logical conclusion for a 17-year-old college freshman) and gave up on them. My ego has recovered some since then, because I've found that convincing people to start using email just to talk to me is almost impossible. This argument worked with my parents, after a while, especially after my sister also started using email heavily at Cornell. But otherwise? I can't think of a single person whom I've convinced to use email for my sake. The moral of the story is that you should assume that you can talk only to people who already use email.

Okay, so once past that reality check, how do you find the address of someone who you know uses email? The simplest and most effective method seldom occurs to many net denizens -- use the telephone and ask them. This method, low-tech though it may be, has the advantage of being quick, accurate, and easy. Of course, it does ruin the surprise value of that first email note. Such is life. You do need to know your friend's telephone number, or failing that, her address so you can call the all-knowing information computers at the phone company. If you don't even know where your friend lives, she may be trying to hide from you anyway after that ugly incident a while back.

"Aha!" you say, "If the all-knowing phone company computers can give me my friend's telephone number, aren't there all-knowing computers on the Internet that can give me my friend's email address?" Nice try, and good question, but the answer is, unfortunately, maybe. Some computers know what users they support, and you can find some information via services called Finger, Whois, X.500, Knowbot, and various others, but that information doesn't help unless you already know what machine to search. Several attempts have been made at linking various directory services on different machines, but I've never found them in the slightest bit useful. The problem is twofold. First, hooking a local directory of users to an Internet-wide directory requires some effort and certain standards, and inertia being what it is, that effort isn't always made and the standards don't exist. Second, many organizations shield their users from the outside world for reasons of security and privacy. These shields also make it difficult to determine how many people actually use the Internet because one domain name may have two users, like tidbits.com, or many thousands of users, like microsoft.com.

NOTE: Frankly, because I find these services so completely useless, I'm not going to bother to discuss them further. That said, if you crave some frustration, go to the University of Minnesota's Gopher server at gopher.tc.umn.edu, select Phone Books, and then check out the various different options available for searching for Internet email addresses. If you know the organization in question, and they have a Phone Book server, that's the best start -- otherwise you're on your own. The main thing you miss via the Gopher route is the Knowbot Information Service -- to access it, telnet to info.cnri.reston.va.us and type help to see the possible commands.


Acquaintances

As I said earlier in this chapter, finding new friends is easy on the Internet. You don't know people beforehand, so communicating with them in a discussion list via email or news requires nothing in terms of opening lines or trivial small talk about the fallibility of weather forecasters. If you have something to contribute to a discussion, or perhaps if you merely want to make a private comment to one of the people in the discussion, meeting him is as easy as replying to his message. Whether that first contact grows beyond a one-time message depends on many variables, but with so many people, finding correspondents on the net doesn't take long.

As much as meeting people may be easy, finding them again after some time often proves more difficult. You may not remember where a person lives, if you ever knew, and if it's in the United States at all; you probably don't know his telephone number; and frankly, you may not even remember how to spell his name. And yet, all too often I've had long, involved conversations that eventually trail off after several weeks or months, and then I don't hear from that person again. If I haven't saved a message (which contains the all-important email address in the header) or recorded his email address somewhere, I have to hope that my friend has better organizational systems than I do.

I suggest that you figure out some way to keep track of your correspondents' email addresses. Nickname features work well although they may prove unwieldy as a storage mechanism later on. If that's true, I recommend using a standard database or address book program that can handle extra fields for email addresses. This advice may sound obvious, but I can't tell you how many times I've lost an address that I wanted several months later. These days I keep a copy of every piece of email I send, in part so I can search that file, large though it may be, for email addresses that have escaped my short-term memory.


Mailing Lists


There's no accounting for taste, and similarly, there's no accounting for different interests. I may be interested in electronic publishing, tropical fish, and competitive distance running, whereas the next person might favor The Simpsons, aviation, and Irish culture. As a result, discussion groups have sprung up around almost every imaginable topic, and if your area of interest isn't represented, it's not too difficult to start your own group. These groups take two forms: mailing lists and Usenet newsgroups. I talk more about Usenet in the next chapter; for now I'll concentrate on mailing lists.

The beauty of mailing lists is that they cover specific topics and they come straight to you, without any extra work on your part. If you find yourself interested in a topic, you can subscribe to the appropriate mailing list, and all the traffic comes directly to your electronic mailbox. This system makes participating in many mailing lists easy, even if you have only email access to the Internet; Usenet access may require more money and effort. Luckily for those of you who cannot get Usenet access, many mailing lists and newsgroups mirror each other.

Mailing lists have several other advantages over Usenet news. Email is ubiquitous on the Internet, whereas access to news is far less common (although certainly widespread). Because of the way Usenet news propagates throughout the nets, mailing lists often arrive faster than any given posting in a newsgroup might. Because mailing lists arrive in your electronic mailbox, they may seem less intimidating than large newsgroups with many participants. And frankly, many of us who lead busy lives find mailing lists easier to keep up with because we don't have to run another program to read the list, whereas reading news always requires leaving that ubiquitous email program and running a newsreader.

There are a number of programs that operate mailing lists, the most well-known of which are LISTSERV, ListProcessor, and Majordomo. They all support similar commands; I'll get into those in a moment. LISTSERV is a commercial program from Eric Thomas of LSoft and currently requires an IBM mainframe running VM/CMS (although versions for VMS, Unix, and Windows NT are in the works). The Unix-based ListProcessor comes from Anastasios Kotsikonas and is now owned by CREN (remember them from chapter 4?). The Unix-based Majordomo is free as far as I can tell.

There are also many mailing lists that are run through hacks to the Unix mailer software -- these generally require some sort of human intervention for subscribing and signing off, although sometimes they use non-standard commands that do the same thing. Have I mentioned yet that I dislike programs that don't work in standard ways? They make life even more confusing than it already is.

NOTE: You may wonder why LISTSERV doesn't have an E at the end and why it is spelled with all capitals. LISTSERV software has existed for some time on IBM mainframes that run the VM/CMS operating system. This operating system limits userids to eight characters (hence the missing E), and because the operating system itself was not case sensitive, all commands and program names have traditionally been typed in uppercase only. The name also may have had something to do with early computer terminals not supporting lowercase, but I can't prove that theory. Just believe me -- by convention, LISTSERVs are always addressed in the uppercase, although it doesn't matter any more.

Along with the different mailing list manager programs, you may have to deal with two other variables related to mailing lists -- moderation and digests. Each of these possibilities slightly changes how you interact with the list, so let's look at each in turn and then go over the basics of using the list manager software as a subscriber.


Moderated vs. Unmoderated

I suspect many mailing lists started out unmoderated, which means that anyone was able to send a message on any topic (whether or not it was appropriate to the group) to the list. The list software then distributed that message to the entire list. You see the problem already -- no one wants to read a bunch of messages that have nothing to do with the topic or discussion at hand. Similarly, if a discussion is spinning out of control and turning into a flame war, it's just a waste of time for many people.

Thus was born the concept of the moderated mailing list. To stem inappropriate postings, a moderator reads all the postings before they go out to the group at large and decides which are appropriate. Moderated groups tend to have less traffic, and the messages that go through are guaranteed by the moderator to have some worth. This system is good.

NOTE: The Info-IBMPC Digest is a prominent example of a moderated group in the IBM PC world.

On the downside, moderated groups occasionally run into sticky issues of censorship because the moderator may not always represent the views of the majority of the readers. Moderator positions are volunteer only; I've never heard of a mailing list that elected a moderator, although it's certainly possible, particularly among lists that carry traffic associated with a professional organization.

I see no reason to choose to read or not read a mailing list based on its moderation until you've spent a while seeing what goes on in the group. I subscribe to various lists, some moderated, some not, and on the whole, both have their place. Keep in mind, though, that if you post to a moderated list, the moderator may reject your posting. Don't feel bad, but do ask why so that your future submissions stand a better chance of reaching the rest of the group. On the other hand, when posting to an unmoderated group, try to stick to appropriate topics because people hate hearing about how you like your new car in a list devoted to potbellied pigs. Too many misdirected postings to a list, and the list members may start agitating for a moderator to limit the discussion.


Individual Messages vs. Digests

When the number of messages in a mailing list increases to a certain level, many lists consider creating a digest version of the list. A digest is simply a single message that contains all the individual messages concatenated in a specific way. Why bother with a digest? Depending on how your email program works, you might find it awkward to receive and read as many as 30 messages a day, especially if your email service, such as Prodigy, charges you a per-message fee to receive email. Just think how many messages you may have waiting after a week of vacation. If the messages are sent in digest form, a mailing list becomes easier to handle for some people because you get one big message instead of lots of little messages.

Unfortunately, digests have problems too. Some email gateways to commercial services limit the size of incoming email messages. Thus, digest mailing lists like the Info-IBMPC Digest can range in size from 30K to over 100K, so very few issues of the digest sneak through the gateways with size limitations. In addition, you may find it easier to read (or skip through) small individual messages, whereas scrolling through a 100K file can take quite a bit of time and be extremely awkward with some email programs. To add to the complication, certain email programs can break up a digest into its individual messages for easier viewing. I'm talking the email equivalent of digestive enzymes here.

You must decide for yourself whether a digest is easier or harder to work with, but only with some groups do you have any choice. The LISTSERV and ListProcessor software sometimes provide an option that you can set to switch your subscription to a mailing list from individual messages to a single, usually daily, digest. I don't believe you can toggle this option for Majordomo-based lists, but Majordomo list administrators can set up a separate list that sends out a digest -- you would simply subscribe to the separate (digest) list instead. These separate digest lists in Majordomo generally have "-digest" appended to the listname.


Mailing List Managers

Mailing list managers sport many sophisticated features for managing large mailing lists, and these features have made the programs popular among the people who start and run mailing lists (you didn't think lists just worked on their own, did you?). For instance, you can easily and automatically subscribe to and sign off from mailing lists run with a mailing list manager without bothering a human (in most cases). This significantly reduces the amount of work the list administrator has to do. These programs generally also have provisions for tracking the subscribers to a list, and for those who want to remain unknown, concealing certain subscriptions.

Mailing list managers can prevent unauthorized people from sending messages to the list. The TidBITS list works this way in theory because only I can send a message, in this case an issue of TidBITS, to the list. I say "in theory" because in practice the safeguards have broken down twice, resulting in confusing messages going to the entire list. The LISTSERV that runs the TidBITS list also knows to route all replies to postings on the list to me directly, which is normally good, but when these two accidental postings got through the safeguards, I received hundreds of messages from confused readers who didn't know why they had gotten this message. It was a major hassle.

The LISTSERV software knows about other LISTSERVs running on other machines around the world and uses this knowledge to limit network traffic. For instance, I send a single message from my machine to a mainframe at Rice University in Texas that runs the LISTSERV handling the TidBITS list. Once the message arrives at Rice, the LISTSERV software checks to make sure it came from me and then sends it out to the thousands of readers on the TidBITS subscription list.

The LISTSERV is smart, however. It doesn't blindly send out thousands of messages, one per user, because that would waste network bandwidth, especially on expensive transoceanic satellite or cable links. Instead, the LISTSERV determines how to enlist the help of certain other LISTSERVs running around the world. If it knows of a LISTSERV site in Australia, for instance, it sends a single copy of the message to Australia along with the list of Australian readers to distribute to. If 100 people in Australia subscribe to the TidBITS list, only one message crosses the Pacific instead of 100 identical copies of the same message. That's elegant.

I gather that ListProcessor and Majordomo, Unix mail-based mailing list managers, don't have as many features as the LISTSERV software, but that's more from an administrator's point of view. Users generally shouldn't care which they use. Don't worry about it one way or another; you have no choice when picking mailing lists to subscribe to. And despite the added features of the LISTSERV software, the thing that makes the administrative details of a list easy to deal with is the administrator, not the software.

NOTE: ListProcessor used to be called Unix-Listserv and was distributed freely (version 6.0c is still free, even now that CREN has bought it and will be selling future versions), but after some unpleasantness regarding the term "Listserv," Anastasios Kotsikonas decided to rename it to avoid confusion. So, if you see references to Unix-Listserv, they're talking about ListProcessor.


Using LISTSERVs

Most people find dealing with LISTSERVs quite easy; however, you should watch out for a few common pitfalls while working with LISTSERV-based mailing lists. Many of the commands and pitfalls below apply to lists run by the other mailing list managers as well, so it's worth reading through the LISTSERV section even if, for instance, you're dealing with a ListProcessor list.

Every LISTSERV list has two email addresses associated with it: the address for the LISTSERV itself, and the address for the mailing list. Why the dichotomy? Well, the LISTSERV address handles all the commands, things such as subscriptions and requests for lists of subscribers and the like. The mailing list address is where you send submissions to the list, assuming of course that it's that sort of list. Here, I use the TidBITS list as an example for my illustrations of the basic tasks you do with a LISTSERV-based mailing list. (The only difference between the TidBITS list and many others is that if you send mail to the mailing list address, it doesn't go to everyone else on the list because the TidBITS list is dedicated to distributing TidBITS, not to discussion, as are most lists. Any mail sent to the mailing list address comes to me, which is fine, because such messages are usually comments on articles.)

If you want to send the LISTSERV that handles the TidBITS list a command, such as your subscription request, you send it to listserv@ricevm1.rice.edu. Notice that nowhere in the address is TidBITS mentioned, which is a hint that you have to specify TidBITS somewhere else. LISTSERVs ignore the Subject line entirely, so don't worry about filling it in at all. In the body of the message, though, you can put one or more commands, each on its own line.

To subscribe to the TidBITS list, you send the preceding address a message with the following command on one line in the body of the message: SUBSCRIBE TIDBITS your full name, where you replace your full name with your real name, not your email address or some cute nickname. If the list administrator has to contact you about a problem, she probably doesn't appreciate having to address you as "Dear Swedish Chef Fan Club Ork Ork Ork." To clarify the preceding command, to subscribe to any LISTSERV mailing list, you send the SUBSCRIBE command, a space, the name of the list you want to subscribe to, a space, and then your full name, which must be at least two words. I don't know how rock star types like Cher or Prince manage with LISTSERVs, although I did once get mail from someone who really only had one name. I advised him to use "No really, I only have one name" as his last name. See figure 6.4.

Figure 6.4: Subscribing to TidBITS.

NOTE: Prince has legally changed his name to a single character that looks like a little stick figure person. Such characters are called dingbats in the publishing world, so I vote that we simply refer to Prince as Dingbat, or perhaps Prince Dingbat to be unambiguous. Needless to say, there's no way to subscribe to a mailing list using a single nonalphabetic character as your name.

The LISTSERV always returns a welcome note after you have subscribed successfully. Keep that note! It lists various useful commands, such as how to sign off from the list, and it usually provides the address of the list administrator. You can contact the list administrator to handle any problems that the automated program chokes on.

After you have subscribed to a list, you mainly want to read messages (which is easy) and post occasional messages to the rest of the people on the list. Once again, to post a message you send it to the mailing list address, which is always the name of the list at the same machine. If, for example, you want to send mail to the TidBITS list (which comes only to me), you send the email to tidbits@ricevm1.rice.edu. I realize I've almost beaten this particular horse to death, but I can't emphasize enough the difference between the LISTSERV address and the mailing list address. You send commands to the LISTSERV, and submissions to the mailing list address. Perhaps the most common problem I see on LISTSERV mailing lists is that people forget to send commands to the LISTSERV address and instead fill up the mailing list with the electronic equivalent of junk mail that no one wants to see. And, of course, sending commands to the mailing list address isn't just annoying and flame-provoking, it's futile because the LISTSERV doesn't respond to them there.

After you've been on a list for some time, the LISTSERV may ask you to confirm your subscription. I set this option with the TidBITS list to clean the deadwood from the list every year. Students graduate, employees move on, bulletin boards close up, and those addresses don't always go away, so the LISTSERV wastes network resources sending to a nonexistent person, much like talking to a politician. After you have received TidBITS for a year from the LISTSERV, it sends you a message asking you to confirm that you still want to get the newsletter. If you don't respond within seven days, the LISTSERV removes you from the list, assuming that you don't want to continue receiving email from it. If you respond, you must respond with a command so that you send it to the LISTSERV address, not the mailing list address. The command is simply CONFIRM TIDBITS (or the name of the list you are asked to confirm).

A portion of the time this confirmation process fails. As I'm sure you noticed in the preceding paragraphs, nowhere do you provide your email address to the LISTSERV, which is supposed to determine it from the header of your message. This idea seems excellent at first because the header should, in theory, have your email address correct, and it doesn't suffer from typos or simple human mistakes that you make if you type it in by hand. However, depending on the routing that your mail takes and how you or your system administrators have your system set up, your address as it appears in the header may change from time to time. Those changes play havoc with the LISTSERV, which is a very literal program. Therefore, when you confirm a subscription, if that confirmation comes from an address the LISTSERV doesn't recognize, poof, it doesn't work. You probably still receive mail to the original address just fine because the address is usually merely a variant on the theme, so many people sit helplessly by as the LISTSERV asks for confirmation, rejects it, and then calmly deletes them from the list.

NOTE: This situation is a perfect example of why computers should never be given direct control over human lives. If you don't properly match for some reason, you're just another file to be deleted.

There is a simple fix. Just resubscribe as soon as the LISTSERV sends either the confirmation rejection or the message saying that it has deleted you from the list. You may get duplicates of everything for a few days, but then the LISTSERV deletes your old address and continues to send to your new one.

If you blow it and misspell your name while subscribing, or perhaps decide to change your name for one reason or another, you can always change your name (only) with the LISTSERV by sending another SUBSCRIBE command. The danger here, as discussed in the preceding paragraphs, is that if your address looks at all different from when you originally subscribed, the LISTSERV happily adds you to the list again, and you receive duplicates of everything. Now is a good time to ask the list administrator for help because the LISTSERV recognizes only your new address, so you can't delete your old address. Bit of a catch-22 there.

This catch-22 can apply to trying to sign off from a list normally as well. Under standard circumstances, if you send the command SIGNOFF TIDBITS to the LISTSERV address, it removes you from the list. If your address in the header has changed, however, it doesn't recognize you as a current subscriber and thus doesn't let you sign off. Once again, if you need help beyond what the LISTSERV program can provide, don't hesitate to ask the list administrator, but ask nicely. These people don't get paid to take abuse, and in fact, they don't get paid to administrate a list at all. I'll tell you how to contact a list administrator in a moment.

The reason for this seemingly irritating address feature is that administrators realized early on that it would be way too much fun to sign other people up for mailing lists if you really don't like them. You could, for example, sign them up for all the special offers in the back of The National Enquirer. Some friends of mine once had a war with that game, but one was declared the loser when he received bronzed baby shoes and a free subscription to a white supremacist newsletter, or some such nonsense. I'm sure it would be great fun to sign Bill Gates up for a really far-out mailing list, but it gets old after a while and is generally considered abuse of the networks.

Some LISTSERVs can send you files if you send them proper commands in a message. The LISTSERV at Rice, listserv@ricevm1.rice.edu, is one of these sites. In fact, it stores files that also exist on the popular FTP site sumex-aim.stanford.edu. You can find site-specific information by sending a HELP command to any LISTSERV, and for the standard LISTSERV information, send INFO REFCARD.

LISTSERVs support a number of other commands, of which only a few are generally useful. If you want to see a list of all the people who have subscribed to a LISTSERV list, you can use the REVIEW command. For instance, if you want to receive a 900K message listing all the subscribers to TidBITS (and I don't really recommend you do so , in large part because we've turned this feature off for the TidBITS list), send email to the LISTSERV address, listserv@ricevm1.rice.edu with the following line in the body of the message: REVIEW TIDBITS COUNTRIES. I threw in the COUNTRIES modifier (it's not necessary) because it instructs the LISTSERV to sort the subscribers by country and to include a count of subscribers for each country at the bottom, which is neat.

The other utility of the REVIEW command is that it includes the address of the list administrator at the top, so it's a good way to find out who to ask for help. Using the REVIEW command is a good way to see what address the LISTSERV thinks you used to subscribe and then ask the administrator for help. For just the administrator address, you can change the command to REVIEW SHORT.

NOTE: Budding direct marketers should be aware that if you request a bunch of subscriber lists and use them for nefarious marketing purposes, the following will occur: (a) that feature will be immediately turned off in most lists, and (b) I will personally lead the flamethrower crews on a mission to turn you into a fine electronic ash. That sort of opportunism doesn't fly on the Internet.

To switch a LISTSERV subscription (you must already be subscribed) from individual messages to a digest format, send the LISTSERV address the command SET listname DIGEST. To switch back to individual messages, send it the command SET listname MAIL.

Most of the other commands that LISTSERVs support aren't as interesting, or as much fun to write about, so I'll refrain and let you find them on your own.


Using ListProcessor

Working with a mailing list run by the ListProcessor program is remarkably like working with a mailing list run by the LISTSERV program. The similarity isn't coincidental -- ListProcessor started out as a clone of LISTSERV, not in terms of the code, but in terms of the command structure. Thus, the few differences between the two are minimal, especially in the basic functions.

Just as LISTSERVs have a listserv@domain.name address, ListProcessors are generally referred to as listproc@domain.name, although a number of them may still use the listserv@domain.name address left over from when ListProcessor was called Unix-Listserv. And just as the mailing list itself has a different address from the LISTSERV address, something like listname@domain.name, so too do ListProcessor lists. In other words, the confusing dichotomy between the ListProcessor address and the list address exists, just as it does with LISTSERV lists. You send commands to the ListProcessor address (in the body of the message -- the Subject line doesn't matter) and submissions to the mailing list address. I'm really beginning to feel sorry for this poor horse, since I keep beating it, but I can't tell you how many people fail to understand this basic distinction, and in the process irritate thousands of other people on numerous lists.

To subscribe to a ListProcessor-based mailing list, send subscribe listname your full name to the ListProcessor address. Just as with the LISTSERV mailing lists, replace listname with the name of the list you wish to subscribe to and use your real name in place of your full name. ListProcessor figures out your email address from the header of the message.

You leave a ListProcessor-based mailing list by sending the command unsubscribe listname to the ListProcessor address. The command signoff listname does exactly the same thing. Just like the LISTSERV lists, if your address has changed, the automated process very well may not work, at which point you must talk to the list administrator.

The command to switch a ListProcessor subscription from individual messages to digest format differs slightly from LISTSERV -- send the command set listname mail digest to the ListProcessor address. Frankly, I can't see from the instructions how to switch back to individual messages.

If all else fails, try sending the ListProcessor the help command for a simple reference card that explains the options.


Using Majordomo

This is getting kind of boring, but Majordomo works pretty much like the other two mailing list managers. There are two addresses -- the Majordomo address to send your commands to (often majordomo@domain.name), and the mailing list address to send submissions to (listname@domain.name). You may also (if they're running a recent version of Majordomo) be able to send commands to listname-request@domain.name.

To subscribe to a Majordomo-based list, send email to the Majordomo address with the command subscribe listname. Majordomo differs slightly from the other two mailing list managers in that you don't have to specify your full name, and if you like, you can append an email address to the subscription command. This enables you to subscribe someone else to a mailing list, which can be handy -- just don't abuse it. The same structure applies to removing yourself or someone else from a list -- send unsubscribe listname to the Majordomo address (signoff listname works as well).

An easier method of subscribing and unsubscribing to Majordomo-based lists is to send email to listname-request@domain.name with either the subscribe command or the unsubscribe command in the body of the message. Since you've made it clear which list you want to subscribe to with the address, there's no need to include it in the subscription command.

Finally, you can send Majordomo a help command to see what other options are available. I always recommend that you do this, just so you know how and so that you see what's possible.


Neither Rain, nor Snow...


I believe I promised early on in this book that there would be no quiz, but if I were going to break my promise, this is probably the chapter I'd do it in. You cannot get around on the Internet unless you understand how machine names and email addresses are put together. And, quite frankly, since you're likely to use email heavily, I hope you've gotten a sense of how it works, what sorts of things you shouldn't do with it, what an email program should do for you, and what it makes possible in terms of mailing lists. Enough about mailing lists -- let's move on to the next sort of discussion lists, the Usenet newsgroups.