|
0
|
1 Request For Comments: draft
|
|
|
2
|
|
|
3
|
|
|
4
|
|
|
5
|
|
|
6
|
|
|
7
|
|
|
8
|
|
|
9
|
|
|
10
|
|
|
11
|
|
|
12
|
|
|
13
|
|
|
14 Post Office Protocol (revised)
|
|
|
15 Extended Service Offerings
|
|
|
16
|
|
|
17
|
|
|
18 Wed Dec 18 23:17:52 1985
|
|
|
19
|
|
|
20
|
|
|
21 Marshall T. Rose
|
|
|
22
|
|
|
23 Northrop Research and Technology Center
|
|
|
24 One Research Park
|
|
|
25 Palos Verdes Peninsula, CA 90274
|
|
|
26
|
|
|
27 MRose%NRTC@USC-ECL
|
|
|
28
|
|
|
29
|
|
|
30
|
|
|
31
|
|
|
32 This memo suggests a simple method for workstations to dynamically
|
|
|
33 access mail from a discussion group server, as an extension to an
|
|
|
34 earlier memo which dealt with dynamically accessing mail from a
|
|
|
35 mailbox server using the Post Office Protocol (POP). This RFC
|
|
|
36 specifies a proposed protocol for the ARPA Internet community, and
|
|
|
37 requests discussion and suggestions for improvements. All of the
|
|
|
38 extensions described in this memo to the POP are OPTIONAL.
|
|
|
39
|
|
|
40 Request For Comments: draft M. Rose
|
|
|
41 POP (revised) Extended Service Offerings NRTC
|
|
|
42
|
|
|
43
|
|
|
44
|
|
|
45 Introduction and Motivation
|
|
|
46
|
|
|
47 It is assumed that the reader is familiar with the previous memo
|
|
|
48 that discusses the Post Office Protocol (POP) [MRose84]. This memo
|
|
|
49 describes extensions to the POP which enhance the service it offers
|
|
|
50 to clients. This additional service permits a client host to access
|
|
|
51 discussion group mail, which is often kept in a separate spool area,
|
|
|
52 using the general POP facilities.
|
|
|
53
|
|
|
54 The next section describes the evolution of discussion groups and
|
|
|
55 the technologies currently used to implement them. To summarize:
|
|
|
56
|
|
|
57 o An exploder is used to map from a single address to
|
|
|
58 a list of addresses which subscribe to the list, and redirects
|
|
|
59 any subsequent error reports associated with the delivery of
|
|
|
60 each message. This has two primary advantages:
|
|
|
61 - Subscribers need know only a single address
|
|
|
62 - Responsible parties get the error reports and not
|
|
|
63 the subscribers
|
|
|
64
|
|
|
65 o Typically, each subscription address is not a person's private
|
|
|
66 maildrop, but a system-wide maildrop, which can be accessed
|
|
|
67 by more than one user. This has several advantages:
|
|
|
68 - Only a single copy of each message need traverse the
|
|
|
69 net for a given site (which may contain several local
|
|
|
70 hosts). This conserves bandwidth and cycles.
|
|
|
71 - Only a single copy of each message need reside on each
|
|
|
72 subscribing host. This conserves disk space.
|
|
|
73 - The private maildrop for each user is not cluttered
|
|
|
74 with discussion group mail.
|
|
|
75
|
|
|
76 Despite this optimization of resources, further economy can be
|
|
|
77 achieved at sites with more than one host. Typically, sites with
|
|
|
78 more than one host either:
|
|
|
79
|
|
|
80 1. Replicate discussion group mail on each host. This
|
|
|
81 results in literally gigabytes of disk space committed to
|
|
|
82 unnecessarily store redundant information.
|
|
|
83
|
|
|
84 2. Keep discussion group mail on one host and give all users a
|
|
|
85 login on that host (in addition to any other logins they may
|
|
|
86 have). This is usually a gross inconvenience for users who
|
|
|
87 work on other hosts, or a burden to users who are forced to
|
|
|
88 work on that host.
|
|
|
89
|
|
|
90 As discussed in [MRose84], the problem of giving workstations
|
|
|
91 dynamic access to mail from a mailbox server has been explored in
|
|
|
92 great detail (originally there was [RFC918], this prompted the
|
|
|
93 author to write [MRose84], independently of this [RFC918] was
|
|
|
94 upgraded to [RFC937]). A natural solution to the problem outlined
|
|
|
95 above is to keep discussion group mail on a mailbox server at each
|
|
|
96 site and permit different hosts at that site to employ the POP to
|
|
|
97 access discussion group mail. If implemented properly, this
|
|
|
98 avoids the problems of both strategies outlined above.
|
|
|
99
|
|
|
100 ASIDE: It might be noted that a good distributed filesystem
|
|
|
101 could also solve this problem. Sadly, "good"
|
|
|
102 distributed filesystems, which do not suffer
|
|
|
103 unacceptable response time for interactive use, are
|
|
|
104 few and far between these days!
|
|
|
105
|
|
|
106 Given this motivation, now let's consider discussion groups, both in
|
|
|
107 general and from the point of view of a user agent. Following this,
|
|
|
108 extensions to the POP defined in [MRose84] are presented. Finally,
|
|
|
109 some additional policy details are discussed along with some initial
|
|
|
110 experiences.
|
|
|
111
|
|
|
112 What's in a Discussion Group
|
|
|
113
|
|
|
114 Since mailers and user agents first crawled out of the primordial
|
|
|
115 ARPAnet, the value of discussion groups have been appreciated,
|
|
|
116 (though their implementation has not always been well-understood).
|
|
|
117
|
|
|
118 Described simply, an discussion group is composed of a number of
|
|
|
119 subscribers with a common interest. These subscribers post mail to
|
|
|
120 a single address, known as a distribution address. From this
|
|
|
121 distribution address, a copy of the message is sent to each
|
|
|
122 subscriber. Each group has a moderator, which is the person that
|
|
|
123 administrates the group. The moderator can usually be reached at a
|
|
|
124 special address, known as a request address. Usually, the
|
|
|
125 responsibilities of the moderator are quite simple, since the mail
|
|
|
126 system handles the distribution to subscribers automatically. In
|
|
|
127 some cases, the interest group, instead of being distributed
|
|
|
128 directly to its subscribers, is put into a digest format by the
|
|
|
129 moderator and then sent to the subscribers. Although this requires
|
|
|
130 more work on the part of the moderator, such groups tend to be
|
|
|
131 better organized.
|
|
|
132
|
|
|
133 Unfortunately, there are a few problems with the scheme outlined
|
|
|
134 above. First, if two users on the same host subscribe to the same
|
|
|
135 interest group, two copies of the message get delivered. This is
|
|
|
136 wasteful of both processor and disk resources.
|
|
|
137
|
|
|
138 Second, some of these groups carry a lot of traffic. Although
|
|
|
139 subscription to an group does indicate interest on the part of a
|
|
|
140 subscriber, it is usually not interesting to get 50 messages or so
|
|
|
141 delivered to the user's private maildrop each day, interspersed with
|
|
|
142 personal mail, that is likely to be of a much more important and
|
|
|
143 timely nature.
|
|
|
144
|
|
|
145 Third, if a subscriber on the distribution list for a group becomes
|
|
|
146 "bad" somehow, the originator of the message and not the moderator
|
|
|
147 of the group is notified. It is not uncommon for a large list to
|
|
|
148 have 10 or so bogus addresses present. This results in the
|
|
|
149 originator being flooded with "error messages" from mailers across
|
|
|
150 the ARPA Internet stating that a given address on the list was bad.
|
|
|
151 Needless to say, the originator usually could not care less if the
|
|
|
152 bogus addresses got a copy of the message or not. The originator is
|
|
|
153 merely interested in posting a message to the group at large.
|
|
|
154 Furthermore, the moderator of the group does care if there are bogus
|
|
|
155 addresses on the list, but ironically does not receive notification.
|
|
|
156
|
|
|
157 There are various approaches which can be used to solve some or all
|
|
|
158 of these problems. Usually these involve placing an exploder agent
|
|
|
159 at the distribution source of the discussion group, which expands
|
|
|
160 the name of the group into the list of subscription addresses for
|
|
|
161 the group. In the process, the exploder will also change the
|
|
|
162 address that receives error notifications to be the request address
|
|
|
163 or other responsible party.
|
|
|
164
|
|
|
165 A complementary approach, used in order to cut down on resource
|
|
|
166 utilization of all kinds, replaces all the subscribers at a single
|
|
|
167 host (or group of hosts under a single administration) with a single
|
|
|
168 address at that host. This address maps to a file on the host,
|
|
|
169 usually in a spool area, which all users can access. (Advanced
|
|
|
170 implementations can also implement private discussion groups this
|
|
|
171 way, in which a single copy of each message is kept, but is
|
|
|
172 accessible to only a select number of users on the host.)
|
|
|
173
|
|
|
174 The two approaches can be combined to avoid all of the problems
|
|
|
175 described above.
|
|
|
176
|
|
|
177 Finally, a third approach can be taken, which can be used to aid
|
|
|
178 user agents processing mail for the discussion group: In order to
|
|
|
179 speed querying of the maildrop which contains the local host's copy
|
|
|
180 of the discussion group, two other items are usually associated with
|
|
|
181 the discussion group, on a local basis. These are the maxima and
|
|
|
182 the last-date. Each time a message is received for the group on the
|
|
|
183 local host, the maxima is increased by at least one. Furthermore,
|
|
|
184 when a new maxima is generated, the current date is determined.
|
|
|
185 This is called the last date. As the message is entered into the
|
|
|
186 local maildrop, it is given the current maxima and last-date. This
|
|
|
187 permits the user agent to quickly determine if new messages are
|
|
|
188 present in the maildrop.
|
|
|
189
|
|
|
190 NOTE: The maxima may be characterized as a monotonically
|
|
|
191 increasing quanity. Although sucessive values of the
|
|
|
192 maxima need not be consecutive, any maxima assigned
|
|
|
193 is always greater than any previously assigned value.
|
|
|
194
|
|
|
195 Definition of Terms
|
|
|
196
|
|
|
197 To formalize these notions somewhat, consider the following 7
|
|
|
198 parameters which describe a given discussion group from the
|
|
|
199 perspective of the user agent (the syntax given is from [RFC822]):
|
|
|
200
|
|
|
201 NAME Meaning: the name of the discussion group
|
|
|
202 Syntax: TOKEN (ALPHA *[ ALPHA / DIGIT / "-" ])
|
|
|
203 (case-insensitive recognition)
|
|
|
204 Example: unix-wizards
|
|
|
205
|
|
|
206 ALIASES Meaning: alternates names for the group, which
|
|
|
207 are locally meaningful; these are
|
|
|
208 typically used to shorten user typein
|
|
|
209 Syntax: TOKEN (case-insensitive recognition)
|
|
|
210 Example: uwiz
|
|
|
211
|
|
|
212 ADDRESS Meaning: the primary source of the group
|
|
|
213 Syntax: 822 address
|
|
|
214 Example: Unix-Wizards@BRL
|
|
|
215
|
|
|
216 REQUEST Meaning: the primary moderator of the group
|
|
|
217 Syntax: 822 address
|
|
|
218 Example: Unix-Wizards-Request@BRL
|
|
|
219
|
|
|
220 FLAGS Meaning: locally meaningful flags associated
|
|
|
221 with the discussion group; this memo
|
|
|
222 leaves interpretation of this parameter
|
|
|
223 to each POP implementation
|
|
|
224 Syntax: octal number
|
|
|
225 Example: 01
|
|
|
226
|
|
|
227 MAXIMA Meaning: the magic cookie associated with the
|
|
|
228 last message locally received for the
|
|
|
229 group; it is the property of the magic
|
|
|
230 cookie that it's value NEVER decreases,
|
|
|
231 and increases by at least one each time
|
|
|
232 a message is locally received
|
|
|
233 Syntax: decimal number
|
|
|
234 Example: 1004
|
|
|
235
|
|
|
236 LASTDATE Meaning: the date that the last message was
|
|
|
237 locally received
|
|
|
238 Syntax: 822 date
|
|
|
239 Example: Thu, 19 Dec 85 10:26:48 -0800
|
|
|
240
|
|
|
241 Note that the last two values are locally determined for the
|
|
|
242 maildrop associated with the discussion group and with each message
|
|
|
243 in that maildrop. Note however that the last message in the
|
|
|
244 maildrop have a different MAXIMA and LASTDATE than the discussion
|
|
|
245 group. This often occurs when the maildrop has been archived.
|
|
|
246
|
|
|
247 Finally, some local systems provide mechanisms for automatically
|
|
|
248 archiving discussion group mail. In some cases, a two-level archive
|
|
|
249 scheme is used: current mail is kept in the standard maildrop,
|
|
|
250 recent mail is kept in an archive maildrop, and older mail is kept
|
|
|
251 off-line. With this scheme, in addition to having a "standard"
|
|
|
252 maildrop for each discussion group, an "archive" maildrop may also
|
|
|
253 be available. This permits a user agent to examine the most recent
|
|
|
254 archive using the same mechanisms as those used on the current mail.
|
|
|
255
|
|
|
256 The XTND Command
|
|
|
257
|
|
|
258 The following commands are valid only in the TRANSACTION state of
|
|
|
259 the POP. This implies that the POP server has already opened the
|
|
|
260 user's maildrop (which may be empty). This maildrop is called the
|
|
|
261 "default maildrop". The phrase "closes the current maildrop" has
|
|
|
262 two meanings, depending on whether the current maildrop is the
|
|
|
263 default maildrop or is a maildrop associated with a discussion
|
|
|
264 group.
|
|
|
265
|
|
|
266 In the former context, when the current maildrop is closed any
|
|
|
267 messages marked as deleted are removed from the maildrop currently
|
|
|
268 in use. The exclusive-access lock on the maildrop is then released
|
|
|
269 along with any implementation-specific resources (e.g.,
|
|
|
270 file-descriptors).
|
|
|
271
|
|
|
272 In the latter context, a maildrop associated with a discussion group
|
|
|
273 is considered to be read-only to the POP client. In this case, the
|
|
|
274 phrase "closes the current maildrop" merely means that any
|
|
|
275 implementation-specific resources are released. (Hence, the POP
|
|
|
276 command DELE is a no-op.)
|
|
|
277
|
|
|
278 All the new facilities are introduced via a single POP command,
|
|
|
279 XTND. All positive reponses to the XTND command are multi-line.
|
|
|
280
|
|
|
281 The most common multi-line response to the commands contains a
|
|
|
282 "discussion group listing" which presents the name of the discussion
|
|
|
283 group along with it's maxima. In order to simplify parsing all POP
|
|
|
284 servers are required to use a certain format for discussion group
|
|
|
285 listings:
|
|
|
286
|
|
|
287 NAME SP MAXIMA
|
|
|
288
|
|
|
289 This memo makes no requirement on what follows the maxima in the
|
|
|
290 listing. Minimal implementations should just end that line of the
|
|
|
291 response with a CRLF pair. More advanced implementations may
|
|
|
292 include other information, as parsed from the message.
|
|
|
293
|
|
|
294 NOTE: This memo STRONGLY discourages implementations from
|
|
|
295 supplying additional information in the listing.
|
|
|
296
|
|
|
297
|
|
|
298 XTND BBOARDS [name]
|
|
|
299 Arguments: the name of a discussion group (optionally)
|
|
|
300 Restrictions: may only be given in the TRANSACTION state.
|
|
|
301 Discussion:
|
|
|
302
|
|
|
303 If an argument was given, the POP server closes the current
|
|
|
304 maildrop. The POP server then validates the argument as the
|
|
|
305 name of a discussion group. If this is successful, it opens
|
|
|
306 the maildrop associated with the group, and returns a
|
|
|
307 multi-line response containing the discussion group listing.
|
|
|
308 If the discussion group named is not valid, or the associated
|
|
|
309 archive maildrop is not readable by the user, then an error
|
|
|
310 response is returned.
|
|
|
311
|
|
|
312 If no argument was given, the POP server issues a multi-line
|
|
|
313 response. After the initial +OK, for each discussion group
|
|
|
314 known, the POP server responds with a line containing the
|
|
|
315 listing for that discussion group. Note that only
|
|
|
316 world-readable discussion groups are included in the multi-line
|
|
|
317 response.
|
|
|
318
|
|
|
319 In order to aid user agents, this memo requires an extension to
|
|
|
320 the scan listing when an "XTND BBOARDS" command has been given.
|
|
|
321 Normally, a scan listing, as generated by the LIST, takes the
|
|
|
322 form:
|
|
|
323
|
|
|
324 MSGNO SIZE
|
|
|
325
|
|
|
326 where MSGNO is the number of the message being listed and SIZE
|
|
|
327 is the size of the message in octets. When reading a maildrop
|
|
|
328 accessed via "XTND BBOARDS", the scan listing takes the form
|
|
|
329
|
|
|
330 MSGNO SIZE MAXIMA
|
|
|
331
|
|
|
332 where MAXIMA is the maxima that was assigned to the message
|
|
|
333 when it was placed in the BBoard.
|
|
|
334
|
|
|
335 Possible Responses:
|
|
|
336 +OK XTND
|
|
|
337 -ERR no such bboard
|
|
|
338 Examples:
|
|
|
339 C: XTND BBOARDS
|
|
|
340 S: +OK XTND
|
|
|
341 S: system 10
|
|
|
342 S: mh-users 100
|
|
|
343 S: .
|
|
|
344 C: XTND BBOARDS system
|
|
|
345 S: + OK XTND
|
|
|
346 S: system 10
|
|
|
347 S: .
|
|
|
348
|
|
|
349 XTND ARCHIVE name
|
|
|
350 Arguments: the name of a discussion group (required)
|
|
|
351 Restrictions: may only be given in the TRANSACTION state.
|
|
|
352 Discussion:
|
|
|
353
|
|
|
354 The POP server closes the current maildrop. The POP server
|
|
|
355 then validates the argument as the name of a discussion group.
|
|
|
356 If this is successful, it opens the archive maildrop associated
|
|
|
357 with the group, and returns a multi-line response containing
|
|
|
358 the discussion group listing. If the discussion group named is
|
|
|
359 not valid, or the associated archive maildrop is not readable
|
|
|
360 by the user, then an error response is returned.
|
|
|
361
|
|
|
362 In addition, the scan listing generated by the LIST command is
|
|
|
363 augmented (as described above).
|
|
|
364
|
|
|
365 Possible Responses:
|
|
|
366 +OK XTND
|
|
|
367 -ERR no such bboard
|
|
|
368 Examples:
|
|
|
369 C: XTND ARCHIVE system
|
|
|
370 S: + OK XTND
|
|
|
371 S: system 3
|
|
|
372 S: .
|
|
|
373
|
|
|
374 XTND X-BBOARDS name
|
|
|
375 Arguments: the name of a discussion group (required)
|
|
|
376 Restrictions: may only be given in the TRANSACTION state.
|
|
|
377 Discussion:
|
|
|
378
|
|
|
379 The POP server validates the argument as the name of a
|
|
|
380 discussion group. If this is unsuccessful, then an error
|
|
|
381 response is returned. Otherwise a multi-line response is
|
|
|
382 returned. The first 14 lines of this response (after the
|
|
|
383 initial +OK) are defined in this memo. Minimal implementations
|
|
|
384 need not include other information (and may omit certain
|
|
|
385 information, outputing a bare CRLF pair). More advanced
|
|
|
386 implementations may include other information.
|
|
|
387
|
|
|
388 Line Information (refer to "Definition of Terms")
|
|
|
389 ---- -----------
|
|
|
390 1 NAME
|
|
|
391 2 ALIASES, separated by SP
|
|
|
392 3 system-specific: maildrop
|
|
|
393 4 system-specific: archive maildrop
|
|
|
394 5 system-specific: information
|
|
|
395 6 system-specific: maildrop map
|
|
|
396 7 system-specific: encrypted password
|
|
|
397 8 system-specific: local leaders, separated by SP
|
|
|
398 9 ADDRESS
|
|
|
399 10 REQUEST
|
|
|
400 11 system-specific: incoming feed
|
|
|
401 12 system-specific: outgoing feeds
|
|
|
402 13 FLAGS SP MAXIMA
|
|
|
403 14 LASTDATE
|
|
|
404
|
|
|
405 Most of this information is entirely too specific to the UCI
|
|
|
406 Version of the Rand MH Message Handling System[MRose85].
|
|
|
407 Nevertheless, lines 1, 2, 9, 10, 13, and 14 are of general
|
|
|
408 interest, regardless of the implementation.
|
|
|
409
|
|
|
410 Possible Responses:
|
|
|
411 +OK XTND
|
|
|
412 -ERR no such bboard
|
|
|
413 Examples:
|
|
|
414 C: XTND X-BBOARDS system
|
|
|
415 S: + OK XTND
|
|
|
416 S: system
|
|
|
417 S: local general
|
|
|
418 S: /usr/bboards/system.mbox
|
|
|
419 S: /usr/bboards/archive/system.mbox
|
|
|
420 S: /usr/bboards/.system.cnt
|
|
|
421 S: /usr/bboards/.system.map
|
|
|
422 S: *
|
|
|
423 S: mother
|
|
|
424 S: system@nrtc
|
|
|
425 S: system-request@nrtc
|
|
|
426 S:
|
|
|
427 S: dist-system@nrtc-gremlin
|
|
|
428 S: 01 10
|
|
|
429 S: Thu, 19 Dec 85 00:08:49 -0800
|
|
|
430 S: .
|
|
|
431
|
|
|
432 Policy Notes
|
|
|
433
|
|
|
434 Depending on the particular entity administrating the POP service
|
|
|
435 host, two additional policies might be implemented:
|
|
|
436
|
|
|
437 1. Private Discussion Groups
|
|
|
438
|
|
|
439 In the general case, discussion groups are world-readable, any user,
|
|
|
440 once logged in (via a terminal, terminal server, or POP, etc.), is
|
|
|
441 able to read the maildrop for each discussion group known to the POP
|
|
|
442 service host. Nevertheless, it is desirable, usually for privacy
|
|
|
443 reasons, to implement private discussion groups as well.
|
|
|
444
|
|
|
445 Support of this is consistent with the extensions outlined in this
|
|
|
446 memo. Once the AUTHORIZATION state has successfully concluded, the
|
|
|
447 POP server grants the user access to exactly those discussion groups
|
|
|
448 the POP service host permits the authenticated user to access. As a
|
|
|
449 "security" feature, discussion groups associated with unreadable
|
|
|
450 maildrops should not be listed in a positive response to the XTND
|
|
|
451 BBOARDS command.
|
|
|
452
|
|
|
453 2. Anonymous POP Users
|
|
|
454
|
|
|
455 In order to minimize the authentication problem, a policy
|
|
|
456 permitting "anonymous" access to the world-readable maildrops for
|
|
|
457 discussion groups on the POP server may be implemented.
|
|
|
458
|
|
|
459 Support of this is consistent with the extensions outlined in this
|
|
|
460 memo. The POP server can be modified to accept a USER command for a
|
|
|
461 well-known pseudonym (i.e., "anonymous") which is valid with any
|
|
|
462 PASS command. As a "security" feature, it is advisable to limit
|
|
|
463 this kind of access to only hosts at the local site, or to hosts
|
|
|
464 named in an access list.
|
|
|
465
|
|
|
466 Experiences and Conclusions
|
|
|
467
|
|
|
468 All of the facilities described in this memo and in [MRose84] have
|
|
|
469 been implemented in MH #6.1. Initial experiences have been, on the
|
|
|
470 whole, very positive.
|
|
|
471
|
|
|
472 After the first implementation, some performance tuning was
|
|
|
473 required. This consisted primarily of caching the datastructures
|
|
|
474 which describe discussion groups in the POP server. A second
|
|
|
475 optimization pertained to the client: the program most commonly
|
|
|
476 used to read BBoards in MH was modified to retrieve messages only
|
|
|
477 when needed. Two schemes are used:
|
|
|
478
|
|
|
479 o If only the headers (and the first few lines of the body) of
|
|
|
480 the message are required, e.g., for a scan listing, then only
|
|
|
481 these are retrieved. The resulting output is then cached, on
|
|
|
482 a per-message basis.
|
|
|
483
|
|
|
484 o If the entire message is required, then it is retrieved intact,
|
|
|
485 and cached locally.
|
|
|
486
|
|
|
487 With these optimizations, response time is quite adequate when the
|
|
|
488 POP server and client are connected via a high-speed local area
|
|
|
489 network. In fact, the author uses this mechanism to access certain
|
|
|
490 private discussion groups over the ARPAnet. In this case, response
|
|
|
491 is still good. When a 9.6Kbps modem is inserted in the path,
|
|
|
492 response went from good to almost tolerable (fortunately the author
|
|
|
493 only reads a few discussion groups in this fashion).
|
|
|
494
|
|
|
495 To conclude: the POP is a good thing, not only for personal mail
|
|
|
496 but for discussion group mail as well.
|
|
|
497
|
|
|
498 References
|
|
|
499
|
|
|
500 [MRose84] M.T. Rose.
|
|
|
501 "Post Office Protocol (revised)", University of Delaware.
|
|
|
502 (October, 1984)
|
|
|
503
|
|
|
504 [MRose85] M.T. Rose, J.L. Romine.
|
|
|
505 "The Rand MH Message Handling System: User's Manual",
|
|
|
506 University of California, Irvine. (November, 1985)
|
|
|
507
|
|
|
508 [RFC822] D.H. Crocker.
|
|
|
509 "Standard for the Format of ARPA Internet Text
|
|
|
510 Messages", University of Delaware. (August, 1982)
|
|
|
511
|
|
|
512 [RFC918] J.K. Reynolds.
|
|
|
513 "Post Office Protocol", USC/Information Sciences Institute.
|
|
|
514 (October, 1984)
|
|
|
515
|
|
|
516 [RFC937] M. Butler, J.B. Postel, et. al.
|
|
|
517 "Post Office Protocol - Version 2", USC/Information Sciences
|
|
|
518 Institute.
|
|
|
519 (February, 1985)
|
