| 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. Gahrns
|
|
yuuji@0
|
8 Request for Comments: 2193 Microsoft
|
|
yuuji@0
|
9 Category: Standards Track September 1997
|
|
yuuji@0
|
10
|
|
yuuji@0
|
11
|
|
yuuji@0
|
12 IMAP4 Mailbox Referrals
|
|
yuuji@0
|
13
|
|
yuuji@0
|
14 Status of this Memo
|
|
yuuji@0
|
15
|
|
yuuji@0
|
16 This document specifies an Internet standards track protocol for the
|
|
yuuji@0
|
17 Internet community, and requests discussion and suggestions for
|
|
yuuji@0
|
18 improvements. Please refer to the current edition of the "Internet
|
|
yuuji@0
|
19 Official Protocol Standards" (STD 1) for the standardization state
|
|
yuuji@0
|
20 and status of this protocol. Distribution of this memo is unlimited.
|
|
yuuji@0
|
21
|
|
yuuji@0
|
22 1. Abstract
|
|
yuuji@0
|
23
|
|
yuuji@0
|
24 When dealing with large amounts of users, messages and geographically
|
|
yuuji@0
|
25 dispersed IMAP4 [RFC-2060] servers, it is often desirable to
|
|
yuuji@0
|
26 distribute messages amongst different servers within an organization.
|
|
yuuji@0
|
27 For example an administrator may choose to store user's personal
|
|
yuuji@0
|
28 mailboxes on a local IMAP4 server, while storing shared mailboxes
|
|
yuuji@0
|
29 remotely on another server. This type of configuration is common
|
|
yuuji@0
|
30 when it is uneconomical to store all data centrally due to limited
|
|
yuuji@0
|
31 bandwidth or disk resources.
|
|
yuuji@0
|
32
|
|
yuuji@0
|
33 Mailbox referrals allow clients to seamlessly access mailboxes that
|
|
yuuji@0
|
34 are distributed across several IMAP4 servers.
|
|
yuuji@0
|
35
|
|
yuuji@0
|
36 A referral mechanism can provide efficiencies over the alternative
|
|
yuuji@0
|
37 "proxy method", in which the local IMAP4 server contacts the remote
|
|
yuuji@0
|
38 server on behalf of the client, and then transfers the data from the
|
|
yuuji@0
|
39 remote server to itself, and then on to the client. The referral
|
|
yuuji@0
|
40 mechanism's direct client connection to the remote server is often a
|
|
yuuji@0
|
41 more efficient use of bandwidth, and does not require the local
|
|
yuuji@0
|
42 server to impersonate the client when authenticating to the remote
|
|
yuuji@0
|
43 server.
|
|
yuuji@0
|
44
|
|
yuuji@0
|
45 2. Conventions used in this document
|
|
yuuji@0
|
46
|
|
yuuji@0
|
47 In examples, "C:" and "S:" indicate lines sent by the client and
|
|
yuuji@0
|
48 server respectively.
|
|
yuuji@0
|
49
|
|
yuuji@0
|
50 A home server, is an IMAP4 server that contains the user's inbox.
|
|
yuuji@0
|
51
|
|
yuuji@0
|
52 A remote mailbox is a mailbox that is not hosted on the user's home
|
|
yuuji@0
|
53 server.
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Gahrns Standards Track [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 A remote server is a server that contains remote mailboxes.
|
|
yuuji@0
|
64
|
|
yuuji@0
|
65 A shared mailbox, is a mailbox that multiple users have access to.
|
|
yuuji@0
|
66
|
|
yuuji@0
|
67 An IMAP mailbox referral is when the server directs the client to
|
|
yuuji@0
|
68 another IMAP mailbox.
|
|
yuuji@0
|
69
|
|
yuuji@0
|
70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
yuuji@0
|
71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
yuuji@0
|
72 document are to be interpreted as described in [RFC-2119].
|
|
yuuji@0
|
73
|
|
yuuji@0
|
74 3. Introduction and Overview
|
|
yuuji@0
|
75
|
|
yuuji@0
|
76 IMAP4 servers that support this extension MUST list the keyword
|
|
yuuji@0
|
77 MAILBOX-REFERRALS in their CAPABILITY response. No client action is
|
|
yuuji@0
|
78 needed to invoke the MAILBOX-REFERRALS capability in a server.
|
|
yuuji@0
|
79
|
|
yuuji@0
|
80 A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals
|
|
yuuji@0
|
81 that result in a referrals loop.
|
|
yuuji@0
|
82
|
|
yuuji@0
|
83 A referral response consists of a tagged NO response and a REFERRAL
|
|
yuuji@0
|
84 response code. The REFERRAL response code MUST contain as an
|
|
yuuji@0
|
85 argument a one or more valid URLs separated by a space as defined in
|
|
yuuji@0
|
86 [RFC-1738]. If a server replies with multiple URLs for a particular
|
|
yuuji@0
|
87 object, they MUST all be of the same type. In this case, the URL MUST
|
|
yuuji@0
|
88 be an IMAP URL as defined in [RFC-2192]. A client that supports the
|
|
yuuji@0
|
89 REFERRALS extension MUST be prepared for a URL of any type, but it
|
|
yuuji@0
|
90 need only be able to process IMAP URLs.
|
|
yuuji@0
|
91
|
|
yuuji@0
|
92 A server MAY respond with multiple IMAP mailbox referrals if there is
|
|
yuuji@0
|
93 more than one replica of the mailbox. This allows the implementation
|
|
yuuji@0
|
94 of a load balancing or failover scheme. How a server keeps multiple
|
|
yuuji@0
|
95 replicas of a mailbox in sync is not addressed by this document.
|
|
yuuji@0
|
96
|
|
yuuji@0
|
97 If the server has a preferred order in which the client should
|
|
yuuji@0
|
98 attempt to access the URLs, the preferred URL SHOULD be listed in the
|
|
yuuji@0
|
99 first, with the remaining URLs presented in descending order of
|
|
yuuji@0
|
100 preference. If multiple referrals are given for a mailbox, a server
|
|
yuuji@0
|
101 should be aware that there are synchronization issues for a client if
|
|
yuuji@0
|
102 the UIDVALIDITY of the referred mailboxes are different.
|
|
yuuji@0
|
103
|
|
yuuji@0
|
104 An IMAP mailbox referral may be given in response to an IMAP command
|
|
yuuji@0
|
105 that specifies a mailbox as an argument.
|
|
yuuji@0
|
106
|
|
yuuji@0
|
107
|
|
yuuji@0
|
108
|
|
yuuji@0
|
109
|
|
yuuji@0
|
110
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Gahrns Standards Track [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 Example:
|
|
yuuji@0
|
120
|
|
yuuji@0
|
121 A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox
|
|
yuuji@0
|
122
|
|
yuuji@0
|
123 NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a
|
|
yuuji@0
|
124 client falling back to anonymous login.
|
|
yuuji@0
|
125
|
|
yuuji@0
|
126 Remote mailboxes and their inferiors, that are accessible only via
|
|
yuuji@0
|
127 referrals SHOULD NOT appear in LIST and LSUB responses issued against
|
|
yuuji@0
|
128 the user's home server. They MUST appear in RLIST and RLSUB
|
|
yuuji@0
|
129 responses issued against the user's home server. Hierarchy referrals,
|
|
yuuji@0
|
130 in which a client would be required to connect to the remote server
|
|
yuuji@0
|
131 to issue a LIST to discover the inferiors of a mailbox are not
|
|
yuuji@0
|
132 addressed in this document.
|
|
yuuji@0
|
133
|
|
yuuji@0
|
134 For example, if shared mailboxes were only accessible via referrals
|
|
yuuji@0
|
135 on a remote server, a RLIST "" "#SHARED/%" command would return the
|
|
yuuji@0
|
136 same response if issued against the user's home server or the remote
|
|
yuuji@0
|
137 server.
|
|
yuuji@0
|
138
|
|
yuuji@0
|
139 Note: Mailboxes that are available on the user's home server do not
|
|
yuuji@0
|
140 need to be available on the remote server. In addition, there may be
|
|
yuuji@0
|
141 additional mailboxes available on the remote server, but they will
|
|
yuuji@0
|
142 not accessible to the client via referrals unless they appear in the
|
|
yuuji@0
|
143 LIST response to the RLIST command against the user's home server.
|
|
yuuji@0
|
144
|
|
yuuji@0
|
145 A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB
|
|
yuuji@0
|
146 commands in lieu of LIST and LSUB. The RLIST and RLSUB commands
|
|
yuuji@0
|
147 behave identically to their LIST and LSUB counterparts, except remote
|
|
yuuji@0
|
148 mailboxes are returned in addition to local mailboxes in the LIST and
|
|
yuuji@0
|
149 LSUB responses. This avoids displaying to a non MAILBOX-REFERRALS
|
|
yuuji@0
|
150 enabled client inaccessible remote mailboxes.
|
|
yuuji@0
|
151
|
|
yuuji@0
|
152 4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND
|
|
yuuji@0
|
153 Referrals
|
|
yuuji@0
|
154
|
|
yuuji@0
|
155 An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE,
|
|
yuuji@0
|
156 SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more
|
|
yuuji@0
|
157 IMAP mailbox referrals to indicate to the client that the mailbox is
|
|
yuuji@0
|
158 hosted on a remote server.
|
|
yuuji@0
|
159
|
|
yuuji@0
|
160 When a client processes an IMAP mailbox referral, it will open a new
|
|
yuuji@0
|
161 connection or use an existing connection to the remote server so that
|
|
yuuji@0
|
162 it is able to issue the commands necessary to process the remote
|
|
yuuji@0
|
163 mailbox.
|
|
yuuji@0
|
164
|
|
yuuji@0
|
165
|
|
yuuji@0
|
166
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Gahrns Standards Track [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 Example: <IMAP4 connection to home server>
|
|
yuuji@0
|
176
|
|
yuuji@0
|
177 C: A001 DELETE "SHARED/FOO"
|
|
yuuji@0
|
178 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
|
|
yuuji@0
|
179 Remote mailbox. Try SERVER2.
|
|
yuuji@0
|
180
|
|
yuuji@0
|
181 <Client established a second connection to SERVER2 and
|
|
yuuji@0
|
182 issues the DELETE command on the referred mailbox>
|
|
yuuji@0
|
183
|
|
yuuji@0
|
184 S: * OK IMAP4rev1 server ready
|
|
yuuji@0
|
185 C: B001 AUTHENTICATE KERBEROS_V4
|
|
yuuji@0
|
186 <authentication exchange>
|
|
yuuji@0
|
187 S: B001 OK user is authenticated
|
|
yuuji@0
|
188
|
|
yuuji@0
|
189 C: B002 DELETE "SHARED/FOO"
|
|
yuuji@0
|
190 S: B002 OK DELETE completed
|
|
yuuji@0
|
191
|
|
yuuji@0
|
192 Example: <IMAP4 connection to home server>
|
|
yuuji@0
|
193
|
|
yuuji@0
|
194 C: A001 SELECT REMOTE
|
|
yuuji@0
|
195 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE
|
|
yuuji@0
|
196 IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox.
|
|
yuuji@0
|
197 Try SERVER2 or SERVER3.
|
|
yuuji@0
|
198
|
|
yuuji@0
|
199 <Client opens second connection to remote server, and
|
|
yuuji@0
|
200 issues the commands needed to process the items in the
|
|
yuuji@0
|
201 remote mailbox>
|
|
yuuji@0
|
202
|
|
yuuji@0
|
203 S: * OK IMAP4rev1 server ready
|
|
yuuji@0
|
204 C: B001 AUTHENTICATE KERBEROS_V4
|
|
yuuji@0
|
205 <authentication exchange>
|
|
yuuji@0
|
206 S: B001 OK user is authenticated
|
|
yuuji@0
|
207
|
|
yuuji@0
|
208 C: B002 SELECT REMOTE
|
|
yuuji@0
|
209 S: * 12 EXISTS
|
|
yuuji@0
|
210 S: * 1 RECENT
|
|
yuuji@0
|
211 S: * OK [UNSEEN 10] Message 10 is first unseen
|
|
yuuji@0
|
212 S: * OK [UIDVALIDITY 123456789]
|
|
yuuji@0
|
213 S: * FLAGS (Answered Flagged Deleted Seen Draft)
|
|
yuuji@0
|
214 S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
|
|
yuuji@0
|
215 S: B002 OK [READ-WRITE] Selected completed
|
|
yuuji@0
|
216
|
|
yuuji@0
|
217 C: B003 FETCH 10:12 RFC822
|
|
yuuji@0
|
218 S: * 10 FETCH . . .
|
|
yuuji@0
|
219 S: * 11 FETCH . . .
|
|
yuuji@0
|
220 S: * 12 FETCH . . .
|
|
yuuji@0
|
221 S: B003 OK FETCH Completed
|
|
yuuji@0
|
222
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Gahrns Standards Track [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 <Client is finished processing the REMOTE mailbox and
|
|
yuuji@0
|
232 wants to process a mailbox on its home server>
|
|
yuuji@0
|
233
|
|
yuuji@0
|
234 C: B004 LOGOUT
|
|
yuuji@0
|
235 S: * BYE IMAP4rev1 server logging out
|
|
yuuji@0
|
236 S: B004 OK LOGOUT Completed
|
|
yuuji@0
|
237
|
|
yuuji@0
|
238 <Client continues with first connection>
|
|
yuuji@0
|
239
|
|
yuuji@0
|
240 C: A002 SELECT INBOX
|
|
yuuji@0
|
241 S: * 16 EXISTS
|
|
yuuji@0
|
242 S: * 2 RECENT
|
|
yuuji@0
|
243 S: * OK [UNSEEN 10] Message 10 is first unseen
|
|
yuuji@0
|
244 S: * OK [UIDVALIDITY 123456789]
|
|
yuuji@0
|
245 S: * FLAGS (Answered Flagged Deleted Seen Draft)
|
|
yuuji@0
|
246 S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
|
|
yuuji@0
|
247 S: A002 OK [READ-WRITE] Selected completed
|
|
yuuji@0
|
248
|
|
yuuji@0
|
249 4.2. CREATE Referrals
|
|
yuuji@0
|
250
|
|
yuuji@0
|
251 An IMAP4 server MAY respond to the CREATE command with one or more
|
|
yuuji@0
|
252 IMAP mailbox referrals, if it wishes to direct the client to issue
|
|
yuuji@0
|
253 the CREATE against another server. The server can employ any means,
|
|
yuuji@0
|
254 such as examining the hierarchy of the specified mailbox name, in
|
|
yuuji@0
|
255 determining which server the mailbox should be created on.
|
|
yuuji@0
|
256
|
|
yuuji@0
|
257 Example:
|
|
yuuji@0
|
258
|
|
yuuji@0
|
259 C: A001 CREATE "SHARED/FOO"
|
|
yuuji@0
|
260 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
|
|
yuuji@0
|
261 Mailbox should be created on remote server
|
|
yuuji@0
|
262
|
|
yuuji@0
|
263 Alternatively, because a home server is required to maintain a
|
|
yuuji@0
|
264 listing of referred remote mailboxes, a server MAY allow the creation
|
|
yuuji@0
|
265 of a mailbox that will ultimately reside on a remote server against
|
|
yuuji@0
|
266 the home server, and provide referrals on subsequent commands that
|
|
yuuji@0
|
267 manipulate the mailbox.
|
|
yuuji@0
|
268
|
|
yuuji@0
|
269 Example:
|
|
yuuji@0
|
270
|
|
yuuji@0
|
271 C: A001 CREATE "SHARED/FOO"
|
|
yuuji@0
|
272 S: A001 OK CREATE succeeded
|
|
yuuji@0
|
273
|
|
yuuji@0
|
274 C: A002 SELECT "SHARED/FOO"
|
|
yuuji@0
|
275 S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
|
|
yuuji@0
|
276 Remote mailbox. Try SERVER2
|
|
yuuji@0
|
277
|
|
yuuji@0
|
278
|
|
yuuji@0
|
279
|
|
yuuji@0
|
280
|
|
yuuji@0
|
281
|
|
yuuji@0
|
282 Gahrns Standards Track [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 4.3. RENAME Referrals
|
|
yuuji@0
|
288
|
|
yuuji@0
|
289 An IMAP4 server MAY respond to the RENAME command with one or more
|
|
yuuji@0
|
290 pairs of IMAP mailbox referrals. In each pair of IMAP mailbox
|
|
yuuji@0
|
291 referrals, the first one is an URL to the existing mailbox name and
|
|
yuuji@0
|
292 the second is an URL to the requested new mailbox name.
|
|
yuuji@0
|
293
|
|
yuuji@0
|
294 If within an IMAP mailbox referral pair, the existing and new mailbox
|
|
yuuji@0
|
295 URLs are on different servers, the remote servers are unable to
|
|
yuuji@0
|
296 perform the RENAME operation. To achieve the same behavior of
|
|
yuuji@0
|
297 server RENAME, the client MAY issue the constituent CREATE, FETCH,
|
|
yuuji@0
|
298 APPEND, and DELETE commands against both servers.
|
|
yuuji@0
|
299
|
|
yuuji@0
|
300 If within an IMAP mailbox referral pair, the existing and new mailbox
|
|
yuuji@0
|
301 URLs are on the same server it is an indication that the currently
|
|
yuuji@0
|
302 connected server is unable to perform the operation. The client can
|
|
yuuji@0
|
303 simply re-issue the RENAME command on the remote server.
|
|
yuuji@0
|
304
|
|
yuuji@0
|
305 Example:
|
|
yuuji@0
|
306
|
|
yuuji@0
|
307 C: A001 RENAME FOO BAR
|
|
yuuji@0
|
308 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO
|
|
yuuji@0
|
309 IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
|
|
yuuji@0
|
310 across servers
|
|
yuuji@0
|
311
|
|
yuuji@0
|
312 Since the existing and new mailbox names are on different servers,
|
|
yuuji@0
|
313 the client would be required to make a connection to both servers and
|
|
yuuji@0
|
314 issue the constituent commands require to achieve the RENAME.
|
|
yuuji@0
|
315
|
|
yuuji@0
|
316 Example:
|
|
yuuji@0
|
317
|
|
yuuji@0
|
318 C: A001 RENAME FOO BAR
|
|
yuuji@0
|
319 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO
|
|
yuuji@0
|
320 IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
|
|
yuuji@0
|
321 located on SERVER2
|
|
yuuji@0
|
322
|
|
yuuji@0
|
323 Since both the existing and new mailbox are on the same remote
|
|
yuuji@0
|
324 server, the client can simply make a connection to the remote server
|
|
yuuji@0
|
325 and re-issue the RENAME command.
|
|
yuuji@0
|
326
|
|
yuuji@0
|
327 4.4. COPY Referrals
|
|
yuuji@0
|
328
|
|
yuuji@0
|
329 An IMAP4 server MAY respond to the COPY command with one or more IMAP
|
|
yuuji@0
|
330 mailbox referrals. This indicates that the destination mailbox is on
|
|
yuuji@0
|
331 a remote server. To achieve the same behavior of a server COPY, the
|
|
yuuji@0
|
332 client MAY issue the constituent FETCH and APPEND commands against
|
|
yuuji@0
|
333 both servers.
|
|
yuuji@0
|
334
|
|
yuuji@0
|
335
|
|
yuuji@0
|
336
|
|
yuuji@0
|
337
|
|
yuuji@0
|
338 Gahrns Standards Track [Page 6]
|
|
yuuji@0
|
339
|
|
yuuji@0
|
340 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
341
|
|
yuuji@0
|
342
|
|
yuuji@0
|
343 Example:
|
|
yuuji@0
|
344
|
|
yuuji@0
|
345 C: A001 COPY 1 "SHARED/STUFF"
|
|
yuuji@0
|
346 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF]
|
|
yuuji@0
|
347 Unable to copy message(s) to SERVER2.
|
|
yuuji@0
|
348
|
|
yuuji@0
|
349 5.1 RLIST command
|
|
yuuji@0
|
350
|
|
yuuji@0
|
351 Arguments: reference name
|
|
yuuji@0
|
352 mailbox name with possible wildcards
|
|
yuuji@0
|
353
|
|
yuuji@0
|
354 Responses: untagged responses: LIST
|
|
yuuji@0
|
355
|
|
yuuji@0
|
356 Result: OK - RLIST Completed
|
|
yuuji@0
|
357 NO - RLIST Failure
|
|
yuuji@0
|
358 BAD - command unknown or arguments invalid
|
|
yuuji@0
|
359
|
|
yuuji@0
|
360 The RLIST command behaves identically to its LIST counterpart, except
|
|
yuuji@0
|
361 remote mailboxes are returned in addition to local mailboxes in the
|
|
yuuji@0
|
362 LIST responses.
|
|
yuuji@0
|
363
|
|
yuuji@0
|
364 5.2 RLSUB Command
|
|
yuuji@0
|
365
|
|
yuuji@0
|
366 Arguments: reference name
|
|
yuuji@0
|
367 mailbox name with possible wildcards
|
|
yuuji@0
|
368
|
|
yuuji@0
|
369 Responses: untagged responses: LSUB
|
|
yuuji@0
|
370
|
|
yuuji@0
|
371 Result: OK - RLSUB Completed
|
|
yuuji@0
|
372 NO - RLSUB Failure
|
|
yuuji@0
|
373 BAD - command unknown or arguments invalid
|
|
yuuji@0
|
374
|
|
yuuji@0
|
375 The RLSUB command behaves identically to its LSUB counterpart, except
|
|
yuuji@0
|
376 remote mailboxes are returned in addition to local mailboxes in the
|
|
yuuji@0
|
377 LSUB responses.
|
|
yuuji@0
|
378
|
|
yuuji@0
|
379 6. Formal Syntax
|
|
yuuji@0
|
380
|
|
yuuji@0
|
381 The following syntax specification uses the augmented Backus-Naur
|
|
yuuji@0
|
382 Form (BNF) as described in [ABNF].
|
|
yuuji@0
|
383
|
|
yuuji@0
|
384 list_mailbox = <list_mailbox> as defined in [RFC-2060]
|
|
yuuji@0
|
385
|
|
yuuji@0
|
386 mailbox = <mailbox> as defined in [RFC-2060]
|
|
yuuji@0
|
387
|
|
yuuji@0
|
388 mailbox_referral = <tag> SPACE "NO" SPACE
|
|
yuuji@0
|
389 <referral_response_code> (text / text_mime2)
|
|
yuuji@0
|
390 ; See [RFC-2060] for <tag>, text and text_mime2 definition
|
|
yuuji@0
|
391
|
|
yuuji@0
|
392
|
|
yuuji@0
|
393
|
|
yuuji@0
|
394 Gahrns Standards Track [Page 7]
|
|
yuuji@0
|
395
|
|
yuuji@0
|
396 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
397
|
|
yuuji@0
|
398
|
|
yuuji@0
|
399 referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
|
|
yuuji@0
|
400 ; See [RFC-1738] for <url> definition
|
|
yuuji@0
|
401
|
|
yuuji@0
|
402 rlist = "RLIST" SPACE mailbox SPACE list_mailbox
|
|
yuuji@0
|
403
|
|
yuuji@0
|
404 rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox
|
|
yuuji@0
|
405
|
|
yuuji@0
|
406 6. Security Considerations
|
|
yuuji@0
|
407
|
|
yuuji@0
|
408 The IMAP4 referral mechanism makes use of IMAP URLs, and as such,
|
|
yuuji@0
|
409 have the same security considerations as general internet URLs [RFC-
|
|
yuuji@0
|
410 1738], and in particular IMAP URLs [RFC-2192].
|
|
yuuji@0
|
411
|
|
yuuji@0
|
412 With the MAILBOX-REFERRALS capability, it is potentially easier to
|
|
yuuji@0
|
413 write a rogue server that injects a bogus referral response that
|
|
yuuji@0
|
414 directs a user to an incorrect mailbox. Although referrals reduce
|
|
yuuji@0
|
415 the effort to write such a server, the referral response makes
|
|
yuuji@0
|
416 detection of the intrusion easier.
|
|
yuuji@0
|
417
|
|
yuuji@0
|
418 7. References
|
|
yuuji@0
|
419
|
|
yuuji@0
|
420 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
|
|
yuuji@0
|
421 4rev1", RFC 2060, University of Washington, December 1996.
|
|
yuuji@0
|
422
|
|
yuuji@0
|
423 [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
|
|
yuuji@0
|
424 September 1997.
|
|
yuuji@0
|
425
|
|
yuuji@0
|
426 [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
|
|
yuuji@0
|
427 Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
|
|
yuuji@0
|
428 University of Minnesota, December 1994.
|
|
yuuji@0
|
429
|
|
yuuji@0
|
430 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
431 Requirement Levels", RFC 2119, Harvard University, March 1997.
|
|
yuuji@0
|
432
|
|
yuuji@0
|
433 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
|
|
yuuji@0
|
434 Syntax Specifications: ABNF", Work in Progress, Internet Mail
|
|
yuuji@0
|
435 Consortium, April 1997.
|
|
yuuji@0
|
436
|
|
yuuji@0
|
437 8. Acknowledgments
|
|
yuuji@0
|
438
|
|
yuuji@0
|
439 Many valuable suggestions were received from private discussions and
|
|
yuuji@0
|
440 the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
|
|
yuuji@0
|
441 Mark Keasling, Chris Newman and Larry Osterman made significant
|
|
yuuji@0
|
442 contributions to this document.
|
|
yuuji@0
|
443
|
|
yuuji@0
|
444
|
|
yuuji@0
|
445
|
|
yuuji@0
|
446
|
|
yuuji@0
|
447
|
|
yuuji@0
|
448
|
|
yuuji@0
|
449
|
|
yuuji@0
|
450 Gahrns Standards Track [Page 8]
|
|
yuuji@0
|
451
|
|
yuuji@0
|
452 RFC 2193 IMAP4 Mailbox Referrals September 1997
|
|
yuuji@0
|
453
|
|
yuuji@0
|
454
|
|
yuuji@0
|
455 9. Author's Address
|
|
yuuji@0
|
456
|
|
yuuji@0
|
457 Mike Gahrns
|
|
yuuji@0
|
458 Microsoft
|
|
yuuji@0
|
459 One Microsoft Way
|
|
yuuji@0
|
460 Redmond, WA, 98072
|
|
yuuji@0
|
461
|
|
yuuji@0
|
462 Phone: (206) 936-9833
|
|
yuuji@0
|
463 EMail: mikega@microsoft.com
|
|
yuuji@0
|
464
|
|
yuuji@0
|
465
|
|
yuuji@0
|
466
|
|
yuuji@0
|
467
|
|
yuuji@0
|
468
|
|
yuuji@0
|
469
|
|
yuuji@0
|
470
|
|
yuuji@0
|
471
|
|
yuuji@0
|
472
|
|
yuuji@0
|
473
|
|
yuuji@0
|
474
|
|
yuuji@0
|
475
|
|
yuuji@0
|
476
|
|
yuuji@0
|
477
|
|
yuuji@0
|
478
|
|
yuuji@0
|
479
|
|
yuuji@0
|
480
|
|
yuuji@0
|
481
|
|
yuuji@0
|
482
|
|
yuuji@0
|
483
|
|
yuuji@0
|
484
|
|
yuuji@0
|
485
|
|
yuuji@0
|
486
|
|
yuuji@0
|
487
|
|
yuuji@0
|
488
|
|
yuuji@0
|
489
|
|
yuuji@0
|
490
|
|
yuuji@0
|
491
|
|
yuuji@0
|
492
|
|
yuuji@0
|
493
|
|
yuuji@0
|
494
|
|
yuuji@0
|
495
|
|
yuuji@0
|
496
|
|
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 Gahrns Standards Track [Page 9]
|
|
yuuji@0
|
507
|
