File: rfc1203.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 (2747 lines) | stat: -rw-r--r-- 120,579 bytes parent folder | download | duplicates (5)
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
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747






Network Working Group                                           J. Rice
Request for Comments: 1203                                     Stanford
Obsoletes: RFC 1064                                       February 1991


              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3

Status of this Memo

   This RFC suggests a method for workstations to access mail
   dynamically from a mailbox server ("repository").  This RFC specifies
   a standard for the SUMEX-AIM community and 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.

Scope

   The following document is a modified version of RFC 1064, the
   definition of the IMAP2 protocol.  This RFC has been written
   specifically as a counter proposal to RFC 1176, which itself proposes
   modifications to IMAP2.  Sadly, RFC 1176 was made without internal
   consultation with the IMAP community, so we are in a position of
   feeling we have to present a counter proposal to what, if we do not
   act, will become a de facto standard.  The reasons for this counter
   proposal are numerous but fall mostly into the following categories:

      - IMAP2 is insufficiently powerful for a number of server/client
        interactions which we believe to be important.  RFC 1176
        negligibly enhances the functionality of IMAP2.

      - IMAP2 makes what we believe to be an erroneous definition for
        unsolicited vs. solicited data.  IMAP3 as specified herein
        attempts to correct this.  RFC 1176 makes no effort to remedy
        these problems.

      - RFC 1176 has explicitly modified the intent of RFC 1064 by
        allowing the server to make assumptions about the client's
        caching architecture.  We believe this to be a grave error
        and do not support it in this proposal.

      - RFC 1176 specifies a number of "optional" features in the
        protocol without specifying a suitable metaprotocol by which
        servers and clients can adequately negotiate over the set of
        implemented features.  This proposal specifies a mechanism
        by which servers and clients can come to an unambiguous
        understanding about which features are usable by each party.



Rice                                                            [Page 1]

RFC 1203                         IMAP3                     February 1991



      - RFC 1176 pays only lip-service to being network protocol
        independent and, in fact assumes the use of TCP/IP.  Neither
        RFC 1064 nor this proposal make any such assumption.

   Although there are numerous other detailed objections to RFC 1176, we
   believe that the above will serve to show that we believe strongly in
   the importance of mailbox abstraction level mail protocols and, after
   a couple of years of use of IMAP2 under RFC 1064 we believe that we
   have a good enough understanding of the issues involved to be able to
   take the next step.

   It is important to take this next step because of the rapid pace of
   both mail system and user interface development.  We believe that,
   for IMAP not to die in its infancy, IMAP must be ready to respond to
   emerging ISO and RFC standards in mail, such as for multi-media mail.
   We believe that RFC 1176 not only provides a very small increment in
   functionality over RFC 1064 but also adds a number of bugs, which
   would be detrimental to the IMAP cause.  Thus we propose the
   following definition for IMAP3.

Compatibility notes:

   In revising the IMAP2 protocol it has been our intent, wherever
   possible to make upwards compatible changes to produce IMAP3.  There
   were, however, some places that had to be changed incompatibly in
   order to compensate for either ambiguities in the IMAP2 protocol as
   defined by RFC 1064 or behavior that proved undesirable in the light
   of experience.

   It is our goal, however, that existing IMAP2 clients should still be
   supported and that, at least for the foreseeable future, all IMAP3
   servers will support IMAP2 behavior as their default mode.

   The following are the major differences between this proposal, RFC
   1176 and RFC 1064:

      - In this proposal we specify a difference between "solicited" and
        "unsolicited" data sent from the server.  It is generally the
        case that data sent by the server can be sent either in response
        to an explicit request by the client or by the server of its own
        volition.  Any data that the server is required to sent to the
        client as the result of a request is said to be solicited and
        carries the same tag as the request that provoked it.  Any data
        sent by the server to the client that is not required by the
        protocol is said to be unsolicited and carries the special "*"
        tag.  RFC 1176 preserves the original RFC 1064 terminology that
        calls all such data sent by the server "unsolicited" even when



Rice                                                            [Page 2]

RFC 1203                         IMAP3                     February 1991


        it is, in fact, solicited.

      - This proposal introduces the experimental concept of
        distinguishing between Generic, Canonical and Concrete keys,
        allowing the mailbox to be viewed as a relational database
        indexed by these keys.  This should allow the IMAP protocol
        to evolve away from its current reliance on RFC 822.  RFC 1176
        does not have such a unifying model.

      - The SEARCH command has been changed so as to allow multiple
        simultaneous searches to be made and to allow unsolicited
        search messages to be sent by the server.  Such a change is
        essential to allow more sophisticated servers that can process
        commands asynchronously, possibly substantially delaying
        searches over slow backing storage media, for example.  It is
        also important to allow servers to be able to send unsolicited
        search messages that might inform the client of interesting
        patterns of messages, such as new and unseen mail.

      - This proposal introduces a specific protocol for the negotiation
        of protocol versions and server features.  This is important
        because it allows client/server pairs to come to an agreement on
        what behavior is really available to it.  RFC 1176 introduces a
        number of "optional" commands, which are in some way analogous
        to "feature-introduced" commands in this proposal.  The principle
        distinction between these is that in RFC 1176 there is no way
        for a client to discover the set of optional commands, nor is
        there a way for it to determine whether a specific command
        really is supported, since RFC 1176 requires the use of the
        "BAD" response if a feature is not supported.  There is,
        therefore, no way for the client to determine why the attempted
        command did not work.  This also means that, for example, a
        client cannot disable certain user commands or make them
        invisible on menus if they are not supported, since there
        is no way for the client to discover whether the commands are
        indeed supported without trying to execute such a command.

      - This proposal introduces a mechanism for clients to create and
        delete user flags (keywords).  This is nor supported in either
        RFC 1176 or RFC 1064, requiring the user to add keys manually
        on the server, generally by editing some form of "init" file.

      - RFC 1064 has no mechanism for determining whether a mailbox is
        readonly or not.  RFC 1176 introduces a non-enforced convention
        of encoding data about the readonly status of a mailbox in the
        SELECT message's OK respose comment field.  This is not regular
        with respect to the rest of the protocol, in which the comment
        field is used for no purpose other than documentation.  This



Rice                                                            [Page 3]

RFC 1203                         IMAP3                     February 1991


        proposal introduces specific protocol additions for the dynamic
        determination and modification of the readonly/readwrite status
        of mailboxes.

Introduction

   The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3)
   is to allow a (possibly unreliable) workstation or similar machine to
   access electronic mail from a reliable mailbox server in an efficient
   manner.

   Although different in many ways from POP2 (RFC 937), IMAP3 may be
   thought of as a functional superset of POP2, and the POP2 RFC was
   used as a model for this RFC.  There was a cognizant reason for this;
   RFC 937 deals with an identical problem and it was desirable to offer
   a basis for comparison.

   Like POP2, IMAP3 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).  A comparison with the DMSP protocol of
   PCMAIL can be found at the end of "System Model and Philosophy"
   section.

   This protocol assumes a reliable data stream such as provided by TCP
   or any similar protocol.  When TCP is used, the IMAP server listens
   on port 220.  When CHAOS is used the IMAP server listens for the
   logical contact name "IMAP3".

   Communication in IMAP is defined to be using the ASCII character
   interpretation of data.  Communication using other conventions may be
   possible by the selection of features on some servers.

