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
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
|
<pre>Network Working Group M. Butler
Request for Comments: 937 J. Postel
D. Chase
J. Goldberger
J. K. Reynolds
Obsoletes: RFC <a href="./rfc918">918</a> ISI
February 1985
<span class="h1">POST OFFICE PROTOCOL - VERSION 2</span>
Status of this Memo
This RFC suggests a simple method for workstations to dynamically
access mail from a mailbox server. This RFC specifies a proposed
protocol for the ARPA-Internet community, and requests discussion and
suggestions for improvement. This memo is a revision of <a href="./rfc918">RFC 918</a>.
Distribution of this memo is unlimited.
Introduction
The intent of the Post Office Protocol Version 2 (POP2) is to allow a
user's workstation to access mail from a mailbox server. It is
expected that mail will be posted from the workstation to the mailbox
server via the Simple Mail Transfer Protocol (SMTP). For further
information see <a href="./rfc821">RFC-821</a> [<a href="#ref-1" title=""Simple Mail Transfer Protocol"">1</a>] and <a href="./rfc822">RFC-822</a> [<a href="#ref-2" title=""Standard for the Format of ARPA-Internet Text Messages"">2</a>].
This protocol assumes a reliable data stream such as provided by TCP
or any similar protocol. When TCP is used, the POP2 server listens
on port 109 [<a href="#ref-4" title=""Assigned Numbers"">4</a>].
System Model and Philosophy
While we view the workstation as an Internet host in the sense that
it implements IP, we do not expect the workstation to contain the
user's mailbox. We expect the mailbox to be on a server machine.
We believe it is important for the mailbox to be on an "always up"
machine and that a workstation may be frequently powered down, or
otherwise unavailable as an SMTP server.
POP2 is designed for an environment of workstations and servers on a
low-delay, high-throughput, local networks (such as Ethernets). POP2
may be useful in other environments as well, but if the environment
is substantially different, a different division of labor between the
client and server may be appropriate, and a different protocol
required.
Suppose the user's real name is John Smith, the user's machine is
called FIDO, and that the mailbox server is called DOG-HOUSE. Then
<span class="grey">Butler, et. al. [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA
(not JSmith@FIDO.ARPA).
That is, the destination of the mail is the mailbox on the server
machine. The POP2 protocol and the workstation are merely a
mechanism for viewing the messages in the mailbox.
The user is not tied to any particular workstation for accessing his
mail. The workstation does not appear as any part of the mailbox
address.
This is a very simple protocol. This is not a user interface. We
expect that there is a program in the workstation that is friendly to
the user. This protocol is not "user friendly". One basic rule of
this protocol is "if anything goes wrong close the connection".
Another basic rule is to have few options.
POP2 does not parse messages in any way. It does not analyze message
headers (Date:, From:, To:, Cc:, or Subject:). POP2 simply transmits
whole messages from a mailbox server to a client workstation.
The Protocol
The POP2 protocol is a sequence of commands and replies. The design
draws from many previous protocols of the ARPA-Internet community.
The server must be listening for a connection. When a connection
is opened the server sends a greeting message and waits for
commands. When commands are received the server acts on them and
responds with replies.
The client opens a connection, waits for the greeting, then sends
the HELO command with the user name and password arguments to
establish authorization to access mailboxes. The server returns
the number of messages in the default mailbox.
The client may read the default mailbox associated with the user
name or may select another mailbox by using the FOLD command. The
server returns the number of messages in the mailbox selected.
The client begins a message reading transaction with a READ
command. The read command may optionally indicate which message
number to read, the default is the current message (incremented
when a message is read and set to one when a new folder is
selected). The server returns the number of characters in the
message.
<span class="grey">Butler, et. al. [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
The client asks for the content of the message to be sent with the
RETR command. The server sends the message data.
When all the data has been received the client sends an
acknowledgment command. This is one of ACKS, ACKD, and NACK.
ACKS means "I've received the message successfully and please
keep it in the mailbox".
ACKD means "I've received the message successfully and please
delete it from the mailbox".
NACK means "I did not receive the message and please keep it in
the mailbox".
In the case of ACKS or ACKD the server increments the current
message indicator. In the case of NACK the current message
indicator stays the same.
In all cases the server returns the number of characters in the
(now) current message.
The client terminates the session with the QUIT command. The
server returns an ok.
<span class="grey">Butler, et. al. [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
The Normal Scenario
Client Server
------ ------
Wait for Connection
Open Connection -->
<-- + POP2 Server Ready
Wait for Command
HELO Fred Secret -->
<-- #13 messages for you
Wait for Command
READ 13 -->
<-- =537 characters in that message
Wait for Command
RETR -->
<-- (send the message data)
Wait for Command
ACKS -->
<-- =0 no more messages
Wait for Command
QUIT -->
<-- + OK
Close connection --> <-- Close connection
Wait for Connection (go back to start)
Conventions
Arguments
These arguments have system specific definitions.
user - A login account name.
password - The password for the login account.
mailbox - A mailbox name (also called a mail folder).
<span class="grey">Butler, et. al. [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Default Mailboxes
TOPS-20
MAIL.TXT.1 - from login directory
UNIX
both
/usr/spool/mail/user
and
/usr/user/Mail/inbox/*
where "user" is the user value supplied in the HELO command.
End of Line
End of Line is Carriage Return (CR) followed by Line Feed (LF).
This sequence is indicated by "CRLF" in this document. This end
of line convention must be used for commands and replies.
Message Length
The reply to the READ command or an acknowledgment command (ACKS,
ACKD, NACK) is the length (a character count) of the next message
to be transmitted. This includes all the characters in the data
transmitted. CRLF counts as two characters. A length of zero
means the message does not exist or is empty. A request to
transmit a message of zero length will result in the server
closing the connection. The message is transmitted in the
standard internet format described in <a href="./rfc822">RFC-822</a> [<a href="#ref-2" title=""Standard for the Format of ARPA-Internet Text Messages"">2</a>] and NVT-ASCII.
This may be different from the storage format and may make
computing the message length from the stored message non-trivial.
Message Numbers
The reply to the HELO and FOLD commands is a count of the number
of messages in a the selected mailbox. The READ command has a
message number as an optional argument. These numbers are
decimal, start at one, and computed with respect to the current
mailbox. That is, the first message in a mailbox is message
number 1.
Numbers
All numbers in this memo and protocol are decimal.
<span class="grey">Butler, et. al. [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Quoting
In a few cases, there may be a need to have a special character in
an argument (user, password, or mailbox) that is not allowed by
the syntax. For example, a space in a password. To allow for
this, a quoting convention is defined. Unfortunately, such
quoting conventions "use up" another otherwise uninteresting
character. In this protocol the back slash "\" is used as the
quote character. To include a space in an argument the two
character sequence "back-slash, space" is transmitted. To include
a back-slash in an argument the two character sequence
"back-slash, back-slash" is transmitted. This quoting convention
is used in the command arguments only, it is not used in the mail
data transmitted in response to a RETR command.
Reply Strings
The first character is required to be as specified (i.e.,
"+", "-", "=", "#"). The optional strings that follow can be
whatever the implementer thinks is appropriate.
Definitions of Commands and Replies
Summary of Commands and Replies
Commands Replies
-------- -------
HELO user password + OK
FOLD mailbox - Error
READ [n] #xxx
RETR =yyy
ACKS
ACKD
NACK
QUIT
<span class="grey">Butler, et. al. [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Commands
HELO user password
The Hello command identifies the user to the server and carries
the password authenticating this user. This information is
used by the server to control access to the mailboxes. The
Hello command is the "HELO" keyword, followed by the user
argument, followed by the password argument, followed by CRLF.
Possible responses:
"#nnn"
where nnn is the number of messages in the default
mailbox,"
"- error report" and Close the connection.
FOLD mailbox
The Folder command selects another mailbox or mail folder. The
server must check that the user is permitted read access to
this mailbox. If the mailbox is empty or does not exist, the
number of messages reported is zero. The Folder command is the
"FOLD" keyword, followed by the mailbox argument, followed by
CRLF.
Possible responses:
"#nnn"
where nnn is the number of messages in this mailbox.
READ [nnn]
The Read command begins a message reading transaction. If the
Read command is given without an argument the current message
is implied (the current message indicator is incremented by
the ACKS or ACKD commands). If an argument is used with the
Read command it is the message number to be read, and this
command sets the current message indicator to that value. The
server returns the count of characters in the message to be
transmitted. If there is no message to be read, the count of
zero is returned. If the message was previously deleted with
the ACKD command, the count of zero is returned. The Read
command is followed by the RETR command, the READ command, the
FOLD command, or the QUIT command. Do not attempt to RETR a
<span class="grey">Butler, et. al. [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
message of zero characters. The Read command is the "READ"
keyword, optionally followed by the message number argument,
followed by CRLF.
Possible responses:
"=ccc"
where ccc is the number of characters in this message.
RETR
The Retrieve command confirms that the client is ready to
receive the mail data. It must be followed by an
acknowledgment command. The server will close the connection
if asked to transmit a message of zero characters (i.e.,
transmit a non-existent message). The message is transmitted
according to the Internet mail format standard <a href="./rfc822">RFC-822</a> [<a href="#ref-2" title=""Standard for the Format of ARPA-Internet Text Messages"">2</a>] in
NVT-ASCII. The Retrieve command is the "RETR" keyword,
followed by CRLF.
Possible responses:
the message data
Close the connection
ACKS
The Acknowledge and Save command confirms that the client has
received and accepted the message. The ACKS command ends the
message reading transaction. The message is kept in the
mailbox. The current message indicator is incremented. The
server returns the count of characters in the now current
message to be transmitted. If there is no message to be read
or the message is marked deleted, the count of zero is
returned. The Acknowledge and Save command is the "ACKS"
keyword, followed by CRLF.
Possible responses:
"=ccc"
where ccc is the number of characters in the next
message.
<span class="grey">Butler, et. al. [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
ACKD
The Acknowledge and Delete command confirms that the client has
received and accepted the message. The ACKD command ends the
message reading transaction. If the user is authorized to have
write access to the mailbox, the message is deleted from the
mailbox. Actually, the message is only marked for deletion.
The actual change is made when the mailbox is released at the
end of the session or when the client selects another mailbox
with the FOLD command. The messages are not renumbered until
the mailbox is released. If the user does not have write
access to the mailbox no change is made to the mailbox. The
response is the same whether or not the message was actually
deleted. The current message indicator is incremented. The
server returns the count of characters in the now current
message to be transmitted. If there is no message to be read
or the message is marked deleted, the count of zero is
returned. The Acknowledge and Delete command is the "ACKD"
keyword, followed by CRLF.
Possible responses:
"=ccc"
where ccc is the number of characters in the next
message.
NACK
The Negative Acknowledge command reports that the client did
not receive the message. The NACK command ends the message
reading transaction. The message is kept in the mailbox. The
current message indicator remains the same. The server returns
the count of characters in the current message. Since the
count to be returned is for the message just transmitted it the
message must exist and not be marked deleted, and the count
must be positive (non-zero). The Negative Acknowledge command
is the "NACK" keyword, followed by CRLF.
Possible responses:
"=ccc"
where ccc is the number of characters in this message.
<span class="grey">Butler, et. al. [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
QUIT
The Quit command indicates the client is done with the session.
The server sends an OK response and then closes the connection.
The Quit command is the "QUIT" keyword, followed by CRLF.
Possible responses:
"+ OK" and Close the connection
Replies
Greeting
The greeting is sent by the server as soon as the connection is
established. The greeting is a plus sign, followed by the
protocol name ("POP2"), followed by the server host name,
optionally followed by text, and ending with a CRLF.
+
The success or plus sign response indicates successful
completion of the operation specified in the command. The
success response is a plus sign, optionally followed by text,
and ending with a CRLF.
-
The failure or minus sign response indicates the failure of the
operation specified in the command. The failure response is a
minus sign, optionally followed by text, and ending with a
CRLF.
=
The length or equal sign response tells the length in
characters of the message referenced by the command. The
length response is a equal sign, followed by a number,
optionally followed by text, and ending with a CRLF.
#
The count or number sign response tells the number of messages
in a folder or mailbox referenced by the command. The count
response is a number sign, followed by a number, optionally
followed by text, and ending with a CRLF.
<span class="grey">Butler, et. al. [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Timeouts
In any protocol of this type there have to be timeouts. Neither
side wants to get stuck waiting forever for the other side
(particularly is the other side has gone crazy or crashed).
The client expects a reply to a command fairly quickly and so
should have a short timeout for this. This timeout is called T1.
For some servers, it may take some processing to compute the
number of messages in a mailbox, or the length of a message, or
to reformat a stored message for transmission, so this time out
has to allow for such processing time. Also care must be taken
not to timeout waiting for the completion of a RETR reply while
a long message is in fact being transfered.
The server expects the session to progress with some but not
excessive delay between commands and so should have a long timeout
waiting for the next command. This time out is T2.
One model of use of this protocol is that any number of
different types of clients can be built with different ways of
interacting with the human user and the server, but still
expecting the client to open the connection to the server,
present a sequence of commands, and close the connection,
without waiting for intervention by the human user. With such
client implementations, it is reasonable for the server to have
a fairly small value for timeout T2.
On the other hand, one could easily have the client be very
human user directed with the user making decisions between
commands. This would cause arbitrary delays between client
commands to the server, and require the value of timeout T2 to
be quite large.
Implementation Discussion
Comments on a Server on TOPS-20
On TOPS-20, a mailbox is a single file. New messages are appended
to the file. There is a separator line between messages.
The tricky part of implementing a POP2 server on TOPS-20 is to
provide for deleting messages. This only has to be done for the
mailboxes (files) for which the user has write access. The
problem is to avoid both (1) preventing other users from accessing
or updating the mailbox for long periods, and (2) accidentally
deleting a message the user has not seen.
<span class="grey">Butler, et. al. [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
One suggestion is as follows:
When a mailbox is first selected, if the user has write access,
rename the mailbox file to some temporary name. Thus new
messages will be placed in a new instance of the mailbox file.
Conduct all POP2 operation on the temporary mailbox file
(including deleting messages). When the POP2 session is over
or another mailbox is selected, prepend any messages left
undeleted in the temporary file to the new instance of the
mailbox file.
Sizes
The maximum length of a command line is 512 characters (including
the command word and the CRLF).
The maximum length of a reply line is 512 characters (including
the success indicator (+, -, =, #) and the CRLF).
The maximum length of a text line is 1000 characters (including
CRLF).
ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2
Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix.
Extensions Not Supported
POP2 does not examine the internal data of messages. In particular,
the server does not parse message headers.
The server doesn't have any state information (i.e., it doesn't know
from one session to the next what has happened). For example, the
server doesn't know which messages were received since the last time
the user used POP2, so it can't send just the "new" messages.
<span class="grey">Butler, et. al. [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Examples
Example 1:
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 USC-ISIF.ARPA Server
HELO POSTEL SECRET -->
<-- #2 messages in your mailbox
READ -->
<-- =537 characters in message 1
RETR -->
<-- [data of message 1]
ACKD -->
<-- =234 characters in message 2
RETR -->
<-- [data of message 2]
ACKD -->
<-- =0 no more messages
QUIT -->
<-- + OK, bye, bye
Close connection --> <-- Close connection
Go back to start
<span class="grey">Butler, et. al. [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Example 2:
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server here
HELO smith secret -->
<-- #35 messages
FOLD /usr/spool/mail/smith -->
<-- #27 messages
READ 27 -->
<-- =10123 characters in that message
RETR -->
<-- [data of message 27]
ACKS -->
<-- =0 no more messages
QUIT -->
<-- + bye, call again sometime.
Close connection --> <-- Close connection
Go back to start
Example 3:
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server here
HELO Jones secret -->
<-- #0 messages
READ -->
<-- Close connection
Close connection -->
Go back to start
<span class="grey">Butler, et. al. [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Formal Syntax
<digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<letter> = A | B | C | ... | Z
a | b | c | ... | z
<punct> = ! | " | # | $ | % | & | ' | ( | ) | * |
+ | , | - | / | : | < | = | > | ? | @ |
[ | ] | ^ | _ | ` | { | | | } | ~
<quote> = \
<any> = any one of the 128 ASCII codes
<CR> = carriage return, code 10
<LF> = line feed, code 13
<SP> = space, code 32
<CRLF> = <CR> <LF>
<print> = <letter> | <digit> | <punct> | <quote> <any>
<char> = <print> | <SP>
<word> = <print> | <print> <word>
<string> = <char> | <char> <string>
<ld> = <letter> | <digit>
<ldh> = <letter> | <digit> | -
<ldhs> = <ldh> | <ldh> <ldhs>
<name> = <letter> [ [ <ldhs> ] <ld> ]
<host> = <name> | <name> . <host>
<user> = <word>
<password> = <word>
<mailbox> = <string>
<number> = <digit> | <digit> <number>
<span class="grey">Butler, et. al. [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
<helo> = HELO <SP> <user> <SP> <password> <CRLF>
<fold> = FOLD <SP> <mailbox> <CRLF>
<read> = READ [<SP> <number>] <CRLF>
<retr> = RETR <CRLF>
<acks> = ACKS <CRLF>
<ackd> = ACKD <CRLF>
<nack> = NACK <CRLF>
<quit> = QUIT <CRLF>
<ok> = + [<SP> <string>] <CRLF>
<err> = - [<SP> <string>] <CRLF>
<count> = # <number> [<SP> <string>] <CRLF>
<greet> = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF>
<length> = = <number> [<SP> <string>] <CRLF>
<command> = <helo> | <fold> | <read> | <retr> |
<acks> | <ackd> | <nack> | <quit>
<reply> = <ok> | <err> | <count> | <length> | <greet>
<span class="grey">Butler, et. al. [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Client State Diagram
| ^ + BYE
| Open | -----
| Greet | Close
V ----- |
+-------+ QUIT +-------+
| CALL |-------------->| EXIT |
+-------+ +-------+
| ^
| Greet |
| ----- |
| HELO |
+---->+ | |
#NNN ^ | | #NNN |
---- | V V ---- |
FOLD | +-------+ QUIT |
+<---| NMBR |--------------------->+
+-------+ ^
^ | |
| | #NNN |
| | ---- |
=CCC | | READ |
---- | | |
FOLD | | =CCC |
| V ---- |
=CCC +--->+-------+ QUIT |
---- ^ | SIZE |--------------------->+
READ +<---+-------+
^ |
| | =CCC
data | | ----
---- | | RETR
ack | |
| V
+-------+
| XFER |
+-------+
<span class="grey">Butler, et. al. [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Server State Diagram
+<----------------------+ Close
| | -----
Listen | | Close
V |
+-------+ +-------+
| LSTN | | DONE |
+-------+ +-------+
| ^
| Open |
| ----- |
| Greet |
| |
| QUIT |
V ----- |
+-------+ + BYE |
| AUTH |--------------------->+
+-------+ ^
| |
| HELO |
| ---- |
| #NNN |
| |
| QUIT |
V ----- |
FOLD +--->+-------+ + BYE |
---- ^ | MBOX |--------------------->+
#NNN +<---+-------+ ^
^ | |
| | READ |
FOLD | | ---- |
---- | | =CCC |
#NNN | | QUIT |
| V ----- |
READ +--->+-------+ + BYE |
---- ^ | ITEM |--------------------->+
=CCC +<---+-------+
^ |
| | RETR
ack | | ----
---- | | data
=CCC | |
| V
+-------+
| NEXT |
+-------+
<span class="grey">Butler, et. al. [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Combined Flow Diagram
+----+
|CALL|<------------------------------------------------------------+
|LSTN| ^
+----+ |
| Greet |
| |
| +----------------------------------------------------->+ |
| ^ QUIT | |
V | V |
+----+ +----+ +----+ |
|CALL| HELO |NMBR| |EXIT| |
|AUTH|------->|AUTH| |AUTH| |
+----+ +----+ +----+ |
| #NNN + Bye | |
| | |
| +------------------------------------>+ | |
| ^ QUIT | | |
V | V | |
+--->+----+ +----+ +----+ | |
FOLD ^ |NMBR| READ |SIZE| |EXIT| | |
---- | |MBOX|------->|MBOX| |MBOX| | |
#NNN +<---+----+ +----+ +----+ | |
^ | =CCC + Bye | | |
| | | | |
FOLD +<--------+ | +------------------->+ | | |
---- ^ | ^ QUIT | | | |
#NNN | V | V | | |
+--->+-----+ +----+ +----+ | | |
READ ^ |SIZE | RETR |XFER| |EXIT| | | |
---- | | ITEM|------->|ITEM| |ITEM| | | |
=CCC +<---+-----+ +----+ +----+ | | |
^ | data | | | |
| | | | | |
=CCC | V + Bye | | | |
+----+ +----+ | | | |
|SIZE| Ack |XFER| | | | |
|NEXT|<-------|NEXT| | | | |
+----+ +----+ | | | |
| | | |
| | | |
V V V |
+-------+ |
| EXIT |-->+
| DONE |
+-------+
<span class="grey">Butler, et. al. [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Client Decision Table
| STATE |
-------+----------------------------------|
INPUT | CALL | NMBR | SIZE | XFER | EXIT |
-------+----------------------------------|
Greet | 2 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
#NNN | 1 | 3 | 1 | 1 | 6 |
-------+----------------------------------|
=CCC | 1 | 1 | 4 | 1 | 6 |
-------+----------------------------------|
data | 1 | 1 | 1 | 5 | 6 |
-------+----------------------------------|
+ Bye | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
Close | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
other | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
Timeout| 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
<span class="grey">Butler, et. al. [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Actions:
1. This is garbage. Send "QUIT", and go to EXIT state.
2. (a) If the greeting is right then send "HELO"
and go to NMBR state,
(b) Else send "QUIT" and go to EXIT state.
3. (a) If user wants this folder and NNN > 0
then send "READ" and go to SIZE state,
(b) If user wants a this folder and NNN = 0
then send "QUIT" and go to EXIT state,
(c) If user wants a different folder
then send "FOLD" and go to NMBR state.
4. (a) If user wants this message and CCC > 0
then send "RETR" and go to XFER state,
(b) If user wants a this message and CCC = 0
then send "QUIT" and go to EXIT state,
(c) If user wants a different message
then send "READ" and go to SIZE state.
5. (a) If user wants this message kept
then send "ACKS" and go to SIZE state,
(b) If user wants a this message deleted
then send "ACKD" and go to SIZE state,
(c) If user wants a this message again
then send "NACK" and go to SIZE state.
6. Close the connection.
<span class="grey">Butler, et. al. [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Server Decision Table
| STATE
-------+-----------------------------------------
INPUT | LSTN | AUTH | MBOX | ITEM | NEXT | DONE |
-------+-----------------------------------------|
Open | 2 | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
HELO | 1 | 3 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
FOLD | 1 | 1 | 5 | 5 | 1 | 1 |
-------+-----------------------------------------|
READ | 1 | 1 | 6 | 6 | 1 | 1 |
-------+-----------------------------------------|
RETR | 1 | 1 | 1 | 7 | 1 | 1 |
-------+-----------------------------------------|
ACKS | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
ACKD | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
NACK | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
QUIT | 1 | 4 | 4 | 4 | 1 | 1 |
-------+-----------------------------------------|
Close | 1 | 1 | 1 | 1 | 1 | 9 |
-------+-----------------------------------------|
other | 1 | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
Timeout| | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
<span class="grey">Butler, et. al. [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Actions:
1. This is garbage. Send "- error", and Close the connection.
2. Send the greeting. Go to AUTH state.
3. (a) If authorized user then send "#NNN" and go tp MBOX state,
(b) Else send "- error" and Close the connection.
4. Send "+ Bye" and go to DONE state.
5. Send "+NNN" and go to MBOX state.
6. Send "=CCC" and go to ITEM state.
7. If message exists then send the data and got to NEXT state,
Else Close the connection.
8. Do what ACKS/ACKD/NACK require and go to ITEM state.
9. Close the connection.
<span class="grey">Butler, et. al. [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc937">RFC 937</a> February 1985</span>
Post Office Protocol
Acknowledgment
We would like to acknowledge the helpful comments that we received on
the first version of POP described in <a href="./rfc918">RFC 918</a>, and the draft of POP2
distributed to interested parties.
References
[<a id="ref-1">1</a>] Postel, J., "Simple Mail Transfer Protocol", <a href="./rfc821">RFC 821</a>,
USC/Information Sciences Institute, August 1982.
[<a id="ref-2">2</a>] Crocker, D., "Standard for the Format of ARPA-Internet Text
Messages", <a href="./rfc822">RFC 822</a>, University of Delaware, August 1982.
[<a id="ref-3">3</a>] Reynolds, J.K., "Post Office Protocol", <a href="./rfc918">RFC 918</a>, USC/Information
Sciences Institute, October 1984.
[<a id="ref-4">4</a>] Reynolds, J.K., and J. Postel, "Assigned Numbers", <a href="./rfc923">RFC 923</a>,
USC/Information Sciences Institute, October 1984.
Butler, et. al. [Page 24]
</pre>
|
