1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
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
friendlier.
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
mailbox.
-1-^L
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
specified by the user:
Name:(Person(User-Id(Mailbox) at Host),...),; ...
Where
"Name" is the name of the mailing list; "Person" presumably is
the name of the person receiving the mail;
"User-Id" is their online reference name (usually their signon
directory);
"Mailbox" is a a secondary mailbox/file;
and the rest conforms to RFC 680, although "@" may be used in
place of " at " in the specification.
Parentheses may be replaced by other bracketing pairs ([], {}, <>).
Quotation marks must be used any time the string contains ambiquating
characters, such as space or parentheses. The brackets after Name are
used to request exclusion of the address list from the message, instead
using text which gives the pathname to the source of the list.
The formal syntax for address specification, within network mail
actually sent, is included in the next section.
Not all of a specification is required, so perhaps some examples will
clarify things:.
A normal specification, as used currently: Walker at ISI
A named list, to be carried with the message, with the last
address not a member of the list: List:Walker at
ISI,greep@rand-isd;Action@ISI
A named list, NOT to be carried with the message; the list
contents will be replaced with a text string indicating the source
of the list -- not very useful if the list is typed in by the
user, rather than pulled from a file; therefore
List:(Walker@ISI,greep at rand); Action at ISi will be changed to
appear in the message as List:("/rnd/dcrocker/mail.list"); Action
at ISI
A list with personal names. separate from addresses: "Steve
Walker"[Walker at ISI], Bob<rha@isd>
A teleconferencing address list:
Talkers:"Dave C"(DCrocker(TC.msg)@isi),...;
-2-^L
Formal Specification
--------------------
The following modified BNF is to serve as a direct
addition/replacement for specifications within RFC 680. The fields
eliminated from the existing specification are: <addressee item>,
<address list>, <addressee>, <mailbox>, <host spec>, <attention spec>.
<user list>, <mailbox group>, <group numbers>, and <mailbox list>.
<Attention spec> can be performed through use of the person's name
and secondary file specification. Also, <Sender> should be modified
to be::
Sender = "SENDER: " Individual
And the added fields are:
Address-Field = Address-List / Address-List ,,:,
Address-Field
Address-List = Individual-List / Group-List
Group-List = Group-Name Group-Members
Group-Name = / Name ":"
Group-Members = Individual-List / L-Bracket Pathname
R-Bracket
Pathname = {A Name which can at least provide a
human with enough information to find
the file containing the Group-List}
Individual-List = Individual / Individual
Individual-List
Address Specification Syntax for Network Mail
Individual = Mailbox / Name L-Bracket Mailbox
R-Bracket
L-Bracket = "(" / "[" / "{" / "<"
R-Bracket = ")" / "]" / "}" / ">"
Mailbox = Id Secondary-File At Host
Id = Name
At = "" at "" / "@"
Host = {An acceptable host name}
-3-^L
Secondary-File = / L-Bracket Filename R-Bracket
Filename = Name
Name = {An Ascii string without carriage
return, line feed, space, '"', ",",
";", or any L-Bracket or R-Bracket} /
'"' {An Ascii string with any double
quotation marks doubled} '"'
The particular L-Bracket and R-Bracket characters used must match
each other. The requirement for quotation marks has been made more
severe than absolutely necessary in order to simplify software
requirments. Note also that the above specified syntax is for
inter-entity communications and is not necessarily indicative of what
the user types.
-4-
|
