The desire to communicate is the essence of networking. People have always wanted to correspond with each other in the fastest way possible, short of normal conversation. Electronic mail (or email) is the most prevalent application of this in computer networking. It allows people to write back and forth without having to spend much time worrying about how the message actually gets delivered. As technology grows closer and closer to being a common part of daily life, the need to understand the many ways it can be utilized and how it works, at least to some level, is vital.
Electronic mail is hinged around the concept of an address; the section on Networking Basics made some reference to it while introducing domains. Your email address provides all of the information required to get a message to you from anywhere in the world. An address doesn't necessarily have to go to a human being. It could be an archive server [Footnote: See Archive Servers, Appendix B, for a description], a list of people, or even someone's pocket pager. These cases are the exception to the norm--mail to most addresses is read by human beings.
Email addresses usually appear in one of two forms--using the Internet format which contains '@', an "at"-sign, or using the UUCP format which contains '!', an exclamation point, also called a "bang." The latter of the two, UUCP "bang" paths, is more restrictive, yet more clearly dictates how the mail will travel. To reach Jim Morrison on the system south.america.org, one would address the mail as 'email@example.com'. But if Jim's account was on a UUCP site named brazil, then his address would be 'brazil!jm'. If it's possible (and one exists), try to use the Internet form of an address; bang paths can fail if an intermediate site in the path happens to be down. There is a growing trend for UUCP sites to register Internet domain names, to help alleviate the problem of path failures.
Another symbol that enters the fray is '%'--it acts as an extra "routing" method. For example, if the UUCP site dream is connected to south.america.org, but doesn't have an Internet domain name of its own, a user debbie on dream can be reached by writing to the address:
The form is significant. This address says that the local system should first send the mail to south.america.org. There the address debbie%dream will turn into debbie@dream, which will hopefully be a valid address. Then south.america.org will handle getting the mail to the host dream, where it will be delivered locally to debbie.
All of the intricacies of email addressing methods are fully covered in the book !%@.. A Directory of Electronic Mail Addressing and Networks published by O'Reilly and Associates, as part of their Nutshell Handbook series. It is a must for any active email user. Write to firstname.lastname@example.org for ordering information.
We'll make one quick diversion from being OS-neuter here, to show you what it will look like to send and receive a mail message on a Unix system. Check with your system administrator for specific instructions related to mail at your site.
A person sending the author mail would probably do something like this:
% mail email@example.com Subject: print job's stuck I typed 'print babe.gif' and it didn't work! Why??
The next time the author checked his mail, he would see it listed in his mailbox as:
% mail "/usr/spool/mail/brendan": 1 messages 1 new 1 unread U 1 firstname.lastname@example.org Tue May 5 20:36 29/956 print job's stuck ?
which gives information on the sender of the email, when it was sent, and the subject of the message. He would probably use the 'reply' command of Unix mail to send this response:
? r To: email@example.com Subject: Re: print job's stuck You shouldn't print binary files like GIFs to a printer! Brendan
Try sending yourself mail a few times, to get used to your system's mailer. It'll save a lot of wasted aspirin for both you and your system administrator.
An electronic mail message has a specific structure to it that's common across every type of computer system. [Footnote: The standard is written down in RFC-822. See RFCs, section 9.2, for more info on how to get copies of the various RFCs.] A sample would be:
From firstname.lastname@example.org Sat May 25 17:06:01 1991 Received: from hq.mil by house.gov with SMTP id AA21901 (4.1/SMI for email@example.com); Sat, 25 May 91 17:05:56 -0400 Date: Sat, 25 May 91 17:05:56 -0400 From: The President
Message-Id: <9105252105.AA06631@hq.mil> To: firstname.lastname@example.org Subject: Meeting Hi Dan .. we have a meeting at 9:30 a.m. with the Joint Chiefs. Please don't oversleep this time.
The first line, with 'From' and the two lines for 'Received:' are usually not very interesting. They give the "real" address that the mail is coming from (as opposed to the address you should reply to, which may look much different), and what places the mail went through to get to you. Over the Internet, there is always at least one 'Received:' header and usually no more than four or five. When a message is sent using UUCP, one 'Received:' header is added for each system that the mail passes through. This can often result in more than a dozen 'Received:' headers. While they help with dissecting problems in mail delivery, odds are the average user will never want to see them. Most mail programs will filter out this kind of "cruft" in a header.
The 'Date:' header contains the date and time the message was sent. Likewise, the "good" address (as opposed to "real" address) is laid out in the 'From:' header. Sometimes it won't include the full name of the person (in this case 'The President'), and may look different, but it should always contain an email address of some form.
The 'Message-ID:' of a message is intended mainly for tracing mail routing, and is rarely of interest to normal users. Every 'Message-ID:' is guaranteed to be unique.
'To:' lists the email address (or addresses) of the recipients of the message. There may be a 'Cc:' header, listing additional addresses. Finally, a brief subject for the message goes in the 'Subject:' header.
The exact order of a message's headers may vary from system to system, but it will always include these fundamental headers that are vital to proper delivery.
When an email address is incorrect in some way (the system's name is wrong, the domain doesn't exist, whatever), the mail system will bounce the message back to the sender, much the same way that the Postal Service does when you send a letter to a bad street address. The message will include the reason for the bounce; a common error is addressing mail to an account name that doesn't exist. For example, writing to Lisa Simpson at Widener University's Computer Science department will fail, because she doesn't have an account [Footnote: Though if she asked, we'd certainly give her one.]
From: Mail Delivery Subsystem
Date: Sat, 25 May 91 16:45:14-0400 To: email@example.com Cc: Postmaster@cs.w idener.edu Subject: Returned mail: User unknown ----- Transcript of session follows ----- While talking to cs.widener.edu: >>> RCPT To: <<< 550 ... User unknown 550 lsimpson... User unknown
As you can see, a carbon copy of the message (the 'Cc:' header entry) was sent to the postmaster of Widener's CS department. The Postmaster is responsible for maintaining a reliable mail system on his system. Usually postmasters at sites will attempt to aid you in getting your mail where it's supposed to go. If a typing error was made, then try re-sending the message. If you're sure that the address is correct, contact the postmaster of the site directly and ask him how to properly address it.
The message also includes the text of the mail, so you don't have to retype everything you wrote.
----- Unsent message follows ----- Received: by cs.widener.edu id AA06528; Sat, 25 May 91 16:45:14 -0400 Date: Sat, 25 May 91 16:45:14 -0400 From: Matt Groening
Message-Id: <9105252045.AA06528@gracie.com> To: firstname.lastname@example.org Subject: Scripting your future episodes Reply-To: email@example.com ....verbiage......
The full text of the message is returned intact, including any headers that were added. This can be cut out with an editor and fed right back into the mail system with a proper address, making redelivery a relatively painless process.
People that share common interests are inclined to discuss their hobby or interest at every available opportunity. One modern way to aid in this exchange of information is by using a mailing list--usually an email address that redistributes all mail sent to it back out to a list of addresses. For example, the Sun Managers mailing list (of interest to people that administer computers manufactured by Sun) has the address 'firstname.lastname@example.org'. Any mail sent to that address will "explode" out to each person named in a file maintained on a computer at Northwestern University. Administrative tasks (sometimes referred to as administrivia) are often handled through other addresses, typically with the suffix '-request'. To continue the above, a request to be added to or deleted from the Sun Managers list should be sent to 'email@example.com'.
When in doubt, try to write to the '-request' version of a mailing list address first; the other people on the list aren't interested in your desire to be added or deleted, and can certainly do nothing to expedite your request. Often if the administrator of a list is busy (remember, this is all peripheral to real jobs and real work), many users find it necessary to ask again and again, often with harsher and harsher language, to be removed from a list. This does nothing more than waste traffic and bother everyone else receiving the messages. If, after a reasonable amount of time, you still haven't succeeded to be removed from a mailing list, write to the postmaster at that site and see if they can help.
Exercise caution when replying to a message sent by a mailing list. If you wish to respond to the author only, make sure that the only address you're replying to is that person, and not the entire list. Often messages of the sort "Yes, I agree with you completely!" will appear on a list, boring the daylights out of the other readers. Likewise, if you explicitly do want to send the message to the whole list, you'll save yourself some time by checking to make sure it's indeed headed to the whole list and not a single person.
A list of the currently available mailing lists is available in at least two places; the first is in a file on ftp.nisc.sri.com called 'interest-groups' under the 'netinfo/' directory. It's updated fairly regularly, but is large (presently around 700K), so only get it every once in a while. The other list is maintained by Gene Spafford (firstname.lastname@example.org), and is posted in parts to the newsgroup news.lists semi-regularly. (See Chapter 4 [Usenet News], page 29, for info on how to read that and other newsgroups.)
On BITNET there's an automated system for maintaining discussion lists called the listserv. Rather than have an already harried and overworked human take care of additions and removals from a list, a program performs these and other tasks by responding to a set of user-driven commands.
Areas of interest are wide and varied--ETHICS-L deals with ethics in computing, while ADND-L has to do with a role-playing game. A full list of the available BITNET lists can be obtained by writing to 'LISTSERV@BITNIC.BITNET' with a body containing the command
However, be sparing in your use of this--see if it's already on your system somewhere. The reply is quite large.
The most fundamental command is 'subscribe'. It will tell the listserv to add the sender to a specific list. The usage is
subscribe foo-l Your Real Name
It will respond with a message either saying that you've been added to the list, or that the request has been passed on to the system on which the list is actually maintained.
The mate to 'subscribe' is, naturally, 'unsubscribe'. It will remove a given address from a BITNET list. It, along with all other listserv commands, can be abbreviated--'subscribe' as 'sub', 'unsubscribe' as 'unsub', etc. For a full list of the available listserv commands, write to 'LISTSERV@BITNIC.BITNET', giving it the command 'help'.
As an aside, there have been implementations of the listserv system for non-BITNET hosts (more specifically, Unix systems). One of the most complete is available on cs.bu.edu in the directory 'pub/listserv'.
Go to the next chapter.
Go to the previous chapter.
Go to the Table of Contents.
Go to the Glossary.