File: rfc1176.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1683 lines) | stat: -rw-r--r-- 65,648 bytes parent folder | download | duplicates (7)
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
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683






Network Working Group                                         M. Crispin
Request for Comments: 1176                                    Washington
Obsoletes: RFC 1064                                          August 1990


              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2


Status of this Memo

   This RFC suggests a method for personal computers and workstations to
   dynamically access mail from a mailbox server ("repository").  It
   obosoletes RFC 1064.  This RFC specifies an Experimental Protocol for
   the Internet community.  Discussion and suggestions for improvement
   are requested.  Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Introduction

   The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
   is to allow a workstation, personal computer, or similar small
   machine to access electronic mail from a mailbox server.  Since the
   distinction between personal computers and workstations is blurring
   over time, it is desirable to have a single solution that addresses
   the need in a general fashion.  IMAP2 is the "glue" of a distributed
   electronic mail system consisting of a family of client and server
   implementations on a wide variety of platforms, from small single-
   tasking personal computing engines to complex multi-user timesharing
   systems.

   Although different in many ways from the Post Office Protocols (POP2
   and POP3, hereafter referred to collectively as "POP") described in
   RFC 937 and RFC 1081, IMAP2 may be thought of as a functional
   superset of these.  RFC 937 was used as a model for this RFC.  There
   was a cognizant reason for this; POP deals with a similar problem,
   albeit with a less comprehensive solution, and it was desirable to
   offer a basis for comparison.

   Like POP, IMAP2 specifies a means of accessing stored mail and not of
   posting mail; this function is handled by a mail transfer protocol
   such as SMTP (RFC 821).

   This protocol assumes a reliable data stream such as provided by TCP
   or any similar protocol.  When TCP is used, the IMAP2 server listens
   on port 143.





Crispin                                                         [Page 1]

RFC 1176                         IMAP2                       August 1990


System Model and Philosophy

   Electronic mail is a primary means of communication for the widely
   spread Internet community.  The advent of distributed personal
   computers and workstations has forced a significant rethinking of the
   mechanisms employed to manage electronic mail.  With mainframes, each
   user tends to receive and process mail at the computer he uses most
   of the time, his "primary host".  The first inclination of many users
   when an independent workstation is placed in front of them is to
   begin receiving mail at the workstation, and many vendors have
   implemented facilities to do this.  However, this approach has
   several disadvantages:

      (1) Personal computers and many workstations have a software
      design that gives full control of all aspects of the system to the
      user at the console.  As a result, background tasks such as
      receiving mail may not run for long periods of time; either
      because the user is asking to use all the machine's resources, or
      because the user has (perhaps accidentally) manipulated the
      environment in such a way that it prevents mail reception.  In
      many personal computers, the operating system is single-tasking
      and this is the only mode of operation.  Any of these conditions
      could lead to repeated failed delivery attempts by outside agents.

      (2) The hardware failure of a single machine can keep its user
      "off the air" for a considerable time, since repair of individual
      units may be delayed.  Given the growing number of personal
      computers and workstations spread throughout office environments,
      quick repair of such systems is not assured.  On the other hand, a
      central mainframe is generally repaired soon after failure.

      (3) Personal computers and workstations are often not backed up
      with as much diligence as a central mainframe, if at all.

      (4) It is more difficult to keep track of mailing addresses when
      each person is associated with a distinct machine.  Consider the
      difficulty in keeping track of many postal addresses or phone
      numbers, particularly if there was no single address or phone
      number for an organization through which you could reach any
      person in that organization.  Traditionally, electronic mail on
      the ARPANET involved remembering a name and one of several "hosts"
      (machines) whose name reflected the organization in which the
      individual worked.  This was suitable at a time when most
      organizations had only one central host.  It is less satisfactory
      today unless the concept of a host is changed to refer to an
      organizational entity and not a particular machine.

      (5) It is difficult to keep a multitude of heterogeneous machines



Crispin                                                         [Page 2]

RFC 1176                         IMAP2                       August 1990


      working properly with complex mailing protocols, making it
      difficult to move forward as progress is made in electronic
      communication and as new standards emerge.  Each system has to
      worry about receiving incoming mail, routing and delivering
      outgoing mail, formatting, storing, and providing for the
      stability of mailboxes over a variety of possible filing and
      mailing protocols.

   Consequently, while a personal computer or workstation may be viewed
   as an Internet host in the sense that it implements TCP/IP, it should
   not be viewed as the entity that contains the user's mailbox.
   Instead, a mail server machine ("server", sometimes called a
   "repository") should hold the mailbox, and the personal computer or
   workstation (hereafter referred to as a "client") should access the
   mailbox via mail transactions.

   Because the mail server machine is isolated from direct user
   manipulation, it should achieve high software reliability easily,
   and, as a shared resource, it should also achieve high hardware
   reliability, perhaps through redundancy.  The mail server may be
   accessed from arbitrary locations, allowing users to read mail across
   campus, town, or country using commonly available clients.
   Furthermore, the same user may access his mailbox from different
   clients at different times, and multiple users may access the same
   mailbox simultaneously.

   The mail server acts an an interface among users, data storage, and
   other mailers.  A mail access protocol retrieves messages, accesss
   and changes properties of messages, and otherwise manages mailboxes.
   This differs from some approaches (e.g., Unix mail via NFS) in that
   the mail access protocol is used for all message manipulations,
   isolating the user and the client from all knowledge of how the data
   storage is used.  This means that the mail server can use the data
   storage in whatever way is most efficient to organize the mail in
   that particular environment, without having to worry about storage
   representation compatibility across different machines.

   A mail access protocol further differs in that it transmits
   information only on demand.  A well-designed mail access protocol
   requires considerably less network traffic than Unix mail via NFS,
   particularly when the mail file is large.  The result is that a mail
   access protocol can scale well to situations of large mailboxes or
   networks with high latency or low speed.

   In defining a mail access protocol, it is important to keep in mind
   that the client and server form a macrosystem, in which it should be
   possible to exploit the strong points of both while compensating for
   each other's weaknesses.  Furthermore, it is desirable to allow for a



Crispin                                                         [Page 3]