System Model and Philosophy

   Electronic mail is a primary means of communication for the widely
   spread SUMEX-AIM community.  The advent of distributed workstations
   is forcing a significant rethinking of the mechanisms employed to
   manage such mail.  With mainframes, each user tends to receive and
   process mail at the computer he used 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, in fact, many vendors have implemented
   facilities to do this.  However, this approach has several
   disadvantages:

      (1)  Workstations (especially Lisp 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,



Rice                                                            [Page 4]

RFC 1203                         IMAP3                     February 1991


           like receiving mail, could well be kept from running for
           long periods of time either because the user is asking to
           use all of the machine's resources, or because, in the course
           of working, the user has (perhaps accidentally) manipulated
           the environment in such a way as to prevent mail reception.
           This could lead to repeated failed delivery attempts by
           outside agents.

      (2)  The hardware failure of a single workstation could keep its
           user "off the air" for a considerable time, since repair of
           individual workstation units might be delayed.  Given the
           growing number of workstations spread throughout office
           environments, quick repair would not be assured, whereas a
           centralized mainframe is generally repaired very soon after
           failure.

      (3)  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 a large number of 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.

      (4)  It is very difficult to keep a multitude of heterogeneous
           workstations 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 the workstation may be viewed as an Internet host
   in the sense that it implements IP, it should not be viewed as the
   entity which contains the user's mailbox.  Rather, a mail server
   machine (sometimes called a "repository") should hold the mailbox,
   and the workstation (hereafter referred to as a "client") should
   access the mailbox via mail transactions.  Because the mail server
   machine would be isolated from direct user manipulation, it could
   achieve high software reliability easily, and, as a shared resource,



Rice                                                            [Page 5]

RFC 1203                         IMAP3                     February 1991


   it could achieve high hardware reliability, perhaps through
   redundancy.  The mail server could be used from arbitrary locations,
   allowing users to read mail across campus, town, or country using
   more and more 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.  The mail access protocol is used to retrieve
   messages, access and change properties of messages, and manage
   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
   utilize 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.

   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's desirable to allow for a
   growth path beyond the hoary text-only RFC 822 protocol.  Unlike
   POP2, IMAP3 has extensive features for remote searching and parsing
   of messages on the server.  For example, a free text search
   (optionally in conjunction with other searching) can be made
   throughout 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.

   Additionally, IMAP3 offers several facilities for managing a mailbox
   beyond the simple "delete message" functionality of POP2.

   In spite of this, IMAP3 is a relatively simple protocol.  Although
   servers should implement the full set of IMAP3 functions, a simple
   client can be written which uses IMAP3 in much the way as a POP2
   client.

   IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more
   fundamental manner, reflecting the differing architectures of IMAP
   and PCMAIL.  PCMAIL is either an online ("interactive mode"), or
   offline ("batch mode") system.  IMAP is primarily an online system in
   which real-time and simultaneous mail access were considered



Rice                                                            [Page 6]

RFC 1203                         IMAP3                     February 1991


   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 which 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
   state from the server.

   In IMAP, the client/server relationship lasts only for the duration
   of the IMAP3 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".  This structure makes it unnecessary for a client to know
   anything about RFC 822 parsing.  There is no synchronization since
   the client does not remember state between IMAP3 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 IMAP3 and DMSP.
   DMSP has functions for sending messages, printing messages, and
   changing passwords, all of which are done outside of IMAP3.  DMSP has
   16 binary flags of which 8 are defined by the system.  IMAP has flag
   names; there are currently 5 defined system flag names and a facility
   for some number (29 in the current implementations) of user flag
   names.  IMAP3 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 relatively small set of "interesting" messages, which
   were either "new" mail or mail based upon some user-selected
   criteria. Consequently, IMAP3 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".

   One crucial philosophical difference between IMAP and other common



Rice                                                            [Page 7]

RFC 1203                         IMAP3                     February 1991


   mail protocols is that IMAP is a mailbox access protocol, not a
   protocol for manipulating mail files.  In the IMAP model, unlike
   other mail system models in which mail is stored in a linear mail
   file, no specification is made for the implementation architecture
   for mail storage.  Servers may choose to implement mailboxes as files
   but this is a detail of which the client can be totally unaware.

   What is more, in the IMAP model, mailboxes are viewed as mappings
   from keys into values.  There are broadly three types of keys,
   generic, canonical and concrete.  Generic keys are generic, mail
   protocol independent keys defined by IMAP which are meaningful across
   multiple mail encoding formats.  An example of such a generic key
   might be "TO", which would be associated with the "To:" field of an
   RFC 822 format message.

   Canonical keys represent the way in which the server can associate
   values that are generally "about" a certain key concept, possibly
   integrating several mail format specific fields, without having to
   worry the client with the particular details of any particular
   message format.  Thus, the canonical TO key (called $TO) could denote
   anything that could reasonably be construed as being directed towards
   someone.  Hence, in an RFC 822 message the server could find the
   union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to
   be the appropriate value associated with the canonical $TO key.

   Concrete keys allow the client to gain access to certain mail format
   specific concepts, that are not pre-specified by the IMAP protocol,
   in a well defined manner.  For example, If the client asks for the
   value associated with the "APPARENTLY-TO" key then, if the message
   were to be in RFC 822 format, the server would look for a header
   field called "Apparently-To:".  If no such field is found or the
   field is not implemented or meaningful for the particular message
   format then the server will respond with the null value, called NIL,
   indicating the non-existence of the field.

   Thus, IMAP servers are at liberty to implement mailboxes as a
   relational databases if it seems convenient.  Indeed, we anticipate
   that future mail systems will tend to use database technology for the
   storage and indexing of mailboxes as a result of the pressure caused
   by the increasing size of mailboxes.

   Although for historical reasons IMAP is currently somewhat closely
   associated with RFC 822, we anticipate that future developments in
   IMAP will remove these mail format specific components and will move
   towards the generic model mentioned above.  This will allow IMAP more
   easily to incorporate such things as multi-media mail.





Rice                                                            [Page 8]

RFC 1203                         IMAP3                     February 1991


The Protocol

   The IMAP3 protocol consists of a sequence of client commands and
   server responses to those commands, with extra information from the
   server data being sent asynchronously to and independent to the
   responses to client commands.  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.

   We distinguish between data sent by the server as the result of a
   client request, which we term "SOLICITED" and data sent by the server
   not as the result of a client request, which we term "UNSOLICITED".
   The server may send unsolicited data at any time that would not
   fragment another piece of data on the same stream rendering it
   unintelligible.  The server is contractually required, however, to
   return all data that is solicited by the client before the return of
   the completion signal for that command, i.e., all solicited data must
   be returned within the temporal extent of the request/completion
   acknowledgement wrapper.  This does not, however, preclude the
   simultaneous processing of multiple requests by the client, it simply
   requires that the client be confident that it has all the requested
   data when a request finishes.  This allows the implementation of both
   synchronous and asynchronous clients.

   Solicited data is identified by the tag of the initial request by the
   client.  Unsolicited data is identified by the special reserved tag
   of "*".  There is another special reserved tag, "+", discussed below.

   Note: the tagging of SOLICITED data is only permitted for a selected
   server version other than 2.0.

   No assumptions concerning serial or monolithic processing by the
   server can be made by a correct client.  The server is at liberty to
   process multiple requests by the same client in any order.  This
   allows servers to process costly searches over mailboxes on slow
   backing storage media in the background, while still preserving
   interactive performance.  Clients can, however, assume the
   serialization of the request/data/completion behavior mentioned
   above.

   When a connection is opened the server sends an unsolicited OK
   response as a greeting message and then waits for commands.  When
   commands are received the server acts on them and responds with
   responses, often interspersed with data.




Rice                                                            [Page 9]

RFC 1203                         IMAP3                     February 1991


   The client opens a connection, waits for the greeting, then sends a
   LOGIN command with user name and password arguments to establish
   authorization.  Following an OK response from the server, the client
   then sends a SELECT command to access the desired mailbox.  The
   user's default mailbox has a special reserved name of "INBOX" which
   is independent of the operating system that the server is implemented
   on.  The server will generally send a list of valid flags, number of
   messages, and number of messages arrived since last access for this
   mailbox as solicited data, followed by an OK response.  The client
   may terminate access to this mailbox and access a different one with
   another SELECT command.

   Because the SELECT command affects the state of the server in a
   fundamental way, the server is required to process all outstanding
   commands for any given mailbox before sending the OK tag for the
   SELECT command.  Thus, the client will always know that all responses
   before an OK SELECT response will refer to the old mailbox and all
   responses following it will apply to the new mailbox.

   Because, in the real world, local needs or experimental work will
   dictate that servers will support both supersets of the defined
   behavior and incompatible changes, servers will support a
   SELECT.VERSION command and a SELECT.FEATURES command, the purpose of
   which is to allow clients to select the overall behavior and specific
   features that they want from a server.  The default behavior of any
   server is to process commands and to have interaction syntax the same
   as is specified by IMAP2 in RFC 1064.  A server may not behave in any
   other manner unless the SELECT.VERSION or SELECT.FEATURES commands
   are used to select different behavior.

   Over time, when groups of generally useful changes to the current,
   default behavior of the server are found, these will be collected
   together and incorporated in such a way that all of the features can
   be selected simply by selecting a particular major version number of
   the protocol.  It should be noted that the version numbers (both
   major and minor) selected by the SELECT.VERSION command denote
   versions of the IMAP protocol, not versions of the server per se.
   Thus, although in general changes to the protocol specification will
   be made in such a way that they are upwards compatible, this cannot
   be guaranteed.  No client should rely on tests of the form "if
   major_version > 2 then..." being valid for all protocol versions,
   since incompatible changes might be made in the future.

   The client reads mailbox information by means of FETCH commands.  The
   actual data is transmitted via the solicited data mechanism (that is,
   FETCH should be viewed as poking 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 which may be fetched.



Rice                                                           [Page 10]

RFC 1203                         IMAP3                     February 1991


   The first category is that data which is associated with a message as
   an entity in the mailbox.  There are presently 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 of 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 which 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 which 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.]  IMAP3 defines a
   structured and unambiguous representation for the envelope which is
   particularly nice 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 and
   second category 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 which is intended for direct human
   viewing.  The present RFC 822 based IMAP3 defines three such items:
   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
   former appended together in a single text string).  Fetching "RFC822"
   is equivalent to typing the RFC 822 representation of the message as
   stored on the mailbox without any filtering or processing.

   Typically, a 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 POP2-type functionality.

   The client can alter certain data by means of a STORE command.  As an
   example, a message is deleted from a mailbox by a STORE command which
   includes the \DELETED flag as one of the flags 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 which match certain criteria (SEARCH command).



Rice                                                           [Page 11]

