Browse Prior Art Database

Address Specification Syntax for Network Mail (RFC0720) Disclosure Number: IPCOM000003766D
Original Publication Date: 1976-Aug-05
Included in the Prior Art Database: 2004-Aug-15
Document File: 8 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Crocker: AUTHOR


Experience with processing mail on the Arpanet has pointed up many addressing issues, including:

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 43% of the total text.

Network Working Group                                         D. Crocker  (ISI)

Request for Comments: 720                                              Aug 1976

NIC #36337

References: RFC #680

          Address Specification Syntax for Network Mail

Experience with processing mail on the Arpanet has pointed up many

addressing issues, including:

1. People's names are not the same as their addresses;

2. Mailing lists can get quite long;

3. To allow responding, messages often need to carry all of their

mailing list with them;

4. It would be very useful to be able to send mail to files other

than the person's primary mailbox.

The current mail syntax, specified in RFC 680, does not provide a

convenient mechanism for distinguishing between a person's name and

their mailing address. In cases of shared directories, the ATTN: clause

is marginally adequate; however it is completely inappropriate for

single-user mailboxes in which the address specification is simply

cryptic. CMU's identification tags are good examples of this problem,

since they tend to appear to be random character sequences; the use of

initials as tags also points up the problem. If you doubt the

referential ambiguity of addresses, then try to use only the information

presented, rather than random personal knowledge, to discern who

Micro@ISI, JFH@ISI, or Greep@ISD are. By having a formal syntax for

separately specifying names and addresses, mail display software can

printout out name lists which only contain human names...makes things


The problem with long mailing lists is that, if included in the text of

a message, they often are longer than the main part of the message.

Group names are allowed in address fields primarily to circumvent this

problem. However the advent of semi-automated message answering, in

which a receiver's message system prepares address lists for reply

messages by copying appropriate fields from the original message, makes

the current mechanism deficient: having the group name means that the

receiver does not have the names/addresses of the members of the group.

A convention is generally followed, now, which has the group name be a

pathname to the file containing the list. Though facilitative, this

does not represent an adequate solution.

And lastly is the issue of multiple mailboxes for a single user. This

feature is probably has the largest potential for teleconferencing

applications, with messages for an on-going discussion automatically

placed into a separate mailbox. In the case of shared directories, this

mechanism also would allow easy channeling into each person's own



With these needs in mind, and until a more robust mail syntax and

protocol is specified, the following general syntax is proposed to

augment the existing syntax specified in RFC 680, for address fields