electronic mail and unix

communications

First of a two-part

review of mailing

systems

Electronic mail and Unix by RICHARD ARMITAGE, DAVID HUTCHISON and STEPHEN J MUIR

E lectronic mail is a system whereby text messages may be passed from one computer user to one

or more people. Occasionally, electronic mail is used to send mail to programs instead. The recipients may be on the same computer or another one, accessible by one or more connecting networks. The messages pas- ed are stored at the receiving computer until the recipient deals with them. At that time he/she may use a program to read and perhaps reply to

Abstract: This is thefirst of two papers concerned with electronic mail. In this paper the essential elements of mail systems - the user agent and the mail delivery agent - are introduced and explained. The various specific mailing systems available with the Unix operating system are briefly compared. A basic minimum set and an extended set of mail user facilities are identified and presented.

Keywords: data processing, electronic, mail, Unix.

Richard Armitage, David Hutchison and

Stephen Muir are with the department of

Computing at the University of Lancaster.

or otherwise act upon his mail. This has important consequences since the two users do not need to use their computers at the same time: problems which plague telephone conver-

sations, such as different time zones and peculiar working hours, are solved.

The method used to transfer the mail messages from one site to another differs between different computer systems and networks. This

paper describes methods used by the Unix operating system and the wide variety of networks it supports.

Structure of electronic mail systems

A mail system typically consists of two separate parts to reflect the two distinct parts of the mail operation: the user agent, which deals with mail preparation and mail reading, and the mail delivery agent. This is essentially the structure used in the Message Handling System (MHS) model described in the CCITT X.400 series of standards documents. In that standard model the MHS consists of User Agents (UAs) and Message Transfer Agents (MTAs).

~0128 no 9 november 1986 0011-684X/86/090461-08$03.00 0 1986 Butterworth & Co (Publishers) Ltd 461

User of the

mail system

f ” User agent

responsible for all communications with

User’s mailbox

I the user I

Optional text editor I= ’ ’ t I

Alias 1 1 Mail delivery agent

responsible for deciding the best

expansions

network network

Figure I. A diagrammatic representation of the Sendmail system

User agent

This program is responsible for com- municating with the user of the mail

system in order to allow him to read and send mail. Essentially, this program has the task of hiding the implementation details of the mail system from the user while providing all the mail perusal and editing facilities that he might need.

Mail delivery agent

This program is responsible for delivering the mail messages which have been prepared by the user agent in communication with the user. The mail delivery agent at no time com- municates directly with the user but, rather, via the user agent. With the Unix operating system this operation

is often performed by the program Sendmail, from Britton Lee.

The delivery agent receives the preformatted message from the user agent and makes some decision about how best to deliver it and which networks, if any, should be used to connect to the mail recipient’s machine. This decision is often based upon the format used for the message address (described later). Having decided the next network to use, the delivery agent then, if necessary, reformats the message to conform to some of the standards used on that network. The delivery agent then calls the program responsible for the required network and allows this to initiate the mail transfer.

In addition, the system may also be receiving mail from other sites or users via connecting networks. These

messages are received by the programs monitoring and controlling those networks and are passed directly to the delivery agent. They are then examined to ascertain whether they are intended for users registered at this site. If they are, then they are passed to a local-mail delivery program which usually delivers them to the user’s mailbox (a file where in-

coming mail is always placed). If they are not intended for this site, then the

delivery agent treats them as if they are incoming messages, reformatting and retransmitting them as necessary.

Sendmail system

The sendmail system is an example of a mail delivery agent (see Figure 1). Sendmail runs within the computer receiving mail messages from any of several sources. Some examples are

given. In the local-mail system, mail re-

ceived from this source has been created by a mail user agent in con- junction with the user.

The Ethernet network allows mail to be received from the Ethernet local

area network. The UUCP* mail network will be

described in more detail later. In the X.25 network, mail is re-

ceived from a wide-area network con- forming to the X.25 standard proto-

cols. Once mail has been received from

any of these sources it is examined to ascertain the next stage of delivery. The program then reformats the message and passes it onto one of the following.

The local-mail system is where the message is usually intended for a user of this computer. Assuming the delivery address is not an alias, the local- mail system examines the users directory for a file named ‘forward’.