RFC 1203                         IMAP3                     February 1991


   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 IMAP3 Server Ready
                                    {Wait for command}
    A001 SUPPORTED.VERSIONS   -->
                                <-- * SUPPORTED.VERSIONS ((2 0 )
                                        (3 0 EIGHT.BIT.TRANSPARENT
                                             AUTO.SET.SEEN
                                             TAGGED.SOLICITED))
                                    A001 OK Supported Versions returned.
                                    {Wait for command}
    A002 SELECT.VERSION (3 0) -->
                                <-- A002 OK Version 3.0 Selected.
                                    {Wait for command}
    A002 SELECT.FEATURES TAGGED.SOLICITED -->
                                <-- A002 OK Features selected.
                                    {Wait for command}
    A003 LOGIN Fred Secret   -->
                                <-- A003 OK User Fred logged in
                                    {Wait for command}
    A004 SELECT INBOX        -->
                                <-- A004 FLAGS (Meeting Notice \Answered
                                             \Flagged \Deleted \Seen)
                                <-- A004 19 EXISTS
                                <-- A004 2 RECENT
                                <-- A004 OK Select complete
                                    {Wait for command}
    A005 FETCH 1:19 ALL      -->
                                <-- A005 1 Fetch (......)
                                        ...
                                <-- A005 18 Fetch (......)
                                <-- A005 19 Fetch (......)
                                <-- A005 OK Fetch complete
                                    {Wait for command}
    A006 FETCH 8 RFC822.TEXT -->
                                <-- A006 8 Fetch (RFC822.TEXT {893}
                                       ...893 characters of text...
                                <-- )
                                <-- A006 OK Fetch complete
                                    {Wait for command}




Rice                                                           [Page 12]

RFC 1203                         IMAP3                     February 1991


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

   A more complex scenario produced by a pipelining multiprocess client.

        Client                          Server
        ------                          ------
                                    {Wait for Connection}
    {Open session as above}
                                <-- A004 19 EXISTS
                                <-- A004 2 RECENT
                                <-- A004 OK Select complete
                                    {Wait for command}
    A005 SEARCH RECENT       -->
                                <-- A005 SEARCH (18 19) (RECENT)
                                <---A005 OK Search complete
    A006 FETCH 18:19 ALL RFC822.TEXT
    A007 STORE 18:19 +FLAGS (\SEEN)
    A008 FETCH 1:17 ALL      -->
                                <-- A006 18 Fetch (... RFC822.TEXT ...)
    A009 STORE 18 +FLAGS (\DELETED)
                                <-- A006 19 Fetch (... RFC822.TEXT ...)
                                <-- A006 OK Fetch complete
                                <-- A007 18 STORE (Flags (\Seen))
    A010 STORE 19 +FLAGS (\DELETED)
                                <-- A007 19 STORE (Flags (\Seen))
                                <-- A007 OK Store complete
                                <-- A008 1 Fetch (......)
                                       ...
                                <-- A008 16 Fetch (......)
                                <-- A008 17 Fetch (......)
                                <-- A008 OK Fetch complete
                                <-- A009 18 STORE (Flags (\Seen
                                                          \Deleted))



Rice                                                           [Page 13]

RFC 1203                         IMAP3                     February 1991


                                <-- A009 OK Store complete
                                <-- A010 19 STORE (Flags (\Seen
                                                          \Deleted))
                                <-- A010 OK Store complete
                                    {Wait for command}
                                <-- * EXISTS 23
                                <-- * RECENT 4
                                <-- * SEARCH (20 21 22 23) (RECENT)
   A011 FETCH 20:23 ALL RFC822.TEXT

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 which 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.

   One of the most common fields in the IMAP3 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 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



Rice                                                           [Page 14]

RFC 1203                         IMAP3                     February 1991


   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 indicating all numbers between
   those two numbers, or a list of single numbers and/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 of those messages.

Definitions of Commands and Responses

   Summary of Commands and Responses

Commands:
       tag NOOP
       tag LOGIN user password
       tag LOGOUT
       tag SELECT mailbox
       tag CHECK
       tag EXPUNGE
       tag COPY sequence mailbox
       tag FETCH sequence data
       tag STORE sequence data value
       tag SEARCH criteria
       tag BBOARD bboard
       tag FIND (BBOARDS / MAILBOXES) pattern
       tag READONLY
       tag READWRITE
       tag SELECT.VERSION (major_version minor_version)
       tag SELECT.FEATURES features
       tag SUPPORTED.VERSIONS
       tag FLAGS
       tag SET.FLAGS

Responses (can be either solicited or unsolicited):
       */tag FLAGS flag_list
       */tag SEARCH (numbers) (criteria)
       */tag EXISTS
       */tag RECENT
       */tag EXPUNGE
       */tag STORE data
       */tag FETCH data
       */tag BBOARD bboard_name
       */tag MAILBOX non_inbox_mailbox_name
       */tag SUPPORTED.VERSIONS version_data
       */tag READONLY
       */tag READWRITE
       */tag OK text
       */tag NO text
       */tag BAD text



Rice                                                           [Page 15]

RFC 1203                         IMAP3                     February 1991


       */tag BYE text

Responses (can only be solicited):
       tag COPY message_number

Responses (can only be unsolicited):
       + 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 which 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 which 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
      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 indicates the client is done with the session.
      The server sends a solicited BYE response before the (tagged) OK
      response, and then closes the 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.
      Prior to returning an OK to the client, the server must send an
      solicited FLAGS and <n> EXISTS response to the client giving the
      flags list for this mailbox (simply the system flags if this
      mailbox doesn't have any special flags) and the number of messages
      in the mailbox.  It is also recommended that the server send a <n>
      RECENT unsolicited response to the client for the benefit of
      clients which make use of the number of new messages in a mailbox.
      It is further recommended that servers should send an unsolicited
      READONLY message if the mailbox that has been selected is not



Rice                                                           [Page 16]

RFC 1203                         IMAP3                     February 1991


      writable by the user.

      Multiple SELECT commands are permitted in a session, in which case
      the prior mailbox is deselected first.

      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 path of the
      mailbox on the current servers), though it could reflect any
      server-specific naming convention for the namespace of mailboxes.
      Such a namespace need not and should not be viewed as being
      equivalent or linked to the server machine's file system.

      EXAMPLES: A002 SELECT INBOX  ;; selects the default mailbox.
                A002 197 EXISTS    ;; server says 197 messages in INBOX
                A002 5 RECENT      ;; server says 5 are recent.
                A002 OK Select complete.
      or
                A003 SELECT /usr/fred/my-mail.txt
                 ;; select a different user specified mailbox.
                ...

   tag CHECK

      The CHECK command forces a check for new messages and a rescan of
      the mailbox for internal change for those implementations which
      allow multiple simultaneous read/write access to the same mailbox
      (e.g., TOPS-20).  It is recommend that periodic implicit checks
      for new mail be done by servers as well.  The server must send a
      solicited <n> EXISTS response prior to 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.  Prior to
      returning an OK to the client, for each message which is removed,
      a solicited <n> EXPUNGE response is sent indicating which message
      was removed.  The message number of each subsequent message in the
      mailbox is immediately decremented by 1; this means that if the
      last 5 messages in a 9-message mailbox are expunged you will
      receive 5 "5 EXPUNGE" responses for message 5.  To ensure mailbox
      integrity and server/client synchronization, it is recommended
      that the server do an implicit check prior to commencing the
      expunge and again when the expunge is completed.  Furthermore, if
      the server allows multiple simultaneous access to the same mailbox
      the server must guarantee both the integrity of the mailbox and



Rice                                                           [Page 17]

RFC 1203                         IMAP3                     February 1991


      the views of it held by the clients.

      EXPUNGE is not allowed if the user does not have write access to
      this mailbox.  If a user does not have write access to the mailbox
      then the server is required to signal this fact by replying with a
      NO response with a suitable text string that can be presented to
      the user explaining that the mailbox is read-only.  It is further
      recommended that servers send an unsolicited READONLY message to
      clients that attempt an expunge operation on a read only 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.  Prior to returning an OK to the
      client, the server must return a solicited <n> COPY response for
      each message copied.

      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.  If a user does not have write access to the
      destination mailbox then the server is required to signal this
      fact by replying with a NO response with a suitable text string
      that can be presented to the user explaining that the mailbox is
      read-only.  It is further recommended that servers send an
      unsolicited READONLY message to clients that attempt to copy to a
      read only mailbox.  IMAP3 does not specify "where" the message
      will be put in the mailbox to which it has been copied.

   tag FETCH sequence fetch_att

      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 attributes that can be fetched are
      any of those mentioned specifically below along with any generic,
      canonical or concrete key.  The set of predefined generic keys is:
      {BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}.  The set
      of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}.  The
      value returned by the server for a non-existent or non-meaningful
      key is defined to be the null value, NIL.

      ALL             Equivalent to:
                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)

      ENVELOPE        The envelope of the message.  The envelope is
                      computed by the server by parsing the header,



Rice                                                           [Page 18]