RFC 1176                         IMAP2                       August 1990


   growth path beyond the hoary text-only RFC 822 protocol, specifically
   in the area of attachments and multi-media mail, to ease the eventual
   transition to ISO solutions.

   Unlike POP, IMAP2 has extensive features for remote searching and
   parsing of messages on the server.  A free text search (optionally
   with other searching) can be made in the entire mailbox by the server
   and the results made available to the client without the client
   having to transfer the entire mailbox and searching itself.  Since
   remote parsing of a message into a structured (and standard format)
   "envelope" is available, a client can display envelope information
   and implement commands such as REPLY without having any understanding
   of how to parse RFC 822, etc. headers.  The effect of this is
   twofold: it further improves the ability to scale well in instances
   where network traffic must be reduced, and it reduces the complexity
   of the client program.

   Additionally, IMAP2 offers several facilities for managing individual
   message state and the mailbox as a whole beyond the simple "delete
   message" functionality of POP.  Another benefit of IMAP2 is the use
   of tagged responses to reduce the possibility of synchronization
   errors and the concept of state on the client (a "local cache") that
   the server may update without explicit request by the client.  These
   concepts and how they are used are explained under "Implementation
   Discussion" below.

   In spite of this functional richness, IMAP2 is a small protocol.
   Although servers should implement the full set of IMAP2 functions, a
   simple client can be written that uses IMAP2 in much the way as a POP
   client.

   A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL
   (RFC 1056).  IMAP2 differs from DMSP more fundamentally, reflecting a
   differing architecture from PCMAIL.  PCMAIL is either an online
   ("interactive mode"), or offline ("batch mode") system with long-term
   shared state.  Some POP based systems are also offline; in such
   systems, since there is no long-term shared state POP is little more
   than a download mechanism of the "mail file" to the client.  IMAP2-
   based software is primarily an online system in which real-time and
   simultaneous mail access were considered important.

   In PCMAIL, there is a long-term client/server relationship in which
   some mailbox state is preserved on the client.  There is a
   registration of clients used by a particular user, and the client
   keeps a set of "descriptors" for each message that summarize the
   message.  The server and client synchronize their states when the
   DMSP connection starts up, and, if a client has not accessed the
   server for a while, the client does a complete reset (reload) of its



Crispin                                                         [Page 4]

RFC 1176                         IMAP2                       August 1990


   state from the server.

   In IMAP2-based software, the client/server relationship lasts only
   for the duration of the TCP connection.  All mailbox state is
   maintained on the server.  There is no registration of clients.  The
   function of a descriptor is handled by a structured representation of
   the message "envelope" as noted above.  There is no client/server
   synchronization since the client does not remember state between
   IMAP2 connections.  This is not a problem since in general the client
   never needs the entire state of the mailbox in a single session,
   therefore there isn't much overhead in fetching the state information
   that is needed as it is needed.

   There are also some functional differences between IMAP2 and DMSP.
   DMSP has functions for sending messages, printing messages, listing
   mailboxes, and changing passwords; these are done outside IMAP2.
   DMSP has 16 binary flags of which 8 are defined by the system.  IMAP2
   has flag names; there are currently 5 defined system flag names and a
   facility for some number (30 in the current implementations) of user
   flag names.  IMAP2 has a sophisticated message search facility in the
   server to identify interesting messages based on dates, addresses,
   flag status, or textual contents without compelling the client to
   fetch this data for every message.

   It was felt that maintaining state on the client is advantageous only
   in those cases where the client is only used by a single user, or if
   there is some means on the client to restrict access to another
   user's data.  It can be a serious disadvantage in an environment in
   which multiple users routinely use the same client, the same user
   routinely uses different clients, and where there are no access
   restrictions on the client.  It was also observed that most user mail
   access is to a small set of "interesting" messages, which were either
   new mail or mail based on some user-selected criteria.  Consequently,
   IMAP2 was designed to easily identify those "interesting" messages so
   that the client could fetch the state of those messages and not those
   that were not "interesting".

The Protocol

   The IMAP2 protocol consists of a sequence of client commands and
   server responses, with server data interspersed between the
   responses.  Unlike most Internet protocols, commands and responses
   are tagged.  That is, a command begins with a unique identifier
   (typically a short alphanumeric sequence such as a Lisp "gensym"
   function would generate e.g., A0001, A0002, etc.), called a tag.  The
   response to this command is given the same tag from the server.
   Additionally, the server may send an arbitrary amount of "unsolicited
   data", which is identified by the special reserved tag of "*".  There



Crispin                                                         [Page 5]

RFC 1176                         IMAP2                       August 1990


   is another special reserved tag, "+", discussed below.

   The server must be listening for a connection.  When a connection is
   opened the server sends an unsolicited OK response as a greeting
   message and then waits for commands.

   The client opens a connection and waits for the greeting.  The client
   must not send any commands until it has received the greeting from
   the server.

   Once the greeting has been received, the client may begin sending
   commands and is not under any obligation to wait for a server
   response to this command before sending another command, within the
   constraints of TCP flow control.  When commands are received the
   server acts on them and responds with command responses, often
   interspersed with data.  The effect of a command can not be
   considered complete until a command response with a tag matching the
   command is received from the server.

   Although all known IMAP2 servers at the time of this writing process
   commands to completion before processing the next command, it is not
   required that a server do so.  However, many commands can affect the
   results of other commands, creating processing-order dependencies
   (or, for SEARCH and FIND, ambiguities about which data is associated
   with which command).  All implementations that operate in a non-
   lockstep fashion must recognize such dependencies and defer or
   synchronize execution as necessary.  In general, such multi-
   processing is limited to consecutive FETCH commands.

   Generally, the first command from the client is a LOGIN command with
   user name and password arguments to establish identity and access
   authorization, unless this has already been accomplished through
   other means, e.g. Kerberos.  Until identity and access authorization
   have been established, no operations other than LOGIN or LOGOUT are
   permitted.

   Once identity and authorization have been established, the client
   must send a SELECT command to access the desired mailbox; no mailbox
   is selected by default.  SELECT's argument is implementation-
   dependent; however the word "INBOX" must be implemented to mean the
   primary or default mailbox for this user, independent of any other
   server semantics.  On a successful SELECT, the server will send a
   list of valid flags, number of messages, and number of messages
   arrived since last access for this mailbox as unsolicited data,
   followed by an OK response.  The client may terminate access to this
   mailbox and access a different one with another SELECT command.

   The client reads mailbox information with FETCH commands.  The actual



