Previous Page TOC Index Next Page Home


5

E-Mail

--by Philip Baczewski

E-mail is the staple of any Internet habitué. The effective use of e-mail is particularly important for anyone wishing to take advantage of the Internet for interpersonal communication or information gathering. Experience is probably the best teacher in this regard, and any knowledge of an e-mail program on a particular system will be enhanced by knowledge of the editor employed within the e-mail program and by experience manipulating files on that particular system. There are some e-mail topics that go beyond the basic level of knowledge. Among these are using programs to preprocess and organize your mail, and making the content of your mail messages secure. The following discussion covers both of these areas, along with a number of other tidbits that you might find handy when working with electronic mail from the Internet.

Manipulate Your Mailer

The more you know about your mail environment, the more efficient you can be in using electronic mail. The more you can control your mail environment, the more powerful you can be using electronic mail. Here are some items that may help on both accounts.

Mail Options No Guru Does Without

No guru does without the options that enable the most efficient possible configuration of mail—unless, of course, those options aren't available. In general, I find the following to be important in the mail programs I use. Sorting—preferably multiple levels of sorting—should always be configurable in a good mail program. Forwarding is another important e-mail function that will be useful or required at some point in your Internet career. Another option to be aware of in your mail package is that of acknowledgements. The level of acknowledgement available from various mail programs varies. As you will see below, however, you can often generate your own acknowledgements via an e-mail preprocessor program. The most powerful automated manipulation of e-mail can be done with the preprocessing filter programs described in this chapter. An overall knowledge of your e-mail environment and a good idea of how you can best organize your incoming mail will ultimately provide you with the basis for using the various tools described below.

Taking Advantage of Simple Mail Transport Protocol (SMTP)

The openness of Internet mail exchange can make it easier to identify problems or find information about a particular Internet mail address. A telnet session to port 25 of an SMTP-capable system should get you that system's SMTP interface, which will enable you to perform several handy functions. It is important, however, that this capability be used judiciously. Abuse of any open system will only lead to a more closed future environment. The SMTP verify (VRFY) command can tell you that a user does or doesn't exist at a particular e-mail location (useful for solving delivery problems), and can also provide information about an alternate or forwarding address for that user. The expand (EXPN) command can confirm that an address is a mailing list and provide a membership list. Since VRFY and EXPN sometimes can return a false positive, these commands should be used to confirm other evidence of an address. More information about SMTP can be found in numerous references, including the original specification document, Internet Request for Comment (RFC) 821 (see the following for more information about obtaining RFCs).

Exploiting Various Headers

If you haven't done so already and you want to know all about Internet mail headers, find a copy of RFC 822 (just do an Archie search on the string rfc822 and you are sure to find it). If you don't know, RFC 822 is the set of specifications that defines the way information is structured in an Internet e-mail header. You are probably familiar with most of the common elements of a header—From:, To:, Subject:, and so on. If you haven't managed an Internet mailer or had to solve mail-routing problems, you might be unaware of the usefulness of some of the other header elements.

Header Elements to Be Aware of

The following are comments on the general usefulness of headers and may be a review or an overview for you. For the technical specifications of these fields, see RFC 822.

Received:

The Received: field enables you to track a message through mail handlers and gateways. One Received: field is present for each delivery transaction. You can examine these to pinpoint gateways as well as to solve delivery problems. You might want to use a mail filter to process mail delivered from a specific site instead of from a specific person.

Reply-to:

Mailing lists usually set the Reply-to: field to the list address so that replies will automatically be redistributed to all subscribers. This stimulates discussion on the list, but as you have probably seen, it also results in messages that were meant for an individual being inadvertently sent to the list. You can usually use your mail program to set a Reply-to: field that will supersede any From: field. Most mail programs also enable you to send your reply specifically to the From: field. When I forward mailing-list mail, though, I sometimes set the Reply-to: to my address to help prevent an accidental reply to the list.

BCC:

BCC: helps ensure e-mail discretion as long as you are aware that you are the blind "copyee." "BCC" stands for "Blind Carbon Copy" and causes a copy of the message to be sent to the BCC address without that address showing up in the headers of the primary or carbon copies. (Since most computers do not use carbon paper, sometimes "CC" is referred to as a "Complementary Copy.") A word of advice: Be careful not to inadvertently or inappropriately forward mail that was intended to be discreet. The "reply all" function of your mail program can be dangerous in this situation as well.

Headers and Rules-Based Mail

The contents of header fields such as From:, Resent-From:, Subject:, and others can serve as the basis for preprocessing and organizing your mail using a "rules" or filter facility. For example, if you wanted to discard automatically all messages whose subjects contain the word unsubscribe, a mail filter could scan for that word in mail subjects and perform a discard function based on such a match.

Concepts of E-mail Rules Facilities

If you are willing to do some work, you can set up your filter to generate automated replies to selected mail messages or even trigger other automated processes. Most people will want to redirect messages to specific folders or forward mail to another location.

Pegasus Mail

Several e-mail products in common use support filtering rules in one manner or another. For example, David Harris's Pegasus mail package, which runs on Novell file servers, has a built-in filter rules facility that enables you to perform actions based on the From:, CC:, To:, Subject:, or Reply-to: fields. Pegasus mail can check any of these fields for a specified string and can trigger twelve different functions based upon a match. Rules are defined by a fairly simple interface where you define the action fields, the string to match, the action and any parameters needed for the action. This is a simple, but effective, implementation of mail filter rules and illustrates the general concepts involved. (This concept has also reached commercial products like Lotus' cc:Mail and Novell's GroupWise 4.1, formerly WordPerfect Office mail.)

The following represents a sample filter rule definition in Pegasus mail.

If this field  :  Cc, To

Contains       : [netmanl                     ]

Then do this   :  Move

      (Using)     Network Managers List
Filter

In the UNIX environment, some even more sophisticated tools are available for mail filtering. If you have the Elm mail package, it probably came with a program named Filter, which performs rules-based mail filtering in conjunction with that mail reader. To make use of the program, you must create a rules file, named filter-rules, in your .elm directory. Rules are rather simple in their construction. The general syntax is as follows:

if (condition) then action

Condition consists of a field, a relation, and a value. The fields include subject, sender, from, to, lines, and contains. For lines, the relation can be any standard numeric equivalence or comparison (<, >, =, <=, and so on). For other fields, contains can be used as a relation. Values are quoted strings for all fields (except lines) where the value is an integer. Nonnumeric values can also be regular expressions enclosed in quotes. Actions include delete, save foldername, savecopy foldername, forward address forwardc address, execute command, executec command leave. Most of these are self-explanatory. Forwardc and executec are commands that leave a copy of the message in your mailbox. Leave is the explicit command to leave the message in your mailbox.

A rule, for example, to delete all of those pesky subscribe and unsubscribe messages that are sent to mailing lists might look like this:

if (subject contains "subscribe") then delete

To log messages to a particular folder, you might try the following:

if (to contains "MACAV-L" and lines > 15) then save "~/mail/Macintosh"