RFC 1203                         IMAP3                     February 1991


                      i.e., the RFC 822 header for an RFC822 format
                      message, into the component parts, defaulting
                      various fields as necessary.

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

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

                              \RECENT    Message arrived since
                                          last read of this mailbox
                              \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.

      RFC822          The message in RFC 822 format.

      RFC822.HEADER   The RFC 822 format header of the message.

      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.

      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.

      A006 FETCH 42 $SUBJECT
      A006 FETCH $SUBJECT "Some subject text..."
      A006 OK FETCH completed ok.
         fetches the canonical subject field.



Rice                                                           [Page 19]

RFC 1203                         IMAP3                     February 1991


      A007 FETCH 42 APPARENTLY-TO
      A007 FETCH APPARENTLY-TO NIL
      A007 OK FETCH found no value.
         fetches the concrete apparently-to field.

   tag STORE sequence data value

      The STORE command alters the values associated with particular
      keys for a message in the mailbox.  As is the case for the FETCH
      command, any generic, canonical or concrete key may be used to
      index the value provided.  In addition to these, the following
      pre-defined keys are provided.

   FLAGS           Replace the flags for the message with the
                   argument (in flag list format).
                  The server must respond with a solicited STORE FLAGS
                  message, showing the new state of the flags after
                  the store.

   +FLAGS          Add the flags in the argument to the
                   message's flag list.
                 The server must respond with a solicited STORE FLAGS
                 message, showing the new state of the flags after
                 the store.

  -FLAGS          Remove the flags in the argument from the
                  message's flag list.
                 The server must respond with a solicited STORE FLAGS
                 message, showing the new state of the flags after
                 the store.

  RFC822.HEADER   Replace the header of the message(s) with that
                  specified.  This allows users to use their mailboxes
                  as databases with header fields as keys.
                  The server must respond with solicited
                  STORE RFC822.HEADER, STORE RFC822.SIZE and
                  STORE ENVELOPE messages,  showing the new state
                  of the reparsed header after the store.

  RFC822.TEXT     Replace the body of the messages with that specified.
                  The server must respond with solicited
                  STORE RFC822.TEXT and STORE RFC822.SIZE messages,
                  showing the new state of the message after the store.

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

         The server is required to send a solicited STORE response for



Rice                                                           [Page 20]

RFC 1203                         IMAP3                     February 1991


         each store operation that results in a format transformation by
         the server.  For example, the server is required to send a
         STORE FLAGS response when the client performs a STORE +FLAGS or
         a STORE -FLAGS, since the client may not easily be able to know
         what the result of this command will be.  Similarly, if the
         client emits a STORE FROM command then the server should
         respond with a suitable STORE FROM response because the client
         would be sending a string value to be stored and the server
         should transform this into a set of addresses.  In general,
         however, although it is legal for the server to send a
         solicited STORE response for each STORE operation, this is
         discouraged, since it might result in the retransmission of
         very large and unnecessary amounts of data that have been
         stored.

         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 which match
      the given set of criteria.  The server response SEARCH (criteria)
      (numbers) gives the set of messages which match the conjunction of
      the criteria specified.  In addition to each of the search
      criteria there is its logical inverse.  The logical inverse
      criterion is denoted by the ~ (tilda) sign.

      Thus, no message that matches the criterion:
         FROM crispin

      will match the criterion:
         ~FROM crispin

      The criteria for the search can be any generic, canonical or
      concrete key.  In addition to these, the following pre-defined
      keys are also provided:

      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.




Rice                                                           [Page 21]

RFC 1203                         IMAP3                     February 1991


      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.

      HEADER string   Messages which contain the specified string
                      in the message header.

      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".

      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.

         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 mailbox since October 1, 1987.

      Implementation note:  The UNANSWERED, UNDELETED, UNFLAGGED,



Rice                                                           [Page 22]

RFC 1203                         IMAP3                     February 1991


      UNKEYWORD and UNSEEN criteria, described below, are preserved in
      IMAP3 for IMAP2 compatibility.  They are, however, considered
      obsolete and new Client programs are encouraged to use the ~
      notation for the logical inverses of search criteria with a view
      to the dropping of this outmoded syntax in later versions.

      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.

   tag READONLY

      The READONLY command indicates that the client wishes to make the
      mailbox read-only.  The server is required to reply with a
      solicited READONLY or READWRITE response.

   tag READWRITE

      The READWRITE command indicates that the client wishes to make the
      mailbox read-write.  The server is required to reply with a
      solicited READONLY or READWRITE response.

   tag SUPPORTED.VERSIONS

      The SUPPORTED.VERSIONS solicits from the server a
      SUPPORTED.VERSIONS message, which encapsulates information about
      which versions and features the server supports.

   tag SELECT.VERSION (major_version minor_version)

      The SELECT.VERSION command indicates that the client wishes to
      select certain behavior on the part of the server.  The major and
      minor versions indicate the specific version of the protocol being
      selected.

      EXAMPLE: A002 SELECT.VERSION (3 0)

      A client may not request a server version that is not supported by



Rice                                                           [Page 23]

RFC 1203                         IMAP3                     February 1991


      the server, i.e., which is specifically mentioned in the response
      to a SUPPORTED.VERSIONS command.  An attempt to do so by a client
      will result in a NO response from the server.  It is an error for
      the SELECT.VERSION command to be used after a mailbox has been
      selected.  The rationale for this is that for some server
      implementations it might be necessary to spawn separate programs
      to implement widely divergent protocol versions.  Thus, the client
      cannot be allowed to expect any server state to be preserved after
      the use of the SELECT.VERSION command.  The default version of all
      servers is 2.0, i.e., IMAP2 as defined by RFC 1064.

   tag SELECT.FEATURES 1#features

      The SELECT.FEATURES command indicates that the client wishes to
      select certain specific features on the part of the server. A
      client may not request a feature that is not supported by the
      server, i.e., one that is explicitly mentioned in the set of
      features for the selected version returned by the
      SUPPORTED.VERSIONS command.  An attempt to do so by a client will
      result in a NO response from the server.

      EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED
              EIGHT.BIT.TRANSPARENT

      i.e., select the set of features called AUTO.SET.SEEN and
      EIGHT.BIT.TRANSPARENT and deselect the feature called
      TAGGED.SOLICITED.  The use of the SELECT.FEATURES command
      completely resets the set of selected features.  Note:  These are
      only example feature names and are not necessarily supported by
      any server.  See the appendix on features for more information on
      features.  Note:  Some features, when present in the server, will
      cause the upwards compatible extension of the grammar, i.e., by
      adding extra commands.  The server is at liberty not to remove
      these upwards compatible extensions to the command tables when a
      feature is disabled.  Thus, it is an error for a client to rely on
      getting a NO or BAD response in any way, for instance to determine
      the selectedness or presence of a feature.

   tag BBOARD bboard

      The BBOARD command is equivalent to SELECT, except that its
      argument is a bulletin board (BBoard) name.  The format of a
      BBoard 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 on the particular system.
      There is no requirement that a BBoard name be a mailbox name or a
      file name (in particular, Unix netnews has a completely different
      namespace from mailbox or file names).



Rice                                                           [Page 24]

RFC 1203                         IMAP3                     February 1991


      The result from the BBOARD command is identical from that of the
      SELECT command.  For example, in the TOPS-20 server
      implementation, the command
         A0002 BBOARD FOO
      is exactly equivalent to the command
         A0002 SELECT POBOX:<BBOARD>FOO.TXT
         Note: the equivalence in this example is *not* required by the
         protocol, and merely reflects the fuzzy distinction between
         mailboxes and BBoards on TOPS-20.

   tag FIND (BBOARDS / MAILBOXES) pattern

      The FIND command accepts as arguments the keywords BBOARDS or
      MAILBOXES and a pattern which specifies some set of BBoard/mailbox
      names which are usable by the BBOARD/SELECT command.  Two wildcard
      characters are defined; "*" specifies that any number (including
      zero) characters may match at this position and "%" specifies that
      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; furthermore, "*" will match all
      BBoards/mailboxes.  The following quoting convention applies to
      wildcards: "\*" is the literal "*" character, "\%" is the literal
      "%" character and "\\" is the literal "\" character.  Notes: The
      format of mailboxes is server implementation dependent.  The
      special mailbox name INBOX is not included in the output to the
      FIND MAILBOXES command.

      The FIND command solicits any number of BBOARD or MAILBOX
      responses from the server as appropriate.

      Examples:
          A0002 FIND BBOARDS *
          A0002 BBOARD FOOBAR
          A0002 BBOARD GENERAL
          A0002 OK FIND completed
      or
          A0002 FIND MAILBOXES FOO%BA*
          A0002 MAILBOX FOO.BAR
          A0002 MAILBOX FOO.BAZZAR
          A0002 OK FIND completed

      Note: 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 solicited
      reply be usable in the SELECT command without remembering any path
      specification which may have been used in the FIND MAILBOXES
      pattern.




Rice                                                           [Page 25]

RFC 1203                         IMAP3                     February 1991


   tag FLAGS

      The FLAGS command solicits a FLAGS response from the server.

   tag SET.FLAGS flag_list

      The SET.FLAGS command defines the user specifiable flags for this
      mailbox, i.e., the keywords.  If this set does not include flags
      formerly sent to the client by the server in a FLAGS message then
      this constitutes a request to delete the flag.  Any new flags
      should be created.  This command does not affect the system
      defined flags and any system flags that are included in the
      flag_list will be ignored.  The server must respond to this
      command with a solicited FLAGS message.  If the deletion of a flag
      results in the invalidation of the flag sets of any messages then
      the server is required to send solicited STORE FLAGS messages to
      the client for each modified message.

