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
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
|
<pre>Network Working Group T. Myer
Request for Comment: 680 D. Henderson
NIC: 32116 BBN-TENEX
April 30, 1975
<span class="h1">Message Transmission Protocol</span>
Theodore H. Myer
D. Austin Henderson
BBN-TENEX
This document defines a number of message fields beyond those
discussed in <a href="./rfc561">RFC 561</a>. The overall message format is compatible with
<a href="./rfc561">RFC 561</a>; it makes extensive use of the miscellaneous fileds defined
within <a href="./rfc561">RFC 561</a>. The purpose of this document is to establish ARPANET
standards with regard to the syntax and semantics for these
additional fields. It is fully expected that all fields discussed
herein will not be automatically processed by all Message Servers;
however, the standard is necessary so that sites which wish to make
use of these fields have a standard to work with.
This document attempts to tread the narrow line between features for
human processing and features for machine processing. The general
feeling is that the fields listed are useful to people even if
automatic processing is not supplied. In most cases, machine-
readable notations have been enclosed in angle brackets (<>) to allow
easy non-ambiguous ways for automatic processes to know whether and
where to look in any field. The entire specifications has been made
excessively general to allow for experimentation. Future documents
based on experience will try to be more specific. This is simply the
next step following <<a href="./rfc561">RFC 561</a>>.
This document is contained in two sections. Section I contains the
relevant parts of <a href="./rfc561">RFC 561</a> which define the basic message syntax.
Section II lists the new (and existing) header fields together with
their proposed uses.
<span class="grey"> [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc680">RFC 680</a></span>
SECTION I: BASIC MESSAGE SYNTAX
<message> ::= <header><crlf><body>
<header> ::= <required header><optional header>
<required header> ::= <date item><sender item>
<date item> ::= DATE:<sp><date><sp>AT<sp>
<time>-<zone><crlf>
<date> ::= <vdate> ! <tdate>
<vdate> ::= <dayofmonth><SP><vmonth><SP><vyear>
<tdate> ::= <tmonth>/<dayofmonth>/<tyear>
<dayofmonth> ::= one or two decimal digits
<vmonth> ::= JAN ! FEB ! MAR ! APR ! MAY ! JUN !
JUL ! AUG ! SEP ! OCT ! NOV ! DEC
<tmonth> ::= one or two decimal digits
<vyear> ::= four decimal digits
<tyear> ::= two decimal digits
<zone> ::= EST ! EDT ! CST ! CDT ! MST ! MDT !
PST ! PDT ! GMT ! GDT
<time> ::= four decimal digits
<sender item := SENDER: <sp><user><sp>AT<sp><host>
<crlf>
<optional header> ::= <subjects><optional items>
<subjects> ::= !<subject item> !
<subject item><subjects>
<subject item> ::= SUBJECT:<sp><line><crlf>
<optional items> ::= <optional item> ! <optional item>
<optional items>
<optional item> ::= <messid> ! <addressee item> !
<other item>
<addressee item> ::= <addressee keyword>:<sp><addressee
list><crlf>
<addressee keywork> ::= TO:! CC:! BCC:!
<messid> ::= Message-ID:<sp>[<Net
Address>}]<line>
<crlf>
<other item> ::= <other keyword>:<sp><line><crlf>
<other keyword> ::= FROM ! IN-REPLY-TO! REFERENCES!
KEYWORD ! PRECEDENCE !
MESSAGE-CLASS!
SPECIAL-HANDLING! AUTHENTICATION!
ACCESSION-KEY
<address list> ::= <addressee> ! <addressee><addressee
list>
<addressee> ::= <mailbox> ! <mailbox group>
<mailbox> ::= <user><host spec><attention spec>
<host spec> ::= !@<host>
<attention spec> ::= (ATTN:<sp><user list>)
<span class="grey"> [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc680">RFC 680</a></span>
<user list> ::= <user> ! <user><user list>
<mailbox group> ::= <group name>:(<group numbers>)
<group numbers> ::= ! (<mailbox list>)
<mailbox list> ::= <mailbox> ! <mailbox>,<mailboxlist>
<body> ::= <line><CRLF> ! <line><CRLF><body>
<user> ::= <word>
<host> ::= a standard host name
<group name> ::= ! <word>
<line> ::= a string containing any of the 128
ASCII
characters except CR and LF
<word> ::= a string containing any of the 128
ASCII
characters except CR, LF, and SP
<CRLF> ::= CR LF
<SP> ::= space
Notes:
1. A message may have at most one MESSAGE-ID item.
2. All items with the same keyword must be grasped together.
Please note the following:
(1) The case (upper or lower) of keywords -- specifically, 'FROM',
'DATE', 'SUBJECT', 'AT', <host>, <zone>, <vmonth> and <keyword> --
is insignificant. Although 'FROM', for example, appears in
upper-case in the formal syntax above, in the header of an actual
message it may appear as 'FROM', 'from', or 'From', etc.
(2) No attempt has been made to legislate the format of <user>
except to exclude spaces from it.
(3) The time has no internal punctuation.
<span class="grey"> [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc680">RFC 680</a></span>
SECTION II: MESSAGE HEADER FIELDS
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">A</a>. ORIGINATOR SPECIFICATION FIELDS</span>
FROM
This field contains the identity of the person who wished this
message to be sent. This is expected to be the originator field
which is specified by the user in the case that the message is being
entered by one person for another. The message-creation process
should default this field to be the user entering the message. [The
usage for FROM and SENDER differs from that of <a href="./rfc561">RFC 561</a>.]
SENDER
This field contains the identity of the person who sends the message.
This field is expected to be set by the message-creation process
automatically. It is possible that some sites will not include this
field in external communications.
AUTHENTICATION
This field contains a description of which originator fields have
been authenticated, and by which operating systems. This field
should be created by message transmission and/or reception processes
(FTP/Operating System level).
It is expected that current system will be able to authenticate only
the SENDER field; however, later systems might have mechanisms to
verify that the FROM actually authorized the SENDER to act on his/her
behalf. It is expected that, when the FROM is authenticated, the
SENDER will no longer be necessary for external distribution.
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">B</a>. REFERENCE SPECIFICATION FIELDS</span>
MESSAGE-ID
This field contains a unique identifier to refer to this message.
The format for a message identifier is:
[Net Address]Text String CRLF
Examples:
[ISIB]7-DEC-74.14:23:45
[ARC]QLOURNAL 39274a3
<span class="grey"> [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc680">RFC 680</a></span>
The uniqueness of the message identifier is guaranteed by each net-
address message processor making the text which follows unique for
that net-address. This, specifically says net-address and not site
name. This would allow BBN (for instance) to allocate unique
identifiers over all four machines, which may be addressed as BBN
within the message system, thus producing a more integrated service
for their users.
The text following the net-address is not defined here, as the
problems associated with this specification are too great at this
time. However, the net-address should allow automatic processes to
determine if they can deal intelligently with the following text.
Several types of automatic processing by the local message reader are
thus possible: 1) if the site uses a filing mechanism known to the
reader, the reader can retrieve the message 2) if the site supports
remote message access (protocol not currently defined), the message
id can be passed to the remote site and the message has been filed in
the Datacomputer (using the entire message id [including net-address]
as the handle), the reader can retrieve it from the Datacomputer.
IN-REPLY-TO
The contents of this field identify previous correspondence which
this message answers. If message identifiers are used in this field,
they should be enclosed in angle brackets (<>).
REFERENCES
The contents of this field identify other correspondence which this
message references. If message identifiers are used, they should be
enclosed in angle brackets (<>).
KEYWORDS
This field contains keywords or phrases from the message, separated
by commas.
<span class="grey"> [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc680">RFC 680</a></span>
<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">C</a>. RECEIVER SPECIFICATION FIELDS</span>
TO
This field contains the identity of the primary receivers of the
message.
CC
This field contains the identity of the secondary receivers of the
message.
BCC
This field contains the identity of the tertiary receivers of the
message. This field should not be made available to the primary and
secondary receivers, but it may be recorded to provide information
for access control.
<span class="h2"><a class="selflink" id="appendix-D" href="#appendix-D">D</a>. MESSAGE-TYPE SPECIFICATION FIELDS</span>
PRECEDENCE
This field describes the importance and urgency of the message.
Machine-readable notations will be enclosed in angle brackets (<>).
<PRIORITY> means that the message should be delivered as soons as
possible. <ROUTINE> means that Priority processing is not necessary.
Plain text may also be included in this field.
MESSAGE-CLASS
This field describes the "legal" status of the message. Examples:
Official, Unofficial, Record, Off the Record, Junk Mail. No
automatic processing of this field is immediately expected. Certain
message creation processes might, for example, always insert:
MESSAGE CLASS: Unofficial ARPANET Message
SPECIAL-HANDLING
This field contains any special instructions with regard to the
handling of the message at the receiver's end. Machine-readable
notations will be enclosed in angle brackets (<>). <PRIVATE> means
that the message reception process should not aid the user in
circulating copies to others. Plain text may also be included in
this field.
[Page 6]
</pre>
|