Notice that in the preceding example two conditions are tested and linked via a logical AND operator. To test for the negative of a condition, the field value can be prefixed with NOT. A logical OR condition is not supported in Filter (at least not in Elm version 2.4). Comments can be placed in your filter-rules by starting the line with a pound sign (#).

Filter is invoked by placing a line in your .forward or equivalent file, which also means that your UNIX system must be running sendmail or some equally functional program. A typical entry in the .forward file might look like the following:

"| /usr/local/bin/filter -o ~/mail/FilterErrors"

Because the filter may be run while you are not logged on, Filter includes the option of logging any errors to a file, as specified by the -o option. (You might also log the errors to tmp or scratch space.)

Whenever mail forwarding is involved, it's best to observe some caution, lest you accidentally create e-mail loops or route all your mail to a null file. Your rules will be processed in the order that they appear in the file, so be sure to evaluate carefully whether the operations performed will be done in a logical and desirable sequence. You can check what rules are in place by using the command filter -r. Before using Filter, read The Elm Filter System Guide, which is distributed with the program. Documentation is also found in the Filter man page distributed with Elm.

Procmail

Procmail is another UNIX program that can be used to preprocess your incoming mail based upon the content of the mail message. Procmail is a bit more powerful than Filter, since it can scan both the header and the body of your message. It also enables checking of multiple conditions within each rule definition (or in Procmail parlance, within each "recipe"). Procmail, like Filter, can be invoked via the .forward file, but Procmail can also be installed by the system administrator as the primary mail delivery agent. The latter case makes the configuration process a bit easier for the average user.

Procmail rules are defined in a file named .procmailrc, usually located in your home directory. The .procmailrc file contains environment variable assignments (some of which are significant to Procmail) and recipes, and both can be freely interspersed within the file. Comments can be placed in the file by starting the line with a pound sign (#).

Procmail recipes begin with a line starting with a colon (:). Following the colon is an optional number that indicates how many conditions are to be checked within the recipe. Following the number are one or more optional flags that indicate how a recipe will be processed. The last item on a recipe's first line is a colon followed optionally by the name of a local lock file. Specifying the colon by itself will cause Procmail to use a lock file name formed from default values. If several Procmail programs are delivering mail at once, the existence of a lock file will prevent multiple attempts to deliver mail to a mail folder. Following the first line of a Procmail recipe are zero or more conditions, with each condition occupying its own line. A single action line follows any conditions.

The flags available are as follows:

Flag


Function


H

Searches the header of the message (the default)

B

Searches the body of the message

D

Distinguishes between case (ignore case is the default)

A

Recipe depends on the completion of the preceding recipe

a

Recipe depends on the successful completion of the preceding recipe

h

Processes (that is, forwards, saves, and so on) the header (default)

b

Processes the body (default)

f

Considers the processing to be a filter

c

Continues processing other recipes even if this recipe matches

w

Waits for processing to finish and checsk a return code

W

Waits for processing to finish, checks the return code, but suppresses any failure message

i

Ignores any write errors for this recipe

Since Procmail uses egrep to search the specified portion of a message, conditions are written as egrep regular expressions. If a condition starts with an exclamation point (!), then the condition is inverted. Greater than (>) or less than (<) signs, followed by a decimal integer, can be used to make a condition true only if the size of the mail is greater than or less than the specified number (in bytes). Regular expressions starting with the value ^TO will be replaced with the expresssion ^(To|Cc|Apparently-To):.* in order to find all destination specifications. The following condition would match any message sent to the Macintosh AV mailing list:

^TOmacav-l

A match of the string subscribe in the subject field would be found by the following:

^Subject:.*subscribe

An action can be as simple as specifying a folder name into which a message will be filed. Beginning an action with an exclamation point (!) will cause the message to be forwarded to an immediately following e-mail address. A pipe (|) can be used to initiate some other action regarding the message. The following is an example of a .procmailrc file.

#Example .procmailrc file

#See man procmailex for more examples

LOGFILE=$HOME/mail/.proclog

MAILDIR=$HOME/mail

#Save any messages to "staff" in staff folder

:w:

^TOstaff.*

staff

#Save any message from the Macintosh AV list in the

#macintosh folder

:w:

^TOmacav-l

macintosh

#Save all correspondance with "Bob"

:w:

(^From|^To:|^Cc:).*Bob.*

BobMail

#Forward any mainframe-related mail

:2w:

^TO(mainframe&manager)

^Subject:.*mainframe.*

!myname@mainframe.here.edu

#Add all mail about horses to the horses archive and

#forward a copy to Betty

:wc:

^Subject:.*horse.*

|uncompress horses.Z;cat>>horses;compress horses

  :A

  !Betty@stable.com

#End of .procmailrc example

As is the case when dealing with e-mail, great care should be taken in writing your forwarding rules. If you are interested in using Procmail, it would be best to check with your system administrator as to whether it is installed globally or whether it will work with your particular system mailer. For more information on Procmail, see man procmail, man procmailrc, and man procmailex.

Nathaniel Borenstein

by Tod Foley

Chief Scientist at First Virtual Holdings, Inc., Nathaniel Borenstein is a world-reknowned doctor of computer science and a veritable legend of the online world. His programming work focuses on e-mail encoding/decoding and transport, and it places special emphasis on interoperability issues and the problems associated with multimedia on the Net. Nathaniel's programming credits include such applications as Andrew (a pioneering multimedia messaging application), metamail (a portable MIME implementation used by millions worldwide), and the ATOMICMAIL and Safe-Tcl languages (for safe and portable interactive electronic mail messages); but his most famous work is undoubtably MIME (the Internet standard format for interoperable multimedia data). He is also the founder of the experimental electronic magazine Electric Eclectic, and the author of Programming As If People Mattered: Friendly Programs, Software Engineering, and Other Noble Delusions. Now, with his partners at First Virtual, he continues to forge ahead, developing new answers to the problems of networked information delivery. In a recent e-mail interview, Nathaniel explained the groundbreaking MIME format, and took a look at the future of the pan-platform multimedia world.

TF: These days, many people are familiar with MIME—at least in terms of seeing the word in their e-mail headers—but few people seem to grasp the concept. What is MIME really, and how does it extend the e-mail capabilities of users?

NB: I can tell you what I think MIME really is. This isn't what I thought when we were designing it, but it's what I think now:

I think that the best one-phrase summary of MIME is "ASCII version two." By this, I mean that it is a data representation format that is totally machine-independent and can be used anywhere, like ASCII. In fact, it is represented entirely in ASCII, so you could view it as a backwards-compatible extension to ASCII. What it comes down to is a well-defined, totally portable way to represent any kind of data inside ASCII. This explains why MIME is rapidly being adopted for so many non-e-mail uses (netnews, WWW, Gopher, and even for X11 cut & paste in the COSE proposals). It turns out that there are lots of applications for a totally platform- and vendor-neutral way to represent any kind of data in the world and encapsulate it in an ASCII byte stream. That's what MIME's turning out to be.

TF: So it's a transparent protocol,not a tool or service. . ..

NB: Well, what MIME becomes is the lingua franca for communication between multimedia applications, even though users never need to know they're using MIME. Today, if two users exchange mail, and one of them is using, say, Eudora, and the other is using Lotus Notes, and the mail being exchanged between them includes a picture (which is something both systems support), then one of two things will happen:

1. The message will be garbled.
2. The message will work fine, because they're using a recent version of Eudora and a recent Notes-to-SMTP gateway, both of which support MIME.

Note what this looks like from the end user's perspective: either "the system" works, or it doesn't. Evolutionarily, it used to be always case #1, and is slowly turning into case #2 more often. Even a user who is alert enough to notice the improvement will just think "they've improved the software," but such users never have to hear the word "MIME" or know anything about it at all.

TF: That's a great description97Ämakes things a lot clearer. Of course the primary source for information on MIME would be RFC 1521, but are there any other good sources for users to turn to? Third-party literature?

NB: Well. . .that depends on your definition of "third-party." I'd refer you to Marshall Rose's book The Internet Message, published by Prentice Hall, which has a whole chapter on MIME. There's also the MIME FAQ, which is itself third-party, and which contains lots of pointers to other information.

TF: How does one use MIME to encode multimedia e-mail—assuming the mailer has that capability?

NB: That depends on the mail tool you're using. In some systems, you have to type an arcane command, followed by the filename, and you even have to type in the MIME content-type (for example, image/gif, or audio/basic, and so on) by hand. Some systems have an "include attachment" menu or button, and may or may not use file type information to deduce the content-type. Other systems have particular buttons or menus for "include image" or "include sound," or even more specialized ones such as "include screen dump" or "record & include sound." The best systems (including Andrew, about which I am a shockingly immodest author <g> ) will even let you compose and edit pictures, sounds, and so on, right in the middle of your mail message as you compose it. But as long as these systems all produce MIME as their data format, their users can all interoperate. MIME simply increases the infrastructure available for vendors of ever-better mail tools.

TF: Are MIME messages transportable across both SMTP and UUCP networks?

NB: Absolutely. In fact, we designed MIME to be transportable across every mail system in the known world. If properly encoded, MIME messages can pass through gateways that connect not only SMTP and UUCP, but also Bitnet, FidoNet, X.400, SNADS, PROFS, and everything else (including some really odd stuff) that was known to the hundred-odd mail gurus involved in the protocol design. A MIME message can pass through any or all such gateways, and as long as the headers aren't stripped off, if the recipient has MIME-smart software, the message will be seen in its full multimedia glory. Einar Stefferud, one of the great visionaries and grand old men of the Internet, likes to speak of MIME as generalized "tunnelling technology," by which arbitrary data can be safely transported through some of the strangest transport gateways in the world. He also calls it "teflon-coated e-mail armor," or something like that, but my favorite description is still "ASCII version two."

TF: Metamail—the program that performs the actual MIME encoding/decoding and display—is described as "a portable MIME implementation" which is called by the mailer. I would imagine that Andrew calls metamail; and it's fairly common knowledge that Pine and Eudora also support its use—what other mailers currently allow for calls to metamail?

NB: Well, actually, this is not quite right. Andrew, Pine, and Eudora all support MIME, but the implementation in Eudora is totally independent of metamail. I'm not sure about Pine, but I think it started out as mostly metamail but is adding stuff. Andrew uses metamail as a fallback when it hits a MIME content-type for which it doesn't have built-in support; but it has built-in support for the most common types, such as image and audio data. So the story is considerably more complicated.

Basically, metamail was designed to be a program that you could easily plug into any mail reader to let it display MIME. This strategy was a very successful way to add minimal support for MIME to existing mail readers, but the result was not what you'd call a seamless or well-integrated user interface. I always saw it as primarily being a transitional tool, to aid in the transition from pre-MIME to post-MIME mail readers. It turns out to be a bit more than that, because nowadays a fair number of MIME-smart mail readers are being designed to use metamail as a fallback for unrecognized data types, the way Andrew does. This is a nice strategy because metamail is so easily configured to handle new content-types by running separate external viewing programs.

Anyway, to get back to your original question, it turns out that I don't really know all the tools that use metamail. I do know that not all of them are mail readers—there are news readers and various other tools that use metamail to handle multimedia "attachments" in MIME format. I know that I have personally patched or received patches for Berkeley Mail and its many variants; Xmail, Mailtool, MH, XMH, MH-E, Rmail, VM, the four Andrew mail-reading tools; Elm, Mush, MM, Msgs, UUPC, RN, TRN, and various lesser-known packages. It has been fairly amazing to watch the way it has taken off. It was 22 days from the first public release of metamail on SunOS to my receipt of the first MS-DOS port, which is when I was really sure I had a hit on my hands.

TF: What about offline applications? Is the day coming when my paint program will have the option to save directly into MIME format instead of saving bit maps or .GIFs?

NB: That's a particularly interesting question, I think, because it goes to the heart of what the world really needs for multimedia interoperability. There are still competing approaches in this regard, such as Bento, and I'm not sure I can predict the future. The cut & paste situation in X11 is the best example of why MIME would be useful for these "offline applications," as you call them—you need either MIME or something just like it if you're ever going to be able to cut & paste compound multimedia stuff including text, audio, and video between independently-developed applications. I think that day probably is coming on UNIX systems. It's harder to predict in non-UNIX environments because there's more of a chance for vendor-defined standards. For example, cut & paste already works fairly well on the Mac, because Apple managed to control the standards quite nicely by anticipating the need, at least at the level of things like bit maps. (Cut & paste actually breaks down at a more structured level of data, but it remains to be seen if the market really requires the cutting & pasting of active spreadsheets, for example.) Microsoft could have probably set the standards equally well for Windows, but they may have missed the boat by not doing it right sooner—I don't know.

I'd certainly like to think that the day you mention is coming, but if it is I think it will be customer-driven. It will happen if enough users demand the ability to get really high-level interoperability between independent multivendor applications. And that will only happen if consumers are educated enough to realize that this is even possible.

You can obtain more information on MIME and related topics in the following places:

The MIME FAQ, currently maintained by Jerry Sweet, can be found via anonymous FTP at a number of sites; simply ask Archie to find mime-faq, or FTP to any of these sites:

rtfm.mit.edu/pub/usenet-by-group/news.answers/mail/mime-faq/*
ftp.uu.net/usenet/news.answers/mail/mime-faq/*
ftp.ics.uci.edu/mh/contrib/multimedia/mime-faq.txt.gz

To retrieve the FAQ by FTPmail, send e-mail to

archive-server@ics.uci.edu

with the text body:

mimesend /mh/contrib/multimedia mime-faq.txt.gz

The MIME FAQ is also posted monthly to the Usenet newsgroup comp.mail.mime.

mime.txt, a good primer on MIME and how it works, can be found at ftp.netcom.com, in the directory /pub/mdg/mime.txt.

MIME, metamail, and related programs and sample files are available via anonymous FTP from thumper.bellcore.com, in the /pub/nsb directory.

Anonymous E-Mail and Privacy Issues (PEM, PGP, and So on)

In my capacity as Bitnet support person, I once ran across the classic bit of forged e-mail shown in the following screen dump. This was a message posted to the Bitnet LINKFAIL mailing list—undoubtedly as a parody of the usual kinds of notices posted there. While it provided an amusing aside to the usual monitoring of downed Bitnet links (a critical issue at that time, since Bitnet was still primarily a store-and-forward network), it also drove home the fact that not all e-mail was authentic. Today, while a number of safeguards have been put in place by system managers, forged e-mail is still a possibility. The following Bitnet Listserv mail message was a funny, if obvious, forgery.

IPFRCVM  Iowa Pig Farm Research Center will be down tomorrow from

20:0023:00 for system maintenance. Since we are an end node, nobody

will be affected except for us.

It turns out that one of our sows got in through a hole in the wall

and had her litter of piglets under our raised floor. The operator on

duty got quite a scare when he heard a number of squeals. He assumed

we had some massive head crashes and powered down the CPU. Since the

squeals continued we traced it to a corner under our raised floors.

We will be off the air tonight so that we can power down again and

get the sow and her piglets out from under the floor.

Zeke  System Grunt IPFRC

Anonymous access to the Internet is counter to the usage guidelines of most Internet service providers, who require that news posts and mail be traceable to a specific computer or human user. In spite of this requirement, however, standard Internet mail is not guaranteed to be legitimate, secure, or authentic. It's still possible to forge SMTP mail, but these days it's harder to do so without getting caught. While mail is, for the most part, provided a degree of legitimacy by the security of the computing systems attached to the Internet, standard Internet mail has to date not been secure enough to support things like monetary transactions, business negotiations, and other truly private transactions.

The Problem of E-Mail Security

It is the intent of most system managers to keep their systems secure and to guard user privacy. Such concern for security and privacy usually extends to electronic mail as well. After mail leaves a host machine, control over that security and privacy is out of the hands of the sender or the system's manager. While it is counterproductive to question the motives and integrity of every system manager other than your own, most of us who have spent a good deal of time on the Internet live by the tenet that e-mail is everlasting and ubiquitous. Never commit something to an e-mail message that you would not be able to defend or laugh off at a later date.

To quell some tinges of paranoia, it is unlikely that some secret agency is routinely gathering all Internet e-mail messages ever sent. They would probably like to, but the volume of mail is just too great. The problem is far more practical and mundane. For example, messages sometimes pass through gateways—computers that use disk space to store messages for later delivery. Disk drives get backed up on a regular basis. In other words, your e-mail message may exist on someone's backup tape. Although it may be the case that no one knows that your e-mail message is there, that does not prevent that message from being accessed at some later time. The way systems communicate on the Internet is also part of the problem. Internet protocols are open and well documented. While it's usually software programs that do so, anyone can connect to an SMTP mail agent and begin to enter commands. because most e-mail messages exist in clear text, there is no guarantee that it will be read only by the individual for whom it is intended.

Some E-Mail Privacy Solutions

Since e-mail exists in clear text, the answer to security must lie in encryption, right? Well, the answer is both no and yes. Standard encryption methods require that some "key" value be used to encode and decode the text. If you are sending e-mail, transmitting a key value is problematic. It is possible to do so via some other secured channel of communication, but it certainly would not be convenient, especially on a regular basis. The answer may lie in the dual key model of encryption proposed by the RSA (Rivest, Shamir, and Adleman) standard, published (much to the NSA's chagrin, apparently) in 1977.

The RSA algorithm makes use of a public and private key to ensure both privacy and authenticity. The private key remains the secret possession of an individual, while an associated public key can be published to others on the network. To put it simply, text encrypted using the public key can only be decrypted using the corresponding private key, thereby ensuring that only the recipient (and private key holder) can access the text, thus preserving the privacy of the message. Likewise, text encrypted with the private key can be decrypted only using the associated public key, thereby ensuring that the text is indeed originating from the sender (and private key holder), thus providing authentication.

The PEM Standard

Implementation of RSA security for Internet mail has progressed far beyond the proposal stage, but it has not yet reached the practical level of other implemented and offically accepted Internet standards. Any mail program that wants to operate on the Internet must be capable of "speaking" SMTP (or at least be on speaking terms with another program that is). Very few programs are yet "speaking" PEM.

PEM stands for Privacy Enhanced Mail, and is documented in RFC numbers 1421, 1422, 1423, and 1424. The PEM standard is intended to implement the RSA encryption algorithm in a manner that can support the exchange of secure electronic mail via Internet protocols. The RFCs mentioned above outline all aspects of managing such a protocol on the Internet, including encryption algorithms used for management of public and private keys. The standard proposes a centralized hierarchical structure for the issuance of public key certificates, and outlines how public keys could be integrated with directory services. The overall scheme is ambitious and has not been fully implemented or officially adopted at this writing.

One problem with relying on a dual-key encryption method is the inability to ensure that published public keys are actually associated with the person whom they purport to represent. If an impostor publishes a public key for a person, then the impostor can decode messages intended for that person if unsuspecting people use the bogus key to encrypt messages. The PEM standard proposes a hierarchy of certification authorities who would be charged with the task of providing presumably secure "key certificates." Some people, however, are uncomfortable with entrusting this task to a central authority and advocate a "grass-roots" network of authentication, with one's personal authorities serving as the basis for deciding that a public key is valid. The debates on this topic and on topics such as the U.S. Government-proposed "clipper chip" show that this can be an emotional and complicated issue.

Introducing RIPEM

A version of PEM is available from a company name Trusted Information Systems. However, another version named RIPEM seems to be more readily available via the Internet. RIPEM is a program written by Mark Riordin that implements many aspects of the PEM standard but does not implement a hierarchical certification scheme.

RIPEM makes use of a package of encryption algorithms named the RSAREF Toolkit, which is available from RSA Data Security Inc. at the anonymous FTP site rsa.com. RSA licenses several patented encryption algorithms (including the RSA algorithm) from a company named Public Key Partners. Public Key Partners owns the exclusive licensing rights to those algorithms. The RSAREF Toolkit—actually a package of C libraries—is freely available subject to export limitations and licensing restrictions. Because of U.S. Government rules, only citizens of the U.S. and Canada are eligible to acquire and use the RSAREF package. This is also true of RIPEM and other RSA encryption packages. The following copy of the RSA license agreement illuminates the various restrictions in relation to this package.

     RSA LABORATORIES

PROGRAM LICENSE AGREEMENT

     January 5, 1993

RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA")

GRANTS YOU A LICENSE AS FOLLOWS TO THE "RSAREF" PROGRAM:

1.   LICENSE. RSA grants you a nonexclusive, nontransferable,

     perpetual (subject to the conditions of section 8) license

     for the "RSAREF" program (the "Program") and its associated

     documentation, subject to all of the following terms and

     conditions:

     a.   to use the Program on any computer in your possession;

     b.   to make copies of the Program for backup purposes;

     c.   to modify the Program in any manner for porting or

          performance improvement purposes (subject to Section 2)

          or to incorporate the  Program into other computer programs

          for your own personal or internal use, provided that you

          provide RSA with a copy  of any such modification or

          Application Program by electronic mail, and grant RSA

          a perpetual, royaltyfree license to use and distribute

          such modifications and Application Programs on the terms

          set forth in this Agreement.

     d.   to copy and distribute the Program and Application Programs

          in accordance with the limitations set forth in Section 2.

"Application Programs" are programs which incorporate all or any

portion of the Program in any form. The restrictions imposed on

Application Programs in this Agreement shall not apply to any software

which, through the mere aggregation on distribution media, is

colocated or stored with the Program.

2.   LIMITATIONS ON LICENSE.

     a.   RSA owns the Program and its associated documentation and

          all copyrights therein. You may only use, copy, modify and

          distribute the Program as expressly provided for in this

          Agreement. You must reproduce and include this Agreement,

          RSA's copyright notices and disclaimer of warranty on any

          copy and its associated documentation.

     b.   The Program and all Application Programs are to be used only

          for noncommercial purposes. However, media costs associated

          with the distribution of the Program or Application Programs

          may be recovered.

     c.   The Program, if modified, must carry prominent notices

          stating that changes have been made, and the dates of any

          such changes.

     d.   Prior permission from RSA is required for

          any modifications that access the Program through ways

          other than the published Program interface or for

          modifications to the Program interface. RSA will grant

          all reasonable requests for permission to make such

          modifications.

3.   NO RSA OBLIGATION. You are solely responsible for all of your

     costs and expenses incurred in connection with the distribution

     of the Program or any Application Program hereunder, and RSA

     shall have no liability, obligation or responsibility therefor.

     RSA shall have no obligation to provide maintenance, support,

     upgrades or new releases to you or to any distributee of the

     Program or any Application Program.

4.   NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED

     DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR

     PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR

     PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF

     THE PROGRAM IS ASSUMED BY YOU AND YOUR DISTRIBUTEES. SHOULD THE

     PROGRAM PROVE DEFECTIVE, YOU AND YOUR DISTRIBUTEES (AND NOT RSA)

     ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR

     CORRECTION.

5.   LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN

     SECTION 6 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS

     BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE

     PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY

     DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF RSA HAS BEEN

     ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

6.   PATENT INFRINGEMENT OBLIGATION. Subject to the limitations set

     forth below, RSA, at its own expense, shall: (i) defend, or at

     its option settle, any claim, suit or proceeding against you on

     the basis of infringement of any United States patent in the

     field of cryptography by the unmodified Program; and (ii) pay

     any final judgment or settlement entered against you on such

     issue in any such suit or proceeding defended by RSA. The

     obligations of RSA under this Section 6 are subject to:

     (i) RSA's having sole control of the defense of any such claim,

     suit or proceeding; (ii) your notifying RSA promptly in writing

     of each such claim, suit or  proceeding and giving RSA authority

     to proceed as stated in this  Section 6; and (iii) your giving

     RSA all information known to you relating to such claim,

     suit or proceeding and cooperating  with RSA to defend any such

     claim, suit or proceeding. RSA shall have no obligation under

     this Section 6 with respect to any claim to the extent it is

     based upon (A) use of the Program  as modified by any person

     other than RSA or use of any Application Program, where use

     of the unmodified Program would not constitute an infringement,

     or (B) use of the Program in a manner other than that permitted

     by this Agreement.  THIS SECTION 6 SETS FORTH RSA'S ENTIRE

     OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR

     PROPRIETARY RIGHTS INFRINGEMENT.

     NOTE: Portions of the Program practice methods described in and

     subject to U.S. Patents Nos. 4,200,770, 4,218,582 and 4,405,829,

     and all foreign counterparts and equivalents, issued to Leland

     Stanford Jr. University and to Massachusetts Institute of

     Technology. Such patents are licensed to RSA by Public Key

     Partners of Sunnyvale, California, the holder of exclusive

     licensing rights. This Agreement does not grant or convey any

     interest whatsoever in such patents.

7.   RSAREF is a noncommercial publication of cryptographic

     techniques. Portions of RSAREF have been published in the

     International Security Handbook and the August 1992 issue of Dr.

     Dobb's Journal. Privacy applications developed with RSAREF may be

     subject to export controls. If you are located in the United States

     and develop such applications, you are advised to consult with the

     State Department's Office of Defense Trade Controls.

8.   TERM. The license granted hereunder is effective until

     terminated. You may terminate it at anytime by destroying

     the Program and its associated documentation. The termination

     of your license will not result in the termination of the

     licenses of any distributees who have received rights to the

     Program through you so long as they are in compliance with

     the provisions of this license.

9.   GENERAL

     a.   This Agreement shall be governed by the laws of the State of

          California.

     b.   Address all correspondence regarding this license to RSA's

          electronic mail address <rsarefadministrator@rsa.com>, or

          to

               RSA Laboratories

               ATTN: RSAREF Administrator

               100 Marine Parkway, Suite 500

               Redwood City, CA  94065

RIPEM is available for several platforms including UNIX, Macintosh, and MS-DOS. It is a program that acts independently of your mail program, providing file encryption/decryption, and public and private key management. It is not without its limitations, however. As per the PEM standard, it can act upon text files only. It is limited to a 1023-character line length, and the encryptable message size is limited by the available size of your computer system's memory.

RIPEM and other similar programs use a two-step encryption process. The message text is first encrypted using the Data Encryption Standard (DES) algorithm and that encryption's key value is then encrypted using the RSA algorithm. This process takes less time, since RSA encryption generally is more complex than DES. The text remains secure because the DES key is guarded by the RSA encryption. RIPEM can also ensure that a file has not been altered. It does this by encrypting a hash value with a signed file. The whole process is transparent to the user.

Obtaining RIPEM

The official distribution site for RIPEM is ripem.msu.edu, and information about the program can be found in the /pub/crypt/ripem directory. The files ripemusr.txt and ripem.man (the man page) are particularly informative. Since RIPEM and programs like it are export-restricted, the actual executables are only distributable upon request. The RIPEM source code has been placed in the public domain, but because of RSAERF restrictions commercial use of the program is apparently forbidden.

To gain access, you can send an e-mail message to ripem@ripem.msu.edu with several pieces of information: you must provide your citizenship (must be U.S. or Canadian to be authorized to receive RIPEM), you must state your willingness to comply with relevant export laws and software licenses, and you must provide the fully-qualified domain name of your Internet host and the country in which it resides. Assuming you qualify, you will receive a message with a special FTP name and password usable only from your specified host. RIPEM is also available from rsa.com with similar restrictions. The following README file on that host gives the instructions for accessing both RSARREF and RIPEM and gives you a good idea of the restrictions involved.

Please note: RSAREF and the associated programs distributed in this

directory are EXPORT CONTROLLED and are available via anonymous FTP to

U.S. persons only. Canadian citizens may obtain RSAREF via electronic

mail by sending a message acknowledging the four points below,

changing the country as necessary, to <rsarefadministrator@rsa.com>.

The RSAREF license is in the file 'license.txt'. Please read it. If

you acknowledge that:

     1. You have read the RSAREF Program License Agreement and

        understand and agree to be bound by its terms and conditions,

        including without limitation its restrictions on foreign

        reshipment of the Program and information related to the

        Program;

     2. The computer to which you are requesting that the program be

        transmitted is located in the United States of America;

     3. You are a United States citizen or a permanent resident of the

        United States; and

     4. The RSAREF Program License Agreement is the complete and

        exclusive agreement between RSA Laboratories and you relating

        to the Program, and supersedes any proposal or prior

        agreement, oral or written, and any other communications

        between RSA Laboratories and you relating to the Program,

then change to the following directory:

dist/U.S.onlyf1dd43

This is a timedependent directory. Check this file again if you can't

find the directory.

RSAREF is in the files 'rsaref.tar.Z' and 'rsaref.zip'.  On the first

you would run the commands:

     uncompress rsaref.tar.Z       # produces rsaref.tar

     tar xvf rsaref.tar

On the second you would run:

     pkunzip rsaref.zip

RIPEM, Mark Riordan's RSAREFbased privacyenhanced mail program, is

also distributed in that directory. 'ripem*.tar.Z' includes RSAREF,

so you only need to get one file. 'ripem.el' contains an Emacs command

interface to RIPEM. 'ripemmacintosh*.sit.hqx' is Raymond Lau's

version of RIPEM for the Macintosh(R), archived and compressed with

StuffIt and encoded in ASCII with BinHex.

A collection of RIPEM public keys is in the file 'rpubkeys'. Those

keys are uncertified, so use them AT YOUR OWN RISK. We just add

whatever people send to us. To have your RIPEM public keys added, send

electronic mail to <ripemkeys@rsa.com>.

If you have questions on RSAREF software, licenses, export

restrictions, or other RSA Laboratories offerings, send electronic

mail to <rsarefadministrator@rsa.com>.

Revised December 1, 1993

An Introduction to Pretty Good Privacy (PGP)

Pretty Good Privacy, or PGP, has the potential to be the Kermit of the 1990s. Kermit, the public-domain, file-transfer protocol developed at Columbia University, is—while not necessarily the fastest or most elegant—certainly the most widespread solution. It achieved its ubiquitous status because it was freely available and implementable on many diverse computer systems. PGP has yet to attain the same status, but like Kermit it is freely available for noncommercial use (but not in the public domain), and because the source code is available, it has the potential to be implemented on diverse systems.

PGP is an implementation of dual-key encryption for use with Internet mail and for general data security. PGP was written by Philip Zimmerman, and is credited to his company, Phil's Pretty Good Software. PGP also has a rather storied history, since it has been in the center of a controversy related to whether posting on an anonymous FTP site constitutes export, and it has drawn attention to the sensitivity about cryptography technology in some government circles. Early versions were subject to some RSA license questions as well. The current versions of PGP have been developed using the RSAREF Toolkit, a move that has apparently quelled any ambiguities about licensing.

Advantages of PGP

PGP is very explicitly a publicly available security solution—RSA for the "little guy." Its author is quite open and eloquent about the various issues of encryption security within the electronic society of the Internet. PGP's attractiveness goes beyond this availability, however. Unlike RIPEM and other PEM-based programs, PGP goes beyond simple encryption and includes built-in compression and ASCII encoding as well. PGP can perform the compression functions of zip-like programs and do ASCII encoding (similarly to uuencode) in one single operation and provide encryption security on top of it all. It can also produce clear text messages with encrypted signatures attached. PGP is very simple to use, but it is highly recommended that you read all the accompanying documentation to fully understand the concepts of its use as well as the program's limitations.

Where to Get PGP

The official distribution point for PGP in the U.S. is at the Massachusetts Institute of Technology (MIT), on the node net-dist.mit.edu, in the directory /pub/PGP. The README file in that directory will provide an explanation of the procedure for acquiring PGP from that site. An Archie search for PGP will turn up numerous other sites. Care should always be taken, however, to obtain the package from the most authoritative source available. A commercial version is available from a company named ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona 85029; tel. 602-944-0773).

How to Use PGP

After PGP is acquired, installed, and configured, it is fairly straightforward to use. The pgp command is used in combination with a number of subcommand options to perform various functions. Encryption is accomplished by using the -e option and decryption is accomplished by using the command pgp filename, where your filename usually has a .pgp extension. Another possible option is -a, which produces an ASCII-encoded output (radix-64) suitable for mailing over the Internet. For example, if you wanted to create a file encrypted with someone's public key and signed with your private key and suitable for sending via an e-mail message, you might use a command like the following:

pgp -esa testfile.txt Bob Jones

The following is a key-generation dialog resulting from the command pgp -kg.

pgp -kg

Pretty Good Privacy(tm) 2.6  Publickey encryption for the masses.

(c) 19901994 Philip Zimmermann, Phil's Pretty Good Software. 23 May 94

Distributed by the Massachusetts Institute of Technology. Uses RSAREF.

Export of this software may be restricted by the U.S. government.

Current time: 1994/06/07 15:56 GMT

Pick your RSA key size:

    1)   512 bits Low commercial grade, fast but less secure

    2)   768 bits High commercial grade, medium speed, good security

    3)  1024 bits "Military" grade, slow, highest security

Choose 1, 2, or 3, or enter desired number of bits: 2

Generating an RSA key with a 768bit modulus.

You need a user ID for your public key. The desired form for this

user ID is your name, followed by your Email address enclosed in

<angle brackets>, if you have an Email address.

For example: John Q. Smith <12345.6789@compuserve.com>

Enter a user ID for your public key:

John R. Smith <smith@somewhere.edu>

You need a pass phrase to protect your RSA secret key.

Your pass phrase can be any sentence or phrase and may have many

words, spaces, punctuation, or any other printable characters.

Enter pass phrase:

Enter same pass phrase again:

We need to generate 385 random bits. This is done by measuring the

time intervals between your keystrokes. Please enter some random text

on your keyboard until you hear the beep:

   0 * Enough, thank you.

.............++++ .................++++

Key generation completed.

The following is an example of a simple encryption/decryption process.

C:\PGP:pgp e c:\testfile.txt o testfile.pgp

Pretty Good Privacy(tm) 2.6  Publickey encryption for the masses.

(c) 19901994 Philip Zimmermann, Phil's Pretty Good Software. 23 May 94

Distributed by the Massachusetts Institute of Technology.  Uses RSAREF.

Export of this software may be restricted by the U.S. government.

Current time: 1994/06/07 14:42 GMT

Recipients' public key(s) will be used to encrypt.

A user ID is required to select the recipient's public key.

Enter the recipient's user ID: John R. Smith

Key for user ID: John R. Smith

768bit key, Key ID 0E922109, created 1994/06/07

.

Ciphertext file: testfile.pgp

C:\PGP:pgp testfile.pgp

Pretty Good Privacy(tm) 2.6  Publickey encryption for the masses.

(c) 19901994 Philip Zimmermann, Phil's Pretty Good Software. 23 May 94

Distributed by the Massachusetts Institute of Technology. Uses RSAREF.

Export of this software may be restricted by the U.S. government.

Current time: 1994/06/07 14:49 GMT

File is encrypted. Secret key is required to read it.

Key for user ID: John R. Smith

768bit key, Key ID 0E922109, created 1994/06/07

You need a pass phrase to unlock your RSA secret key.

Enter pass phrase: Pass phrase is good. Just a moment......

Plaintext filename: testfile

C:\PGP:
Caveats: Disadvantages of Using PGP

One disadvantage to relying upon PGP or other programs such as RIPEM is that your intended recipient must also have a copy of the program or of a program that supports the same implementation of the encryption algorithm. As a standard develops, it will be increasingly possible to have some assurance that your message can be decrypted and verified by the recipient. For example, the same is currently true of the MIME standard for mail attachments. Even though MIME is fairly well established, it will become a useful standard after most e-mail programs have support built in.

Unlike most MIME support, PGP and other similar programs are currently implemented independently of mail programs and require you to act upon a file before sending it via e-mail. The PEM standard seems to support integration of security into mail applications, but at the time of this writing, no major mail programs are supporting built-in PEM. Such independence will not necessarily prevent a standard from being established. Uuencode/uudecode and the various "zip" programs have achieved de facto standard status and are commonly available on many platforms and in many locations. A standard becomes useful when a "critical mass" of people or computers employ it, and PGP has as much chance of catching on as many other programs at this point.

Verifying the security of the security software and signature certificates can be somewhat problematic with PGP. Because no central authority provides or certifies the public keys for PGP, you must rely on "personal" authorities to verify signatures. PGP even supports this interpersonal certification method, enabling you to certify public keys on your key ring for later distribution to others and enabling you to specify your confidence level in a particular key based upon who else has certified it. MIT serves as the central authority for distribution of the PGP software, and also maintains some public keys.

Export controls and other licensing issues related to products using RSA security can be somewhat complex and sometimes confusing. The fact that U.S. export restrictions for this software are in place currently reduces the likelihood of it becoming a global standard. (While there is an international version of PGP named PGPui, establishment of a global standard is still somewhat inhibited by U.S. restrictions.) An overview of the political debate on this subject is not appropriate here, but if you research these programs you can't help but get a sense of the nature of the debate. The PGP documentation provides a good overview of some of the legal issues involved for this program and others like it.

Finding Out More about PGP and PEM

If you are new to RSA security and want to learn more about the general concepts and some of the technical issues involved, the PGP documentation files (pgtdoc1.txt and pgpdoc2.txt) are great places to start. As already mentioned, they provide a good overview of the technology involved, as well as an overview of the legal and licensing issues. The RIPEM documentation (ripemusr.txt) is also helpful in this regard. Other sources for information are the news groups alt.security.pgp, alt.security.ripem, sci.crypt, and info.pem-dev.

Subscribing and Staying Current on Listservs and Mailing Lists (How a Guru Is Able to Track So Many Groups)


ALEPH: The Rise and Fall of a Virtual Community --by Tod Foley


The Internet is touted as a place where people of diverse types and scattered localities can come together to work, play, and socialize in the spirit of the common good, congregating in all manner of self-organizing groups often known as virtual communities. As many Net gurus will tell you, e-mail lists present an excellent environment for the construction of such experimental communities: distribution is handled automatically, list subscription can be strictly controlled (if desired), and the asynchronous nature of the medium enables subscribers to participate at their own pace, in their own unique way.

To many people (including myself), this sort of structure represents total creative freedom, and perhaps the best environment yet designed for shared human labor and social expression. Last year, I was a key participant in one of these working environments—a progressive hothouse of furious metaphysical speculation called aleph@pyramid.com—where I learned that such freedom is not without its cost.

The Ambistructure of Aleph

One way of looking at an e-list is to liken the entire structure to a single massive mind, speaking to itself in a holographic and self-reflexive way. If this model were applied to Aleph, the diagnosis would have revealed a schizophrenic physicist/mystic, compulsively obsessed with the idea of codifying the twin universes of mind and matter into a single massive body of semiformal systems theory. The early days of Aleph, like those of most creative projects, were marked by feverish bouts of prolific brainstorming, and by an overly-broad definition of our interests and activities. There were no hierarchies and no official titles, just various "electronic citizens" adding the contents of their minds and hearts to this strange portable public forum. In general, Mitch Porter provided the basis of our scientific research, while I dug up the arcane works of mystics and Heath Rezabek ("free agent .rez") rallied the creative forces of Alephian text-artists.

Among the various tasks Aleph set upon were the Fixion project (an exercise in cooperative writing and creative role-playing, devised by .rez), the study of Applied Memetics (the means by which ideas spread from mind to mind), the creation of The Alephian Lexicon (a huge collection of useful terms and redefinitions from the realms of philosophy, science, and mysticism), Alpha/Omega (Mitch's idea for a global event heralding a huge worldwide networked Millennial Climax), Gaia 2000 (an experiment in the creation of real-life organizations based upon our fictional structures), and the formation of the HyperQabalah (an interactive Qabalistic Tree of Life). Ultimately, the Alephians assumed, this massive body of knowledge would result in the creation of what we called the AAleph—a relativistic online model of the universe. Unrealistic? Perhaps. Insane? Probably. But none of this stopped us from working. Aleph was unleashed upon the unsuspecting Net in May of 1993; by the end of July, our archives contained over three megabytes—800 pages—of dense and self-reflexive text, loosely referred to as The Alephian Current.

Weird Sister

In the first week of August, the list began receiving essays and letters from someone who called herself "Doctress Neutopia." She immediately proved herself to be a prolific writer, highly imaginative and not prone to holding back her opinion. The writings of The Doctress dealt consistently with issues of sexism and the oppression of females by males, and were generally of tremendous length and great personal investment. In shorter e-mailed notes, she spoke of adding a love saga to the rapidly-developing Fixion project. She also told us she was looking for "the A/O (Alpha/Omega) Man," who would join her in rule over the Earth when the Lovolution came. (In an early letter to me she asked if I was that man; a little stunned, I bounced back Mitch's address, figuring she was looking for the author of A/O.) Day after day, her writings poured in, screenful after screenful. She seemed to care little for our already-developing lines of work, preferring instead to stick to her own campaign and agenda. For a week or so, her words seemed illuminating in a unique way; her over-the-top, egocentric, dyslexic metaphor seemed intentionally postmodern, and her research skills were undeniable (even if her prose tended toward hyperbole). The Doctress was unconditionally welcomed to the list. Relatively speaking; Aleph had found another weird sister.

Upon acceptance, her tone changed almost immediately. As I soon found out, she was not one to submit herself to the communal-editor approach we fostered; the slightest criticism of her words would send her into a rant, and heaven forbid if that criticism come from a male! Beneath her hard-edged rhetoric, it soon became apparent that another thread existed: as she often revealed in her own poetic works and letters to the list, The Doctress was actually an extremely sensitive person who had been imprinted by various unfortunate incidents throughout her life. She was very badly wounded, very much in pain, and quite possibly out of touch with reality. As her words rolled in by the bufferload, she began painting for us her feverish visions of a "Neutopian Society" with herself at its apex; a world in which males were subservient to females. The issue of subservience was key—there had always been Alephians of both sexes, but sexism per se had never been an issue. Some Alephians became outraged by her continued presence, and several of them unsubbed from the list. Others supported her views but tried to convince her to adopt a more sensitive viewpoint. Some of us ignored her posts altogether, and, in their own naive neohumanistic ways, some of us assumed they could help her.

War in Cyberspace

Alone or in groups, the Alephians tried every possible means of communication to rationalize with "The Doctress." Her writings were analyzed, edited, ignored, attacked, defended, spoofed and satirized; she was contacted in private e-mail as well as in our public forum, and even spoke to a few of us live, via IRC channels and telephone. In synchronous dialogue—such as the five-hour telephone conversation we once had—she was quite personable, even engaging. In realtime, it was possible to nip potential misunderstandings in the bud, saying, "No no, I meant this," or "Why did you use that word?" But back online, driven by the juggernaut of her cybernetic persona, she again assumed her autocratic and ignominious tone.

Publicly, diehard Alephians tried to ignore her posts. In private e-mail, the same group worried about the future of the list. Certainly, we could have removed her "forcibly," but we didn't want to do that. Moderating is a tricky job, requiring a strange new social skillset (one which I'm not really sure I've developed completely), but the general consensus was: (a) if we kicked her off the list we would be acting like the "fascists" she often accused us of being, and (b) if anyone could actually help this woman, it would be us. While we brainstormed and deliberated, further arousing Neutopia's temper, the Alephian Current was becoming a socio-sexual flamewar. Things move very quickly in Cyberspace, and a reputation for a low signal-to-noise ratio can be a real subscription-killer.

On August 20th, Neutopia played out her gambit. I logged on that morning to find another e-comm from The Doctress in my .inbox, ominously entitled, "Urgency—THE COUP OF ALEPH." I opened the message and read. A sick feeling crept over me as I took in The Doctress' words; she was attempting to take over the list! In paragraph after ranting paragraph, Doctress Neutopia was dictating what the list was about, what our goals had become, and what our individual functions were, where we would strike, whom we would contact, and—of course—eliciting her call for the deific A/O Man who would sit beside her on the planetary throne. Her massive agenda called for investigations of NASA and military science institutes, microbiological research projects on the state of Gaia, phreaking and cracking maneuvers intended to "free" the Internet, public lectures and performance events, reports on extraterrestrial contacts, video documentaries, book summaries, activist mobilizations, recruitment projects, press releases and publicity campaigns, all aimed at the Neutopian goal of taking over the world.

For the next few weeks, what traffic remained on Aleph stumbled and halted. The Fixion project did its best to continue, but our dwindling population was making it difficult to maintain our original velocity. A month after the "coup," Neutopia was still arguing with nonsupporters, and our ongoing research projects had ceased entirely. Our subscription base was next to nil. Having spent hundreds of dollars in Aleph-related phone calls over the previous few weeks, Mitch and I were both seriously indebted to our respective phone companies and were having difficulty getting online. Soon after, free agent .rez and the Fixioneers moved on to another site (fixion-list@netcom.com), and the Alephian Current, for all intents and purposes, came to an end.

Alephtermath

The Doctress hung around for a little while after the dissolution but apparently found the lack of company disenchanting; she eventually discovered other elists, and recently began posting to Usenet. The funny thing is; sometimes I miss her.

Aleph still exists today, although lately it's held little more than a slow-motion conversation on "quantum consciousness" and a number of press releases reflected there from other lists. Mitch and I are back online regularly again, although neither of us is racking up linetime like it's going out of style (quite the opposite, in fact). As we enter the summer of 1994, a number of old and new friends have come around; there are signs that the Current may be unceremoniously returning to life, but cautiously, and in a totally new form (the cliche might be "sadder but wiser"). We haven't yet determined our "policy" regarding subscription denials, killfiles, and electronic coups ;-) , but like the futuristic telecommunications commercials constantly remind us: "We will." The moral of our story? Draw your own. Perhaps simply, "Caveat Listor."

To subscribe to the Aleph Elist, send e-mail to:

Majordomo@gossip.pyramid.com

Text body: subscribe aleph

To subscribe to the Fixion Elist, send e-mail to:

fixion-list-request@netcom.com

Subject: subscribe fixion-list

After years of subscribing to many active mailing lists and reading very active newsgroups, in self-defense I have developed a set of personal rules to guide my own activities in this regard and to keep my head above e-mail water.

Five Major Guru Rules for Reading All That Mail

Everyone's rules may be different and may reflect their own personality, but it's been my observation that people I know who read and track a lot of information in newsgroups and mailing lists seem to have several of these rules in common. They are presented here in order of importance (in my opinion). In some cases these may seem like common sense, but I've seen too many competent computing professionals bogged down by their e-mail reading to believe that even the most commonsensical rules are easily adopted.

1. Don't Read It All

There is an overwhelming urge, when presented with so much information, to try to absorb it all. A colleague of mine once decided that he should try to read all of Usenet news (back when there were less than 1500 groups) and even he, who was notorious for such exploits, gave up early in the process. The bottom line is that you don't have to read it all to be reasonably informed. Even the most professional of discussion groups has e-mail "noise" mixed in with the informative messages. Even some informative messages will not be of interest to you. I scan subject lines fairly thoroughly and delete many mail messages from my mailbox before reading them. You can use e-mail rules facilities to automatically discard messages such as those with the notorious unsubscribe in the subject field. The same is true for news readers that support kill files. By being very selective in what you read, you can cover a lot of territory without devoting your life to e-mail. Remember that in most cases, you can search a mailing list archive for a particular topic after the fact if you do miss something important the first time around.

2. Read Your Mail Every Day; Suspend Subscriptions When Away

If you are like me, with subscriptions to more than several active mailing lists, not reading mail for even one day will result in an uncomfortably large number of messages waiting for you on the next day. The best way to keep up with mail is to read it every day. I know several people who are continually catching up on their e-mail because they let one or more days go by without their attention. It's a simple rule, but it takes a lot of discipline for some people to follow it. One very nice feature of e-mail is that it is out-of-time communication, so it does not usually matter when or how often you read it. Sneaking in four fifteen-minute segments in one day is sometimes more productive than spending a whole hour at once. Also, my general rule is that if you are going to be gone a week or more, it's more productive to suspend delivery of your most active mailing lists than to weed through the volumes of messages when you get back. If you find an interesting thread occurring, you can usually retrieve list archives to catch up on the start of the "conversation."

3. Be Selective in Your Subscriptions

Find the mailing lists that provide the best information for your needs and stick with them. Most mailing list beginners, enthusiastic about the medium, have a tendency to over-subscribe, and even veterans sometimes have trouble letting go of a list that has previously been useful but is no longer relevant. Mailing lists can become part of your life and sometimes it's just hard to say goodbye. There are many good reference lists that can serve as pointers to information on a wide range of topics (new-list and net-happenings are a couple of examples). Sometimes you can fulfill an information need by searching a list's archives or by posting to a list of which you are not a member and asking for replies directly to your address.

4. When Possible, Read News Rather Than Mail

Mailing-list mail usually comes whether you want it to or not. Usenet news is there, waiting to be read. It doesn't count against your space quota if you skip a few days of reading, and you can easily read as much or as little as you wish. Many news readers have fairly sophisticated mechanisms for managing messages, making news reading more efficient than e-mail access. Many mailing lists are echoed to news and vice versa. The bit.listserv hierarchy is dedicated to echoing Bitnet Listserv mailing lists, and you can participate in the discussions via news without having to subscribe and then sign off later. This makes it much easier to visit lists on a temporary basis.

5. Organize Your Reading Process

Even if you are not by nature an organized person, you should try to organize your e-mail reading. I have my mail options set so that mail is automatically sorted by the From: field and the Date: field. This groups messages by sender or mailing list and places them in chronological order. I further reduce my view of messages to read only one group at a time. This can be accomplished in some mail programs with a SELECT command or by using a mail preprocessor or rules facility to file the mail into different folders based on the header fields. If you can further select messages based upon subject thread, you can further increase the efficiency of the process—especially for groups or lists that have frequent ongoing discussions on a particular topic. I find the thread feature of my news readers to be one of my favorite features. However you do it, an organized approach to reading news and mail will cut down on the amount of time needed and increase the amount of information you can track.

Previous Page TOC Index Next Page Home