Responses:

   */tag OK text

      In its solicited form this response identifies successful
      completion of the command with the indicated tag.  The text is a
      line of human-readable text which may be useful in a protocol
      telemetry log for debugging purposes.

      In its unsolicited form, this response indicates simply that the
      server is alive.  No special action on the part of the client is
      called for.  This is presently only used by servers at startup as
      a greeting message indicating that they are ready to accept the
      first command.  This usage, although legal, is by no means
      required.  The text is a line of human-readable text which may be
      logged in protocol telemetry.

   */tag NO text

      In its solicited form this response identifies unsuccessful
      completion of the command with the indicated tag.  The text is a
      line of human-readable text which probably should be displayed to
      the user in an error report by the client.

      In its unsolicited form this response indicates some operational
      error at the server which cannot be traced to any protocol
      command.  The text is a line of human-readable text which should
      be logged in protocol telemetry for the maintainer of the server
      and/or the client.




Rice                                                           [Page 26]

RFC 1203                         IMAP3                     February 1991


   */tag BAD text

      In its solicited form response indicates faulty protocol received
      from the client and indicates a bug.  The text is a line of
      human-readable text which should be recorded in any telemetry as
      part of a bug report to the maintainer of the client.

      In its unsolicited form response indicates some protocol error at
      the server which cannot be traced to any protocol command.  The
      text is a line of human-readable text which should be logged in
      protocol telemetry for the maintainer of the server and/or the
      client.  This generally indicates a protocol synchronization
      problem, and examination of the protocol telemetry is advised to
      determine the cause of the problem.

   */tag BYE text

      This indicates that the server is about to close the connection.
      The text is a line of human-readable text which should be
      displayed to the user in a status report by the client.  IMAP2
      requires that the server emit a solicited BYE response as part of
      a normal logout sequence.  This solicited form is not required
      under IMAP3, though is still legal for compatibility.  In its
      unsolicited form the BYE response is used as a panic shutdown
      announcement by the server.  It is required to be used by any
      server which performs autologouts due to inactivity.

   */tag number message_data

      The solicited (tag number message_data) response is generated as
      the result of a number of client requests.  The server may also
      emit any the following at any time as unsolicited data (i.e., *
      number message_data).  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
              last time this mailbox was selected with the SELECT
              command or equivalent.

      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.
             The server must send a solicited EXPUNGE response
             for each message that it expunges as the result
             of an EXPUNGE command.  Note: future versions of the
             protocol may allow the use of a message sequence
             as a value returned by the EXPUNGE response to allow the



Rice                                                           [Page 27]

RFC 1203                         IMAP3                     February 1991


             more efficient compaction of client representations of
             mailboxes.

      STORE data
             Functionally equivalent to FETCH, only it is sent by the
             server when the state of a mailbox changes.  The server
             must send solicited STORE responses as the result of
             any change caused by a STORE command.

      FETCH data
              This is the principle means by which data about a
              message is sent to the client.  The data is in a
              Lisp-like S-expression property list form.  Just as the
              FETCH request from the client can fetch any generic,
              canonical or concrete key, so also the FETCH response
              can return values for any of these keys as well as for
              the pre-defined attributes mentioned below.  Note that
              the server is permitted to send any unsolicited FETCH
              or STORE messages that it should choose, be they the
              values associated with generic, canonical or concrete
              keys.  Clients are required to ignore any such
              FETCH responses that it cannot interpret.  For example,
              clients are not required to be able to understand, i.e.,
              use fruitfully, the canonical $TO key, but they are
              required to be able to ignore an unsolicited $TO message
              correctly.

         ENVELOPE     An S-expression format list which describes the
                      envelope of a message.  The envelope is computed
                      by the server by parsing the RFC 822 header into
                      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 which
                      describes an electronic mail address.  The fields
                      of an address are in the following order:
                      personal name, source-route (i.e., the
                      at-domain-list in SMTP), mailbox name, host name
                      and comments.  Implementation note:  The addition
                      of the comment field is an incompatible extension
                      from IMAP2.  The server is required not to provide



Rice                                                           [Page 28]

RFC 1203                         IMAP3                     February 1991


                      this field when running in IMAP2 mode.

                      Any field of an envelope or address which 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 which are set
                      for this message.  This may include the following
                      system flags:

                      \RECENT       Message arrived since last
                                     read of this mailbox
                      \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.
                      Note: Some implementations of IMAP2 servers
                      had the (undocumented) behavior of setting
                      the \SEEN flag as a side effect of fetching
                      the body of a message.  This resulted in
                      erroneous behavior for clients that prefetch
                      messages that the user might not get
                      around to reading.  Thus, this behavior is
                      explicitly disallowed in IMAP3.
                      Note: this is not a significant performance
                      restriction because it is always possible for
                      IMAP3 clients to use an interaction with the
                      server of the following type:
                      A001 FETCH 42 RFC822
                      A002 STORE 42 +FLAGS (\SEEN)
                      A001 42 FETCH RFC822 {637} ......
                      A001 OK Fetch completed
                      A002 42 STORE FLAGS (\SEEN \FLAGGED...)
                      A002 OK Store Completed.

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




Rice                                                           [Page 29]

RFC 1203                         IMAP3                     February 1991


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

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

   */tag FLAGS flag_list

      A solicited FLAGS response must occur as a result of a SELECT
      command.  The flag list is the list of flags (at a minimum, the
      IMAP defined flags) which are applicable for this mailbox.  Flags
      other than the system flags are a function of the server
      implementation.

   */tag SEARCH (numbers) (search_criteria)

      This response occurs as a result of a SEARCH command.  The
      number(s) refer to those messages which match the search criteria.
      In its solicited form this message allows clients to find
      interesting groups of messages, e.g., unseen messages from
      Crispin.  In its unsolicited form it allows the server to inform
      the client of interesting patterns, e.g., when new mail arrives,
      recent and from Crispin.  Compatibility note:  The search_criteria
      are sent by the server along with the matching numbers so
      unsolicited SEARCH messages may be interpreted.  This syntax is
      not upwards compatible with IMAP2 and so the new syntax is
      intended to make it simple for clients that are not able to take
      advantage of unsolicited SEARCH messages still to interpret
      solicited SEARCH messages simply by ignoring everything that
      follows the list of numbers with minimal parsing.  Such clients
      may not, however, simply discard the rest of the line because
      there might be LITERALs in the search pattern.

      Examples:
         A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN)
      and
         * SEARCH (42) (FROM Crispin RECENT)

   */tag READONLY

      This indicates that the mailbox is read-only.  The server is
      required to respond to a READONLY or READWRITE command with either
      a solicited READONLY or a solicited READWRITE response.  Note:  If
      the client attempts a mutation operation, such as STORE, on a
      mailbox to which it does not have write access then the server is
      required to reply with a solicited READONLY response on the first



Rice                                                           [Page 30]

RFC 1203                         IMAP3                     February 1991


      such attempted mutation.  The server may also choose to send
      solicited READONLY responses for each subsequent attempted
      mutation.

   */tag READWRITE

      This indicates that the mailbox is read-write.  The server is
      required to respond to a READONLY or READWRITE command with either
      a solicited READONLY or a solicited READWRITE response.

   */tag BBOARD bboard_name

      This message is produced in its solicited form as a response to a
      FIND BBOARDS command.  In its unsolicited form it represents a
      notification by the server that a new BBoard has been added.
      Bboard_name must be a name that can be supplied to the BBOARD
      command so as to select the appropriate bboard.

   */tag MAILBOX non_inbox_mailbox_name

      This message is produced in its solicited form as a response to a
      FIND MAILBOXES command.  In its unsolicited form it represents a
      notification by the server that a new mailbox has been added,
      perhaps as the result of a COPY command creating a new mailbox.
      Non_inbox_mailbox_name must be a name that can be supplied to the
      SELECT command so as to select the appropriate mailbox.  Note:
      non_inbox_mailbox_name is never the string "INBOX".

   */tag SUPPORTED.VERSIONS (version_specs)

      This message is used either as a response to the
      SUPPORTED.VERSIONS or, in its unsolicited form, to indicate the
      dynamic addition or removal of support for features or protocol
      versions.  Each version_spec is of the form (4 2
      EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN ...), i.e., a major version
      number and a minor version number for the protocol and the set of
      features supported under the server's implementation of that
      protocol version.  A server may not dynamically remove support for
      any version or feature that has been selected by any currently
      logged in client by the use of the VERSION command.

      Example:
        A00005 SUPPORTED.VERSIONS ((2 0 )
              (2 2 TAGGED.SOLICITED)
              (3 0 EIGHT.BIT.TRANSPARENT TAGGED.SOLICITED))

      Indicates that two major versions are supported and one minor
      version is supported and that tagged solicited messages are



Rice                                                           [Page 31]

