summaryrefslogtreecommitdiff
path: root/imap/docs/rfc/rfc2062.txt
blob: 865d1dad959cd86c60305525cfd01304e16f002b (plain)
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






Network Working Group                                         M. Crispin
Request for Comments: 2062                      University of Washington
Category: Informational                                    December 1996


           Internet Message Access Protocol - Obsolete Syntax

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document describes obsolete syntax which may be encountered by
   IMAP4 implementations which deal with older versions of the Internet
   Mail Access Protocol.  IMAP4 implementations MAY implement this
   syntax in order to maximize interoperability with older
   implementations.

   This document repeats information from earlier documents, most
   notably RFC 1176 and RFC 1730.

Obsolete Commands and Fetch Data Items

   The following commands are OBSOLETE.  It is NOT required to support
   any of these commands or fetch data items in new server
   implementations.  These commands are documented here for the benefit
   of implementors who may wish to support them for compatibility with
   old client implementations.

   The section headings of these commands are intended to correspond
   with where they would be located in the main document if they were
   not obsoleted.

6.3.OBS.1.      FIND ALL.MAILBOXES Command

   Arguments:  mailbox name with possible wildcards

   Data:       untagged responses: MAILBOX

   Result:     OK - find completed
               NO - find failure: can't list that name
               BAD - command unknown or arguments invalid






Crispin                      Informational                      [Page 1]

RFC 2062                     IMAP4 Obsolete                December 1996


      The FIND ALL.MAILBOXES command returns a subset of names from the
      complete set of all names available to the user.  It returns zero
      or more untagged MAILBOX replies.  The mailbox argument to FIND
      ALL.MAILBOXES is similar to that for LIST with an empty reference,
      except that the characters "%" and "?" match a single character.

   Example:    C: A002 FIND ALL.MAILBOXES *
               S: * MAILBOX blurdybloop
               S: * MAILBOX INBOX
               S: A002 OK FIND ALL.MAILBOXES completed

6.3.OBS.2.      FIND MAILBOXES Command

   Arguments:  mailbox name with possible wildcards

   Data:       untagged responses: MAILBOX

   Result:     OK - find completed
               NO - find failure: can't list that name
               BAD - command unknown or arguments invalid

      The FIND MAILBOXES command returns a subset of names from the set
      of names that the user has declared as being "active" or
      "subscribed".  It returns zero or more untagged MAILBOX replies.
      The mailbox argument to FIND MAILBOXES is similar to that for LSUB
      with an empty reference, except that the characters "%" and "?"
      match a single character.

   Example:    C: A002 FIND MAILBOXES *
               S: * MAILBOX blurdybloop
               S: * MAILBOX INBOX
               S: A002 OK FIND MAILBOXES completed

6.3.OBS.3.      SUBSCRIBE MAILBOX Command

   Arguments:  mailbox name

   Data:       no specific data for this command

   Result:     OK - subscribe completed
               NO - subscribe failure: can't subscribe to that name
               BAD - command unknown or arguments invalid

      The SUBSCRIBE MAILBOX command is identical in effect to the
      SUBSCRIBE command.  A server which implements this command must be
      able to distinguish between a SUBSCRIBE MAILBOX command and a
      SUBSCRIBE command with a mailbox name argument of "MAILBOX".




Crispin                      Informational                      [Page 2]

RFC 2062                     IMAP4 Obsolete                December 1996


   Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
               S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
               completed
               C: A003 SUBSCRIBE MAILBOX
               S: A003 OK SUBSCRIBE to MAILBOX completed


6.3.OBS.4.      UNSUBSCRIBE MAILBOX Command

   Arguments:  mailbox name

   Data:       no specific data for this command

   Result:     OK - unsubscribe completed
               NO - unsubscribe failure: can't unsubscribe that name
               BAD - command unknown or arguments invalid

      The UNSUBSCRIBE MAILBOX command is identical in effect to the
      UNSUBSCRIBE command.  A server which implements this command must
      be able to distinguish between a UNSUBSCRIBE MAILBOX command and
      an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".

   Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
               S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
               completed
               C: A003 UNSUBSCRIBE MAILBOX
               S: A003 OK UNSUBSCRIBE from MAILBOX completed

6.4.OBS.1       PARTIAL Command

   Arguments:  message sequence number
               message data item name
               position of first octet
               number of octets

   Data:       untagged responses: FETCH

   Result:     OK - partial completed
               NO - partial error: can't fetch that data
               BAD - command unknown or arguments invalid

      The PARTIAL command is equivalent to the associated FETCH command,
      with the added functionality that only the specified number of
      octets, beginning at the specified starting octet, are returned.
      Only a single message can be fetched at a time.  The first octet
      of a message, and hence the minimum for the starting octet, is
      octet 1.




Crispin                      Informational                      [Page 3]

RFC 2062                     IMAP4 Obsolete                December 1996


      The following FETCH items are valid data for PARTIAL: RFC822,
      RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK
      forms of these.

      Any partial fetch that attempts to read beyond the end of the text
      is truncated as appropriate.  If the starting octet is beyond the
      end of the text, an empty string is returned.

      The data are returned with the FETCH response.  There is no
      indication of the range of the partial data in this response.  It
      is not possible to stream multiple PARTIAL commands of the same
      data item without processing and synchronizing at each step, since
      streamed commands may be executed out of order.

      There is no requirement that partial fetches follow any sequence.
      For example, if a partial fetch of octets 1 through 10000 breaks
      in an awkward place for BASE64 decoding, it is permitted to
      continue with a partial fetch of 9987 through 19987, etc.

      The handling of the \Seen flag is the same as in the associated
      FETCH command.

   Example:    C: A005 PARTIAL 4 RFC822 1 1024
               S: * 1 FETCH (RFC822 {1024}
               S: Return-Path: <gray@cac.washington.edu>
               S: ...
               S: .........  FLAGS (\Seen))
               S: A005 OK PARTIAL completed

