| rev |
line source |
|
yuuji@0
|
1
|
|
yuuji@0
|
2
|
|
yuuji@0
|
3
|
|
yuuji@0
|
4
|
|
yuuji@0
|
5
|
|
yuuji@0
|
6
|
|
yuuji@0
|
7 Network Working Group M. Crispin
|
|
yuuji@0
|
8 Request for Comments: 1732 University of Washington
|
|
yuuji@0
|
9 Category: Informational December 1994
|
|
yuuji@0
|
10
|
|
yuuji@0
|
11
|
|
yuuji@0
|
12 IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
|
|
yuuji@0
|
13
|
|
yuuji@0
|
14
|
|
yuuji@0
|
15 Status of this Memo
|
|
yuuji@0
|
16
|
|
yuuji@0
|
17 This memo provides information for the Internet community. This memo
|
|
yuuji@0
|
18 does not specify an Internet standard of any kind. Distribution of
|
|
yuuji@0
|
19 this memo is unlimited.
|
|
yuuji@0
|
20
|
|
yuuji@0
|
21 Introduction
|
|
yuuji@0
|
22
|
|
yuuji@0
|
23 This is a summary of hints and recommendations to enable an IMAP4
|
|
yuuji@0
|
24 implementation to interoperate with implementations that conform to
|
|
yuuji@0
|
25 earlier specifications. None of these hints and recommendations are
|
|
yuuji@0
|
26 required by the IMAP4 specification; implementors must decide for
|
|
yuuji@0
|
27 themselves whether they want their implementation to fail if it
|
|
yuuji@0
|
28 encounters old software.
|
|
yuuji@0
|
29
|
|
yuuji@0
|
30 IMAP4 has been designed to be upwards compatible with earlier
|
|
yuuji@0
|
31 specifications. For the most part, IMAP4 facilities that were not in
|
|
yuuji@0
|
32 earlier specifications should be invisible to clients unless the
|
|
yuuji@0
|
33 client asks for the facility.
|
|
yuuji@0
|
34
|
|
yuuji@0
|
35 In some cases, older servers may support some of the capabilities
|
|
yuuji@0
|
36 listed as being "new in IMAP4" as experimental extensions to the
|
|
yuuji@0
|
37 IMAP2 protocol described in RFC 1176.
|
|
yuuji@0
|
38
|
|
yuuji@0
|
39 This information may not be complete; it reflects current knowledge
|
|
yuuji@0
|
40 of server and client implementations as well as "folklore" acquired
|
|
yuuji@0
|
41 in the evolution of the protocol.
|
|
yuuji@0
|
42
|
|
yuuji@0
|
43
|
|
yuuji@0
|
44
|
|
yuuji@0
|
45
|
|
yuuji@0
|
46
|
|
yuuji@0
|
47
|
|
yuuji@0
|
48
|
|
yuuji@0
|
49
|
|
yuuji@0
|
50
|
|
yuuji@0
|
51
|
|
yuuji@0
|
52
|
|
yuuji@0
|
53
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Crispin [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 1732 IMAP4 - Compatibility December 1994
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 IMAP4 client interoperability with old servers
|
|
yuuji@0
|
64
|
|
yuuji@0
|
65 In general, a client should be able to discover whether an IMAP2
|
|
yuuji@0
|
66 server supports a facility by trial-and-error; if an attempt to use a
|
|
yuuji@0
|
67 facility generates a BAD response, the client can assume that the
|
|
yuuji@0
|
68 server does not support the facility.
|
|
yuuji@0
|
69
|
|
yuuji@0
|
70 A quick way to check whether a server implementation supports the
|
|
yuuji@0
|
71 IMAP4 specification is to try the CAPABILITY command. An OK response
|
|
yuuji@0
|
72 that includes the IMAP4 capability value indicates a server that
|
|
yuuji@0
|
73 supports IMAP4; a BAD response or one without the IMAP4 capability
|
|
yuuji@0
|
74 value indicates an older server.
|
|
yuuji@0
|
75
|
|
yuuji@0
|
76 The following is a list of facilities that are only in IMAP4, and
|
|
yuuji@0
|
77 suggestions for how new clients might interoperate with old servers:
|
|
yuuji@0
|
78
|
|
yuuji@0
|
79 CAPABILITY command
|
|
yuuji@0
|
80 A BAD response to this command indicates that the server
|
|
yuuji@0
|
81 implements IMAP2 (or IMAP2bis) and not IMAP4.
|
|
yuuji@0
|
82
|
|
yuuji@0
|
83 AUTHENTICATE command.
|
|
yuuji@0
|
84 Use the LOGIN command.
|
|
yuuji@0
|
85
|
|
yuuji@0
|
86 LSUB and LIST commands
|
|
yuuji@0
|
87 Try the RFC 1176 FIND command.
|
|
yuuji@0
|
88
|
|
yuuji@0
|
89 * in a sequence
|
|
yuuji@0
|
90 Use the number of messages in the mailbox from the EXISTS
|
|
yuuji@0
|
91 unsolicited response.
|
|
yuuji@0
|
92
|
|
yuuji@0
|
93 SEARCH extensions (character set, additional criteria)
|
|
yuuji@0
|
94 Reformulate the search request using only the searching
|
|
yuuji@0
|
95 options listed in search_old in the IMAP4 grammar. This may
|
|
yuuji@0
|
96 entail doing multiple searches to achieve the desired
|
|
yuuji@0
|
97 results.
|
|
yuuji@0
|
98
|
|
yuuji@0
|
99 BODYSTRUCTURE fetch data item
|
|
yuuji@0
|
100 Try to fetch the non-extensible BODY data item.
|
|
yuuji@0
|
101
|
|
yuuji@0
|
102 body section number 0
|
|
yuuji@0
|
103 Fetch the entire message and extract the header.
|
|
yuuji@0
|
104
|
|
yuuji@0
|
105 RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
|
|
yuuji@0
|
106 Use RFC822.HEADER and remove the unwanted information.
|
|
yuuji@0
|
107
|
|
yuuji@0
|
108 BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
|
|
yuuji@0
|
109 items Use the corresponding non-PEEK versions and manually
|
|
yuuji@0
|
110 clear the \Seen flag as necessary.
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Crispin [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 1732 IMAP4 - Compatibility December 1994
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 UID fetch data item and the UID commands
|
|
yuuji@0
|
120 No equivalent capabilitity exists in older servers.
|
|
yuuji@0
|
121
|
|
yuuji@0
|
122 FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
|
|
yuuji@0
|
123 Use the corresponding non-SILENT versions and ignore the
|
|
yuuji@0
|
124 untagged FETCH responses which com eback.
|
|
yuuji@0
|
125
|
|
yuuji@0
|
126
|
|
yuuji@0
|
127 The following IMAP4 facilities were introduced in the experimental
|
|
yuuji@0
|
128 IMAP2bis revisions to RFC-1176, and may be present in a server that
|
|
yuuji@0
|
129 does not support the CAPABILITY command:
|
|
yuuji@0
|
130
|
|
yuuji@0
|
131 CREATE, DELETE, and RENAME commands
|
|
yuuji@0
|
132 To test whether these commands are present, try a CREATE
|
|
yuuji@0
|
133 INBOX command. If the response is NO, these commands are
|
|
yuuji@0
|
134 supported by the server. If the response is BAD, they are
|
|
yuuji@0
|
135 not. Older servers without the CREATE capability may sup-
|
|
yuuji@0
|
136 port implicit creation of a mailbox by a COPY command with a
|
|
yuuji@0
|
137 non-existant name as the destination.
|
|
yuuji@0
|
138
|
|
yuuji@0
|
139 APPEND command
|
|
yuuji@0
|
140 To test whether this command is present, try to append a
|
|
yuuji@0
|
141 zero-length stream to a mailbox name that is known not to
|
|
yuuji@0
|
142 exist (or at least, highly unlikely to exist) on the remote
|
|
yuuji@0
|
143 system.
|
|
yuuji@0
|
144
|
|
yuuji@0
|
145 SUBSCRIBE and UNSUBSCRIBE commands
|
|
yuuji@0
|
146 Try the form of these commands with the optional MAILBOX
|
|
yuuji@0
|
147 keyword.
|
|
yuuji@0
|
148
|
|
yuuji@0
|
149 EXAMINE command
|
|
yuuji@0
|
150 Use the SELECT command instead.
|
|
yuuji@0
|
151
|
|
yuuji@0
|
152 flags and internal date argument to APPEND command
|
|
yuuji@0
|
153 Try the APPEND without any flag list and internal date argu-
|
|
yuuji@0
|
154 ments.
|
|
yuuji@0
|
155
|
|
yuuji@0
|
156 BODY, BODY[section], and FULL fetch data items
|
|
yuuji@0
|
157 Use RFC822.TEXT and ALL instead. Server does not support
|
|
yuuji@0
|
158 MIME.
|
|
yuuji@0
|
159
|
|
yuuji@0
|
160 PARTIAL command
|
|
yuuji@0
|
161 Use the appropriate FETCH command and ignore the unwanted
|
|
yuuji@0
|
162 data.
|
|
yuuji@0
|
163
|
|
yuuji@0
|
164
|
|
yuuji@0
|
165 IMAP4 client implementations must accept all responses and data for-
|
|
yuuji@0
|
166 mats documented in the IMAP4 specification, including those labeled
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Crispin [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 1732 IMAP4 - Compatibility December 1994
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 as obsolete. This includes the COPY and STORE unsolicited responses
|
|
yuuji@0
|
176 and the old format of dates and times. In particular, client imple-
|
|
yuuji@0
|
177 mentations must not treat a date/time as a fixed format string; nor
|
|
yuuji@0
|
178 may they assume that the time begins at a particular octet.
|
|
yuuji@0
|
179
|
|
yuuji@0
|
180 IMAP4 client implementations must not depend upon the presence of any
|
|
yuuji@0
|
181 server extensions that are not in the base IMAP4 specification.
|
|
yuuji@0
|
182
|
|
yuuji@0
|
183 The experimental IMAP2bis version specified that the TRYCREATE spe-
|
|
yuuji@0
|
184 cial information token is sent as a separate unsolicited OK response
|
|
yuuji@0
|
185 instead of inside the NO response.
|
|
yuuji@0
|
186
|
|
yuuji@0
|
187 The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
|
|
yuuji@0
|
188 are removed from IMAP4. There is no equivalent to the bboard com-
|
|
yuuji@0
|
189 mands, which provided a separate namespace with implicit restrictions
|
|
yuuji@0
|
190 on what may be done in that namespace.
|
|
yuuji@0
|
191
|
|
yuuji@0
|
192 Older server implementations may automatically create the destination
|
|
yuuji@0
|
193 mailbox on COPY if that mailbox does not already exist. This was how
|
|
yuuji@0
|
194 a new mailbox was created in older specifications. If the server
|
|
yuuji@0
|
195 does not support the CREATE command (see above for how to test for
|
|
yuuji@0
|
196 this), it will probably create a mailbox on COPY.
|
|
yuuji@0
|
197
|
|
yuuji@0
|
198 Older server implementations may not preserve flags or internal dates
|
|
yuuji@0
|
199 on COPY. Some server implementations may not permit the preservation
|
|
yuuji@0
|
200 of certain flags on COPY or their setting with APPEND as site policy.
|
|
yuuji@0
|
201
|
|
yuuji@0
|
202
|
|
yuuji@0
|
203
|
|
yuuji@0
|
204
|
|
yuuji@0
|
205
|
|
yuuji@0
|
206
|
|
yuuji@0
|
207
|
|
yuuji@0
|
208
|
|
yuuji@0
|
209
|
|
yuuji@0
|
210
|
|
yuuji@0
|
211
|
|
yuuji@0
|
212
|
|
yuuji@0
|
213
|
|
yuuji@0
|
214
|
|
yuuji@0
|
215
|
|
yuuji@0
|
216
|
|
yuuji@0
|
217
|
|
yuuji@0
|
218
|
|
yuuji@0
|
219
|
|
yuuji@0
|
220
|
|
yuuji@0
|
221
|
|
yuuji@0
|
222
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Crispin [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 1732 IMAP4 - Compatibility December 1994
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 IMAP4 server interoperability with old clients
|
|
yuuji@0
|
232
|
|
yuuji@0
|
233 In general, there should be no interoperation problem between a
|
|
yuuji@0
|
234 server conforming to the IMAP4 specification and a well-written
|
|
yuuji@0
|
235 client that conforms to an earlier specification. Known problems are
|
|
yuuji@0
|
236 noted below:
|
|
yuuji@0
|
237
|
|
yuuji@0
|
238 Poor wording in the description of the CHECK command in earlier
|
|
yuuji@0
|
239 specifications implied that a CHECK command is the way to get the
|
|
yuuji@0
|
240 current number of messages in the mailbox. This is incorrect. A
|
|
yuuji@0
|
241 CHECK command does not necessarily result in an EXISTS response.
|
|
yuuji@0
|
242 Clients must remember the most recent EXISTS value sent from the
|
|
yuuji@0
|
243 server, and should not generate unnecessary CHECK commands.
|
|
yuuji@0
|
244
|
|
yuuji@0
|
245 An incompatibility exists with COPY in IMAP4. COPY in IMAP4
|
|
yuuji@0
|
246 servers does not automatically create the destination mailbox if
|
|
yuuji@0
|
247 that mailbox does not already exist. This may cause problems with
|
|
yuuji@0
|
248 old clients that expect automatic mailbox creation in COPY.
|
|
yuuji@0
|
249
|
|
yuuji@0
|
250 The PREAUTH unsolicited response is new in IMAP4. It is highly
|
|
yuuji@0
|
251 unlikely that an old client would ever see this response.
|
|
yuuji@0
|
252
|
|
yuuji@0
|
253 The format of dates and times has changed due to the impending end
|
|
yuuji@0
|
254 of the century. Clients that fail to accept a four-digit year or
|
|
yuuji@0
|
255 a signed four-digit timezone value will not work properly with
|
|
yuuji@0
|
256 IMAP4.
|
|
yuuji@0
|
257
|
|
yuuji@0
|
258 An incompatibility exists with the use of "\" in quoted strings.
|
|
yuuji@0
|
259 This is best avoided by using literals instead of quoted strings
|
|
yuuji@0
|
260 if "\" or <"> is embedded in the string.
|
|
yuuji@0
|
261
|
|
yuuji@0
|
262 Security Considerations
|
|
yuuji@0
|
263
|
|
yuuji@0
|
264 Security issues are not discussed in this memo.
|
|
yuuji@0
|
265
|
|
yuuji@0
|
266 Author's Address:
|
|
yuuji@0
|
267
|
|
yuuji@0
|
268 Mark R. Crispin
|
|
yuuji@0
|
269 Networks and Distributed Computing, JE-30
|
|
yuuji@0
|
270 University of Washington
|
|
yuuji@0
|
271 Seattle, WA 98195
|
|
yuuji@0
|
272
|
|
yuuji@0
|
273 Phone: (206) 543-5762
|
|
yuuji@0
|
274
|
|
yuuji@0
|
275 EMail: MRC@CAC.Washington.EDU
|
|
yuuji@0
|
276
|
|
yuuji@0
|
277
|
|
yuuji@0
|
278
|
|
yuuji@0
|
279
|
|
yuuji@0
|
280
|
|
yuuji@0
|
281
|
|
yuuji@0
|
282 Crispin [Page 5]
|
|
yuuji@0
|
283
|