RFC 1203                         IMAP3                     February 1991


      supported in versions 2.2 and 3.0 with eight bit characters being
      supported under version 3.  For each feature mentioned in the list
      of features there is also always the negation of that feature.
      For example, if the server supports the TAGGED.SOLICITED feature
      then it also supports the ~TAGGED.SOLICITED feature, which
      disables this feature.  Note:  These are only example feature
      names and are not necessarily supported by any server.  See the
      appendix on features for more information on features.

   + text

      This response indicates 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 in the case of commands which 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 definitely expects it, preserving client/server
      synchronization.

      In actual practice, this situation is rarely encountered.  In the
      current protocol, the only client commands likely to contain
      literals are the LOGIN command and the STORE RFC822.HEADER or
      STORE RFC822.TEXT commands.  Consider a situation in which a
      server 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 due to a bug
      in the client or server and not for some operational problem.

Sample IMAP3 session

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

   S:     * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol
                  III Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT
   U:     a001 SUPPORTED.VERSIONS
   S:     * SUPPORTED.VERSIONS ((2 0 ) (3 0 EIGHT.BIT.TRANSPARENT
                     AUTO.SET.SEEN TAGGED.SOLICITED))



Rice                                                           [Page 32]

RFC 1203                         IMAP3                     February 1991


   S:     A001 Supported Versions returned.
   U:     a002 SELECT.VERSION (3 0)
   S:     a002 OK Version 3.0 Selected.
   U:     a003 SELECT.FEATURES TAGGED.SOLICITED
   S:     a003 OK Features selected.
   U:     a004 login crispin secret
   S:     a004 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT,
                  job 76
   U:     a005 select inbox
   S:     a005 FLAGS (Bugs SF Party Skating Meeting Flames Request AI
                  Question Note \XXXX \YYYY \Answered \Flagged \Deleted
                  \Seen)
   S:     a005 16 EXISTS
   S:     a005 0 RECENT
   S:     a006 OK Select complete
   U:     a006 fetch 16 all
   S:     a006 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:
              RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
              "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
              "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
              "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
              "SUMEX-AIM.Stanford.EDU" NIL)) ((NIL NIL "rindflEISCH"
              "SUMEX-AIM.Stanford.EDU" NIL)) NIL NIL NIL
              "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
   S:  a006 OK Fetch completed
   U:  a007 fetch 16 rfc822
   S:  a007 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:  a007 OK Fetch completed
   U:  a008 logout
   S:  a008 BYE UNIX IMAP III server terminating connection



Rice                                                           [Page 33]

RFC 1203                         IMAP3                     February 1991


   S:  a008 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
                  Service logout

Implementation Discussion

   As of this writing, SUMEX has completed an IMAP2 client for Xerox
   Lisp machines written in hybrid Interlisp/CommonLisp and is beginning
   distribution of a client for TI Explorer Lisp machines.  SUMEX has
   also completed a portable IMAP2 client protocol library module
   written in C.  This library, with the addition of a small main
   program (primarily user interface) and a TCP/IP driver, became a
   rudimentary remote system mail-reading program under Unix.  The first
   production use of this library is as a part of a MacII client which
   has now been under daily use (by real users) at Stanford for quite
   some time.

   As of this writing, SUMEX has completed IMAP2 servers for TOPS-20
   written in DEC-20 assembly language and 4.2/3 BSD Unix written in C.
   The TOPS-20 server is fully compatible with MM-20, the standard
   TOPS-20 mailsystem, and requires no special action or setup on the
   part of the user.  The INBOX under TOPS-20 is the user's MAIL.TXT.
   The TOPS-20 server also supports multiple simultaneous access to the
   same mailbox, including simultaneous access between the IMAP3 server
   and MM-20.  The 4.2/3 BSD Unix server requires that the user use
   either Unix Mail format or mail.txt format which is compatible with
   SRI MM-32 or Columbia MM-C.  The 4.2/3 BSD Unix server allows
   simultaneous read access; write access must be exclusive.  There is
   also an experimental IMAP3 server running on the TI Explorer class of
   machine, which uses MM mailbox format and which can communicate over
   both TCP and Chaos.

   The Xerox Lisp client and DEC-20 server have been in production use
   for over two years; the Unix server was been in production use for
   over a year.  IMAP3 has been used to access mailboxes at remote sites
   from a local workstation via the Internet.  For example, from the
   Stanford local network one of the authors has read his mailbox at a
   Milnet site.

   A number of IMAP clients have now been developed or are being
   developed.  Amongst these are versions that run on the following
   machines:

    . Xerox Lisp machines
    . Apple Macintosh
    . NeXT
    . IBM PC
    . TI Explorer Lisp machines
    . "Glass teletype" version that runs under Unix



Rice                                                           [Page 34]

RFC 1203                         IMAP3                     February 1991


    . GNU Emacs
    . X Windows
    . NTT ELIS

   Each of these client programs is carefully tuned to optimize the
   performance and user interface in a manner that is consistent with
   the the user interface model of the native machine.  For example, the
   Macintosh client features a "messy-desk" interface that allows the
   cutting and pasting of text with the use of the clipboard with a menu
   driven interface with keyboard accelerators.

   This specification does not make any formal definition of size
   restrictions, but some of the existing servers have the following
   limitations:

   DEC-20
    . 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

   TI-Explorer
    . length of a mailbox: limited by the Minimum of the size of the
      virtual address space and the size of the file system
    . maximum number of messages: limited by the the size of the
      virtual address space
    . length of a command line: limited by the the size of the
      virtual address space
    . length of the local host name: limited by the the size of the
      virtual address space
    . length of a "short" argument: limited by the the size of the
      virtual address space
    . length of a "long" argument: limited by the the size of the
      virtual address space
    . maximum amount of data output in a single fetch: not limited

   Typical values for these limits are 30Mb for file systems and 128Mb
   for virtual address space.

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

   There are several advantages to the scheme of tags and solicited



Rice                                                           [Page 35]

RFC 1203                         IMAP3                     February 1991


   responses and unsolicited data.  First, the infamous synchronization
   problems of SMTP and similar protocols do not happen with tagged
   commands; a command is not considered satisfied until a completion
   acknowledgement with the same tag is seen.  Tagging allows an
   arbitrary amount of other responses ("solicited" 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 which would signal the
   client when the tagged response comes in.  Some clients might be
   implemented in a thoroughly asynchronous manner, having, perhaps,
   multiple outstanding commands at any given time.  Note:  this does
   not require that the server process these commands in anything other
   than a lock-step manner.  It simply allows clients to take advantage
   of servers that are able to do such asynchronous operations.

   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 relatively rare; a mechanism (the special
   "+" tag response) was introduced to handle those few cases which
   could happen.  The proper way to address this problem in all cases is
   probably to move towards a record-oriented architecture instead of
   the text stream model provided by TCP.

   Unsolicited data needs some discussion.  Unlike most protocols, in
   which the server merely does the client's bidding, an IMAP3 server
   has a semi-autonomous role.  By means of sending "unsolicited data",
   the server is in effect sending a command to the client -- to update
   and/or extend its (incomplete) model of the mailbox with new
   information from the server.  In this viewpoint, although a "fetch"
   command is a request for specific information from the client, the
   server is always at liberty to include more than the desired data as
   "unsolicited".  A server acknowledgement to the "fetch" is a
   statement that at least all the requested data has been sent.

   In terms of implementation, a simple lock-step client may have a
   local cache of data from the mailbox.  This cache is incomplete in
   general, and at select time is empty.  A listener on the IMAP
   connection in the client processes all solicited and unsolicited data
   symmetrically, and updates the cache based on this data, i.e., the
   client faults on a cache miss and asks the server to fill that cache
   slot synchronously.  If a tagged completion response arrives, the
   listener unblocks the process which sent the tagged request.

   Clearly, given this model it is not strictly necessary to distinguish



Rice                                                           [Page 36]

RFC 1203                         IMAP3                     February 1991


   most solicited from unsolicited data.  Doing so, however, apart from
   being clearer, also allows such simplistic, lock-step client
   implementations that extract the specific value of the response to
   command by trapping the tagged response.  This allows the client not
   to have to block on some complex predicate that involves watching to
   see an update in a cache cell.

   For example, perhaps as a result of opening a mailbox, solicited data
   from the server arrives.  The first piece of data is the number of
   messages.  This is used to size the cache; note that, if new mail
   arrives, by sending a new "number of messages" unsolicited data
   message server will cause the cache to be re-sized.  If the client
   attempts to access information from the cache, it will encounter
   empty spots which will trigger "fetch" requests.  The request would
   be sent, some solicited 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 design will
   recognize this model as being very similar to page-fault handling on
   a demand-paged system.

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_comment ")"

addr_adl        ::= nil / string

addr_comment    ::= nil / string

addr_host       ::= nil / string

addr_mailbox    ::= nil / string

addr_name       ::= nil / string

bboard          ::= "BBOARD" SP bboard_name

bboard_name     ::= string

bboard_notify   ::= "BBOARD" sp bboard_name

canonical_key   ::= "$CC" /  "$FROM" / "$SUBJECT" / "$TO"



Rice                                                           [Page 37]

RFC 1203                         IMAP3                     February 1991


check           ::= "CHECK"

concrete_key    ::= string

copy            ::= "COPY" SP sequence SP mailbox

criterion       ::= "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" / key SP string

criteria        ::= 1#criterion

data            ::= ("FLAGS" SP flag_list /
                  search_notify / bboard_notify / mailbox_notify /
                  supported_versions_notify / "READONLY" / "READWRITE" /
                    "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_length      ::= NUMBER

env_message-id  ::= nil / string

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

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




Rice                                                           [Page 38]

RFC 1203                         IMAP3                     February 1991


env_subject     ::= nil / string

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

expunge         ::= "EXPUNGE"

feature         ::= ATOM

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

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

find            ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern

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

flags           ::= "FLAGS"

generic_key     ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" /
                    "SUBJECT" / "TEXT" / "TO"

key             ::= generic_key / canonical_key / concrete_key

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

login           ::= "LOGIN" SP userid SP password

logout          ::= "LOGOUT"

mailbox         ::= "INBOX" / string

mailbox_notify ::= MAILBOX non_inbox_mailbox_name

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
                     env_length envelope / "FLAGS" SP "(" 1#(recent_flag
                     flag_list) ")" / "INTERNALDATE" SP date /



Rice                                                           [Page 39]

RFC 1203                         IMAP3                     February 1991


                     "RFC822" SP string / "RFC822.HEADER" SP string /
                     "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
                     string / key SP string_list) ")"