* UUCP (Unix to Unix copy) is a system

whereby a job may be issued to answer a

computer simply by placing it within its UUCP

queue.

462 data processing

If this file is present then the mail is redirected to the sites or files named within it. If not, then the mail is placed within the user’s mailbox at

‘/usrlspoollmaillxxxx’ (where ‘xxxx’ is the user’s login name).

In the Ethernet network, mail is transferred via an Ethernet local area

network. The UUCP Mail network allows

mail to be transferred via the UUCP Mail network (see later).

In the X.25 network, mail is transferred via a wide-area network con- forming to the X.25 protocols.

The sendmail system is controlled by a file called ‘/usrlliblsendmail.cf. This file, which must be continually updated to reflect changes in the directly connected networks, holds a series of instructions and rules to allow the system to:

Decide which network should be used to deliver a message. Modify the message addresses to conform to that network.

Modify the message text format to conform to that network. Perform site-specific tailoring.

Format of mail messages

An electronic mail message is usually constructed to conform to a particular format in order to allow the reading of messages to be, to a certain extent, automated. However, as the sender of a message can have no idea of the complexity of the software which will be used by the reader of the message, the format used must, necessarily, also be human readable.

The format chosen for the Unix mail system (and widely adopted by other systems) is described in the document RFC 822” and divides the mail message into two sections each separated by a blank line.

* RFC 822 is a suggested mail formatting standard from Bell Laboratories. The sugges-

tiun proved to be popular enough to be

adopted, almost unchanged, by many mail systems.

Subject: This is the message subject Date: Mon, 27 Jan 86 20:37:52 gmt Message-Id: <[email protected]>

Figure 2. Three different header lines

From: John Smith <jrs> Date: Mon, 27 Jan 86 20:37:52 gmt Message-Id: <[email protected]> To: fred, tom cc: harry, joe Subject: Mail test

Figure 3. Sender and recipients

Message header

The message header contains various information concerning the message, arranged as a series of lines or header fields. Each header field has a name which specifies, in a human readable format, the use of that line. For example, the header field:

Subject: This is the subject of the message

is a field containing a text string which indicates (to the user) the subject of the message. Although the title of the header field must be, and is, in a particular format, the infor-mation contained upon the line is not necessarily so. For example, the three different

header lines in Figure 2 contain, res- pectively, the message subject (which may be any string of characters), the date the message was sent (which must conform to a particular, human- readable format) and a unique identifier for the message which in general is in a non-intelligible format.

The information contained on a header line may also be continued onto further lines simply by preceding the following lines with a space or

TAB character. This feature is essential as some mail networks specify limits on the length of lines that they will carry.

The full format used for message headers is quite long and involved, although many fields are rarely used. In normal use the header field of a message is very similar to Figure 3.

Note that in Figure 3 the message header contains the names of both the sender and the recipients of the mail, in the ‘From’ and ‘To’ lines respec- tively, in a readable format. In addition, the ‘Cc’ field holds the names of recipients of carbon copies of the message. The ‘Message-Id’ field, as previously explained, simply contains a unique identifier which refers to this message and is produced automati-

cally by the mail delivery agent when the message is sent. It can be used to trace lost mail messages, to delete duplicates or as a search string in a file of messages. The ‘Subject’ field mere- ly contains a string which may be used by the User Agent program to provide a summary of the message.

The header section of a message can be of any length from, at one extreme, only three lines (the ‘From’, ‘To’ and ‘Date’ lines must be present) to, at the other extreme, many hundreds and is

~128 no 9 november 1986 463

separated from the message body by a single blank line.

Message body

In contrast to the message header, the message body has no fixed format at all and is simply a sequence of lines of text which make up the message itself. However, dependent upon the installation, there may be certain restrictions upon the text which may be placed in the message body. The most common restriction with Unix mail (as defined by the RFC 822 standard) is that no line in the message text may begin with the word ‘From’ as this is used by the mail listing program to separate the messages in any file (this is imposed by the User Agent). This is usually prevented by automatically preceding the word with a ‘>’ character.

