5 draft POP Version 3: More Service Offerings Apr 92
8 Post Office Protocol: Version 3
11 Fri Apr 17 21:03:20 1992
15 Dover Beach Consulting, Inc.
16 mrose@dbc.mtview.ca.us
23 1. Status of this Memo
25 This memo provides information for the Internet community. It
26 does not specify any standard. Distribution of this memo is
27 unlimited. Please send comments to the author.
32 This memo suggests some modest enhancements to version 3 of
33 the Post Office Protocol (RFC 1081). All of these extensions
34 are optional. In particular, administrators should examine
35 their environment to see if any of these enhancements are
64 draft POP Version 3: More Service Offerings Apr 92
67 3. Historical Overview
69 The Post Office Protocol (POP) was developed to provide a
70 simple mechanism for workstations to download their mailboxes
71 from workgroup and departmental servers. Typically, the
72 workstations and servers are interconnected via a LAN or
73 perhaps an internet-mesh with reasonable throughput and
76 As use of the Internet suite of protocols has grown, different
77 kind of environments are beginning to use the POP. This memo
78 suggests optional enhancements to the POP to allow it to
79 function better in these environments.
123 draft POP Version 3: More Service Offerings Apr 92
128 Each POP session starts with a USER/PASS exchange. This
129 results in a POP-subscriber password being sent in the clear
130 on the network. For intermittent use of POP, this may not
131 introduce a sizable risk. However, many POP client
132 implementations connect to the POP server on a regular
133 basis -- to check for new mail. Further the interval of
134 session initiation may be on the order of five minutes.
135 Hence, the risk of password capture is greatly enhanced.
137 A new method of authentication is required which provides for
138 both origin authentication and replay protection, but which
139 does not involve sending a password in the clear over the
140 network. This memo introduces a new command, APOP, to provide
143 A POP server which implements the APOP command will include a
144 timestamp in its banner greeting. The syntax of the timestamp
145 corresponds to the `msg-id' in RFC 822, and MUST be different
146 each time the POP server issues a banner greeting. For
147 example, on a UNIX implementation in which a separate UNIX
148 process is used for each instance of a POP server, the syntax
149 of the timestamp might be:
151 <process-ID.clock@hostname>
153 where `process-ID' is the decimal value of the process's PID,
154 clock is the decimal value of the system clock, and hostname
155 is the fully-qualified domain-name corresponding to the host
156 where the POP server is running.
158 The POP client makes note of this timestamp, and then issues
159 the APOP command. The syntax of this command is:
163 The `name' parameter is a locally-significant string which
164 identifies a particular POP-subscriber. The `digest'
165 parameter is calculated by applying the MD5 algorithm[1] to a
166 string consisting of the timestamp (including angle-brackets)
167 followed by a shared secret. This shared secret is a string
168 known only to the POP client and POP server. Great care
169 should be taken to prevent unauthorized disclosure of the
170 secret, as knowledge of the secret will allow any entity to
182 draft POP Version 3: More Service Offerings Apr 92
185 successfully masquerade as the named POP-subscriber. The
186 `digest' parameter itself is a 16-octet value which is sent in
189 When the POP server receives the APOP command, it verifies the
190 digest provided. If the digest is correct, the POP server
191 issues a positive response, and the POP session enters the
192 TRANSACTION state. Otherwise, a negative response is issued
193 and the POP session remains in the AUTHORIZATION state.
197 S: +OK POP server ready <1896.697170952@dbc.mtview.ca.us>
199 S: +OK password required for mrose
200 C: APOP c4c9334bac560ecc979e58001b3e22fb
201 S: +OK maildrop has 1 message (369 octets)
203 In this example, the shared secret is the string `tanstaaf'.
204 Hence, the MD5 algorithm is applied to the string
206 <1896.697170952@dbc.mtview.ca.us>tanstaaf
208 which produces a digest value of
210 c4c9334bac560ecc979e58001b3e22fb
241 draft POP Version 3: More Service Offerings Apr 92
244 5. The XTND SCAN command
246 The current POP model works best when network latency and
247 throughput is on the order provided by most LANs. However,
248 when POP is used over low-speed connections (e.g., 2400 baud
249 dialup lines), the POP does not work well.
251 Historically, the POP model has been to make only minimal
252 requirements on the POP server. In order to more effectively
253 operate over low-speed connections, this model must be
254 modified somewhat. Implementation experience shows that the
255 largest improvement can be achieved by making one shift:
256 having the POP server generate a scan listing for the POP
257 client. This memo introduces a new command, XTND SCAN, to
258 provide this functionality.
260 A POP client issues the XTND SCAN command during the
261 TRANSACTION state. The syntax of this command is:
263 XTND SCAN width [format]
265 The `width' parameter is the maximum length for a scan
266 listing. The optional `format' parameter is a quoted-string
267 with the semantics of an mh-format(5) string[2]. If the
268 `format' parameter is not given, the POP server uses a
269 locally-defined default value. Note that the resulting format
270 string must not contain CR or LF.
272 The `format' parameter is the only token in the POP which must
273 be enclosed in double-quotation marks. Within the string, two
274 special sequences are recognized:
279 Otherwise, each character is used verbatim. Note that this
280 string can be quite long (on the order of 400 characters).
282 When the POP server receives the XTND SCAN command and if it
283 implements it, it issues a positive response. Otherwise a
284 negative response is issued. Thereafter, whenever the POP
285 client issues a LIST command, the syntax of the resulting
286 `scan listing' is of the form:
300 draft POP Version 3: More Service Offerings Apr 92
303 As with the standard POP, the `msgno' field gives the message
304 number and the `size' field gives the size of the message in
305 octets. The `string' parameter, which immediately follows the
306 `#' character is the string calculated when the formatting
307 string is applied to the message. Note that the `string' may
312 S: XTND SCAN 80 "%4(msg)%<(cur)+%| %>%<{replied}-%|...
315 C: +OK 1 369 # 1 02/03 17:49PST To:mrose test<<
359 draft POP Version 3: More Service Offerings Apr 92
364 MH 6.7.4 implements the POP extensions described in this memo.
365 Contact Bug-MH@ics.uci.edu for information on how to get MH.
418 draft POP Version 3: More Service Offerings Apr 92
423 The author gratefully acknowledges the comments of Alfred
424 Grimstad and Neil Ostroff of Bellcore, and Keith McCloghrie of
477 draft POP Version 3: More Service Offerings Apr 92
482 [1] R.L. Rivest, The MD5 Message-Digest Algorithm. Request
483 for Comments 1321, (April, 1992).
485 [2] M.T. Rose, J.L. Romine, The Rand MH Message Handling
486 System: User's Manual, November, 1985.
536 draft POP Version 3: More Service Offerings Apr 92
542 1 Status of this Memo ................................... 1
543 2 Abstract .............................................. 1
544 3 Historical Overview ................................... 2
545 4 The APOP command ...................................... 3
546 4.1 Usage Example ....................................... 4
547 5 The XTND SCAN command ................................. 5
548 5.1 Usage Example ....................................... 6
549 6 Implementations ....................................... 7
550 7 Acknowledgements ...................................... 8
551 8 References ............................................ 9