msg_recent      ::= "RECENT"

msg_num         ::= NUMBER

nil             ::= "NIL"

non_inbox_mailbox_name ::= string

noop            ::= "NOOP"

numbers         ::= 1#NUMBER

password        ::= string

pattern         ::= string

recent_flag     ::= "\RECENT"

read_only       ::= "READONLY"

read_write      ::= "READWRITE"

ready           ::= "+" SP text_line

request         ::= tag SP (noop / login / logout / select / check /
                    expunge / copy / fetch / store / search /
                    select_version / select_features /
                    supported_versions / bboard / find /
                    read_only / read_write / flags / set_flags ) CRLF

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

search          ::= "SEARCH" SP criteria

search_notify   ::= "SEARCH" SP (numbers) SP (criteria)

select          ::= "SELECT" SP mailbox

select_features ::= "SELECT.FEATURES" 1#feature

select_version  ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")"

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



Rice                                                           [Page 40]

RFC 1203                         IMAP3                     February 1991


set_flags       ::= "SET.FLAGS" SP flag_list

solicited       ::= tag SP (msg_num SP msg_data / data /
                            solicited_only) CRLF

solicited_only  ::=                {None currently defined}

store           ::= "STORE" SP sequence SP store_att

store_att       ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
                    "FLAGS" SP flag_list / RFC822.TEXT SP string
                    / RFC822.HEADER SP string / key SP string)

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

string_list     ::= string / ("(" 1#string ")")

supported_versions ::= "SUPPORTED.VERSIONS"

supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec
                              ")"

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

tag             ::= atom

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

userid          ::= string

version_spec    ::= "(" NUMBER SP NUMBER SP 1#feature ")"

Appendix: Features.

   In this section we outline the standard features that are supported
   by all IMAP3 servers and identify those features which are
   recommended or experimental.  For each of these features the default
   setting is specified.  This means that it is required of any server
   that supports a given feature to make the default enabledness of that
   feature as is specified below.  It is required that for each feature
   supported by a server the inverse feature should also be supported.
   The inverse feature name shall always be defined as the feature name
   preceded by the "~" character.  Thus, the AUTO.SET.SEEN feature is
   disabled by the ~AUTO.SET.SEEN feature.






Rice                                                           [Page 41]

RFC 1203                         IMAP3                     February 1991


   Required Features:

   AUTO.SET.SEEN - When this features is enabled (default is disabled),
        the \\SEEN flag is set for all appropriate messages as a side
        effect of any of the following:
            FETCH of RFC822
            FETCH of RFC822.TEXT
            COPY
        Justification:  This feature is provided for the use of clients
        that are unable to pipeline their commands effectively and
        communicate over high latency connections.  When disabled,
        the server will not perform any such side effects.  This feature
        is also provided so as to smooth the transition from IMAP2 to
        IMAP3.


   TAGGED.SOLICITED - When this feature is enabled (default is enabled
        for IMAP3, disabled for IMAP2 mode), solicited responses from
        the server will have the tag specified by the client.
        When this feature is disabled, solicited responses from the
        server will have the IMAP2 compatible tag "*", not the
        tag specified by the client.
        Justification:  This feature is provided so as to smooth the
        transition from IMAP2 to IMAP3.

   Recommended Features.

   EIGHT.BIT.TRANSPARENT - When this feature is enabled
        (default is disabled), the server allows the transparent
        transmission of eight bit characters.  When this feature is
        disabled, the value of any bit other than the least significant
        7 bits transmitted by the server is unspecified.  If this
        feature is enabled, the characters that compose all command
        keywords specified in the IMAP3 grammar and all feature names
        use only their 7 least significant bits.
        Justification:  This feature is provided for the purpose of
        supporting national character sets within messages, encoded
        languages such as Japanese Kanji characters and also of binary
        data, such as programs, graphics and sound.


   NEW.MAIL.NOTIFY - When this feature is enabled (default is
        disabled for compatibility with the majority of existing
        IMAP2 servers), the server will notify the client of the
        arrival of new mail in the currently selected mailbox
        using the appropriate RECENT and EXISTS unsolicited messages
        without the client needing to send periodic CHECK commands.
        Justification:  This feature is provided to allow clients to



Rice                                                           [Page 42]

RFC 1203                         IMAP3                     February 1991


        switch off any periodic polling strategy that they may use
        to look for new mail.  Such polling unnecessarily uses bandwidth
        and can cause the interactive performance to degrade because
        the user can be kept waiting while some background process
        is doing a CHECK.


   SEND - When this feature is enabled (default is disabled) a new
        "SEND" command becomes available to the client.  The SEND
        command instructs the server to send a message, rather
        than requiring the client to use its own, local message
        sending capability, for example.  An example of of the
        send command might be as follows:
            tag42 SEND RFC822 {2083}
            From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
            To:.....
        If the server is unable to parse the message being sent then
        it is required to issue a suitable NO notification to the client.
        If the message cannot be delivered for some reason then the
        server should send a suitable message to the FROM: address
        of the message detailing the delivery failure.
        When the SEND feature is enabled, the "send" production in
        the grammar is added and as defined below.  The "send"
        request is added to the list of requests in the request
        production also as shown below:

   message_format  ::= RFC822

   request         ::= tag SP (noop / login / logout / select / check /
                       expunge / copy / fetch / store / search /
                       select_version / select_features /
                       supported_versions / bboard / find /
                       read_only / read_write / flags /
                       set_flags / send) CRLF

   send            ::= SEND SP message_format SP string

        Justification:  This feature is provided so that mail can be
        sent by the same reliable server that is used for the storage
        of mail.  This has, amongst others, the following benefits:
        - Single process clients need not be delayed by mail
          transmission.
        - Mail sent by the client will have the server named as the
          message's sender.  This can be important because there are
          a lot of mailers that erroneously cause reply mail to be
          sent to the Sender, not the From or Reply-To address.  Since
          the client in general is not listening for mail being sent
          to it directly this can cause mail to be lost.



Rice                                                           [Page 43]

RFC 1203                         IMAP3                     February 1991


        - Clients can be written that do not have any native message
          sending capability.


   ADD.MESSAGE - When this feature is enabled (default is disabled)
        a new "ADD.MESSAGE" command becomes available to the client.
        The ADD.MESSAGE command instructs the server to add the
        specified message to the designated mailbox.  This command
        can be thought of as being like a COPY command except in
        this case the message that is put in the designated mailbox
        is specified as a string, rather than as a message number to
        be copied from the currently selected mailbox.  An example
        use of this command might be as follows:
            tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083}
            From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
            To:.....
        This will have the effect of adding the message to the mailbox
        called OUTGOING-MAIL.
        If the server is unable to parse the message being added then
        it is required to issue a suitable NO notification to the client.
        When the ADD.MESSAGE feature is enabled, the "add_message"
        production in the grammar is added and as defined below.
        The "add_message" request is added to the list of requests
        in the request production also as shown below:

   add_message            ::= ADD.MESSAGE SP mailbox SP format SP string

   message_format  ::= RFC822

   request         ::= tag SP (noop / login / logout / select / check /
                       expunge / copy / fetch / store / search /
                       select_version / select_features /
                       supported_versions / bboard / find /
                       read_only / read_write / flags / set_flags /
                       add_message) CRLF

        Justification:  This feature is provided so that clients can
        easily add mail to specific mailboxes.  This allows clients
        to implement such behavior as outgoing mail storage (BCC)
        without the need to resort to mailing to special BCC mailboxes.


   RENUMBER - When this feature is enabled (default is disabled)
        the RENUMBER command becomes available to the client.
        The RENUMBER command will reorder the assignment of message
        numbers to the messages in the mailbox.  If this results in a
        change to the association of any message number with any
        message then the server is required to send solicited RESET