Crispin                                                         [Page 6]

RFC 1176                         IMAP2                       August 1990


   data is transmitted via the unsolicited data mechanism (that is,
   FETCH should be viewed as instructing the server to include the
   desired data along with any other data it wishes to transmit to the
   client).  There are three major categories of data that may be
   fetched.

   The first category is data that is associated with a message as an
   entity in the mailbox.  There are now three such items of data: the
   "internal date", the "RFC 822 size", and the "flags".  The internal
   date is the date and time that the message was placed in the mailbox.
   The RFC 822 size is subject to deletion in the future; it is the size
   in bytes of the message, expressed as an RFC 822 text string.
   Current clients only use it as part of a status display line.  The
   flags are a list of status flags associated with the message (see
   below).  All the first category data can be fetched by using the
   macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS
   INTERNALDATE RFC822.SIZE)".

   The second category is that data that describes the composition and
   delivery information of a message; that is, information such as the
   message sender, recipient lists, message-ID, subject, etc.  This is
   the information that is stored in the message header in RFC 822
   format message and is traditionally called the "envelope".  [Note:
   this should not be confused with the SMTP (RFC 821) envelope, which
   is strictly limited to delivery information.]  IMAP2 defines a
   structured and unambiguous representation for the envelope that is
   particularly suited for Lisp-based parsers.  A client can use the
   envelope for operations such as replying and not worry about RFC 822
   at all.  Envelopes are discussed in more detail below.  The first two
   categories of data can be fetched together by using the macro-fetch
   word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
   RFC822.SIZE ENVELOPE)".

   The third category is that data that is intended for direct human
   viewing.  The present RFC 822 based IMAP2 defines three such items:
   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
   former appended together in a single text string).  RFC822.HEADER is
   the "raw", unprocessed RFC 822 format header of the message.
   Fetching "RFC822" is equivalent to fetching the RFC 822
   representation of the message as stored on the mailbox without any
   filtering or processing.

   An intelligent client will "FETCH ALL" for some (or all) of the
   messages in the mailbox for use as a presentation menu, and when the
   user wishes to read a particular message will "FETCH RFC822.TEXT" to
   get the message body.  A more primitive client could, of course,
   simply "FETCH RFC822" a`la POP-type functionality.




Crispin                                                         [Page 7]

RFC 1176                         IMAP2                       August 1990


   The client can alter certain data (currently only the flags) by a
   STORE command.  As an example, a message is deleted from a mailbox by
   a STORE command that includes the \DELETED flag as a flag being set.

   Other client operations include copying a message to another mailbox
   (COPY command), permanently removing deleted messages (EXPUNGE
   command), checking for new messages (CHECK command), and searching
   for messages that match certain criteria (SEARCH command).

   The client terminates the session with the LOGOUT command.  The
   server returns a "BYE" followed by an "OK".

   A Typical Scenario

           Client                          Server
           ------                          ------
                                       {Wait for Connection}
       {Open Connection}        -->
                                   <-- * OK IMAP2 Server Ready
                                       {Wait for command}
       A001 LOGIN Fred Secret   -->
                                   <-- A001 OK User Fred logged in
                                       {Wait for command}
       A002 SELECT INBOX        -->
                                   <-- * FLAGS (Meeting Notice \Answered
                                                \Flagged \Deleted \Seen)
                                   <-- * 19 EXISTS
                                   <-- * 2 RECENT
                                   <-- A0002 OK Select complete
                                       {Wait for command}
       A003 FETCH 1:19 ALL      -->
                                   <-- * 1 Fetch (......)
                                           ...
                                   <-- * 18 Fetch (......)
                                   <-- * 19 Fetch (......)
                                   <-- A003 OK Fetch complete
                                       {Wait for command}
       A004 FETCH 8 RFC822.TEXT -->
                                   <-- * 8 Fetch (RFC822.TEXT {893}
                                           ...893 characters of text...
                                   <-- )
                                   <-- A004 OK Fetch complete
                                       {Wait for command}








Crispin                                                         [Page 8]

RFC 1176                         IMAP2                       August 1990


       A005 STORE 8 +Flags \Deleted -->
                                   <-- * 8 Store (Flags (\Deleted
                                                  \Seen))
                                   <-- A005 OK Store complete
                                       {Wait for command}
       A006 EXPUNGE             -->
                                   <-- * 19 EXISTS
                                   <-- * 8 EXPUNGE
                                   <-- * 18 EXISTS
                                   <-- A006 Expunge complete
                                       {Wait for command}
       A007 LOGOUT              -->
                                   <-- * BYE IMAP2 server quitting
                                   <-- A007 OK Logout complete
       {Close Connection}       --><-- {Close connection}
                                       {Go back to start}
Conventions

   The following terms are used in a meta-sense in the syntax
   specification below:

      An ASCII-STRING is a sequence of arbitrary ASCII characters.

      An ATOM is a sequence of ASCII characters delimited by SP or CRLF.

      A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
      or "\".

      A CRLF is an ASCII carriage-return character followed immediately
      by an ASCII linefeed character.

      A NUMBER is a sequence of the ASCII characters that represent
      decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
      ":".

      A SP is the ASCII space character.

      A TEXT_LINE is a human-readable sequence of ASCII characters up to
      but not including a terminating CRLF.

   A common field in the IMAP2 protocol is a STRING, which may be an
   ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes),
   or a LITERAL.  A literal consists of an open brace ("{"), a number, a
   close brace ("}"), a CRLF, and then an ASCII-STRING of n characters,
   where n is the value of the number inside the brace.  In general, a
   string should be represented as an ATOM or QUOTED-STRING if at all
   possible.  The semantics for QUOTED-STRING or LITERAL are checked
   before those for ATOM; therefore an ATOM used in a STRING may only



Crispin                                                         [Page 9]

RFC 1176                         IMAP2                       August 1990


   contain CHARACTERs.  Literals are most often sent from the server to
   the client; in the rare case of a client to server literal there is a
   special consideration (see the "+ text" response below).

   Another important field is the SEQUENCE, which identifies a set of
   messages by consecutive numbers from 1 to n where n is the number of
   messages in the mailbox.  A sequence may consist of a single number,
   a pair of numbers delimited by colon (equivalent to all numbers
   between those two numbers), or a list of single numbers or number
   pairs.  For example, the sequence 2,4:7,9,12:15 is equivalent to
   2,4,5,6,7,9,12,13,14,15 and identifies all those messages.

Definitions of Commands and Responses

     Summary of Commands and Responses

       Commands                            ||      Responses
       --------                            ||      -------
       tag NOOP                            ||      tag OK text
       tag LOGIN user password             ||      tag NO text
       tag LOGOUT                          ||      tag BAD text
       tag SELECT mailbox                  ||      * number message_data
       tag BBOARD bulletin_board           ||      * FLAGS flag_list
       tag FIND MAILBOXES pattern          ||      * SEARCH sequence
       tag FIND BBOARDS pattern            ||      * BBOARD string
       tag CHECK                           ||      * MAILBOX string
       tag EXPUNGE                         ||      * BYE text
       tag COPY sequence mailbox           ||      * OK text
       tag FETCH sequence data             ||      * NO text
       tag STORE sequence data value       ||      * BAD text
       tag SEARCH search_program           ||      + text

Commands

   tag NOOP

      The NOOP command returns an OK to the client.  By itself, it does
      nothing, but certain things may happen as side effects.  For
      example, server implementations that implicitly check the mailbox
      for new mail may do so as a result of this command.  The primary
      use of this command is to for the client to see if the server is
      still alive (and notify the server that the client is still alive,
      for those servers that have inactivity autologout timers).

   tag LOGIN user password

      The LOGIN command identifies the user to the server and carries
      the password authenticating this user.  This information is used



Crispin                                                        [Page 10]

RFC 1176                         IMAP2                       August 1990


      by the server to control access to the mailboxes.

      EXAMPLE:  A001 LOGIN SMITH SESAME
      logs in as user SMITH with password SESAME.

   tag LOGOUT

      The LOGOUT command informs the server that the client is done with
      the session.  The server should send an unsolicited BYE response
      before the (tagged) OK response, and then close the network
      connection.

   tag SELECT mailbox

      The SELECT command selects a particular mailbox.  The server must
      check that the user is permitted read access to this mailbox.
      Before returning an OK to the client, the server must send the
      following unsolicited data to the client:
         FLAGS        mailbox's defined flags
         <n> EXISTS   the number of messages in the mailbox
         <n> RECENT   the number of new messages in the mailbox
      in order to define the initial state of the mailbox at the client.

      Multiple SELECT commands are permitted in a session, in which case
      the previous mailbox is automatically deselected when a new SELECT
      is made.

      The default mailbox for the SELECT command is INBOX, which is a
      special name reserved to mean "the primary mailbox for this user
      on this server".  The format of other mailbox names is operating
      system dependent (as of this writing, it reflects the filename
      path of the mailbox file on the current servers).

      It is customary, although not required, for the text of an OK
      response to the SELECT command to begin with either "[READ-ONLY]"
      or "[READ-WRITE]" to show the mailbox's access status.

      EXAMPLE: A002 SELECT INBOX
      selects the default mailbox.

   tag BBOARD bulletin_board

      The BBOARD command is equivalent to SELECT, and returns the same
      output.  However, it differs from SELECT in that its argument is a
      shared mailbox (bulletin board) name instead of an ordinary
      mailbox.  The format of a bulletin name is implementation
      specific, although it is strongly encouraged to use something that
      resembles a name in a generic sense and not a file or mailbox name



Crispin                                                        [Page 11]

RFC 1176                         IMAP2                       August 1990


      on the particular system.  There is no requirement that a bulletin
      board name be a mailbox name or a file name (in particular, Unix
      netnews has a completely different namespace from mailbox or file
      names).

      Support for BBOARD is optional.

   tag FIND MAILBOXES pattern

      The FIND MAILBOXES command accepts as an argument a pattern
      (including wildcards) that specifies some set of mailbox names
      that are usable by the SELECT command.  The format of mailboxes is
      implementation dependent.  The special mailbox name INBOX is not
      included in the output.

      Two wildcard characters are defined; "*" specifies any number
      (including zero) characters may match at this position and "%"
      specifies a single character may match at this position.  For
      example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR,
      whereas FOO%BAR will match only FOO.BAR.  "*" will match all
      mailboxes.

      The FIND MAILBOXES command will return some set of unsolicited
      MAILBOX replies that have as their value a single mailbox name.

      EXAMPLE:  A002 FIND MAILBOXES *
                * MAILBOX FOOBAR
                * MAILBOX GENERAL
                A002 FIND completed

      Although the use of explicit file or path names for mailboxes is
      discouraged by this standard, it may be unavoidable.  It is
      important that the value returned in the MAILBOX unsolicited reply
      be usable in the SELECT command without remembering any path
      specification that may have been used in the FIND MAILBOXES
      pattern.

      Support for FIND MAILBOXES is optional.  If a client's attempt
      returns BAD as a response then the client can make no assumptions
      about what mailboxes exist on the server other than INBOX.

   tag FIND BBOARDS pattern

      The FIND BBOARDS command accepts as an argument a pattern that
      specifies some set of bulletin board names that are usable by the
      BBOARD command.  Wildcards are permitted as in FIND MAILBOXES.

      The FIND BBOARDS command will return some set of unsolicited



Crispin                                                        [Page 12]

RFC 1176                         IMAP2                       August 1990


      BBOARD replies that have as their value a single bulletin board
      name.

      EXAMPLE:  A002 FIND BBOARDS *
                * BBOARD FOOBAR
                * BBOARD GENERAL
                A002 FIND completed

      Support for FIND BBOARDS is optional.  If a client's attempt
      returns BAD as a response then the client can make no assumptions
      about what bulletin boards exist on the server, or that they exist
      at all.

   tag CHECK

      The CHECK command forces a check for new messages and a rescan of
      the mailbox for internal change for those implementations that
      allow multiple simultaneous read/write access to the same mailbox.
      It is recommend that periodic implicit checks for new mail be done
      by servers as well.  The server should send unsolicited EXISTS and
      RECENT responses with the current status before returning an OK to
      the client.

   tag EXPUNGE

      The EXPUNGE command permanently removes all messages with the
      \DELETED flag set in its flags from the mailbox.  Before returning
      an OK to the client, for each message that is removed, an
      unsolicited EXPUNGE response is sent.  The message number for each
      successive message in the mailbox is immediately decremented by 1;
      this means that if the last 5 messages in a 9-message mail file
      are expunged you will receive 5 unsolicited EXPUNGE responses for
      message 5.  To ensure mailbox integrity and server/client
      synchronization, it is recommended that the server do an implicit
      check before commencing the expunge and again when the expunge is
      completed.  Furthermore, if the server allows multiple
      simultaneous access to the same mail file the server must lock the
      mail file for exclusive access while an expunge is taking place.

      EXPUNGE is not allowed if the user does not have write access to
      this mailbox.

   tag COPY sequence mailbox

      The COPY command copies the specified message(s) to the specified
      destination mailbox.  If the destination mailbox does not exist,
      the server should create it.  Before returning an OK to the
      client, the server should return an unsolicited <n> COPY response



Crispin                                                        [Page 13]

RFC 1176                         IMAP2                       August 1990


      for each message copied.  A copy should set the \SEEN flag for all
      messages that were successfully copied (provided, of course, that
      the user has write access to this mailbox).

      EXAMPLE:  A003 COPY 2:4 MEETING
      copies messages 2, 3, and 4 to mailbox "MEETING".

      COPY is not allowed if the user does not have write access to the
      destination mailbox.

   tag FETCH sequence data

      The FETCH command retrieves data associated with a message in the
      mailbox.  The data items to be fetched may be either a single atom
      or an S-expression list.  The currently defined data items that
      can be fetched are:

      ALL             Macro equivalent to:
                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)

      ENVELOPE        The envelope of the message.  The envelope is
                      computed by the server by parsing the RFC 822
                      header into the component parts, defaulting
                      various fields as necessary.

      FAST            Macro equivalent to:
                      (FLAGS INTERNALDATE RFC822.SIZE)

      FLAGS           The flags that are set for this message.
                      This may include the following system flags:

                              \RECENT    Message arrived since the
                                          previous time this mailbox
                                          was read
                              \SEEN      Message has been read
                              \ANSWERED  Message has been answered
                              \FLAGGED   Message is "flagged" for
                                          urgent/special attention
                              \DELETED   Message is "deleted" for
                                          removal by later EXPUNGE

      INTERNALDATE    The date and time the message was written to
                      the mailbox.








Crispin                                                        [Page 14]

RFC 1176                         IMAP2                       August 1990


      RFC822          The message in RFC 822 format.  The \SEEN
                      flag is implicitly set; if this causes the
                      flags to change they should be included as
                      part of the fetch results.  This is the
                      concatenation of RFC822.HEADER and RFC822.TEXT.

      RFC822.HEADER   The "raw" RFC 822 format header of the message
                      as stored on the server.

      RFC822.SIZE     The number of characters in the message as
                      expressed in RFC 822 format.

      RFC822.TEXT     The text body of the message, omitting the
                      RFC 822 header.  The \SEEN flag is implicitly
                      set as with RFC822 above.

      EXAMPLES:

      A003 FETCH 2:4 ALL
         fetches the flags, internal date, RFC 822 size, and envelope
         for messages 2, 3, and 4.

      A004 FETCH 3 RFC822
         fetches the RFC 822 representation for message 3.

      A005 FETCH 4 (FLAGS RFC822.HEADER)
         fetches the flags and RFC 822 format header for message 4.

      Note: An attempt to FETCH already-transmitted data may have no
      result.  See the Implementation Discussion below.

   tag STORE sequence data value

      The STORE command alters data associated with a message in the
      mailbox.  The currently defined data items that can be stored are:

         FLAGS           Replace the flags for the message with the
                         argument (in flag list format).

         +FLAGS          Add the flags in the argument to the
                         message's flag list.

         -FLAGS          Remove the flags in the argument from the
                         message's flag list.

      STORE is not allowed if the user does not have write access to
      this mailbox.




Crispin                                                        [Page 15]

RFC 1176                         IMAP2                       August 1990


      EXAMPLE:  A003 STORE 2:4 +FLAGS (\DELETED)
      marks messages 2, 3, and 4 for deletion.

   tag SEARCH search_criteria

      The SEARCH command searches the mailbox for messages that match
      the given set of criteria.  The unsolicited SEARCH <1#number>
      response from the server is a list of messages that express the
      intersection (AND function) of all the messages which match that
      criteria.  For example,
              A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
      returns the message numbers for all deleted messages from Smith
      that were placed in the mail file since October 1, 1987.

      In all search criteria which use strings, a message matches the
      criteria if the string is a case-independent substring of that
      field.  The currently defined criteria are:

      ALL             All messages in the mailbox; the default
                      initial criterion for ANDing.

      ANSWERED        Messages with the \ANSWERED flag set.

      BCC string      Messages which contain the specified string
                      in the envelope's BCC field.

      BEFORE date     Messages whose internal date is earlier than
                      the specified date.

      BODY string     Messages which contain the specified string
                      in the body of the message.

      CC string       Messages which contain the specified string
                      in the envelope's CC field.

      DELETED         Messages with the \DELETED flag set.

      FLAGGED         Messages with the \FLAGGED flag set.

      FROM string     Messages which contain the specified string
                      in the envelope's FROM field.

      KEYWORD flag    Messages with the specified flag set.

      NEW             Messages which have the \RECENT flag set but
                      not the \SEEN flag.  This is functionally
                      equivalent to "RECENT UNSEEN".




Crispin                                                        [Page 16]

RFC 1176                         IMAP2                       August 1990


      OLD             Messages which do not have the \RECENT flag
                      set.

      ON date         Messages whose internal date is the same as
                      the specified date.

      RECENT          Messages which have the \RECENT flag set.

      SEEN            Messages which have the \SEEN flag set.

      SINCE date      Messages whose internal date is later than
                      the specified date.

      SUBJECT string  Messages which contain the specified string
                      in the envelope's SUBJECT field.

      TEXT string     Messages which contain the specified string.

      TO string       Messages which contain the specified string in
                      the envelope's TO field.

      UNANSWERED      Messages which do not have the \ANSWERED flag
                      set.

      UNDELETED       Messages which do not have the \DELETED flag
                      set.

      UNFLAGGED       Messages which do not have the \FLAGGED flag
                      set.

      UNKEYWORD flag  Messages which do not have the specified flag
                      set.

      UNSEEN          Messages which do not have the \SEEN flag set.

















Crispin                                                        [Page 17]

RFC 1176                         IMAP2                       August 1990


Responses

   tag OK text

      This response identifies successful completion of the command with
      that tag.  The text is a line of human-readable text that may be
      useful in a protocol telemetry log for debugging purposes.

   tag NO text

      This response identifies unsuccessful completion of the command
      with that tag.  The text is a line of human-readable text that
      probably should be displayed to the user in an error report by the
      client.

   tag BAD text

      This response identifies faulty protocol received from the client;
      The text is a line of human-readable text that should be recorded
      in any telemetry as part of a bug report to the maintainer of the
      client.

   * number message_data

      This response occurs as a result of several different commands.
      The message_data is one of the following:

      EXISTS  The specified number of messages exists in the mailbox.

      RECENT  The specified number of messages have arrived since the
              previous time this mailbox was read.

      EXPUNGE The specified message number has been permanently
              removed from the mailbox, and the next message in the
              mailbox (if any) becomes that message number.

      STORE data
              Obsolete and functionally equivalent to FETCH.

      FETCH data
              This is the principle means by which data about a
              message is returned to the client.  The data is in a
              Lisp-like S-expression property list form.  The current
              properties are:

         ENVELOPE     An S-expression format list that describes the
                      envelope of a message.  The envelope is computed
                      by the server by parsing the RFC 822 header into



Crispin                                                        [Page 18]

RFC 1176                         IMAP2                       August 1990


                      the component parts, defaulting various fields
                      as necessary.

                      The fields of the envelope are in the following
                      order: date, subject, from, sender, reply-to, to,
                      cc, bcc, in-reply-to, and message-id.  The date,
                      subject, in-reply-to, and message-id fields are
                      strings.  The from, sender, reply-to, to, cc,
                      and bcc fields are lists of addresses.

                      An address is an S-expression format list that
                      describes an electronic mail address.  The fields
                      of an address are in the following order:
                      personal name, source-route (a.k.a. the
                      at-domain-list in SMTP), mailbox name, and
                      host name.

                      Any field of an envelope or address that is
                      not applicable is presented as the atom NIL.
                      Note that the server must default the reply-to
                      and sender fields from the from field; a client is
                      not expected to know to do this.

         FLAGS        An S-expression format list of flags that are set
                      for this message.  This may include the following
                      system flags:

                      \RECENT       Message arrived since the
                                     previous time this mailbox
                                     was read
                      \SEEN         Message has been read
                      \ANSWERED     Message has been answered
                      \FLAGGED      Message is "flagged" for
                                     urgent/special attention
                      \DELETED      Message is "deleted" for
                                     removal by later EXPUNGE

         INTERNALDATE  A string containing the date and time the
                       message was written to the mailbox.

         RFC822        A string expressing the message in RFC 822
                       format.

         RFC822.HEADER A string expressing the RFC 822 format
                       header of the message

         RFC822.SIZE   A number indicating the number of
                       characters in the message as expressed



Crispin                                                        [Page 19]

RFC 1176                         IMAP2                       August 1990


                       in RFC 822 format.

         RFC822.TEXT   A string expressing the text body of the
                       message, omitting the RFC 822 header.

   * FLAGS flag_list

      This response occurs as a result of a SELECT command.  The flag
      list are the list of flags (at a minimum, the system-defined
      flags) that are applicable for this mailbox.  Flags other than the
      system flags are a function of the server implementation.

   * SEARCH number(s)

      This response occurs as a result of a SEARCH command.  The
      number(s) refer to those messages that match the search criteria.
      Each number is delimited by a space, e.g., "SEARCH 2 3 6".

   * BBOARD string

      This response occurs as a result of a FIND BBOARDS command.  The
      string is a bulletin board name that matches the pattern in the
      command.

   * MAILBOX string

      This response occurs as a result of a FIND MAILBOXES command.  The
      string is a mailbox name that matches the pattern in the command.

   * BYE text

      This response identifies that the server is about to close the
      connection.  The text is a line of human-readable text that should
      be displayed to the user in a status report by the client.  This
      may be sent as part of a normal logout sequence, or as a panic
      shutdown announcement by the server.  It is also used by some
      servers as an announcement of an inactivity autologout.

   * OK text

      This response identifies normal operation on the server.  No
      special action by the client is called for, however, the text
      should be displayed to the user in some fashion.  This is
      currently only used by servers at startup as a greeting message to
      show they are ready to accept the first command.






Crispin                                                        [Page 20]

RFC 1176                         IMAP2                       August 1990


   * NO text

      This response identifies a warning from the server that does not
      affect the overall results of any particular request.  The text is
      a line of human-readable text that should be presented to the user
      as a warning of improper operation.

   * BAD text

      This response identifies a serious error at the server; it may
      also indicate faulty protocol from the client in which a tag could
      not be parsed.  The text is a line of human-readable text that
      should be presented to the user as a serious or possibly fatal
      error.  It should also be recorded in any telemetry as part of a
      bug report to the maintainer of the client and server.

   + text

      This response identifies that the server is ready to accept the
      text of a literal from the client.  Normally, a command from the
      client is a single text line.  If the server detects an error in
      the command, it can simply discard the remainder of the line.  It
      cannot do this for commands that contain literals, since a literal
      can be an arbitrarily long amount of text, and the server may not
      even be expecting a literal.  This mechanism is provided so the
      client knows not to send a literal until the server expects it,
      preserving client/server synchronization.

      In practice, this condition is rarely encountered.  In the current
      protocol, the only client command likely to contain a literal is
      the LOGIN command.  Consider a server that validates the user
      before checking the password.  If the password contains "funny"
      characters and hence is sent as a literal, then if the user is
      invalid an error would occur before the password is parsed.

      No such synchronization protection is provided for literals sent
      from the server to the client, for performance reasons.  Any
      synchronization problems in this direction would be caused by a
      bug in the client or server.












Crispin                                                        [Page 21]

RFC 1176                         IMAP2                       August 1990


Sample IMAP2 session

   The following is a transcript of an IMAP2 session.  Server output is
   identified by "S:" and client output by "U:".  In cases where lines
   are too long to fit within the boundaries of this document, the line
   is continued on the next line.

   S:   * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service
         6.1(349) at Thu, 9 Jun 88 14:58:30 PDT
   U:   a001 login crispin secret
   S:   a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76
   U:   a002 select inbox
   S:   * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question
         Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen)
   S:   * 16 EXISTS
   S:   * 0 RECENT
   S:   a002 OK Select complete
   U:   a003 fetch 16 all
   S:   * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT"
         RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
         "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
         "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
         "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
         "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH"
         "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL
         "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
   S:   a003 OK Fetch completed
   U:   a004 fetch 16 rfc822
   S:   * 16 Fetch (RFC822 {637}
   S:   Mail-From: RINDFLEISCH created at  9-Jun-88 12:55:43
   S:   Mail-From: FAGAN created at  4-Jun-88 13:27:12
   S:   Date: Sat, 4 Jun 88 13:27:11 PDT
   S:   From: Larry Fagan  <FAGAN@SUMEX-AIM.Stanford.EDU>
   S:   To: rindflEISCH@SUMEX-AIM.Stanford.EDU
   S:   Subject: INFO-MAC Mail Message
   S:   Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>
   S:   ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
   S:   ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
   S:   ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU,
         Crispin@SUMEX-AIM.Stanford.EDU
   S:   ReSent-Message-ID:
         <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
   S:
   S:   The file is <info-mac>usenetv4-55.arc  ...
   S:   Larry
   S:   -------
   S:   )
   S:   a004 OK Fetch completed



Crispin                                                        [Page 22]

RFC 1176                         IMAP2                       August 1990


   U:   a005 logout
   S:   * BYE DEC-20 IMAP II server terminating connection
   S:   a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
         Service logout















































Crispin                                                        [Page 23]

RFC 1176                         IMAP2                       August 1990


Implementation Discussion

   There are several advantages to the scheme of tags and unsolicited
   responses.  First, the infamous synchronization problems of SMTP and
   similar protocols do not happen with tagged commands; a command is
   not considered satisfied until a response with the same tag is seen.
   Tagging allows an arbitrary amount of other responses ("unsolicited"
   data) to be sent by the server with no possibility of the client
   losing synchronization.  Compare this with the problems that FTP or
   SMTP clients have with continuation, partial completion, and
   commentary reply codes.

   Another advantage is that a non-lockstep client implementation is
   possible.  The client could send a command, and entrust the handling
   of the server responses to a different process that would signal the
   client when the tagged response comes in.  Under certain
   circumstances, the client may have more than one command outstanding.

   It was observed that synchronization problems can occur with literals
   if the literal is not recognized as such.  Fortunately, the cases in
   which this can happen are rare; a mechanism (the special "+" tag
   response) was introduced to handle those few cases.  The proper way
   to address this problem is probably to move towards a record-oriented
   architecture instead of the text stream model provided by TCP.

   An IMAP2 client must maintain a local cache of data from the mailbox.
   This cache is an incomplete model of the mailbox, and at startup is
   empty.  A listener processes all unsolicited data, and updates the
   cache based on this data.  If a tagged response arrives, the listener
   unblocks the process that sent the tagged request.

   Unsolicited data needs some discussion.  Unlike most protocols, in
   which the server merely does the client's bidding, an IMAP2 server
   has a semi-autonomous role.  By sending "unsolicited data", the
   server is in effect sending a command to the client -- to update or
   extend the client's cache with new information from the server.  In
   other words, a "fetch" command is merely a request to the server to
   ensure that the client's cache has the most up-to-date version of the
   requested information.  A server acknowledgement to the "fetch" is a
   statement that all the requested data has been sent.

   Although no current server does this, a server is not obliged by the
   protocol to send data that it has already sent and is unchanged.  An
   exception to this is the actual message text fetching operations
   (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly
   excessive resource consumption of maintaining this data in a cache.
   It can not be assumed that a FETCH will transmit any data; only that
   an OK to the FETCH means that the client's cache has the most up-to-



Crispin                                                        [Page 24]

RFC 1176                         IMAP2                       August 1990


   date information.

   When a mailbox is selected, the initial unsolicited data from the
   server arrives.  The first piece of data is the number of messages.
   By sending a new EXISTS unsolicited data message the server causes
   the client to resize its cache (this is how newly arrived mail is
   handled).  If the client attempts to access information from the
   cache, it will encounter empty spots that will trigger "fetch"
   requests.  The request would be sent, some unsolicited data including
   the answer to the fetch will flow back, and then the "fetch" response
   will unblock the client.

   People familiar with demand-paged virtual memory operating system
   design will recognize this model as being similar to page-fault
   handling on a demand-paged system.




































Crispin                                                        [Page 25]

RFC 1176                         IMAP2                       August 1990


Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in RFC 822 with one exception; the
   delimiter used with the "#" construct is a single space (SP) and not
   a comma.

   address         ::= "(" addr_name SP addr_adl SP addr_mailbox SP
                       addr_host ")"

   addr_adl        ::= nil / string

   addr_host       ::= nil / string

   addr_mailbox    ::= nil / string

   addr_name       ::= nil / string

   bboard          ::= "BBOARD" SP string

   check           ::= "CHECK"

   copy            ::= "COPY" SP sequence SP mailbox

   data            ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number /
                       "BYE" SP text_line / "OK" SP text_line /
                       "NO" SP text_line / "BAD" SP text_line)

   date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"

   envelope        ::= "(" env_date SP env_subject SP env_from SP
                       env_sender SP env_reply-to SP env_to SP
                       env_cc SP env_bcc SP env_in-reply-to SP
                       env_message-id ")"

   env_bcc         ::= nil / "(" 1*address ")"

   env_cc          ::= nil / "(" 1*address ")"

   env_date        ::= string

   env_from        ::= nil / "(" 1*address ")"

   env_in-reply-to ::= nil / string

   env_message-id  ::= nil / string

   env_reply-to    ::= nil / "(" 1*address ")"



Crispin                                                        [Page 26]

RFC 1176                         IMAP2                       August 1990


   env_sender      ::= nil / "(" 1*address ")"

   env_subject     ::= nil / string

   env_to          ::= nil / "(" 1*address ")"

   expunge         ::= "EXPUNGE"

   fetch           ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
                       fetch_att / "(" 1#fetch_att ")")

   fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
                       "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
                       "RFC822.TEXT"

   find            ::= "FIND" SP find_option SP string

   find_option     ::= "MAILBOXES" / "BBOARDS"

   flag_list       ::= ATOM / "(" 1#ATOM ")"

   literal         ::= "{" NUMBER "}" CRLF ASCII-STRING

   login           ::= "LOGIN" SP userid SP password

   logout          ::= "LOGOUT"

   mailbox         ::= "INBOX" / string

   msg_copy        ::= "COPY"

   msg_data        ::= (msg_exists / msg_recent / msg_expunge /
                       msg_fetch / msg_copy)

   msg_exists      ::= "EXISTS"

   msg_expunge     ::= "EXPUNGE"

   msg_fetch       ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
                        envelope / "FLAGS" SP "(" 1#(recent_flag
                        flag_list) ")" / "INTERNALDATE" SP date /
                        "RFC822" SP string / "RFC822.HEADER" SP string /
                        "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
                        string) ")"

   msg_recent      ::= "RECENT"

   msg_num         ::= NUMBER



Crispin                                                        [Page 27]

RFC 1176                         IMAP2                       August 1990


   nil             ::= "NIL"

   noop            ::= "NOOP"

   password        ::= string

   recent_flag     ::= "\RECENT"

   ready           ::= "+" SP text_line

   request         ::= tag SP (noop / login / logout / select / check /
                       expunge / copy / fetch / store / search / find /
                       bboard) CRLF

   response        ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF

   search          ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
                       "BCC" SP string / "BEFORE" SP string /
                       "BODY" SP string / "CC" SP string / "DELETED" /
                       "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
                       "ON" SP string / "RECENT" / "SEEN" /
                       "SINCE" SP string / "TEXT" SP string /
                       "TO" SP string / "UNANSWERED" / "UNDELETED" /
                       "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")

   select          ::= "SELECT" SP mailbox

   sequence        ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
                       sequence)

   store           ::= "STORE" SP sequence SP store_att

   store_att       ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
                       "FLAGS" SP flag_list)

   string          ::= atom / """" 1*character """" / literal

   system_flags    ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
                       "\SEEN"

   tag             ::= atom

   unsolicited     ::= "*" SP (msg_num SP msg_data / data) CRLF

   userid          ::= string






Crispin                                                        [Page 28]

RFC 1176                         IMAP2                       August 1990


Implementation Status

   This information is current as of this writing.

   The University of Washington has developed an electronic mail client
   library called the "C-Client". It provides complete IMAP2, SMTP, and
   local mailbox (both /usr/spool/mail and mail.txt formats) services in
   a well-defined way to a user interface main program.  Using the C-
   Client, the University of Washington has created an operational
   client for BSD Unix and two operational clients (one basic, one
   advanced) for the NeXT.

   Stanford University/SUMEX has developed operational IMAP2 clients for
   Xerox Lisp machines, Texas Instruments Explorers, and the Apple
   Macintosh.  The core of the Macintosh client is an early version of
   the C-Client.  SUMEX has also developed IMAP2 servers for TOPS-20 and
   BSD Unix.

   All of the above software is in production use, with enthusiastic
   local user communities.  Active development continues on the
   Macintosh and C-Client based clients and the BSD Unix server.  This
   software is freely available from the University of Washington and
   SUMEX.

   IMAP2 software exists for other platforms; for example Nippon
   Telephone and Telegraph (NTT) has developed an operational IMAP2
   client for the NTT ELIS.  Several organizations are working on a PC
   client.

   IMAP2 can be used to access mailboxes at very remote sites, where
   echo delays and frequent outages make TELNET and running a local mail
   reader intolerable.  For example, from a desktop workstation on the
   University of Washington local network the author routinely uses
   IMAP2 to read and manage mailboxes on various University of
   Washington local servers, at two systems at Stanford University, at a
   Milnet site, and at a site in Tokyo, Japan.

   This specification does not make any formal definition of size
   restrictions, but the DEC-20 server has the following limitations:

    . length of a mailbox: 7,077,888 characters
    . maximum number of messages: 18,432 messages
    . length of a command line: 10,000 characters
    . length of the local host name: 64 characters
    . length of a "short" argument: 39 characters
    . length of a "long" argument: 491,520 characters
    . maximum amount of data output in a single fetch:
      655,360 characters



Crispin                                                        [Page 29]

RFC 1176                         IMAP2                       August 1990


   To date, nobody has run up against any of these limitations, many of
   which are substantially larger than most current user mail reading
   programs.

Acknowledgements

   Bill Yeager and Rich Acuff both contributed invaluable suggestions in
   the evolution of IMAP2 from the original IMAP.  James Rice pointed
   out several ambiguities in the previous IMAP2 specification and
   otherwise would not allow me to leave bad enough along.  Laurence
   Lundblade reviewed a draft of this version and made several helpful
   suggestions.

   Many dedicated individuals have worked on IMAP2 software, including:
   Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno,
   Christopher Schmidt, and Bill Yeager.

   Any mistakes, flaws, or sins of omission in this IMAP2 protocol
   specification are, however, strictly my own; and the mention of any
   name above does not imply an endorsement.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Mark R. Crispin
   Panda Programming
   6158 Lariat Loop NE
   Bainbridge Island, WA 98110-2020

   Phone: (206) 842-2385

   EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU
















Crispin                                                        [Page 30]