| 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 B. Leiba
|
|
yuuji@0
|
8 Request for Comments: 2683 IBM T.J. Watson Research Center
|
|
yuuji@0
|
9 Category: Informational September 1999
|
|
yuuji@0
|
10
|
|
yuuji@0
|
11
|
|
yuuji@0
|
12 IMAP4 Implementation Recommendations
|
|
yuuji@0
|
13
|
|
yuuji@0
|
14 Status of this Memo
|
|
yuuji@0
|
15
|
|
yuuji@0
|
16 This memo provides information for the Internet community. It does
|
|
yuuji@0
|
17 not specify an Internet standard of any kind. Distribution of this
|
|
yuuji@0
|
18 memo is unlimited.
|
|
yuuji@0
|
19
|
|
yuuji@0
|
20 Copyright Notice
|
|
yuuji@0
|
21
|
|
yuuji@0
|
22 Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|
yuuji@0
|
23
|
|
yuuji@0
|
24 1. Abstract
|
|
yuuji@0
|
25
|
|
yuuji@0
|
26 The IMAP4 specification [RFC-2060] describes a rich protocol for use
|
|
yuuji@0
|
27 in building clients and servers for storage, retrieval, and
|
|
yuuji@0
|
28 manipulation of electronic mail. Because the protocol is so rich and
|
|
yuuji@0
|
29 has so many implementation choices, there are often trade-offs that
|
|
yuuji@0
|
30 must be made and issues that must be considered when designing such
|
|
yuuji@0
|
31 clients and servers. This document attempts to outline these issues
|
|
yuuji@0
|
32 and to make recommendations in order to make the end products as
|
|
yuuji@0
|
33 interoperable as possible.
|
|
yuuji@0
|
34
|
|
yuuji@0
|
35 2. Conventions used in this document
|
|
yuuji@0
|
36
|
|
yuuji@0
|
37 In examples, "C:" indicates lines sent by a client that is connected
|
|
yuuji@0
|
38 to a server. "S:" indicates lines sent by the server to the client.
|
|
yuuji@0
|
39
|
|
yuuji@0
|
40 The words "must", "must not", "should", "should not", and "may" are
|
|
yuuji@0
|
41 used with specific meaning in this document; since their meaning is
|
|
yuuji@0
|
42 somewhat different from that specified in RFC 2119, we do not put
|
|
yuuji@0
|
43 them in all caps here. Their meaning is as follows:
|
|
yuuji@0
|
44
|
|
yuuji@0
|
45 must -- This word means that the action described is necessary
|
|
yuuji@0
|
46 to ensure interoperability. The recommendation should
|
|
yuuji@0
|
47 not be ignored.
|
|
yuuji@0
|
48 must not -- This phrase means that the action described will be
|
|
yuuji@0
|
49 almost certain to hurt interoperability. The
|
|
yuuji@0
|
50 recommendation should not be ignored.
|
|
yuuji@0
|
51
|
|
yuuji@0
|
52
|
|
yuuji@0
|
53
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Leiba Informational [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 should -- This word means that the action described is strongly
|
|
yuuji@0
|
64 recommended and will enhance interoperability or
|
|
yuuji@0
|
65 usability. The recommendation should not be ignored
|
|
yuuji@0
|
66 without careful consideration.
|
|
yuuji@0
|
67 should not -- This phrase means that the action described is strongly
|
|
yuuji@0
|
68 recommended against, and might hurt interoperability or
|
|
yuuji@0
|
69 usability. The recommendation should not be ignored
|
|
yuuji@0
|
70 without careful consideration.
|
|
yuuji@0
|
71 may -- This word means that the action described is an
|
|
yuuji@0
|
72 acceptable implementation choice. No specific
|
|
yuuji@0
|
73 recommendation is implied; this word is used to point
|
|
yuuji@0
|
74 out a choice that might not be obvious, or to let
|
|
yuuji@0
|
75 implementors know what choices have been made by
|
|
yuuji@0
|
76 existing implementations.
|
|
yuuji@0
|
77
|
|
yuuji@0
|
78 3. Interoperability Issues and Recommendations
|
|
yuuji@0
|
79
|
|
yuuji@0
|
80 3.1. Accessibility
|
|
yuuji@0
|
81
|
|
yuuji@0
|
82 This section describes the issues related to access to servers and
|
|
yuuji@0
|
83 server resources. Concerns here include data sharing and maintenance
|
|
yuuji@0
|
84 of client/server connections.
|
|
yuuji@0
|
85
|
|
yuuji@0
|
86 3.1.1. Multiple Accesses of the Same Mailbox
|
|
yuuji@0
|
87
|
|
yuuji@0
|
88 One strong point of IMAP4 is that, unlike POP3, it allows for
|
|
yuuji@0
|
89 multiple simultaneous access to a single mailbox. A user can, thus,
|
|
yuuji@0
|
90 read mail from a client at home while the client in the office is
|
|
yuuji@0
|
91 still connected; or the help desk staff can all work out of the same
|
|
yuuji@0
|
92 inbox, all seeing the same pool of questions. An important point
|
|
yuuji@0
|
93 about this capability, though is that NO SERVER IS GUARANTEED TO
|
|
yuuji@0
|
94 SUPPORT THIS. If you are selecting an IMAP server and this facility
|
|
yuuji@0
|
95 is important to you, be sure that the server you choose to install,
|
|
yuuji@0
|
96 in the configuration you choose to use, supports it.
|
|
yuuji@0
|
97
|
|
yuuji@0
|
98 If you are designing a client, you must not assume that you can
|
|
yuuji@0
|
99 access the same mailbox more than once at a time. That means
|
|
yuuji@0
|
100
|
|
yuuji@0
|
101 1. you must handle gracefully the failure of a SELECT command if the
|
|
yuuji@0
|
102 server refuses the second SELECT,
|
|
yuuji@0
|
103 2. you must handle reasonably the severing of your connection (see
|
|
yuuji@0
|
104 "Severed Connections", below) if the server chooses to allow the
|
|
yuuji@0
|
105 second SELECT by forcing the first off,
|
|
yuuji@0
|
106 3. you must avoid making multiple connections to the same mailbox in
|
|
yuuji@0
|
107 your own client (for load balancing or other such reasons), and
|
|
yuuji@0
|
108 4. you must avoid using the STATUS command on a mailbox that you have
|
|
yuuji@0
|
109 selected (with some server implementations the STATUS command has
|
|
yuuji@0
|
110 the same problems with multiple access as do the SELECT and
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Leiba Informational [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 EXAMINE commands).
|
|
yuuji@0
|
120
|
|
yuuji@0
|
121 A further note about STATUS: The STATUS command is sometimes used to
|
|
yuuji@0
|
122 check a non-selected mailbox for new mail. This mechanism must not
|
|
yuuji@0
|
123 be used to check for new mail in the selected mailbox; section 5.2 of
|
|
yuuji@0
|
124 [RFC-2060] specifically forbids this in its last paragraph. Further,
|
|
yuuji@0
|
125 since STATUS takes a mailbox name it is an independent operation, not
|
|
yuuji@0
|
126 operating on the selected mailbox. Because of this, the information
|
|
yuuji@0
|
127 it returns is not necessarily in synchronization with the selected
|
|
yuuji@0
|
128 mailbox state.
|
|
yuuji@0
|
129
|
|
yuuji@0
|
130 3.1.2. Severed Connections
|
|
yuuji@0
|
131
|
|
yuuji@0
|
132 The client/server connection may be severed for one of three reasons:
|
|
yuuji@0
|
133 the client severs the connection, the server severs the connection,
|
|
yuuji@0
|
134 or the connection is severed by outside forces beyond the control of
|
|
yuuji@0
|
135 the client and the server (a telephone line drops, for example).
|
|
yuuji@0
|
136 Clients and servers must both deal with these situations.
|
|
yuuji@0
|
137
|
|
yuuji@0
|
138 When the client wants to sever a connection, it's usually because it
|
|
yuuji@0
|
139 has finished the work it needed to do on that connection. The client
|
|
yuuji@0
|
140 should send a LOGOUT command, wait for the tagged response, and then
|
|
yuuji@0
|
141 close the socket. But note that, while this is what's intended in
|
|
yuuji@0
|
142 the protocol design, there isn't universal agreement here. Some
|
|
yuuji@0
|
143 contend that sending the LOGOUT and waiting for the two responses
|
|
yuuji@0
|
144 (untagged BYE and tagged OK) is wasteful and unnecessary, and that
|
|
yuuji@0
|
145 the client can simply close the socket. The server should interpret
|
|
yuuji@0
|
146 the closed socket as a log out by the client. The counterargument is
|
|
yuuji@0
|
147 that it's useful from the standpoint of cleanup, problem
|
|
yuuji@0
|
148 determination, and the like, to have an explicit client log out,
|
|
yuuji@0
|
149 because otherwise there is no way for the server to tell the
|
|
yuuji@0
|
150 difference between "closed socket because of log out" and "closed
|
|
yuuji@0
|
151 socket because communication was disrupted". If there is a
|
|
yuuji@0
|
152 client/server interaction problem, a client which routinely
|
|
yuuji@0
|
153 terminates a session by breaking the connection without a LOGOUT will
|
|
yuuji@0
|
154 make it much more difficult to determine the problem.
|
|
yuuji@0
|
155
|
|
yuuji@0
|
156 Because of this disagreement, server designers must be aware that
|
|
yuuji@0
|
157 some clients might close the socket without sending a LOGOUT. In any
|
|
yuuji@0
|
158 case, whether or not a LOGOUT was sent, the server should not
|
|
yuuji@0
|
159 implicitly expunge any messages from the selected mailbox. If a
|
|
yuuji@0
|
160 client wants the server to do so, it must send a CLOSE or EXPUNGE
|
|
yuuji@0
|
161 command explicitly.
|
|
yuuji@0
|
162
|
|
yuuji@0
|
163 When the server wants to sever a connection it's usually due to an
|
|
yuuji@0
|
164 inactivity timeout or is because a situation has arisen that has
|
|
yuuji@0
|
165 changed the state of the mail store in a way that the server can not
|
|
yuuji@0
|
166 communicate to the client. The server should send an untagged BYE
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Leiba Informational [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 response to the client and then close the socket. Sending an
|
|
yuuji@0
|
176 untagged BYE response before severing allows the server to send a
|
|
yuuji@0
|
177 human-readable explanation of the problem to the client, which the
|
|
yuuji@0
|
178 client may then log, display to the user, or both (see section 7.1.5
|
|
yuuji@0
|
179 of [RFC-2060]).
|
|
yuuji@0
|
180
|
|
yuuji@0
|
181 Regarding inactivity timeouts, there is some controversy. Unlike
|
|
yuuji@0
|
182 POP, for which the design is for a client to connect, retrieve mail,
|
|
yuuji@0
|
183 and log out, IMAP's design encourages long-lived (and mostly
|
|
yuuji@0
|
184 inactive) client/server sessions. As the number of users grows, this
|
|
yuuji@0
|
185 can use up a lot of server resources, especially with clients that
|
|
yuuji@0
|
186 are designed to maintain sessions for mailboxes that the user has
|
|
yuuji@0
|
187 finished accessing. To alleviate this, a server may implement an
|
|
yuuji@0
|
188 inactivity timeout, unilaterally closing a session (after first
|
|
yuuji@0
|
189 sending an untagged BYE, as noted above). Some server operators have
|
|
yuuji@0
|
190 reported dramatic improvements in server performance after doing
|
|
yuuji@0
|
191 this. As specified in [RFC-2060], if such a timeout is done it must
|
|
yuuji@0
|
192 not be until at least 30 minutes of inactivity. The reason for this
|
|
yuuji@0
|
193 specification is to prevent clients from sending commands (such as
|
|
yuuji@0
|
194 NOOP) to the server at frequent intervals simply to avert a too-early
|
|
yuuji@0
|
195 timeout. If the client knows that the server may not time out the
|
|
yuuji@0
|
196 session for at least 30 minutes, then the client need not poll at
|
|
yuuji@0
|
197 intervals more frequent than, say, 25 minutes.
|
|
yuuji@0
|
198
|
|
yuuji@0
|
199 3.2. Scaling
|
|
yuuji@0
|
200
|
|
yuuji@0
|
201 IMAP4 has many features that allow for scalability, as mail stores
|
|
yuuji@0
|
202 become larger and more numerous. Large numbers of users, mailboxes,
|
|
yuuji@0
|
203 and messages, and very large messages require thought to handle
|
|
yuuji@0
|
204 efficiently. This document will not address the administrative
|
|
yuuji@0
|
205 issues involved in large numbers of users, but we will look at the
|
|
yuuji@0
|
206 other items.
|
|
yuuji@0
|
207
|
|
yuuji@0
|
208 3.2.1. Flood Control
|
|
yuuji@0
|
209
|
|
yuuji@0
|
210 There are three situations when a client can make a request that will
|
|
yuuji@0
|
211 result in a very large response - too large for the client reasonably
|
|
yuuji@0
|
212 to deal with: there are a great many mailboxes available, there are a
|
|
yuuji@0
|
213 great many messages in the selected mailbox, or there is a very large
|
|
yuuji@0
|
214 message part. The danger here is that the end user will be stuck
|
|
yuuji@0
|
215 waiting while the server sends (and the client processes) an enormous
|
|
yuuji@0
|
216 response. In all of these cases there are things a client can do to
|
|
yuuji@0
|
217 reduce that danger.
|
|
yuuji@0
|
218
|
|
yuuji@0
|
219 There is also the case where a client can flood a server, by sending
|
|
yuuji@0
|
220 an arbitratily long command. We'll discuss that issue, too, in this
|
|
yuuji@0
|
221 section.
|
|
yuuji@0
|
222
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Leiba Informational [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 3.2.1.1. Listing Mailboxes
|
|
yuuji@0
|
232
|
|
yuuji@0
|
233 Some servers present Usenet newsgroups to IMAP users. Newsgroups,
|
|
yuuji@0
|
234 and other such hierarchical mailbox structures, can be very numerous
|
|
yuuji@0
|
235 but may have only a few entries at the top level of hierarchy. Also,
|
|
yuuji@0
|
236 some servers are built against mail stores that can, unbeknownst to
|
|
yuuji@0
|
237 the server, have circular hierarchies - that is, it's possible for
|
|
yuuji@0
|
238 "a/b/c/d" to resolve to the same file structure as "a", which would
|
|
yuuji@0
|
239 then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy
|
|
yuuji@0
|
240 will never end. The LIST response in this case will be unlimited.
|
|
yuuji@0
|
241
|
|
yuuji@0
|
242 Clients that will have trouble with this are those that use
|
|
yuuji@0
|
243
|
|
yuuji@0
|
244 C: 001 LIST "" *
|
|
yuuji@0
|
245
|
|
yuuji@0
|
246 to determine the mailbox list. Because of this, clients should not
|
|
yuuji@0
|
247 use an unqualified "*" that way in the LIST command. A safer
|
|
yuuji@0
|
248 approach is to list each level of hierarchy individually, allowing
|
|
yuuji@0
|
249 the user to traverse the tree one limb at a time, thus:
|
|
yuuji@0
|
250
|
|
yuuji@0
|
251 C: 001 LIST "" %
|
|
yuuji@0
|
252 S: * LIST () "/" Banana
|
|
yuuji@0
|
253 S: * LIST ...etc...
|
|
yuuji@0
|
254 S: 001 OK done
|
|
yuuji@0
|
255
|
|
yuuji@0
|
256 and then
|
|
yuuji@0
|
257
|
|
yuuji@0
|
258 C: 002 LIST "" Banana/%
|
|
yuuji@0
|
259 S: * LIST () "/" Banana/Apple
|
|
yuuji@0
|
260 S: * LIST ...etc...
|
|
yuuji@0
|
261 S: 002 OK done
|
|
yuuji@0
|
262
|
|
yuuji@0
|
263 Using this technique the client's user interface can give the user
|
|
yuuji@0
|
264 full flexibility without choking on the voluminous reply to "LIST *".
|
|
yuuji@0
|
265
|
|
yuuji@0
|
266 Of course, it is still possible that the reply to
|
|
yuuji@0
|
267
|
|
yuuji@0
|
268 C: 005 LIST "" alt.fan.celebrity.%
|
|
yuuji@0
|
269
|
|
yuuji@0
|
270 may be thousands of entries long, and there is, unfortunately,
|
|
yuuji@0
|
271 nothing the client can do to protect itself from that. This has not
|
|
yuuji@0
|
272 yet been a notable problem.
|
|
yuuji@0
|
273
|
|
yuuji@0
|
274 Servers that may export circular hierarchies (any server that
|
|
yuuji@0
|
275 directly presents a UNIX file system, for instance) should limit the
|
|
yuuji@0
|
276 hierarchy depth to prevent unlimited LIST responses. A suggested
|
|
yuuji@0
|
277 depth limit is 20 hierarchy levels.
|
|
yuuji@0
|
278
|
|
yuuji@0
|
279
|
|
yuuji@0
|
280
|
|
yuuji@0
|
281
|
|
yuuji@0
|
282 Leiba Informational [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 3.2.1.2. Fetching the List of Messages
|
|
yuuji@0
|
288
|
|
yuuji@0
|
289 When a client selects a mailbox, it is given a count, in the untagged
|
|
yuuji@0
|
290 EXISTS response, of the messages in the mailbox. This number can be
|
|
yuuji@0
|
291 very large. In such a case it might be unwise to use
|
|
yuuji@0
|
292
|
|
yuuji@0
|
293 C: 004 FETCH 1:* ALL
|
|
yuuji@0
|
294
|
|
yuuji@0
|
295 to populate the user's view of the mailbox. One good method to avoid
|
|
yuuji@0
|
296 problems with this is to batch the requests, thus:
|
|
yuuji@0
|
297
|
|
yuuji@0
|
298 C: 004 FETCH 1:50 ALL
|
|
yuuji@0
|
299 S: * 1 FETCH ...etc...
|
|
yuuji@0
|
300 S: 004 OK done
|
|
yuuji@0
|
301 C: 005 FETCH 51:100 ALL
|
|
yuuji@0
|
302 S: * 51 FETCH ...etc...
|
|
yuuji@0
|
303 S: 005 OK done
|
|
yuuji@0
|
304 C: 006 FETCH 101:150 ALL
|
|
yuuji@0
|
305 ...etc...
|
|
yuuji@0
|
306
|
|
yuuji@0
|
307 Using this method, another command, such as "FETCH 6 BODY[1]" can be
|
|
yuuji@0
|
308 inserted as necessary, and the client will not have its access to the
|
|
yuuji@0
|
309 server blocked by a storm of FETCH replies. (Such a method could be
|
|
yuuji@0
|
310 reversed to fetch the LAST 50 messages first, then the 50 prior to
|
|
yuuji@0
|
311 that, and so on.)
|
|
yuuji@0
|
312
|
|
yuuji@0
|
313 As a smart extension of this, a well designed client, prepared for
|
|
yuuji@0
|
314 very large mailboxes, will not automatically fetch data for all
|
|
yuuji@0
|
315 messages AT ALL. Rather, the client will populate the user's view
|
|
yuuji@0
|
316 only as the user sees it, possibly pre-fetching selected information,
|
|
yuuji@0
|
317 and only fetching other information as the user scrolls to it. For
|
|
yuuji@0
|
318 example, to select only those messages beginning with the first
|
|
yuuji@0
|
319 unseen one:
|
|
yuuji@0
|
320
|
|
yuuji@0
|
321 C: 003 SELECT INBOX
|
|
yuuji@0
|
322 S: * 10000 EXISTS
|
|
yuuji@0
|
323 S: * 80 RECENT
|
|
yuuji@0
|
324 S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
|
|
yuuji@0
|
325 S: * OK [UIDVALIDITY 824708485] UID validity status
|
|
yuuji@0
|
326 S: * OK [UNSEEN 9921] First unseen message
|
|
yuuji@0
|
327 S: 003 OK [READ-WRITE] SELECT completed
|
|
yuuji@0
|
328 C: 004 FETCH 9921:* ALL
|
|
yuuji@0
|
329 ... etc...
|
|
yuuji@0
|
330
|
|
yuuji@0
|
331 If the server does not return an OK [UNSEEN] response, the client may
|
|
yuuji@0
|
332 use SEARCH UNSEEN to obtain that value.
|
|
yuuji@0
|
333
|
|
yuuji@0
|
334
|
|
yuuji@0
|
335
|
|
yuuji@0
|
336
|
|
yuuji@0
|
337
|
|
yuuji@0
|
338 Leiba Informational [Page 6]
|
|
yuuji@0
|
339
|
|
yuuji@0
|
340 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
341
|
|
yuuji@0
|
342
|
|
yuuji@0
|
343 This mechanism is good as a default presentation method, but only
|
|
yuuji@0
|
344 works well if the default message order is acceptable. A client may
|
|
yuuji@0
|
345 want to present various sort orders to the user (by subject, by date
|
|
yuuji@0
|
346 sent, by sender, and so on) and in that case (lacking a SORT
|
|
yuuji@0
|
347 extension on the server side) the client WILL have to retrieve all
|
|
yuuji@0
|
348 message descriptors. A client that provides this service should not
|
|
yuuji@0
|
349 do it by default and should inform the user of the costs of choosing
|
|
yuuji@0
|
350 this option for large mailboxes.
|
|
yuuji@0
|
351
|
|
yuuji@0
|
352 3.2.1.3. Fetching a Large Body Part
|
|
yuuji@0
|
353
|
|
yuuji@0
|
354 The issue here is similar to the one for a list of messages. In the
|
|
yuuji@0
|
355 BODYSTRUCTURE response the client knows the size, in bytes, of the
|
|
yuuji@0
|
356 body part it plans to fetch. Suppose this is a 70 MB video clip. The
|
|
yuuji@0
|
357 client can use partial fetches to retrieve the body part in pieces,
|
|
yuuji@0
|
358 avoiding the problem of an uninterruptible 70 MB literal coming back
|
|
yuuji@0
|
359 from the server:
|
|
yuuji@0
|
360
|
|
yuuji@0
|
361 C: 022 FETCH 3 BODY[1]<0.20000>
|
|
yuuji@0
|
362 S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
|
|
yuuji@0
|
363 S: ...data...)
|
|
yuuji@0
|
364 S: 022 OK done
|
|
yuuji@0
|
365 C: 023 FETCH 3 BODY[1]<20001.20000>
|
|
yuuji@0
|
366 S: * 3 FETCH (BODY[1]<20001> {20000}
|
|
yuuji@0
|
367 S: ...data...)
|
|
yuuji@0
|
368 S: 023 OK done
|
|
yuuji@0
|
369 C: 024 FETCH 3 BODY[1]<40001.20000>
|
|
yuuji@0
|
370 ...etc...
|
|
yuuji@0
|
371
|
|
yuuji@0
|
372 3.2.1.4. BODYSTRUCTURE vs. Entire Messages
|
|
yuuji@0
|
373
|
|
yuuji@0
|
374 Because FETCH BODYSTRUCTURE is necessary in order to determine the
|
|
yuuji@0
|
375 number of body parts, and, thus, whether a message has "attachments",
|
|
yuuji@0
|
376 clients often use FETCH FULL as their normal method of populating the
|
|
yuuji@0
|
377 user's view of a mailbox. The benefit is that the client can display
|
|
yuuji@0
|
378 a paperclip icon or some such indication along with the normal
|
|
yuuji@0
|
379 message summary. However, this comes at a significant cost with some
|
|
yuuji@0
|
380 server configurations. The parsing needed to generate the FETCH
|
|
yuuji@0
|
381 BODYSTRUCTURE response may be time-consuming compared with that
|
|
yuuji@0
|
382 needed for FETCH ENVELOPE. The client developer should consider this
|
|
yuuji@0
|
383 issue when deciding whether the ability to add a paperclip icon is
|
|
yuuji@0
|
384 worth the tradeoff in performance, especially with large mailboxes.
|
|
yuuji@0
|
385
|
|
yuuji@0
|
386 Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]
|
|
yuuji@0
|
387 (or the equivalent FETCH RFC822) to retrieve the entire message.
|
|
yuuji@0
|
388 They then do the MIME parsing in the client. This may give the
|
|
yuuji@0
|
389 client slightly more flexibility in some areas (access, for instance,
|
|
yuuji@0
|
390 to header fields that aren't returned in the BODYSTRUCTURE and
|
|
yuuji@0
|
391
|
|
yuuji@0
|
392
|
|
yuuji@0
|
393
|
|
yuuji@0
|
394 Leiba Informational [Page 7]
|
|
yuuji@0
|
395
|
|
yuuji@0
|
396 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
397
|
|
yuuji@0
|
398
|
|
yuuji@0
|
399 ENVELOPE responses), but it can cause severe performance problems by
|
|
yuuji@0
|
400 forcing the transfer of all body parts when the user might only want
|
|
yuuji@0
|
401 to see some of them - a user logged on by modem and reading a small
|
|
yuuji@0
|
402 text message with a large ZIP file attached may prefer to read the
|
|
yuuji@0
|
403 text only and save the ZIP file for later. Therefore, a client
|
|
yuuji@0
|
404 should not normally retrieve entire messages and should retrieve
|
|
yuuji@0
|
405 message body parts selectively.
|
|
yuuji@0
|
406
|
|
yuuji@0
|
407 3.2.1.5. Long Command Lines
|
|
yuuji@0
|
408
|
|
yuuji@0
|
409 A client can wind up building a very long command line in an effort to
|
|
yuuji@0
|
410 try to be efficient about requesting information from a server. This
|
|
yuuji@0
|
411 can typically happen when a client builds a message set from selected
|
|
yuuji@0
|
412 messages and doesn't recognise that contiguous blocks of messages may
|
|
yuuji@0
|
413 be group in a range. Suppose a user selects all 10,000 messages in a
|
|
yuuji@0
|
414 large mailbox and then unselects message 287. The client could build
|
|
yuuji@0
|
415 that message set as "1:286,288:10000", but a client that doesn't
|
|
yuuji@0
|
416 handle that might try to enumerate each message individually and build
|
|
yuuji@0
|
417 "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command
|
|
yuuji@0
|
418 results in a command line that's almost 49,000 octets long, and,
|
|
yuuji@0
|
419 clearly, one can construct a command line that's even longer.
|
|
yuuji@0
|
420
|
|
yuuji@0
|
421 A client should limit the length of the command lines it generates to
|
|
yuuji@0
|
422 approximately 1000 octets (including all quoted strings but not
|
|
yuuji@0
|
423 including literals). If the client is unable to group things into
|
|
yuuji@0
|
424 ranges so that the command line is within that length, it should
|
|
yuuji@0
|
425 split the request into multiple commands. The client should use
|
|
yuuji@0
|
426 literals instead of long quoted strings, in order to keep the command
|
|
yuuji@0
|
427 length down.
|
|
yuuji@0
|
428
|
|
yuuji@0
|
429 For its part, a server should allow for a command line of at least
|
|
yuuji@0
|
430 8000 octets. This provides plenty of leeway for accepting reasonable
|
|
yuuji@0
|
431 length commands from clients. The server should send a BAD response
|
|
yuuji@0
|
432 to a command that does not end within the server's maximum accepted
|
|
yuuji@0
|
433 command length.
|
|
yuuji@0
|
434
|
|
yuuji@0
|
435 3.2.2. Subscriptions
|
|
yuuji@0
|
436
|
|
yuuji@0
|
437 The client isn't the only entity that can get flooded: the end user,
|
|
yuuji@0
|
438 too, may need some flood control. The IMAP4 protocol provides such
|
|
yuuji@0
|
439 control in the form of subscriptions. Most servers support the
|
|
yuuji@0
|
440 SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to
|
|
yuuji@0
|
441 narrow down a large list of available mailboxes by subscribing to the
|
|
yuuji@0
|
442 ones that they usually want to see. Clients, with this in mind,
|
|
yuuji@0
|
443 should give the user a way to see only subscribed mailboxes. A
|
|
yuuji@0
|
444 client that never uses the LSUB command takes a significant usability
|
|
yuuji@0
|
445 feature away from the user. Of course, the client would not want to
|
|
yuuji@0
|
446 hide the LIST command completely; the user needs to have a way to
|
|
yuuji@0
|
447
|
|
yuuji@0
|
448
|
|
yuuji@0
|
449
|
|
yuuji@0
|
450 Leiba Informational [Page 8]
|
|
yuuji@0
|
451
|
|
yuuji@0
|
452 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
453
|
|
yuuji@0
|
454
|
|
yuuji@0
|
455 choose between LIST and LSUB. The usual way to do this is to provide
|
|
yuuji@0
|
456 a setting like "show which mailboxes?: [] all [] subscribed only".
|
|
yuuji@0
|
457
|
|
yuuji@0
|
458 3.2.3. Searching
|
|
yuuji@0
|
459
|
|
yuuji@0
|
460 IMAP SEARCH commands can become particularly troublesome (that is,
|
|
yuuji@0
|
461 slow) on mailboxes containing a large number of messages. So let's
|
|
yuuji@0
|
462 put a few things in perspective in that regard.
|
|
yuuji@0
|
463
|
|
yuuji@0
|
464 The flag searches should be fast. The flag searches (ALL, [UN]SEEN,
|
|
yuuji@0
|
465 [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
|
|
yuuji@0
|
466 are known to be used by clients for the client's own use (for
|
|
yuuji@0
|
467 instance, some clients use "SEARCH UNSEEN" to find unseen mail and
|
|
yuuji@0
|
468 "SEARCH DELETED" to warn the user before expunging messages).
|
|
yuuji@0
|
469
|
|
yuuji@0
|
470 Other searches, particularly the text searches (HEADER, TEXT, BODY)
|
|
yuuji@0
|
471 are initiated by the user, rather than by the client itself, and
|
|
yuuji@0
|
472 somewhat slower performance can be tolerated, since the user is aware
|
|
yuuji@0
|
473 that the search is being done (and is probably aware that it might be
|
|
yuuji@0
|
474 time-consuming). A smart server might use dynamic indexing to speed
|
|
yuuji@0
|
475 commonly used text searches.
|
|
yuuji@0
|
476
|
|
yuuji@0
|
477 The client may allow other commands to be sent to the server while a
|
|
yuuji@0
|
478 SEARCH is in progress, but at the time of this writing there is
|
|
yuuji@0
|
479 little or no server support for parallel processing of multiple
|
|
yuuji@0
|
480 commands in the same session (and see "Multiple Accesses of the Same
|
|
yuuji@0
|
481 Mailbox" above for a description of the dangers of trying to work
|
|
yuuji@0
|
482 around this by doing your SEARCH in another session).
|
|
yuuji@0
|
483
|
|
yuuji@0
|
484 Another word about text searches: some servers, built on database
|
|
yuuji@0
|
485 back-ends with indexed search capabilities, may return search results
|
|
yuuji@0
|
486 that do not match the IMAP spec's "case-insensitive substring"
|
|
yuuji@0
|
487 requirements. While these servers are in violation of the protocol,
|
|
yuuji@0
|
488 there is little harm in the violation as long as the search results
|
|
yuuji@0
|
489 are used only in response to a user's request. Still, developers of
|
|
yuuji@0
|
490 such servers should be aware that they ARE violating the protocol,
|
|
yuuji@0
|
491 should think carefully about that behaviour, and must be certain that
|
|
yuuji@0
|
492 their servers respond accurately to the flag searches for the reasons
|
|
yuuji@0
|
493 outlined above.
|
|
yuuji@0
|
494
|
|
yuuji@0
|
495 In addition, servers should support CHARSET UTF-8 [UTF-8] in
|
|
yuuji@0
|
496 searches.
|
|
yuuji@0
|
497
|
|
yuuji@0
|
498
|
|
yuuji@0
|
499
|
|
yuuji@0
|
500
|
|
yuuji@0
|
501
|
|
yuuji@0
|
502
|
|
yuuji@0
|
503
|
|
yuuji@0
|
504
|
|
yuuji@0
|
505
|
|
yuuji@0
|
506 Leiba Informational [Page 9]
|
|
yuuji@0
|
507
|
|
yuuji@0
|
508 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
509
|
|
yuuji@0
|
510
|
|
yuuji@0
|
511 3.3 Avoiding Invalid Requests
|
|
yuuji@0
|
512
|
|
yuuji@0
|
513 IMAP4 provides ways for a server to tell a client in advance what is
|
|
yuuji@0
|
514 and isn't permitted in some circumstances. Clients should use these
|
|
yuuji@0
|
515 features to avoid sending requests that a well designed client would
|
|
yuuji@0
|
516 know to be invalid. This section explains this in more detail.
|
|
yuuji@0
|
517
|
|
yuuji@0
|
518 3.3.1. The CAPABILITY Command
|
|
yuuji@0
|
519
|
|
yuuji@0
|
520 All IMAP4 clients should use the CAPABILITY command to determine what
|
|
yuuji@0
|
521 version of IMAP and what optional features a server supports. The
|
|
yuuji@0
|
522 client should not send IMAP4rev1 commands and arguments to a server
|
|
yuuji@0
|
523 that does not advertize IMAP4rev1 in its CAPABILITY response.
|
|
yuuji@0
|
524 Similarly, the client should not send IMAP4 commands that no longer
|
|
yuuji@0
|
525 exist in IMAP4rev1 to a server that does not advertize IMAP4 in its
|
|
yuuji@0
|
526 CAPABILITY response. An IMAP4rev1 server is NOT required to support
|
|
yuuji@0
|
527 obsolete IMAP4 or IMAP2bis commands (though some do; do not let this
|
|
yuuji@0
|
528 fact lull you into thinking that it's valid to send such commands to
|
|
yuuji@0
|
529 an IMAP4rev1 server).
|
|
yuuji@0
|
530
|
|
yuuji@0
|
531 A client should not send commands to probe for the existance of
|
|
yuuji@0
|
532 certain extensions. All standard and standards-track extensions
|
|
yuuji@0
|
533 include CAPABILITY tokens indicating their presense. All private and
|
|
yuuji@0
|
534 experimental extensions should do the same, and clients that take
|
|
yuuji@0
|
535 advantage of them should use the CAPABILITY response to determine
|
|
yuuji@0
|
536 whether they may be used or not.
|
|
yuuji@0
|
537
|
|
yuuji@0
|
538 3.3.2. Don't Do What the Server Says You Can't
|
|
yuuji@0
|
539
|
|
yuuji@0
|
540 In many cases, the server, in response to a command, will tell the
|
|
yuuji@0
|
541 client something about what can and can't be done with a particular
|
|
yuuji@0
|
542 mailbox. The client should pay attention to this information and
|
|
yuuji@0
|
543 should not try to do things that it's been told it can't do.
|
|
yuuji@0
|
544
|
|
yuuji@0
|
545 Examples:
|
|
yuuji@0
|
546
|
|
yuuji@0
|
547 * Do not try to SELECT a mailbox that has the \Noselect flag set.
|
|
yuuji@0
|
548 * Do not try to CREATE a sub-mailbox in a mailbox that has the
|
|
yuuji@0
|
549 \Noinferiors flag set.
|
|
yuuji@0
|
550 * Do not respond to a failing COPY or APPEND command by trying to
|
|
yuuji@0
|
551 CREATE the target mailbox if the server does not respond with a
|
|
yuuji@0
|
552 [TRYCREATE] response code.
|
|
yuuji@0
|
553 * Do not try to expunge a mailbox that has been selected with the
|
|
yuuji@0
|
554 [READ-ONLY] response code.
|
|
yuuji@0
|
555
|
|
yuuji@0
|
556
|
|
yuuji@0
|
557
|
|
yuuji@0
|
558
|
|
yuuji@0
|
559
|
|
yuuji@0
|
560
|
|
yuuji@0
|
561
|
|
yuuji@0
|
562 Leiba Informational [Page 10]
|
|
yuuji@0
|
563
|
|
yuuji@0
|
564 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
565
|
|
yuuji@0
|
566
|
|
yuuji@0
|
567 3.4. Miscellaneous Protocol Considerations
|
|
yuuji@0
|
568
|
|
yuuji@0
|
569 We describe here a number of important protocol-related issues, the
|
|
yuuji@0
|
570 misunderstanding of which has caused significant interoperability
|
|
yuuji@0
|
571 problems in IMAP4 implementations. One general item is that every
|
|
yuuji@0
|
572 implementer should be certain to take note of and to understand
|
|
yuuji@0
|
573 section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec
|
|
yuuji@0
|
574 [RFC-2060].
|
|
yuuji@0
|
575
|
|
yuuji@0
|
576 3.4.1. Well Formed Protocol
|
|
yuuji@0
|
577
|
|
yuuji@0
|
578 We cannot stress enough the importance of adhering strictly to the
|
|
yuuji@0
|
579 protocol grammar. The specification of the protocol is quite rigid;
|
|
yuuji@0
|
580 do not assume that you can insert blank space for "readability" if
|
|
yuuji@0
|
581 none is called for. Keep in mind that there are parsers out there
|
|
yuuji@0
|
582 that will crash if there are protocol errors. There are clients that
|
|
yuuji@0
|
583 will report every parser burp to the user. And in any case,
|
|
yuuji@0
|
584 information that cannot be parsed is information that is lost. Be
|
|
yuuji@0
|
585 careful in your protocol generation. And see "A Word About Testing",
|
|
yuuji@0
|
586 below.
|
|
yuuji@0
|
587
|
|
yuuji@0
|
588 In particular, note that the string in the INTERNALDATE response is
|
|
yuuji@0
|
589 NOT an RFC-822 date string - that is, it is not in the same format as
|
|
yuuji@0
|
590 the first string in the ENVELOPE response. Since most clients will,
|
|
yuuji@0
|
591 in fact, accept an RFC-822 date string in the INTERNALDATE response,
|
|
yuuji@0
|
592 it's easy to miss this in your interoperability testing. But it will
|
|
yuuji@0
|
593 cause a problem with some client, so be sure to generate the correct
|
|
yuuji@0
|
594 string for this field.
|
|
yuuji@0
|
595
|
|
yuuji@0
|
596 3.4.2. Special Characters
|
|
yuuji@0
|
597
|
|
yuuji@0
|
598 Certain characters, currently the double-quote and the backslash, may
|
|
yuuji@0
|
599 not be sent as-is inside a quoted string. These characters must be
|
|
yuuji@0
|
600 preceded by the escape character if they are in a quoted string, or
|
|
yuuji@0
|
601 else the string must be sent as a literal. Both clients and servers
|
|
yuuji@0
|
602 must handle this, both on output (they must send these characters
|
|
yuuji@0
|
603 properly) and on input (they must be able to receive escaped
|
|
yuuji@0
|
604 characters in quoted strings). Example:
|
|
yuuji@0
|
605
|
|
yuuji@0
|
606 C: 001 LIST "" %
|
|
yuuji@0
|
607 S: * LIST () "" INBOX
|
|
yuuji@0
|
608 S: * LIST () "\\" TEST
|
|
yuuji@0
|
609 S: * LIST () "\\" {12}
|
|
yuuji@0
|
610 S: "My" mailbox
|
|
yuuji@0
|
611 S: 001 OK done
|
|
yuuji@0
|
612 C: 002 LIST "" "\"My\" mailbox\\%"
|
|
yuuji@0
|
613 S: * LIST () "\\" {17}
|
|
yuuji@0
|
614 S: "My" mailbox\Junk
|
|
yuuji@0
|
615
|
|
yuuji@0
|
616
|
|
yuuji@0
|
617
|
|
yuuji@0
|
618 Leiba Informational [Page 11]
|
|
yuuji@0
|
619
|
|
yuuji@0
|
620 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
621
|
|
yuuji@0
|
622
|
|
yuuji@0
|
623 S: 002 OK done
|
|
yuuji@0
|
624
|
|
yuuji@0
|
625 Note that in the example the server sent the hierarchy delimiter as
|
|
yuuji@0
|
626 an escaped character in the quoted string and sent the mailbox name
|
|
yuuji@0
|
627 containing imbedded double-quotes as a literal. The client used only
|
|
yuuji@0
|
628 quoted strings, escaping both the backslash and the double-quote
|
|
yuuji@0
|
629 characters.
|
|
yuuji@0
|
630
|
|
yuuji@0
|
631 The CR and LF characters may be sent ONLY in literals; they are not
|
|
yuuji@0
|
632 allowed, even if escaped, inside quoted strings.
|
|
yuuji@0
|
633
|
|
yuuji@0
|
634 And while we're talking about special characters: the IMAP spec, in
|
|
yuuji@0
|
635 the section titled "Mailbox International Naming Convention",
|
|
yuuji@0
|
636 describes how to encode mailbox names in modified UTF-7 [UTF-7 and
|
|
yuuji@0
|
637 RFC-2060]. Implementations must adhere to this in order to be
|
|
yuuji@0
|
638 interoperable in the international market, and servers should
|
|
yuuji@0
|
639 validate mailbox names sent by client and reject names that do not
|
|
yuuji@0
|
640 conform.
|
|
yuuji@0
|
641
|
|
yuuji@0
|
642 As to special characters in userids and passwords: clients must not
|
|
yuuji@0
|
643 restrict what a user may type in for a userid or a password. The
|
|
yuuji@0
|
644 formal grammar specifies that these are "astrings", and an astring
|
|
yuuji@0
|
645 can be a literal. A literal, in turn can contain any 8-bit
|
|
yuuji@0
|
646 character, and clients must allow users to enter all 8-bit characters
|
|
yuuji@0
|
647 here, and must pass them, unchanged, to the server (being careful to
|
|
yuuji@0
|
648 send them as literals when necessary). In particular, some server
|
|
yuuji@0
|
649 configurations use "@" in user names, and some clients do not allow
|
|
yuuji@0
|
650 that character to be entered; this creates a severe interoperability
|
|
yuuji@0
|
651 problem.
|
|
yuuji@0
|
652
|
|
yuuji@0
|
653 3.4.3. UIDs and UIDVALIDITY
|
|
yuuji@0
|
654
|
|
yuuji@0
|
655 Servers that support existing back-end mail stores often have no good
|
|
yuuji@0
|
656 place to save UIDs for messages. Often the existing mail store will
|
|
yuuji@0
|
657 not have the concept of UIDs in the sense that IMAP has: strictly
|
|
yuuji@0
|
658 increasing, never re-issued, 32-bit integers. Some servers solve
|
|
yuuji@0
|
659 this by storing the UIDs in a place that's accessible to end users,
|
|
yuuji@0
|
660 allowing for the possibility that the users will delete them. Others
|
|
yuuji@0
|
661 solve it by re-assigning UIDs every time a mailbox is selected.
|
|
yuuji@0
|
662
|
|
yuuji@0
|
663 The server should maintain UIDs permanently for all messages if it
|
|
yuuji@0
|
664 can. If that's not possible, the server must change the UIDVALIDITY
|
|
yuuji@0
|
665 value for the mailbox whenever any of the UIDs may have become
|
|
yuuji@0
|
666 invalid. Clients must recognize that the UIDVALIDITY has changed and
|
|
yuuji@0
|
667 must respond to that condition by throwing away any information that
|
|
yuuji@0
|
668 they have saved about UIDs in that mailbox. There have been many
|
|
yuuji@0
|
669 problems in this area when clients have failed to do this; in the
|
|
yuuji@0
|
670 worst case it will result in loss of mail when a client deletes the
|
|
yuuji@0
|
671
|
|
yuuji@0
|
672
|
|
yuuji@0
|
673
|
|
yuuji@0
|
674 Leiba Informational [Page 12]
|
|
yuuji@0
|
675
|
|
yuuji@0
|
676 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
677
|
|
yuuji@0
|
678
|
|
yuuji@0
|
679 wrong piece of mail by using a stale UID.
|
|
yuuji@0
|
680
|
|
yuuji@0
|
681 It seems to be a common misunderstanding that "the UIDVALIDITY and
|
|
yuuji@0
|
682 the UID, taken together, form a 64-bit identifier that uniquely
|
|
yuuji@0
|
683 identifies a message on a server". This is absolutely NOT TRUE.
|
|
yuuji@0
|
684 There is no assurance that the UIDVALIDITY values of two mailboxes be
|
|
yuuji@0
|
685 different, so the UIDVALIDITY in no way identifies a mailbox. The
|
|
yuuji@0
|
686 ONLY purpose of UIDVALIDITY is, as its name indicates, to give the
|
|
yuuji@0
|
687 client a way to check the validity of the UIDs it has cached. While
|
|
yuuji@0
|
688 it is a valid implementation choice to put these values together to
|
|
yuuji@0
|
689 make a 64-bit identifier for the message, the important concept here
|
|
yuuji@0
|
690 is that UIDs are not unique between mailboxes; they are only unique
|
|
yuuji@0
|
691 WITHIN a given mailbox.
|
|
yuuji@0
|
692
|
|
yuuji@0
|
693 Some server implementations have attempted to make UIDs unique across
|
|
yuuji@0
|
694 the entire server. This is inadvisable, in that it limits the life
|
|
yuuji@0
|
695 of UIDs unnecessarily. The UID is a 32-bit number and will run out
|
|
yuuji@0
|
696 in reasonably finite time if it's global across the server. If you
|
|
yuuji@0
|
697 assign UIDs sequentially in one mailbox, you will not have to start
|
|
yuuji@0
|
698 re-using them until you have had, at one time or another, 2**32
|
|
yuuji@0
|
699 different messages in that mailbox. In the global case, you will
|
|
yuuji@0
|
700 have to reuse them once you have had, at one time or another, 2**32
|
|
yuuji@0
|
701 different messages in the entire mail store. Suppose your server has
|
|
yuuji@0
|
702 around 8000 users registered (2**13). That gives an average of 2**19
|
|
yuuji@0
|
703 UIDs per user. Suppose each user gets 32 messages (2**5) per day.
|
|
yuuji@0
|
704 That gives you 2**14 days (16000+ days = about 45 years) before you
|
|
yuuji@0
|
705 run out. That may seem like enough, but multiply the usage just a
|
|
yuuji@0
|
706 little (a lot of spam, a lot of mailing list subscriptions, more
|
|
yuuji@0
|
707 users) and you limit yourself too much.
|
|
yuuji@0
|
708
|
|
yuuji@0
|
709 What's worse is that if you have to wrap the UIDs, and, thus, you
|
|
yuuji@0
|
710 have to change UIDVALIDITY and invalidate the UIDs in the mailbox,
|
|
yuuji@0
|
711 you have to do it for EVERY mailbox in the system, since they all
|
|
yuuji@0
|
712 share the same UID pool. If you assign UIDs per mailbox and you have
|
|
yuuji@0
|
713 a problem, you only have to kill the UIDs for that one mailbox.
|
|
yuuji@0
|
714
|
|
yuuji@0
|
715 Under extreme circumstances (and this is extreme, indeed), the server
|
|
yuuji@0
|
716 may have to invalidate UIDs while a mailbox is in use by a client -
|
|
yuuji@0
|
717 that is, the UIDs that the client knows about in its active mailbox
|
|
yuuji@0
|
718 are no longer valid. In that case, the server must immediately
|
|
yuuji@0
|
719 change the UIDVALIDITY and must communicate this to the client. The
|
|
yuuji@0
|
720 server may do this by sending an unsolicited UIDVALIDITY message, in
|
|
yuuji@0
|
721 the same form as in response to the SELECT command. Clients must be
|
|
yuuji@0
|
722 prepared to handle such a message and the possibly coincident failure
|
|
yuuji@0
|
723 of the command in process. For example:
|
|
yuuji@0
|
724
|
|
yuuji@0
|
725
|
|
yuuji@0
|
726
|
|
yuuji@0
|
727
|
|
yuuji@0
|
728
|
|
yuuji@0
|
729
|
|
yuuji@0
|
730 Leiba Informational [Page 13]
|
|
yuuji@0
|
731
|
|
yuuji@0
|
732 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
733
|
|
yuuji@0
|
734
|
|
yuuji@0
|
735 C: 032 UID STORE 382 +Flags.silent \Deleted
|
|
yuuji@0
|
736 S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
|
|
yuuji@0
|
737 S: 032 NO UID command rejected because UIDVALIDITY changed!
|
|
yuuji@0
|
738 C: ...invalidates local information and re-fetches...
|
|
yuuji@0
|
739 C: 033 FETCH 1:* UID
|
|
yuuji@0
|
740 ...etc...
|
|
yuuji@0
|
741
|
|
yuuji@0
|
742 At the time of the writing of this document, the only server known to
|
|
yuuji@0
|
743 do this does so only under the following condition: the client
|
|
yuuji@0
|
744 selects INBOX, but there is not yet a physical INBOX file created.
|
|
yuuji@0
|
745 Nonetheless, the SELECT succeeds, exporting an empty INBOX with a
|
|
yuuji@0
|
746 temporary UIDVALIDITY of 1. While the INBOX remains selected, mail
|
|
yuuji@0
|
747 is delivered to the user, which creates the real INBOX file and
|
|
yuuji@0
|
748 assigns a permanent UIDVALIDITY (that is likely not to be 1). The
|
|
yuuji@0
|
749 server reports the change of UIDVALIDITY, but as there were no
|
|
yuuji@0
|
750 messages before, so no UIDs have actually changed, all the client
|
|
yuuji@0
|
751 must do is accept the change in UIDVALIDITY.
|
|
yuuji@0
|
752
|
|
yuuji@0
|
753 Alternatively, a server may force the client to re-select the
|
|
yuuji@0
|
754 mailbox, at which time it will obtain a new UIDVALIDITY value. To do
|
|
yuuji@0
|
755 this, the server closes this client session (see "Severed
|
|
yuuji@0
|
756 Connections" above) and the client then reconnects and gets back in
|
|
yuuji@0
|
757 synch. Clients must be prepared for either of these behaviours.
|
|
yuuji@0
|
758
|
|
yuuji@0
|
759 We do not know of, nor do we anticipate the future existance of, a
|
|
yuuji@0
|
760 server that changes UIDVALIDITY while there are existing messages,
|
|
yuuji@0
|
761 but clients must be prepared to handle this eventuality.
|
|
yuuji@0
|
762
|
|
yuuji@0
|
763 3.4.4. FETCH Responses
|
|
yuuji@0
|
764
|
|
yuuji@0
|
765 When a client asks for certain information in a FETCH command, the
|
|
yuuji@0
|
766 server may return the requested information in any order, not
|
|
yuuji@0
|
767 necessarily in the order that it was requested. Further, the server
|
|
yuuji@0
|
768 may return the information in separate FETCH responses and may also
|
|
yuuji@0
|
769 return information that was not explicitly requested (to reflect to
|
|
yuuji@0
|
770 the client changes in the state of the subject message). Some
|
|
yuuji@0
|
771 examples:
|
|
yuuji@0
|
772
|
|
yuuji@0
|
773 C: 001 FETCH 1 UID FLAGS INTERNALDATE
|
|
yuuji@0
|
774 S: * 5 FETCH (FLAGS (\Deleted))
|
|
yuuji@0
|
775 S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
|
|
yuuji@0
|
776 S: 001 OK done
|
|
yuuji@0
|
777
|
|
yuuji@0
|
778 (In this case, the responses are in a different order. Also, the
|
|
yuuji@0
|
779 server returned a flag update for message 5, which wasn't part of the
|
|
yuuji@0
|
780 client's request.)
|
|
yuuji@0
|
781
|
|
yuuji@0
|
782
|
|
yuuji@0
|
783
|
|
yuuji@0
|
784
|
|
yuuji@0
|
785
|
|
yuuji@0
|
786 Leiba Informational [Page 14]
|
|
yuuji@0
|
787
|
|
yuuji@0
|
788 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
789
|
|
yuuji@0
|
790
|
|
yuuji@0
|
791 C: 002 FETCH 2 UID FLAGS INTERNALDATE
|
|
yuuji@0
|
792 S: * 2 FETCH (INTERNALDATE "...")
|
|
yuuji@0
|
793 S: * 2 FETCH (UID 399)
|
|
yuuji@0
|
794 S: * 2 FETCH (FLAGS ())
|
|
yuuji@0
|
795 S: 002 OK done
|
|
yuuji@0
|
796
|
|
yuuji@0
|
797 (In this case, the responses are in a different order and were
|
|
yuuji@0
|
798 returned in separate responses.)
|
|
yuuji@0
|
799
|
|
yuuji@0
|
800 C: 003 FETCH 2 BODY[1]
|
|
yuuji@0
|
801 S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
|
|
yuuji@0
|
802 S: Hello world!
|
|
yuuji@0
|
803 S: )
|
|
yuuji@0
|
804 S: 003 OK done
|
|
yuuji@0
|
805
|
|
yuuji@0
|
806 (In this case, the FLAGS response was added by the server, since
|
|
yuuji@0
|
807 fetching the body part caused the server to set the \Seen flag.)
|
|
yuuji@0
|
808
|
|
yuuji@0
|
809 Because of this characteristic a client must be ready to receive any
|
|
yuuji@0
|
810 FETCH response at any time and should use that information to update
|
|
yuuji@0
|
811 its local information about the message to which the FETCH response
|
|
yuuji@0
|
812 refers. A client must not assume that any FETCH responses will come
|
|
yuuji@0
|
813 in any particular order, or even that any will come at all. If after
|
|
yuuji@0
|
814 receiving the tagged response for a FETCH command the client finds
|
|
yuuji@0
|
815 that it did not get all of the information requested, the client
|
|
yuuji@0
|
816 should send a NOOP command to the server to ensure that the server
|
|
yuuji@0
|
817 has an opportunity to send any pending EXPUNGE responses to the
|
|
yuuji@0
|
818 client (see [RFC-2180]).
|
|
yuuji@0
|
819
|
|
yuuji@0
|
820 3.4.5. RFC822.SIZE
|
|
yuuji@0
|
821
|
|
yuuji@0
|
822 Some back-end mail stores keep the mail in a canonical form, rather
|
|
yuuji@0
|
823 than retaining the original MIME format of the messages. This means
|
|
yuuji@0
|
824 that the server must reassemble the message to produce a MIME stream
|
|
yuuji@0
|
825 when a client does a fetch such as RFC822 or BODY[], requesting the
|
|
yuuji@0
|
826 entire message. It also may mean that the server has no convenient
|
|
yuuji@0
|
827 way to know the RFC822.SIZE of the message. Often, such a server
|
|
yuuji@0
|
828 will actually have to build the MIME stream to compute the size, only
|
|
yuuji@0
|
829 to throw the stream away and report the size to the client.
|
|
yuuji@0
|
830
|
|
yuuji@0
|
831 When this is the case, some servers have chosen to estimate the size,
|
|
yuuji@0
|
832 rather than to compute it precisely. Such an estimate allows the
|
|
yuuji@0
|
833 client to display an approximate size to the user and to use the
|
|
yuuji@0
|
834 estimate in flood control considerations (q.v.), but requires that
|
|
yuuji@0
|
835 the client not use the size for things such as allocation of buffers,
|
|
yuuji@0
|
836 because those buffers might then be too small to hold the actual MIME
|
|
yuuji@0
|
837 stream. Instead, a client should use the size that's returned in the
|
|
yuuji@0
|
838 literal when you fetch the data.
|
|
yuuji@0
|
839
|
|
yuuji@0
|
840
|
|
yuuji@0
|
841
|
|
yuuji@0
|
842 Leiba Informational [Page 15]
|
|
yuuji@0
|
843
|
|
yuuji@0
|
844 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
845
|
|
yuuji@0
|
846
|
|
yuuji@0
|
847 The protocol requires that the RFC822.SIZE value returned by the
|
|
yuuji@0
|
848 server be EXACT. Estimating the size is a protocol violation, and
|
|
yuuji@0
|
849 server designers must be aware that, despite the performance savings
|
|
yuuji@0
|
850 they might realize in using an estimate, this practice will cause
|
|
yuuji@0
|
851 some clients to fail in various ways. If possible, the server should
|
|
yuuji@0
|
852 compute the RFC822.SIZE for a particular message once, and then save
|
|
yuuji@0
|
853 it for later retrieval. If that's not possible, the server must
|
|
yuuji@0
|
854 compute the value exactly every time. Incorrect estimates do cause
|
|
yuuji@0
|
855 severe interoperability problems with some clients.
|
|
yuuji@0
|
856
|
|
yuuji@0
|
857 3.4.6. Expunged Messages
|
|
yuuji@0
|
858
|
|
yuuji@0
|
859 If the server allows multiple connections to the same mailbox, it is
|
|
yuuji@0
|
860 often possible for messages to be expunged in one client unbeknownst
|
|
yuuji@0
|
861 to another client. Since the server is not allowed to tell the
|
|
yuuji@0
|
862 client about these expunged messages in response to a FETCH command,
|
|
yuuji@0
|
863 the server may have to deal with the issue of how to return
|
|
yuuji@0
|
864 information about an expunged message. There was extensive
|
|
yuuji@0
|
865 discussion about this issue, and the results of that discussion are
|
|
yuuji@0
|
866 summarized in [RFC-2180]. See that reference for a detailed
|
|
yuuji@0
|
867 explanation and for recommendations.
|
|
yuuji@0
|
868
|
|
yuuji@0
|
869 3.4.7. The Namespace Issue
|
|
yuuji@0
|
870
|
|
yuuji@0
|
871 Namespaces are a very muddy area in IMAP4 implementation right now
|
|
yuuji@0
|
872 (see [NAMESPACE] for a proposal to clear the water a bit). Until the
|
|
yuuji@0
|
873 issue is resolved, the important thing for client developers to
|
|
yuuji@0
|
874 understand is that some servers provide access through IMAP to more
|
|
yuuji@0
|
875 than just the user's personal mailboxes, and, in fact, the user's
|
|
yuuji@0
|
876 personal mailboxes may be "hidden" somewhere in the user's default
|
|
yuuji@0
|
877 hierarchy. The client, therefore, should provide a setting wherein
|
|
yuuji@0
|
878 the user can specify a prefix to be used when accessing mailboxes. If
|
|
yuuji@0
|
879 the user's mailboxes are all in "~/mail/", for instance, then the
|
|
yuuji@0
|
880 user can put that string in the prefix. The client would then put
|
|
yuuji@0
|
881 the prefix in front of any name pattern in the LIST and LSUB
|
|
yuuji@0
|
882 commands:
|
|
yuuji@0
|
883
|
|
yuuji@0
|
884 C: 001 LIST "" ~/mail/%
|
|
yuuji@0
|
885
|
|
yuuji@0
|
886 (See also "Reference Names in the LIST Command" below.)
|
|
yuuji@0
|
887
|
|
yuuji@0
|
888 3.4.8. Creating Special-Use Mailboxes
|
|
yuuji@0
|
889
|
|
yuuji@0
|
890 It may seem at first that this is part of the namespace issue; it is
|
|
yuuji@0
|
891 not, and is only indirectly related to it. A number of clients like
|
|
yuuji@0
|
892 to create special-use mailboxes with particular names. Most
|
|
yuuji@0
|
893 commonly, clients with a "trash folder" model of message deletion
|
|
yuuji@0
|
894 want to create a mailbox with the name "Trash" or "Deleted". Some
|
|
yuuji@0
|
895
|
|
yuuji@0
|
896
|
|
yuuji@0
|
897
|
|
yuuji@0
|
898 Leiba Informational [Page 16]
|
|
yuuji@0
|
899
|
|
yuuji@0
|
900 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
901
|
|
yuuji@0
|
902
|
|
yuuji@0
|
903 clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
|
|
yuuji@0
|
904 "Sent Mail" mailbox. And so on. There are two major
|
|
yuuji@0
|
905 interoperability problems with this practice:
|
|
yuuji@0
|
906
|
|
yuuji@0
|
907 1. different clients may use different names for mailboxes with
|
|
yuuji@0
|
908 similar functions (such as "Trash" and "Deleted"), or may manage
|
|
yuuji@0
|
909 the same mailboxes in different ways, causing problems if a user
|
|
yuuji@0
|
910 switches between clients and
|
|
yuuji@0
|
911 2. there is no guarantee that the server will allow the creation of
|
|
yuuji@0
|
912 the desired mailbox.
|
|
yuuji@0
|
913
|
|
yuuji@0
|
914 The client developer is, therefore, well advised to consider
|
|
yuuji@0
|
915 carefully the creation of any special-use mailboxes on the server,
|
|
yuuji@0
|
916 and, further, the client must not require such mailbox creation -
|
|
yuuji@0
|
917 that is, if you do decide to do this, you must handle gracefully the
|
|
yuuji@0
|
918 failure of the CREATE command and behave reasonably when your
|
|
yuuji@0
|
919 special-use mailboxes do not exist and can not be created.
|
|
yuuji@0
|
920
|
|
yuuji@0
|
921 In addition, the client developer should provide a convenient way for
|
|
yuuji@0
|
922 the user to select the names for any special-use mailboxes, allowing
|
|
yuuji@0
|
923 the user to make these names the same in all clients used and to put
|
|
yuuji@0
|
924 them where the user wants them.
|
|
yuuji@0
|
925
|
|
yuuji@0
|
926 3.4.9. Reference Names in the LIST Command
|
|
yuuji@0
|
927
|
|
yuuji@0
|
928 Many implementers of both clients and servers are confused by the
|
|
yuuji@0
|
929 "reference name" on the LIST command. The reference name is intended
|
|
yuuji@0
|
930 to be used in much the way a "cd" (change directory) command is used
|
|
yuuji@0
|
931 on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox
|
|
yuuji@0
|
932 name is interpreted in much the same way as a file of that name would
|
|
yuuji@0
|
933 be found if one had done a "cd" command into the directory specified
|
|
yuuji@0
|
934 by the reference name. For example, in Unix we have the following:
|
|
yuuji@0
|
935
|
|
yuuji@0
|
936 > cd /u/jones/junk
|
|
yuuji@0
|
937 > vi banana [file is "/u/jones/junk/banana"]
|
|
yuuji@0
|
938 > vi stuff/banana [file is "/u/jones/junk/stuff/banana"]
|
|
yuuji@0
|
939 > vi /etc/hosts [file is "/etc/hosts"]
|
|
yuuji@0
|
940
|
|
yuuji@0
|
941 In the past, there have been several interoperability problems with
|
|
yuuji@0
|
942 this. First, while some IMAP servers are built on Unix or PC file
|
|
yuuji@0
|
943 systems, many others are not, and the file system semantics do not
|
|
yuuji@0
|
944 make sense in those configurations. Second, while some IMAP servers
|
|
yuuji@0
|
945 expose the underlying file system to the clients, others allow access
|
|
yuuji@0
|
946 only to the user's personal mailboxes, or to some other limited set
|
|
yuuji@0
|
947 of files, making such file-system-like semantics less meaningful.
|
|
yuuji@0
|
948 Third, because the IMAP spec leaves the interpretation of the
|
|
yuuji@0
|
949 reference name as "implementation-dependent", in the past the various
|
|
yuuji@0
|
950 server implementations handled it in vastly differing ways.
|
|
yuuji@0
|
951
|
|
yuuji@0
|
952
|
|
yuuji@0
|
953
|
|
yuuji@0
|
954 Leiba Informational [Page 17]
|
|
yuuji@0
|
955
|
|
yuuji@0
|
956 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
957
|
|
yuuji@0
|
958
|
|
yuuji@0
|
959 The following recommendations are the result of significant
|
|
yuuji@0
|
960 operational experience, and are intended to maximize
|
|
yuuji@0
|
961 interoperability.
|
|
yuuji@0
|
962
|
|
yuuji@0
|
963 Server implementations must implement the reference argument in a way
|
|
yuuji@0
|
964 that matches the intended "change directory" operation as closely as
|
|
yuuji@0
|
965 possible. As a minimum implementation, the reference argument may be
|
|
yuuji@0
|
966 prepended to the mailbox name (while suppressing double delimiters;
|
|
yuuji@0
|
967 see the next paragraph). Even servers that do not provide a way to
|
|
yuuji@0
|
968 break out of the current hierarchy (see "breakout facility" below)
|
|
yuuji@0
|
969 must provide a reasonable implementation of the reference argument,
|
|
yuuji@0
|
970 as described here, so that they will interoperate with clients that
|
|
yuuji@0
|
971 use it.
|
|
yuuji@0
|
972
|
|
yuuji@0
|
973 Server implementations that prepend the reference argument to the
|
|
yuuji@0
|
974 mailbox name should insert a hierarchy delimiter between them, and
|
|
yuuji@0
|
975 must not insert a second if one is already present:
|
|
yuuji@0
|
976
|
|
yuuji@0
|
977 C: A001 LIST ABC DEF
|
|
yuuji@0
|
978 S: * LIST () "/" ABC/DEF <=== should do this
|
|
yuuji@0
|
979 S: A001 OK done
|
|
yuuji@0
|
980
|
|
yuuji@0
|
981 C: A002 LIST ABC/ /DEF
|
|
yuuji@0
|
982 S: * LIST () "/" ABC//DEF <=== must not do this
|
|
yuuji@0
|
983 S: A002 OK done
|
|
yuuji@0
|
984
|
|
yuuji@0
|
985 On clients, the reference argument is chiefly used to implement a
|
|
yuuji@0
|
986 "breakout facility", wherein the user may directly access a mailbox
|
|
yuuji@0
|
987 outside the "current directory" hierarchy. Client implementations
|
|
yuuji@0
|
988 should have an operational mode that does not use the reference
|
|
yuuji@0
|
989 argument. This is to interoperate with older servers that did not
|
|
yuuji@0
|
990 implement the reference argument properly. While it's a good idea to
|
|
yuuji@0
|
991 give the user access to a breakout facility, clients that do not
|
|
yuuji@0
|
992 intend to do so should not use the reference argument at all.
|
|
yuuji@0
|
993
|
|
yuuji@0
|
994 Client implementations should always place a trailing hierarchy
|
|
yuuji@0
|
995 delimiter on the reference argument. This is because some servers
|
|
yuuji@0
|
996 prepend the reference argument to the mailbox name without inserting
|
|
yuuji@0
|
997 a hierarchy delimiter, while others do insert a hierarchy delimiter
|
|
yuuji@0
|
998 if one is not already present. A client that puts the delimiter in
|
|
yuuji@0
|
999 will work with both varieties of server.
|
|
yuuji@0
|
1000
|
|
yuuji@0
|
1001 Client implementations that implement a breakout facility should
|
|
yuuji@0
|
1002 allow the user to choose whether or not to use a leading hierarchy
|
|
yuuji@0
|
1003 delimiter on the mailbox argument. This is because the handling of a
|
|
yuuji@0
|
1004 leading mailbox hierarchy delimiter also varies from server to
|
|
yuuji@0
|
1005 server, and even between different mailstores on the same server. In
|
|
yuuji@0
|
1006 some cases, a leading hierarchy delimiter means "discard the
|
|
yuuji@0
|
1007
|
|
yuuji@0
|
1008
|
|
yuuji@0
|
1009
|
|
yuuji@0
|
1010 Leiba Informational [Page 18]
|
|
yuuji@0
|
1011
|
|
yuuji@0
|
1012 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
1013
|
|
yuuji@0
|
1014
|
|
yuuji@0
|
1015 reference argument" (implementing the intended breakout facility),
|
|
yuuji@0
|
1016 thus:
|
|
yuuji@0
|
1017
|
|
yuuji@0
|
1018 C: A001 LIST ABC/ /DEF
|
|
yuuji@0
|
1019 S: * LIST () "/" /DEF
|
|
yuuji@0
|
1020 S: A001 OK done
|
|
yuuji@0
|
1021
|
|
yuuji@0
|
1022 In other cases, however, the two are catenated and the extra
|
|
yuuji@0
|
1023 hierarchy delimiter is discarded, thus:
|
|
yuuji@0
|
1024
|
|
yuuji@0
|
1025 C: A001 LIST ABC/ /DEF
|
|
yuuji@0
|
1026 S: * LIST () "/" ABC/DEF
|
|
yuuji@0
|
1027 S: A001 OK done
|
|
yuuji@0
|
1028
|
|
yuuji@0
|
1029 Client implementations must not assume that the server supports a
|
|
yuuji@0
|
1030 breakout facility, but may provide a way for the user to use one if
|
|
yuuji@0
|
1031 it is available. Any breakout facility should be exported to the
|
|
yuuji@0
|
1032 user interface. Note that there may be other "breakout" characters
|
|
yuuji@0
|
1033 besides the hierarchy delimiter (for instance, UNIX filesystem
|
|
yuuji@0
|
1034 servers are likely to use a leading "~" as well), and that their
|
|
yuuji@0
|
1035 interpretation is server-dependent.
|
|
yuuji@0
|
1036
|
|
yuuji@0
|
1037 3.4.10. Mailbox Hierarchy Delimiters
|
|
yuuji@0
|
1038
|
|
yuuji@0
|
1039 The server's selection of what to use as a mailbox hierarchy
|
|
yuuji@0
|
1040 delimiter is a difficult one, involving several issues: What
|
|
yuuji@0
|
1041 characters do users expect to see? What characters can they enter
|
|
yuuji@0
|
1042 for a hierarchy delimiter if it is desired (or required) that the
|
|
yuuji@0
|
1043 user enter it? What character can be used for the hierarchy
|
|
yuuji@0
|
1044 delimiter, noting that the chosen character can not otherwise be used
|
|
yuuji@0
|
1045 in the mailbox name?
|
|
yuuji@0
|
1046
|
|
yuuji@0
|
1047 Because some interfaces show users the hierarchy delimiters or allow
|
|
yuuji@0
|
1048 users to enter qualified mailbox names containing them, server
|
|
yuuji@0
|
1049 implementations should use delimiter characters that users generally
|
|
yuuji@0
|
1050 expect to see as name separators. The most common characters used
|
|
yuuji@0
|
1051 for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
|
|
yuuji@0
|
1052 file names), and "." (as in news groups). There is little to choose
|
|
yuuji@0
|
1053 among these apart from what users may expect or what is dictated by
|
|
yuuji@0
|
1054 the underlying file system, if any. One consideration about using
|
|
yuuji@0
|
1055 "\" is that it's also a special character in the IMAP protocol. While
|
|
yuuji@0
|
1056 the use of other hierarchy delimiter characters is permissible, A
|
|
yuuji@0
|
1057 DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
|
|
yuuji@0
|
1058 server is intended for special purposes only. Implementers might be
|
|
yuuji@0
|
1059 thinking about using characters such as "-", "_", ";", "&", "#", "@",
|
|
yuuji@0
|
1060 and "!", but they should be aware of the surprise to the user as well
|
|
yuuji@0
|
1061 as of the effect on URLs and other external specifications (since
|
|
yuuji@0
|
1062 some of these characters have special meanings there). Also, a
|
|
yuuji@0
|
1063
|
|
yuuji@0
|
1064
|
|
yuuji@0
|
1065
|
|
yuuji@0
|
1066 Leiba Informational [Page 19]
|
|
yuuji@0
|
1067
|
|
yuuji@0
|
1068 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
1069
|
|
yuuji@0
|
1070
|
|
yuuji@0
|
1071 server that uses "\" (and clients of such a server) must remember to
|
|
yuuji@0
|
1072 escape that character in quoted strings or to send literals instead.
|
|
yuuji@0
|
1073 Literals are recommended over escaped characters in quoted strings in
|
|
yuuji@0
|
1074 order to maintain compatibility with older IMAP versions that did not
|
|
yuuji@0
|
1075 allow escaped characters in quoted strings (but check the grammar to
|
|
yuuji@0
|
1076 see where literals are allowed):
|
|
yuuji@0
|
1077
|
|
yuuji@0
|
1078 C: 001 LIST "" {13}
|
|
yuuji@0
|
1079 S: + send literal
|
|
yuuji@0
|
1080 C: this\%\%\%\h*
|
|
yuuji@0
|
1081 S: * LIST () "\\" {27}
|
|
yuuji@0
|
1082 S: this\is\a\mailbox\hierarchy
|
|
yuuji@0
|
1083 S: 001 OK LIST complete
|
|
yuuji@0
|
1084
|
|
yuuji@0
|
1085 In any case, a server should not use normal alpha-numeric characters
|
|
yuuji@0
|
1086 (such as "X" or "0") as delimiters; a user would be very surprised to
|
|
yuuji@0
|
1087 find that "EXPENDITURES" actually represented a two-level hierarchy.
|
|
yuuji@0
|
1088 And a server should not use characters that are non-printable or
|
|
yuuji@0
|
1089 difficult or impossible to enter on a standard US keyboard. Control
|
|
yuuji@0
|
1090 characters, box-drawing characters, and characters from non-US
|
|
yuuji@0
|
1091 alphabets fit into this category. Their use presents
|
|
yuuji@0
|
1092 interoperability problems that are best avoided.
|
|
yuuji@0
|
1093
|
|
yuuji@0
|
1094 The UTF-7 encoding of mailbox names also raises questions about what
|
|
yuuji@0
|
1095 to do with the hierarchy delimiters in encoded names: do we encode
|
|
yuuji@0
|
1096 each hierarchy level and separate them with delimiters, or do we
|
|
yuuji@0
|
1097 encode the fully qualified name, delimiters and all? The answer for
|
|
yuuji@0
|
1098 IMAP is the former: encode each hierarchy level separately, and
|
|
yuuji@0
|
1099 insert delimiters between. This makes it particularly important not
|
|
yuuji@0
|
1100 to use as a hierarchy delimiter a character that might cause
|
|
yuuji@0
|
1101 confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
|
|
yuuji@0
|
1102
|
|
yuuji@0
|
1103 To repeat: a server should use "/", "\", or "." as its hierarchy
|
|
yuuji@0
|
1104 delimiter. The use of any other character is likely to cause
|
|
yuuji@0
|
1105 problems and is STRONGLY DISCOURAGED.
|
|
yuuji@0
|
1106
|
|
yuuji@0
|
1107 3.4.11. ALERT Response Codes
|
|
yuuji@0
|
1108
|
|
yuuji@0
|
1109 The protocol spec is very clear on the matter of what to do with
|
|
yuuji@0
|
1110 ALERT response codes, and yet there are many clients that violate it
|
|
yuuji@0
|
1111 so it needs to be said anyway: "The human-readable text contains a
|
|
yuuji@0
|
1112 special alert that must be presented to the user in a fashion that
|
|
yuuji@0
|
1113 calls the user's attention to the message." That should be clear
|
|
yuuji@0
|
1114 enough, but I'll repeat it here: Clients must present ALERT text
|
|
yuuji@0
|
1115 clearly to the user.
|
|
yuuji@0
|
1116
|
|
yuuji@0
|
1117
|
|
yuuji@0
|
1118
|
|
yuuji@0
|
1119
|
|
yuuji@0
|
1120
|
|
yuuji@0
|
1121
|
|
yuuji@0
|
1122 Leiba Informational [Page 20]
|
|
yuuji@0
|
1123
|
|
yuuji@0
|
1124 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
1125
|
|
yuuji@0
|
1126
|
|
yuuji@0
|
1127 3.4.12. Deleting Mailboxes
|
|
yuuji@0
|
1128
|
|
yuuji@0
|
1129 The protocol does not guarantee that a client may delete a mailbox
|
|
yuuji@0
|
1130 that is not empty, though on some servers it is permissible and is,
|
|
yuuji@0
|
1131 in fact, much faster than the alternative or deleting all the
|
|
yuuji@0
|
1132 messages from the client. If the client chooses to try to take
|
|
yuuji@0
|
1133 advantage of this possibility it must be prepared to use the other
|
|
yuuji@0
|
1134 method in the even that the more convenient one fails. Further, a
|
|
yuuji@0
|
1135 client should not try to delete the mailbox that it has selected, but
|
|
yuuji@0
|
1136 should first close that mailbox; some servers do not permit the
|
|
yuuji@0
|
1137 deletion of the selected mailbox.
|
|
yuuji@0
|
1138
|
|
yuuji@0
|
1139 That said, a server should permit the deletion of a non-empty
|
|
yuuji@0
|
1140 mailbox; there's little reason to pass this work on to the client.
|
|
yuuji@0
|
1141 Moreover, forbidding this prevents the deletion of a mailbox that for
|
|
yuuji@0
|
1142 some reason can not be opened or expunged, leading to possible
|
|
yuuji@0
|
1143 denial-of-service problems.
|
|
yuuji@0
|
1144
|
|
yuuji@0
|
1145 Example:
|
|
yuuji@0
|
1146
|
|
yuuji@0
|
1147 [User tells the client to delete mailbox BANANA, which is
|
|
yuuji@0
|
1148 currently selected...]
|
|
yuuji@0
|
1149 C: 008 CLOSE
|
|
yuuji@0
|
1150 S: 008 OK done
|
|
yuuji@0
|
1151 C: 009 DELETE BANANA
|
|
yuuji@0
|
1152 S: 009 NO Delete failed; mailbox is not empty.
|
|
yuuji@0
|
1153 C: 010 SELECT BANANA
|
|
yuuji@0
|
1154 S: * ... untagged SELECT responses
|
|
yuuji@0
|
1155 S: 010 OK done
|
|
yuuji@0
|
1156 C: 011 STORE 1:* +FLAGS.SILENT \DELETED
|
|
yuuji@0
|
1157 S: 011 OK done
|
|
yuuji@0
|
1158 C: 012 CLOSE
|
|
yuuji@0
|
1159 S: 012 OK done
|
|
yuuji@0
|
1160 C: 013 DELETE BANANA
|
|
yuuji@0
|
1161 S: 013 OK done
|
|
yuuji@0
|
1162
|
|
yuuji@0
|
1163 3.5. A Word About Testing
|
|
yuuji@0
|
1164
|
|
yuuji@0
|
1165 Since the whole point of IMAP is interoperability, and since
|
|
yuuji@0
|
1166 interoperability can not be tested in a vacuum, the final
|
|
yuuji@0
|
1167 recommendation of this treatise is, "Test against EVERYTHING." Test
|
|
yuuji@0
|
1168 your client against every server you can get an account on. Test
|
|
yuuji@0
|
1169 your server with every client you can get your hands on. Many
|
|
yuuji@0
|
1170 clients make limited test versions available on the Web for the
|
|
yuuji@0
|
1171 downloading. Many server owners will give serious client developers
|
|
yuuji@0
|
1172 guest accounts for testing. Contact them and ask. NEVER assume that
|
|
yuuji@0
|
1173 because your client works with one or two servers, or because your
|
|
yuuji@0
|
1174 server does fine with one or two clients, you will interoperate well
|
|
yuuji@0
|
1175
|
|
yuuji@0
|
1176
|
|
yuuji@0
|
1177
|
|
yuuji@0
|
1178 Leiba Informational [Page 21]
|
|
yuuji@0
|
1179
|
|
yuuji@0
|
1180 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
1181
|
|
yuuji@0
|
1182
|
|
yuuji@0
|
1183 in general.
|
|
yuuji@0
|
1184
|
|
yuuji@0
|
1185 In particular, in addition to everything else, be sure to test
|
|
yuuji@0
|
1186 against the reference implementations: the PINE client, the
|
|
yuuji@0
|
1187 University of Washington server, and the Cyrus server.
|
|
yuuji@0
|
1188
|
|
yuuji@0
|
1189 See the following URLs on the web for more information here:
|
|
yuuji@0
|
1190
|
|
yuuji@0
|
1191 IMAP Products and Sources: http://www.imap.org/products.html
|
|
yuuji@0
|
1192 IMC MailConnect: http://www.imc.org/imc-mailconnect
|
|
yuuji@0
|
1193
|
|
yuuji@0
|
1194 4. Security Considerations
|
|
yuuji@0
|
1195
|
|
yuuji@0
|
1196 This document describes behaviour of clients and servers that use the
|
|
yuuji@0
|
1197 IMAP4 protocol, and as such, has the same security considerations as
|
|
yuuji@0
|
1198 described in [RFC-2060].
|
|
yuuji@0
|
1199
|
|
yuuji@0
|
1200 5. References
|
|
yuuji@0
|
1201
|
|
yuuji@0
|
1202 [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
|
|
yuuji@0
|
1203 4rev1", RFC 2060, December 1996.
|
|
yuuji@0
|
1204
|
|
yuuji@0
|
1205 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
1206 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yuuji@0
|
1207
|
|
yuuji@0
|
1208 [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
|
|
yuuji@0
|
1209 2180, July 1997.
|
|
yuuji@0
|
1210
|
|
yuuji@0
|
1211 [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode
|
|
yuuji@0
|
1212 and ISO 10646", RFC 2044, October 1996.
|
|
yuuji@0
|
1213
|
|
yuuji@0
|
1214 [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
|
|
yuuji@0
|
1215 Transformation Format of Unicode", RFC 2152, May 1997.
|
|
yuuji@0
|
1216
|
|
yuuji@0
|
1217 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
|
|
yuuji@0
|
1218 Progress.
|
|
yuuji@0
|
1219
|
|
yuuji@0
|
1220 6. Author's Address
|
|
yuuji@0
|
1221
|
|
yuuji@0
|
1222 Barry Leiba
|
|
yuuji@0
|
1223 IBM T.J. Watson Research Center
|
|
yuuji@0
|
1224 30 Saw Mill River Road
|
|
yuuji@0
|
1225 Hawthorne, NY 10532
|
|
yuuji@0
|
1226
|
|
yuuji@0
|
1227 Phone: 1-914-784-7941
|
|
yuuji@0
|
1228 EMail: leiba@watson.ibm.com
|
|
yuuji@0
|
1229
|
|
yuuji@0
|
1230
|
|
yuuji@0
|
1231
|
|
yuuji@0
|
1232
|
|
yuuji@0
|
1233
|
|
yuuji@0
|
1234 Leiba Informational [Page 22]
|
|
yuuji@0
|
1235
|
|
yuuji@0
|
1236 RFC 2683 IMAP4 Implementation Recommendations September 1999
|
|
yuuji@0
|
1237
|
|
yuuji@0
|
1238
|
|
yuuji@0
|
1239 7. Full Copyright Statement
|
|
yuuji@0
|
1240
|
|
yuuji@0
|
1241 Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|
yuuji@0
|
1242
|
|
yuuji@0
|
1243 This document and translations of it may be copied and furnished to
|
|
yuuji@0
|
1244 others, and derivative works that comment on or otherwise explain it
|
|
yuuji@0
|
1245 or assist in its implementation may be prepared, copied, published
|
|
yuuji@0
|
1246 and distributed, in whole or in part, without restriction of any
|
|
yuuji@0
|
1247 kind, provided that the above copyright notice and this paragraph are
|
|
yuuji@0
|
1248 included on all such copies and derivative works. However, this
|
|
yuuji@0
|
1249 document itself may not be modified in any way, such as by removing
|
|
yuuji@0
|
1250 the copyright notice or references to the Internet Society or other
|
|
yuuji@0
|
1251 Internet organizations, except as needed for the purpose of
|
|
yuuji@0
|
1252 developing Internet standards in which case the procedures for
|
|
yuuji@0
|
1253 copyrights defined in the Internet Standards process must be
|
|
yuuji@0
|
1254 followed, or as required to translate it into languages other than
|
|
yuuji@0
|
1255 English.
|
|
yuuji@0
|
1256
|
|
yuuji@0
|
1257 The limited permissions granted above are perpetual and will not be
|
|
yuuji@0
|
1258 revoked by the Internet Society or its successors or assigns.
|
|
yuuji@0
|
1259
|
|
yuuji@0
|
1260 This document and the information contained herein is provided on an
|
|
yuuji@0
|
1261 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
yuuji@0
|
1262 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
yuuji@0
|
1263 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
yuuji@0
|
1264 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
yuuji@0
|
1265 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yuuji@0
|
1266
|
|
yuuji@0
|
1267 Acknowledgement
|
|
yuuji@0
|
1268
|
|
yuuji@0
|
1269 Funding for the RFC Editor function is currently provided by the
|
|
yuuji@0
|
1270 Internet Society.
|
|
yuuji@0
|
1271
|
|
yuuji@0
|
1272
|
|
yuuji@0
|
1273
|
|
yuuji@0
|
1274
|
|
yuuji@0
|
1275
|
|
yuuji@0
|
1276
|
|
yuuji@0
|
1277
|
|
yuuji@0
|
1278
|
|
yuuji@0
|
1279
|
|
yuuji@0
|
1280
|
|
yuuji@0
|
1281
|
|
yuuji@0
|
1282
|
|
yuuji@0
|
1283
|
|
yuuji@0
|
1284
|
|
yuuji@0
|
1285
|
|
yuuji@0
|
1286
|
|
yuuji@0
|
1287
|
|
yuuji@0
|
1288
|
|
yuuji@0
|
1289
|
|
yuuji@0
|
1290 Leiba Informational [Page 23]
|
|
yuuji@0
|
1291
|