Rice                                                           [Page 44]

RFC 1203                         IMAP3                     February 1991


        responses to the client.  The intent of this command is
        to allow users to view mailboxes in user-meaningful order
        efficiently.  While the client could do the ordering,
        it would be less efficient in general.  Note that the
        server may or may not change the actual storage of the
        messages and the ordering may or may not remain in effect
        after another mailbox is selected or the IMAP session is
        terminated.  Informally, the syntax for the RENUMBER
        command is:

            tag RENUMBER field_name ordering_type

        this has the effect of changing the IMAP grammar to be
        as follows:

   ordering_type   ::= DATE / NUMERIC / ALPHA

   renumber        ::= RENUMBER SP field_name SP ordering_type

   request         ::= tag SP (noop / login / logout / select / check /
                       expunge / copy / fetch / store / search /
                       select_version / select_features /
                       supported_versions / bboard / find /
                       read_only / read_write / flags / set_flags /
                       renumber) CRLF

        For example:
         tag42 RENUMBER FROM ALPHA
                         ;;;RENUMBER alphabetically by the from field
         tag42 RESET 10:20,49
                         ;;;Messages 10 to 20 and 49 have changed
         tag42 OK RENUMBER finished.  Sequence has changed
         tag43 FETCH ALL 10:20,49
                         ;;;Client chooses to fetch the changed msgs.

        To support this the RESET message is defined as follows:

   */tag RESET message_sequence
       This solicited of unsolicited message from the server informs the
       client that it should flush any information that it has
       retained for the specified messages.

        Justification:  This feature is provided so that clients can
        view mailboxes in an order that is convenient to the user.
        This is particularly important in the context of mailboxes
        that the user copies messages to from other mailboxes.  This
        user-controlled filing process often does not happen in any
        well-defined order.  Because messages in a mailbox are



Rice                                                           [Page 45]

RFC 1203                         IMAP3                     February 1991


        implicitly ordered (usually by arrival date, though this is
        not a required ordering predicate), the user can be confused
        by the apparent order of messages in the mailbox.  The
        addition of the RENUMBER command makes it unnecessary
        for the user to leave IMAP and use some other mail system to
        sort mailboxes.


   ENCODING - When this feature is enabled (default is disabled) a new
        generic key named ENCODING is defined.  The value associated
        with the generic ENCODING key is a list of (tag encoding-type
        options...) lists that represent the ordered, possibly encoded
        body of the message.  Each such list represents a segment of
        the body of the message and the way in which it is encoded.
        Any options that follow the encoding_type are further
        qualifiers that describe the format of the segment.  Each tag
        is created by the server and is unique with respect to the
        other tags allocated for the other elements in the ENCODING
        list.  The client may use the tags returned by the server as
        concrete keys to access a field which is encoded using the
        encoding type and options mentioned in the appropriate list.
        Thus:

 tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196.
 tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded.
 tag41 OK Fetch completed.
 tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197.
 tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies.
 tag42 OK Fetch completed.
 tag43 FETCH 197 G002     ; Client asks for field named G002
 tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field.
 tag43 OK Fetch completed.

     or

 tag44 STORE 197 G002 "0A 00 FF 31 24......."
    ; Store back the segment with nibbles swapped

      Note:  As a side-effect of enabling this feature, the generic key
      TEXT will be redefined so as to return only those body parts of a
      message that are of type TEXT.  The concrete key RFC822.TEXT, on
      the other hand, would still return everything in the body of the
      message, even if it was full of strange, binary character
      sequences.

      When the client STOREs to a field denoted by one of the above tags
      the server will interpret the value being passed as being in the
      same format as is currently specified in the ENCODING field.  The



Rice                                                           [Page 46]

RFC 1203                         IMAP3                     February 1991


      server is not required to be able to reformat the data associated
      with the ENCODING tags if the client STOREs a new value for the
      ENCODING field.  The interpretability of a message in the context
      of its ENCODING field is undefined if the client side-effects that
      ENCODING field, unless the client also STOREs new, reformatted
      values for the fields that have had their encoding changed.

      If the client stores a new value for the ENCODING field then the
      tags in the new value will be used to index the parts of the body.
      All tags in a client-STOREd ENCODING that are the same as those
      originally generated by the server in response to a FETCH ENCODING
      command are said still to denote the fields that they originally
      denoted, though possibly reordered.  Any tags not originally
      defined by the server will denote new message parts, in the
      appropriate format, in the relative position specified.  The
      exclusion of any tags that the server originally defined in a
      FETCH of the ENCODING field will indicate the deletion of that
      part of the message.  Newly created message parts are undefined by
      default, so if the client fails to follow the STOREing of the
      ENCODING field with suitable STORE commands for the values
      associated with any newly created tags, these fields will contain
      the null value NIL.

      Justification:  This feature is supplied so as to allow support
      for emergent multi-part and multi-media mail standards.

   INDEXABLE.FIELDS - When this feature is enabled (default is
        disabled) the grammar of fetch commands is changed to allow the
        client to select a specific subsequence from the field in
        question.  For example:

          tag42 FETCH 197 BODY 2000:3999

        would fetch the second two thousand bytes of the body of message
        197.  This feature allows resource limited clients to access
        small parts of large messages.  The formal syntax for this is:

   fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
                       fetch_key / (fetch_key SP NUMBER ":" NUMBER)

   fetch_key       ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
                       "RFC822.TEXT" / key

      If the lower bound number (the number to the left of the colon)
      exceeds the maximum size of the field then the empty string is
      returned.  If the upper bound exceeds the maximum size of the
      field but the lower bound does not then the server will return the
      remaining substring of the field after the lower bound.  The



Rice                                                           [Page 47]

RFC 1203                         IMAP3                     February 1991


      bounds specified are zero indexed into the fields and the bounds
      index fields by 8-bit bytes.

      Justification:  This feature is provided so as to allow resource-
      limited clients to read very large messages and also to allow
      clients to improve interactive response for the reading of large
      messages by fetching the first "screen full" of data to display
      immediately and fetching the rest of the message in the
      background.

   SET.EOL - When enabled (default is disabled), this feature
        allows the new command SET.EOL to be available, changing the
        grammar as follows:

   character       ::= "CR" / "LF" / number

   request         ::= tag SP (noop / login / logout / select / check /
                       expunge / copy / fetch / store / search /
                       select_version / select_features /
                       supported_versions / bboard / find /
                       read_only / read_write / flags / set_flags /
                       set_eol) CRLF

   set_eol         ::= "SET.EOL" 1#character

      This has the effect of changing the end of line character sequence
      generated by the server for newlines within strings to the
      sequence of characters specified.  The characters in the sequence
      can be either the specified symbolically named characters or a
      numerical value, specifying the decimal value of the character to
      use.  Thus, if the client would like newlines in strings to be
      indicated by a carriage return followed by a control-d, the client
      would issue the following command:

           tag42 SET.EOL CR 4

      If the server is unable to support the combination of characters
      requested by the client as its end-of-line pattern it will reply
      with a NO response.  This might be the case, for example, if a
      server is only able to generate its own native line feed pattern
      and the CRLF required by IMAP by default.

      The server is required to change any length denoting values, such
      as envelope byte counts for all future transactions to reflect the
      new eol setting.  This change in reported sizes should apply to
      all generic size fetching keys, but not to concrete ones such as
      RFC822.SIZE, which by their very nature require a size measurement
      in RFC822 format, i.e., with CRLF as the end-of-line convention.



Rice                                                           [Page 48]

RFC 1203                         IMAP3                     February 1991


      Justification: This feature is provided because frequently clients
      and servers might have end-of-line conventions other than the CRLF
      specified by RFC822.  It is undesirable that the IMAP be linked
      too closely to RFC822 and selecting a different convention might
      allow substantial performance improvements in both clients and
      servers by saving either client, server or both from having to
      shuffle text around so as to add or remove non-local end-of-line
      sequences.

Acknowledgements:

   This text is based on RFC 1064 by Mark Crispin.

   The following have made major contributions to this proposed update
   to the IMAP2 protocol:

      James Rice               <Rice@sumex-aim.stanford.edu>
      Richard Acuff            <acuff@sumex-aim.stanford.edu>
      Bill Yeager              <yeager@sumex-aim.stanford.edu>
      Christopher Lane         <lane@sumex-aim.stanford.edu>
      Bjorn Victor             <Bjorn.Victor@docs.uu.se>

   Additional input was also received from:

      Andrew Sweer             <sweer@sumex-aim.stanford.edu>
      Tom Gruber               <Gruber@sumex-aim.stanford.edu>
      Kevin Brock              <Brock@Sumex-Aim.Stanford.Edu>
      Mark Crispin             <MRC@cac.washington.edu>

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   James Rice
   Stanford University
   Knowledge Systems Laboratory
   701 Welch Road
   Building C
   Palo Alto, CA 94304

   Phone: (415) 723-8405
   EMail: RICE@SUMEX-AIM.STANFORD.EDU







Rice                                                           [Page 49]