For example, the message in Figure 4 would automatically be changed to that in Figure 5.

This is inconvenient but in general is a small price to pay for the lack of complexity in the mail format.

Message addressing

When sending a message, it is vital to be able to specify the address (or mailbox) of the user to whom it should be delivered. When mail is to

be sent on only one machine then this

presents no problem. The user simply enters the mail program and types something of the form:

mail fred

where ‘fred’ is the name of the user for whom the mail is intended (i.e. the mail recipient). The computer knows that there is only one user of that name and is able to deliver the mail message immediately. However, when the mail is intended for a user of another computer altogether, the sender must somehow indicate this by including the name of the destination machine within the mail address.

It should be noted that the name of the intended recipient of the mail cannot now be checked for validity by the sending machine as it will be known only by the destination machine. The sender must, then, send the message in good faith assuming

that the user actually exists on the remote machine. If, once the message has reached the remote computer, it is found that the intended recipient does in fact not exist, it is

usual for the remote computer to send back a mail message to that effect including the text of the message that was sent.

The address ‘postmaster’ is sup- posed to exist on every machine, and this is an alias for the maintainer of

From John Smith<jrs> Date: Mon, 27 Jan 86 20:37:52 gmt Message-Id: <[email protected]> To: fred Subject: Examination results

From Monday the examination results will be posted in the secretary’s office.

Figure 4. Text restrictions

From John Smith<jrs> Date: Mon, 27 Jan 86 20:37:52 gmt Message-Id: <[email protected]> To: fred Subject: Examination results

>From Monday the examination results will be posted in the secretary’s office.

Figure 5. Alternative style

the mail system. Any queries, inclu-

ding ‘What is the mail address for Joe Soap?‘, should be addressed to that mailbox.

Mail addressing formats

To make matters worse, in some network systems it is unlikely that the machine to which the mail is to be sent is connected directly to the sending computer at all. In this case it is necessary to arrange for the message to be forwarded by a sequence of intermediate sites.

A more flexible addressing format is required which can take all of these requirements into account. One scheme adopted is to specify the names of all the intermediate computers within the mail address itself. For example, to send a mail message from the computer named ‘seismo’ to ‘jr? at the computer ‘dcl-cs’ (Lancaster) it is necessary to have the message passed via the computers named ‘mcvax’ and ‘ukc’. If we assume that this is achieved by specifying the address ‘mcvax!ukc!dcl-cs!jrs’ then we may decode (or read) that as in Figure 6.

Thus, the message is passed from the source computer, ‘seismo’, to ‘mcvax’. It is then passed from ‘mcvax’ to ‘ukc’ which, in turn, passes the message to ‘dcl-cs’ (the Lancaster computer). ‘dcl-cs’, of course, knows the user ‘jrs’ and is able to deliver the message.

It is only necessary for each computer to know the name of the next computer in the chain and to pass the message on.

As previously mentioned, several different standards exist to specify the format of the path (known as a source route) to be taken by the mail message (different formats being used by different mail systems or networks). However, the most popular are as follows.

U UCP mail addressing format

