Received: from SOUTH-STATION-ANNEX.MIT.EDU by po10.MIT.EDU (5.61/4.7) id AA13785; Tue, 8 Dec 98 18:00:54 EST
Received: from MIT.MIT.EDU by MIT.EDU with SMTP
	id AA19366; Tue, 8 Dec 98 18:00:35 EST
Received: from FIZZ.MIT.EDU by MIT.MIT.EDU (5.61/4.7) id AA15978; Tue, 8 Dec 98 17:59:55 EST
Message-Id: <v03020902b2935a0e5ad5@[18.152.1.56]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 Dec 1998 17:59:59 -0500
To: "Murphy, Thomas C" <chris@MIT.EDU>, "Salemme, Anne" <salemme@MIT.EDU>
From: Robyn Fizz <fizz@MIT.EDU>
Subject: Final version of E-Mail article
Cc: joanne@MIT.EDU, "Hoffmann, Ron M" <hoffmann@MIT.EDU>

Thank you all for your speedy work in revising the e-mail article. Since
your word count was shorter, I needed to do a bit of padding -- so added
some verbiage to the first and last paragraphs.

Two other very minor tweaks:
* Replaced the word "thus" with ''so" and turned into one sentence: "E-mail
was not designed to be a broadcast mechanism, so you shouldn't use it to
send a general announcement to some large subset of the MIT community.

* Took out the second use of the word "setting" in "To solve the locked
maildrop problem when it occurs, you need to modify some Eudora settings to
increase the network timeout, uncheck the "leave mail on the server"
option, and check mail again."

Otherwise, your revision is intact. Here's a copy if you would like to look
it over one last time.

Regards,
Robyn

------------------------------------------------------------------

Feeling the Strain: E-Mail Can't Do It All

Joanne Costello

For many years, the MIT community has relied on e-mail for educational,
business, and personal needs. The e-mail programs we all use are based on
two Internet standards, the Simple Mail Transfer Protocol (SMTP) and Post
Office Protocol (POP).

These protocols were designed years ago, when e-mail consisted of text
messages sent from one individual to another or to a small group of
individuals. The simplicity of these protocols has kept them robust, but
has also allowed programmers to implement "features" that the original
designers of the protocols never intended. The result has been undue strain
on e-mail systems everywhere.

Broadcasting Messages
E-mail was not designed to be a broadcast mechanism: that is, you should
not use it to send a general announcement to some large subset of the MIT
community. This is true whether you include the recipient usernames
individually or use a mailing list. When a user sends out an announcement
to a huge list of recipients, the mail servers get overloaded, disks fill
up, and staff intervention is required. The overall result is a degradation
of service for all users. It is more appropriate to send one copy of the
announcement to a news group or a discuss meeting or to post the
announcement on the Web.

File Transfer
Nor was e-mail intended to be a file transfer mechanism. Unfortunately
e-mail clients such as Eudora make it easy to send large files to multiple
recipients. You should never send attachments larger than 1MB. They waste
disk space and can prevent someone's pobox from opening correctly because
the mail software times out waiting for large messages. Also, don't send
attachments of any size to large mailing lists.

Mail Storage
When you use POP, your e-mail is downloaded from the post office server to
your computer where you can read, store, and delete messages. You only need
to be connected to the server when you want to download or send messages.
All management of your e-mail - mailboxes, address books, and so on - is
done on your computer. This configuration makes POP awkward for those who
need to move from computer to computer. In an attempt to make up for this,
Eudora lets you set an option to "leave mail on the server."

The problem is that POP servers were not designed to be used as an archive
space for messages but rather for a one-time pick up of mail. The mechanism
used to track which messages have been downloaded is somewhat unreliable.
Users who check the "leave mail on the server" option eventually get
"Locked Maildrop" errors and cannot read their messages once the e-mail
stored on the server accumulates beyond a certain size.

To solve the locked maildrop problem when it occurs, you need to modify
some Eudora settings to increase the network timeout, uncheck the "leave
mail on the server" option, and check mail again. For step-by-step
instructions, go to

http://web.mit.edu/is/help/eudora/

and, under the Help and Information section, click on the Frequently Asked
Questions link.

To eliminate the locked maildrop problem in the future, don't store e-mail
on the server. For guidelines on using Eudora from home or on the road, see

http://web.mit.edu/is/help/eudora/home-use.html

In the Future
Information Systems is looking into new technologies and policies that can
alleviate some of these e-mail problems. However, even with new systems in
place, it will still be important for members of the community to be good
e-mail citizens. To recap, you should not send broadcast messages, attach
large files to outgoing mail, or store e-mail on the post office server.


+++--------------------------------------+++

Robyn Fizz
MIT Information Systems
N42-290b
77 Massachusetts Avenue
Cambridge, MA 02139-4307
Phone: (617) 253-0540
Fax: (617) 258-6875

For up-to-date computing news, see
<http://web.mit.edu/is/newslink>

+++--------------------------------------+++