6.4.5.OBS.1     Obsolete FETCH Data Items

   The following FETCH data items are obsolete:

      BODY[<...>0]   A body part number of 0 is the [RFC-822] header of
                     the message.  BODY[0] is functionally equivalent to
                     BODY[HEADER], differing in the syntax of the
                     resulting untagged FETCH data (BODY[0] is
                     returned).

      RFC822.HEADER.LINES <header_list>
                     Functionally equivalent to BODY.PEEK[HEADER.LINES
                     <header_list>], differing in the syntax of the
                     resulting untagged FETCH data (RFC822.HEADER is
                     returned).







Crispin                      Informational                      [Page 4]

RFC 2062                     IMAP4 Obsolete                December 1996


      RFC822.HEADER.LINES.NOT <header_list>
                     Functionally equivalent to
                     BODY.PEEK[HEADER.LINES.NOT <header_list>],
                     differing in the syntax of the resulting untagged
                     FETCH data (RFC822.HEADER is returned).

      RFC822.PEEK    Functionally equivalent to BODY.PEEK[], except for
                     the syntax of the resulting untagged FETCH data
                     (RFC822 is returned).

      RFC822.TEXT.PEEK
                     Functionally equivalent to BODY.PEEK[TEXT], except
                     for the syntax of the resulting untagged FETCH data
                     (RFC822.TEXT is returned).

Obsolete Responses

   The following responses are OBSOLETE.  Except as noted below, these
   responses MUST NOT be transmitted by new server implementations.
   Client implementations SHOULD accept these responses.

   The section headings of these responses are intended to correspond
   with where they would be located in the main document if they were
   not obsoleted.

7.2.OBS.1.      MAILBOX Response

   Data:       name

      The MAILBOX response MUST NOT be transmitted by server
      implementations except in response to the obsolete FIND MAILBOXES
      and FIND ALL.MAILBOXES commands.  Client implementations that do
      not use these commands MAY ignore this response.  It is documented
      here for the benefit of implementors who may wish to support it
      for compatibility with old client implementations.

      This response occurs as a result of the FIND MAILBOXES and FIND
      ALL.MAILBOXES commands.  It returns a single name that matches the
      FIND specification.  There are no attributes or hierarchy
      delimiter.

   Example:    S: * MAILBOX blurdybloop









Crispin                      Informational                      [Page 5]

RFC 2062                     IMAP4 Obsolete                December 1996


7.3.OBS.1.      COPY Response

   Data:       none

      The COPY response MUST NOT be transmitted by new server
      implementations.  Client implementations MUST ignore the COPY
      response.  It is documented here for the benefit of client
      implementors who may encounter this response from old server
      implementations.

      In some experimental versions of this protocol, this response was
      returned in response to a COPY command to indicate on a
      per-message basis that the message was copied successfully.

   Example:    S: * 44 COPY

7.3.OBS.2.      STORE Response

   Data:       message data

      The STORE response MUST NOT be transmitted by new server
      implementations.  Client implementations MUST treat the STORE
      response as equivalent to the FETCH response.  It is documented
      here for the benefit of client implementors who may encounter this
      response from old server implementations.

      In some experimental versions of this protocol, this response was
      returned instead of FETCH in response to a STORE command to report
      the new value of the flags.

   Example:    S: * 69 STORE (FLAGS (\Deleted))

Formal Syntax of Obsolete Commands and Responses

   Each obsolete syntax rule that is suffixed with "_old" is added to
   the corresponding name in the formal syntax.  For example,
   command_auth_old adds the FIND command to command_auth.

   command_auth_old ::= find

   command_select_old
                   ::= partial

   date_year_old   ::= 2digit
                       ;; (year - 1900)

   date_time_old   ::= <"> date_day_fixed "-" date_month "-" date_year
                       SPACE time "-" zone_name <">



Crispin                      Informational                      [Page 6]

RFC 2062                     IMAP4 Obsolete                December 1996


   find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
                       list_mailbox

   fetch_att_old   ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
                       fetch_text_old

   fetch_text_old  ::= "BODY" [".PEEK"] section_old /
                       "RFC822" [".HEADER" / ".TEXT" [".PEEK"]]

   msg_data_old    ::= "COPY" / ("STORE" SPACE msg_att)

   partial         ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE
                       number SPACE number

   section_old     ::= "[" (number ["." number]) "]"

   subscribe_old   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox

   unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox

   zone_name       ::= "UT" / "GMT" / "Z" /                ;; +0000
                       "AST" / "EDT" /                     ;; -0400
                       "EST" / "CDT" /                     ;; -0500
                       "CST" / "MDT" /                     ;; -0600
                       "MST" / "PDT" /                     ;; -0700
                       "PST" / "YDT" /                     ;; -0800
                       "YST" / "HDT" /                     ;; -0900
                       "HST" / "BDT" /                     ;; -1000
                       "BST" /                             ;; -1100
                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12

Security Considerations

   Security issues are not discussed in this memo.














Crispin                      Informational                      [Page 7]

RFC 2062                     IMAP4 Obsolete                December 1996


Author's Address

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Aveneue NE
   Seattle, WA  98105-4527

   Phone: (206) 543-5762
   EMail: MRC@CAC.Washington.EDU









































Crispin                      Informational                      [Page 8]