This format (also known as bang

data processing

communications

mcvax!ukc!dcl-cs!jrs

[ 1 i i,,,, mail recipient (jrs)

The second forwarding computer

I The first forwarding computer _---

Figure 6. Message decoded

format) is used where mail is to be passed via a UUCP connection between two computers. If the mail message is intended for ‘user’ on computer ‘site 1’ and is passed from ‘site 4’ to ‘site 3’ to ‘site 2’ to ‘site 1’ then the address is written, at ‘site 4’, as:

site 3!site Z!site l!user

This is the format explained in previous section (it was chosen cause it is the most obvious of available formats).

the be-

the

This format (also known as RFC733 format), which is intended for use in a general mail transfer setting, was proposed by the UK Joint Network Team (JNT) as part of their Grey Book standard (see later). The format to be used for the same conditions as in the previous section is:

user”/osite l%site 2@site 3

It is obvious that this is slightly more complex than the previous format although the use of the ‘@?’ does make it obvious which site is the first on the list.

RFC 822 mail addressing format

This is the original mail address specification format and, for the above example, is written as:

@tile 3,@site 2:useQsite I

Note that this is more complex than either of the previous two forms with

~0128 no 9 november 1986

the user name within the list of sites. Problems exist with this format since many User Agent programs use the comma as a mailbox separator.

Problems with mail addressing

Even after we have correctly nego- tiated the problems above, and add-

ressed our message, problems still exist. For example, given the mail address presented previously:

mcvax!ukc!dcl-cs!jrs

The following problems present themselves. It is possible that, for instance, ‘mcvax’ might know a more direct route to ‘dcl-cs’ than the one specified in the list. In an ideal world it would be nice if ‘mcvax’ could arrange automatically to use this other route (thus saving time and money). However, since the addressing scheme requires only that a name be unique to the computers attached directly to it, ‘mcvax’ has no way of knowing if the ‘dcl-cs’ known by ‘ukc’ is the same one that it knows. This means that it is impossible for a site to shorten automatically the route taken by a message.

Since the name of a site, and the route needed to access it, follow no fixed pattern it is not generally possible for a mail sending program to calculate directly the best path to be taken for any mail message. Thus, the user must specify the full pathname for any message that he wishes to send. Even for the short example above this presents problems since

spelling errors cannot be immediately discovered. Also, connections are sub ject to change.

In an attempt to minimize these problems, over 5000 different UUCP sites have registered their names with the ‘UUCP mapping project’ (which

is part of the Usenet project. The Usenet (or User network) is the lar- gest single computer network in the

world and, as well as co-ordinating UUCP names, also provides a world-

wide news and information system. This attempts to ensure that the name given to any particular computer is unique so that both of the above problems are solved. If an intermediate computer knows a faster route to a named computer it is able to act

upon that information as there will be no other computer of that name attached to the network. In order to

specify that the UUCP mapping is to be used it is sometimes necessary to affix the word ‘.uucp’ to the end of an address. Thus the Lancaster computer (‘dcl-cs’) can also, and more fully, be accessed as ‘dci-cs.uucp’.

A program (called findpath) is available to calculate automatically the ‘fastest’ path to any site based upon its name (which, of course, should be unique). This is accomplished by the names and outgoing connections (with costs based on polling fre-

quency) of all the registered sites being sent from time to time to all sites on the network. Each site can

then run this program to calculate a database of sites and the best (cheap- est) routes to reach them from itself.

Since the system can now automatically generate the majority of address-paths, it is often enough to specify the address as:

[email protected]

and allow the system to calculate the best route (assuming the route is known to the Usenet database).

If, having calculated the best route, the machine the mail is to be sent to next is known to run similar software, then the address should be left unchanged since the next machine is

465

comp.lancs.ac.uk

I IL United Kingdom, which contains,

I I’ Academic community, which contains,

Lancaster University, which contains,

A Department of Computing.

Figure 7. Expanded address

nearer the final destination and, there- national addressing tree could be as

fore, is more likely to generate the shown in Figure 8. Note that not all

optimum route (because of the delay nodes correspond to actual machines

in propagating map changes). (there is no ‘ac.uk’ machine).

Although the UUCP mapping is an

improvement, it still does not solve all our problems. In particular, the names chosen for the sites do not, in

general, convey any information about the location of the sites (for example, the site ‘seismo’ could be anywhere), and a central body is required to register and control the sites on the network (which becomes more difficult as the number of registered sites grows). In an effort to improve this situation a domain- oriented addressing system has been introduced.

Also, in Figure 2, it is perfectly

possible for a site other than ‘lanes’ to register the names ‘camp’, ‘vaxl’ and ‘vax2’ as the registration specifies only

junet mil

berkeley

Domain-oriented addressing

In the domain-oriented addressing system the address of a site is built in a hierarchical form. Thus, for example, the Lancaster site (which under the UUCP mapping was ‘dcl-cs’ or ‘dcl-cs.uucp’) is registered as ‘camp. lancs.ac.uk’. This address may be expanded to read as in Figure 7.

The whole system is based upon a ‘tree structure’ in that each site (or word in the address) is a node or subdomain. There is one person (or organization) at each node of the tree responsible for assigning the names of the subdomains attached directly to that node. This means that a large central regulatory body is not required.

Key:

edu - junet - mil - 02 - uk - ac - co -

US educational sites Japanese Unix network US military sites Australian sites Sites in the UK Academic sites in the UK Commercial sites in the UK

For example, part of the inter- Figure 8. An example of domain-oriented addressing

that the sites directly attached to a node have different names (this is particularly useful with names as

imaginative as vaxl , vax2, . . . , vaxN, etc.).

Using this system it is also possible to specify only as much of a domain name as is necessary. The mailer is then able to expand it to the full domain name.

Thus, if the partially-qualified domain were to be specified:

‘cs.strath’

the mailer would try the following expansions (in order):

‘cs.strath.comp.lancs.ac.uk’ ‘cs.strath.lancs.ac.uk’ ‘cs.strath.ac.uk’ ‘cs.strath.uk

This works on the assumption that,

uk

basser ac

camp vax 1 vax 2

466 data processing

communications

the more local the machine, the more mail messages will be sent to it from that site. Although this works in the majority of cases, it is sometimes necessary to specify the fully qualified domain name in order to be unam-

biguous. Therefore, if a program is the sender of the mail, it should

always use the full form. The partial form is recognized to save users typing.

This system seems to satisfy all the criteria which have been required of the addressing system. However, the owners of the UK domain have decided that, within the UK, names should be displayed in the reverse order to that used elsewhere in the world. In this way, the name ‘camp. lancs.ac.uk’ (in little-endian form), which is valid anywhere in the world should, in the UK, be converted to ‘uk.ac.lancs.comp’ (i.e. in decreasing hierarchical order known as big- endian form).

It is intended that gateways to and from the UK should automatically convert to and from these forms but, in addition, many other UK sites have to perform the operation as well (as part of their mail relaying system). This then leads to many problems due to ambiguities. For example, given the address ‘vaxl.strath’, do we convert it to:

‘vaxl.strath.ac.uk’ or ‘uk.ac.lancs.vaxl.strath’ ?

There is, in general, no easy way to resolve these problems, as the sending site may have no knowledge of the receiving site’s subdomains (and thus not be able to see that an address is clearly nonsense). This is a great handicap to the automatic expansion of names for the domain-oriented addressing system. Although use of the full domain name circumvents most of these problems, it fails when the bottom-level subdomain matches a top level domain. For example, the address ‘uk.ac.rl.earn’ gives problems because both ‘uk’ and ‘earn’ are top-

level domains.

Many sites (should) make use of the smarter-mailer technique. Thus, if the mail delivery agent is presented with the address ‘[email protected]’, it should determine that ‘oz’ is the top- level domain for Australia, and pass it by the quickest route to the nearest Australian site. To give another example, given the address ‘ann@ihnpil.

uucp’, and given that the route to ‘ihnp4’ is not known, we would pass the mail to a site that does run the

software to determine the route. Naturally, if that site determines that the route is via us, we run into a mail

loop problem. This is partially alle- viated by returning an error mail message if the hop count exceeds a certain value (usually 30).

Transport of mail messages

Once the message has been correctly formatted by the User Agent, it is passed to the mail delivery agent for delivery. This program ensures, as far as possible, that the address and message text are valid. Assuming that they are, the delivery agent then examines the addresses and used these to decide, for each address, which network to use for delivering the message. Having decided the network to use, the delivery agent then passes the message to the program responsible for the control of the relevant network.

Directly connected systems

Many networks will allow the message to be passed (as far as the user is concerned) directly to the receiving site. Once there, the message is passed to the mail delivery agent at that site. That program then decides which user is to receive the message and finally passes the message to another program which delivers the message to the user.

Indirectly connected systems

Another class of network is one which

does not have a direct connection between the sending and receiving sites; the message must be passed via

intermediate sites. Although this presents no real problem, confusion can occur when a site tries to forward a message via a different network. This may involve modifying the address

format and this can, in some extreme cases, cause great confusion.

UUCP mail system

The UUCP network consists of a number of sites, each of which has a connection to one or more other sites. In this way, any site may be accessed as long as one knows which computers connect directly to those sites, and which connect to them. Fortu- nately, this information is registered as part of the Usenet project so that the sending site can automatically calculate the names of intermediate sites.

The system operates by placing the command:

rmail ‘<remainder-of-the-address- path>’

within the UUCP queue of the next computer in the chain. That computer then executes the command ‘rmail’ which simply passes the message to the delivery agent on its machine. This is repeated until the message reaches its destination.

To allow a reply to be automatically sent, the computer also places its own name onto the beginning of the ‘From:’ field within the message header.

It is also usual to create a trace of the sites that the message has passed through and the time at which it was processed. Thus, when each site receives the message, it places a field of the form:

Received from sireX by siteY;

22132, Man 27 Jan, 1986

onto the start of the message. The field is added, before all previous header fields, when the message is

~0128 no 9 november 1986 461

received rather than when it is forwarded in order to prevent forgery of

message paths.

JNT Grey Book mail transfer protocol

This protocol is very similar to the standard RFC 822 format. Essen- tially, when a message is sent, the mailer creates a JNT file containing:

l control information concerning the message in a special format,

l the message itself.

This file is then transferred between the computer systems. The receiver is then able to separate the control information and act upon it. This has the advantage that the sites do not have to convert the format of the message and its own internal addresses which is an error-prone task.

Essential elements of a mail system

Examination of the facilities provided

by other mail systems suggests that the following basic facilities are the minimum, essential elements, required of any mail system.

Send a mail message

It is essential to be able to send any

message to any (one or more) users. The Unix mail standard (as specified in RFC 822) allows for a mail message to be addressed to up to three groups of people, as described by the header fields:

To: These are the primary recipients

of the message.

Cc: These are carbon-copy reci-

pients of the mail message sent

to users who are not the main

recipients. This might be useful

for sending a discussion paper to

both members of a discussion

group (with the ‘To:’ field) and

other interested parties (with the

‘Cc:’ field).

Bee: This field holds the names of

recipients of ‘blind’ carbon-

copies of the message. It is

automatically deleted from the

copies sent to the primary and

‘Cc’ recipients when the message

is sent and is used for political

reasons.

Display a mail message

It is also vital to be able to read the mail messages sent from other users. It is essential that this is both simple and natural to perform with few or no system imposed constraints. Obvious- ly, the more difficult it is for a user to read his mail, the less likely he is to use the mail system.

Catalogue mail messages

Although the facilities described above are enough for a very basic mail system it is unrealistic to expect users to be satisfied with these alone. It is usually necessary to add the facility to catalogue the messages which the mail system has stored, in order to decide which message to read next. In addition it is useful, but not essential, to be able to decide which messages are new and which are simply unread.

Extensions to the basic commands

Further commands may be added to supplement the basic set. For in-

stance, to complement the ‘send a mail message’ facility, two more facilities may be implemented. These simply take some of the information which the ‘send’ command normally asks the user to provide from another

message.

Reply to a mail message

This facility allows the user to send a message in reply to one previously received. The system will automatically set the ‘To:’ field from either the ‘Reply-To:’ or ‘From’ field of the message (one of which must be present to conform to RFC 822). In addition, the ‘Subject:’ field is copied

from the original message with the prefix ‘Re:‘. Thus, in replying to the message:

From: fred@sitel To: harry@site2 Subject: Examination results

The message header would be:

From: harry@site2 To: fred@sitel Subject: Re: Examination results

Whereas, in reply to the message:

From: fred@sitel To: harry@site2 Reply-To: joe@sitel Subject: Examination results

The message header would be:

From: harry@site2 To: joe@sitel Subject: Re: Examination results

Forward a message

This facility allows a message to be forwarded to one or more users. The ‘Subject:’ field of the message is automatically set to the ‘Subject:’ field of the forwarded message and the message to be forwarded is included in the body of the new message. Thus

the message:

From: fred@sitel To: harryQsite2 Subject: Examination results

Do not forget that the examination

results are due today.

would, if forwarded to ‘joe@site l’,

become:

From: harry@site2

To: joe@sitel

Subject: Examination results

>From: fred@sitel

To: harry@site2

Subject: Examination results

Do not forget that the examination

results are due today.

Note that the ‘From’ in the message text has been changed to ‘>From:’ to avoid confusing the mail system. In this way the message has two headers although the second, being in the body of the message, is ignored.

468 data processing

communications

Mail folders mailbox to some other mailbox. How- This document was intended as a

In addition, it is also useful to be able ever, in more sophisticated systems suggested format for electronic mail

to control the disposition of mail which allow the user to read messages message. This format also forms the

messages. On a very basic system, all from other mailboxes a separate com- basis for the JNT Grey Book format

that is necessary is to delete messages mand may be required. previously referenced.

once they have been read. However, Allman E Sendmail Installation and

this is clearly unsuitable for any form Delete a message from a folder User Guide Britton-Lee Inc., (1983)

of practical system. The most com- Naturally a folder will soon fill up as This document describes the instalia-

mon technique adopted is that of the messages are filed within it (especially tion and day-to-day operation of the

mail folder. if the filing is the automatic result of sendmail Mail Delivery Agent sys-

A mail folder is simply a file of having read a message), so it is advi- tern..

messages (the system mailbox, for sable to be able to delete messages Sheens K Unix Mail Reference instance, is an example of such a mail easily. Manual Computer Science Div-

folder). The user is able to decide However, it is also desirable for the ision, University of California,

which messages are to be stored in mail system to allow the user the Berkeley, CA, USA (Unix BSD 4.2

which folders. In this way messages option of easily ‘undeleting’ the documentation 1984)

on similar subjects may be stored in messages again. The document describes the opera-

the same folders (in much the same tion of the Unix mail package for the

way as a paper mail filing system Copy a message from one folder to inexperienced user.

using manilla folders). The facilities another to control mail folders are usually as

Digital Equipment Corporation

follows. Similarly, it is useful to be able to VAXIVMS Mail Utility Reference

move messages between folders, in ManuaZ( 1984)

Create a folder order to file messages flexibly. This manual describes the operation

Obviously one must be able to create of the VAXIVMS mail utility as

mail folders at will for maximum Conclusion supplied by DEC.

Aexibility and ease of use. It is also These are the facilities necessary to Arnold K C Curses Screen Package

preferable for the system to be able to provide a usable general purpose mail User Guide University of California,

recognize these mail folders easily in system. It is possible to expand and Berkeley, CA, USA.

order to prevent the user from having provide embellishments to these as This document describes the opera-

to do SO himself. The ease with which the software &signer sees fit. Also tion of the curses screen control

folders are presented to the user is a system constraints and/or features package. The package allows screen

good guide to the whole system. If may make some facilities more or less control via a set of standard com-

this useful concept is cluttered with powerful than others. mands which is then converted to the

difficulties for the user then the whole commands required to control the

mail system is downgraded in useful- terminal.

ness. Further reading Joy W and Horton M The Vi Editor

User Guide

Delete a folder Alvey Directorate AZvey-Mail User Guide London (1984)

This document describes the opera-

If the user is to avoid the directory This document describes the Alvey- tion and use of the Vi general purpose

becoming too full it must be possible mail Mail package designed for used text editor. This editor is the standard

to delete unwanted mail folders. Al- with the Alvey project. for use with the Unix operating sys-

though this iS possible from outside KiIle, s E (Ed) Grey Book Mail tern.

the mail system it is preferable to Transfer Protocol Joint Network Allman P ‘ME’ Reference Manual

perform the operation from within the Team, University College London Electronics Research Laboratory,

system in order to simplify it for (1984) University of California, Berkeley,

inexperienced users. CA, USA.

This document details the format of This d ocument describes the ‘ME’

File a message within a folder mail messages for transport between macro package for the ‘NROFF’ text UK and European sites. It is based formatter 0

This facility is generally the default essentially upon the RFC 822 format.

action of having read a message. Cracker D H RFC 822 - Unix Department of Computing, University of- Lan-

Thus, as messages are read they are Mail Format Specification University caster, Engineering Building, Bailrig, Lancas- rer LA1 4YR UK,

unobtrusively copied from the system of Delaware (1983) EMail addresl: D H 6 camp lanes. ac. uk.

~0128 no 9 november 1986 469

electronic mail and unix

Documents