1
2
3
4
5
6
7Network Working Group M. Gahrns
8Request for Comments: 2180 Microsoft
9Category: Informational July 1997
10
11
12 IMAP4 Multi-Accessed Mailbox Practice
13
14Status of this Memo
15
16 This memo provides information for the Internet community. This memo
17 does not specify an Internet standard of any kind. Distribution of
18 this memo is unlimited.
19
201. Abstract
21
22 IMAP4[RFC-2060] is rich client/server protocol that allows a client
23 to access and manipulate electronic mail messages on a server.
24 Within the protocol framework, it is possible to have differing
25 results for particular client/server interactions. If a protocol does
26 not allow for this, it is often unduly restrictive.
27
28 For example, when multiple clients are accessing a mailbox and one
29 attempts to delete the mailbox, an IMAP4 server may choose to
30 implement a solution based upon server architectural constraints or
31 individual preference.
32
33 With this flexibility comes greater client responsibility. It is not
34 sufficient for a client to be written based upon the behavior of a
35 particular IMAP server. Rather the client must be based upon the
36 behavior allowed by the protocol.
37
38 By documenting common IMAP4 server practice for the case of
39 simultaneous client access to a mailbox, we hope to ensure the widest
40 amount of inter-operation between IMAP4 clients and servers.
41
42 The behavior described in this document reflects the practice of some
43 existing servers or behavior that the consensus of the IMAP mailing
44 list has deemed to be reasonable. The behavior described within this
45 document is believed to be [RFC-2060] compliant. However, this
46 document is not meant to define IMAP4 compliance, nor is it an
47 exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be
48 consulted to determine IMAP4 compliance, especially for server
49 behavior not described within this document.
50
51
52
53
54
55
56
57
58Gahrns Informational [Page 1]
59
60RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
61
62
632. Conventions used in this document
64
65 In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
66 clients (client #1, client #2 and client #3) that are connected to a
67 server. "S1:", "S2:" and "S3:" indicated lines sent by the server to
68 client #1, client #2 and client #3 respectively.
69
70 A shared mailbox, is a mailbox that can be used by multiple users.
71
72 A multi-accessed mailbox, is a mailbox that has multiple clients
73 simultaneously accessing it.
74
75 A client is said to have accessed a mailbox after a successful SELECT
76 or EXAMINE command.
77
78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
80 document are to be interpreted as described in [RFC-2119].
81
82
833. Deletion/Renaming of a multi-accessed mailbox
84
85 If an external agent or multiple clients are accessing a mailbox,
86 care must be taken when handling the deletion or renaming of the
87 mailbox. Following are some strategies an IMAP server may choose to
88 use when dealing with this situation.
89
90
913.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
92 mailbox
93
94 In some cases, this behavior may not be practical. For example, if a
95 large number of clients are accessing a shared mailbox, the window in
96 which no clients have the mailbox accessed may be small or non-
97 existent, effectively rendering the mailbox undeletable or
98 unrenamable.
99
100 Example:
101
102 <Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
103 to DELETE the mailbox and is refused>
104
105 C1: A001 DELETE FOO
106 S1: A001 NO Mailbox FOO is in use by another user.
107
108
109
110
111
112
113
114Gahrns Informational [Page 2]
115
116RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
117
118
1193.2. The server MAY allow the DELETE command of a multi-accessed
120 mailbox, but keep the information in the mailbox available for
121 those clients that currently have access to the mailbox.
122
123 When all clients have finished accessing the mailbox, it is
124 permanently removed. For clients that do not already have access to
125 the mailbox, the 'ghosted' mailbox would not be available. For
126 example, it would not be returned to these clients in a subsequent
127 LIST or LSUB command and would not be a valid mailbox argument to any
128 other IMAP command until the reference count of clients accessing the
129 mailbox reached 0.
130
131 In some cases, this behavior may not be desirable. For example if
132 someone created a mailbox with offensive or sensitive information,
133 one might prefer to have the mailbox deleted and all access to the
134 information contained within removed immediately, rather than
135 continuing to allow access until the client closes the mailbox.
136
137 Furthermore, this behavior, may prevent 'recycling' of the same
138 mailbox name until all clients have finished accessing the original
139 mailbox.
140
141 Example:
142
143 <Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
144 mailbox FOO>
145
146 C1: A001 DELETE FOO
147 S1: A001 OK Mailbox FOO is deleted.
148
149 <Client #2 is still able to operate on the deleted mailbox>
150
151 C2: B001 STORE 1 +FLAGS (\Seen)
152 S2: * 1 FETCH FLAGS (\Seen)
153 S2: B001 OK STORE completed
154
155 <Client #3 which did not have access to the mailbox prior to the
156 deletion by client #1 does not have access to the mailbox>
157
158 C3: C001 STATUS FOO (MESSAGES)
159 S3: C001 NO Mailbox does not exist
160
161 <Nor is client #3 able to create a mailbox with the name FOO, while
162 the reference count is non zero>
163
164 C3: C002 CREATE FOO
165 S3: C002 NO Mailbox FOO is still in use. Try again later.
166
167
168
169
170Gahrns Informational [Page 3]
171
172RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
173
174
175 <Client #2 closes its access to the mailbox, no other clients have
176 access to the mailbox FOO and reference count becomes 0>
177
178 C2: B002 CLOSE
179 S2: B002 OK CLOSE Completed
180
181 <Now that the reference count on FOO has reached 0, the mailbox name
182 can be recycled>
183
184 C3: C003 CREATE FOO
185 S3: C003 OK CREATE Completed
186
187
1883.3. The server MAY allow the DELETE/RENAME of a multi-accessed
189 mailbox, but disconnect all other clients who have the mailbox
190 accessed by sending a untagged BYE response.
191
192 A server may often choose to disconnect clients in the DELETE case,
193 but may choose to implement a "friendlier" method for the RENAME
194 case.
195
196 Example:
197
198 <Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs
199 the mailbox FOO>
200
201 C1: A002 DELETE FOO
202 S1: A002 OK DELETE completed.
203
204 <Server disconnects all other users of the mailbox>
205 S2: * BYE Mailbox FOO has been deleted.
206
207
2083.4. The server MAY allow the RENAME of a multi-accessed mailbox by
209 simply changing the name attribute on the mailbox.
210
211 Other clients that have access to the mailbox can continue issuing
212 commands such as FETCH that do not reference the mailbox name.
213 Clients would discover the renaming the next time they referred to
214 the old mailbox name. Some servers MAY choose to include the
215 [NEWNAME] response code in their tagged NO response to a command that
216 contained the old mailbox name, as a hint to the client that the
217 operation can succeed if the command is issued with the new mailbox
218 name.
219
220
221
222
223
224
225
226Gahrns Informational [Page 4]
227
228RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
229
230
231 Example:
232
233 <Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
234 the mailbox.>
235
236 C1: A001 RENAME FOO BAR
237 S1: A001 OK RENAME completed.
238
239 <Client #2 is still able to do operations that do not reference the
240 mailbox name>
241
242 C2: B001 FETCH 2:4 (FLAGS)
243 S2: * 2 FETCH . . .
244 S2: * 3 FETCH . . .
245 S2: * 4 FETCH . . .
246 S2: B001 OK FETCH completed
247
248 <Client #2 is not able to do operations that reference the mailbox
249 name>
250
251 C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
252 21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO
253 BAR] Mailbox has been renamed
254
255
2564. Expunging of messages on a multi-accessed mailbox
257
258 If an external agent or multiple clients are accessing a mailbox,
259 care must be taken when handling the EXPUNGE of messages. Other
260 clients accessing the mailbox may be in the midst of issuing a
261 command that depends upon message sequence numbers. Because an
262 EXPUNGE response can not be sent while responding to a FETCH, STORE
263 or SEARCH command, it is not possible to immediately notify the
264 client of the EXPUNGE. This can result in ambiguity if the client
265 issues a FETCH, STORE or SEARCH operation on a message that has been
266 EXPUNGED.
267
268
2694.1. Fetching of expunged messages
270
271 Following are some strategies an IMAP server may choose to use when
272 dealing with a FETCH command on expunged messages.
273
274
275
276
277
278
279
280
281
282Gahrns Informational [Page 5]
283
284RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
285
286
287 Consider the following scenario:
288
289 - Client #1 and Client #2 have mailbox FOO selected.
290 - There are 7 messages in the mailbox.
291 - Messages 4:7 are marked for deletion.
292 - Client #1 issues an EXPUNGE, to expunge messages 4:7
293
294
2954.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
296 keep the messages available to satisfy subsequent FETCH commands
297 until it is able to send an EXPUNGE response to each client.
298
299 In some cases, the behavior of keeping "ghosted" messages may not be
300 desirable. For example if a message contained offensive or sensitive
301 information, one might prefer to instantaneously remove all access to
302 the information, regardless of whether another client is in the midst
303 of accessing it.
304
305 Example: (Building upon the scenario outlined in 4.1.)
306
307 <Client #2 is still able to access the expunged messages because the
308 server has kept a 'ghosted' copy of the messages until it is able to
309 notify client #2 of the EXPUNGE>
310
311 C2: B001 FETCH 4:7 RFC822
312 S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
313 S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
314 S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
315 S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
316 S2: B001 OK FETCH Completed
317
318 <Client #2 issues a command where it can get notified of the EXPUNGE>
319
320 C2: B002 NOOP
321 S2: * 4 EXPUNGE
322 S2: * 4 EXPUNGE
323 S2: * 4 EXPUNGE
324 S2: * 4 EXPUNGE
325 S2: * 3 EXISTS
326 S2: B002 OK NOOP Complete
327
328 <Client #2 no longer has access to the expunged messages>
329
330 C2: B003 FETCH 4:7 RFC822
331 S2: B003 NO Messages 4:7 are no longer available.
332
333
334
335
336
337
338Gahrns Informational [Page 6]
339
340RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
341
342
3434.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox, ../imapserver/fetch.go:256
344 and on subsequent FETCH commands return FETCH responses only for
345 non-expunged messages and a tagged NO.
346
347 After receiving a tagged NO FETCH response, the client SHOULD issue a
348 NOOP command so that it will be informed of any pending EXPUNGE
349 responses. The client may then either reissue the failed FETCH
350 command, or by examining the EXPUNGE response from the NOOP and the
351 FETCH response from the FETCH, determine that the FETCH failed
352 because of pending expunges.
353
354 Example: (Building upon the scenario outlined in 4.1.)
355
356 <Client #2 attempts to FETCH a mix of expunged and non-expunged
357 messages. A FETCH response is returned only for then non-expunged
358 messages along with a tagged NO>
359
360 C2: B001 FETCH 3:5 ENVELOPE
361 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
362 S2: B001 NO Some of the requested messages no longer exist
363
364 <Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
365 to be informed of any pending EXPUNGE responses>
366
367 C2: B002 NOOP
368 S2: * 4 EXPUNGE
369 S2: * 4 EXPUNGE
370 S2: * 4 EXPUNGE
371 S2: * 4 EXPUNGE
372 S2: * 3 EXISTS
373 S2: B002 OK NOOP Completed.
374
375 <By receiving a FETCH response for message 3, and an EXPUNGE response
376 that indicates messages 4:7 have been expunged, the client does not
377 need to re-issue the FETCH>
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394Gahrns Informational [Page 7]
395
396RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
397
398
3994.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
400 on subsequent FETCH commands return the usual FETCH responses for
401 non-expunged messages, "NIL FETCH Responses" for expunged
402 messages, and a tagged OK response.
403
404 If all of the messages in the subsequent FETCH command have been
405 expunged, the server SHOULD return only a tagged NO. In this case,
406 the client SHOULD issue a NOOP command so that it will be informed of
407 any pending EXPUNGE responses. The client may then either reissue
408 the failed FETCH command, or by examining the EXPUNGE response from
409 the NOOP, determine that the FETCH failed because of pending
410 expunges.
411
412 "NIL FETCH responses" are a representation of empty data as
413 appropriate for the FETCH argument specified.
414
415 Example:
416
417 * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
418 * 1 FETCH (FLAGS ())
419 * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
420 * 1 FETCH (RFC822 "")
421 * 1 FETCH (RFC822.HEADER "")
422 * 1 FETCH (RFC822.TEXT "")
423 * 1 FETCH (RFC822.SIZE 0)
424 * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
425 * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
426 * 1 FETCH (BODY[<section>] "")
427 * 1 FETCH (BODY[<section>]<partial> "")
428
429 In some cases, a client may not be able to distinguish between "NIL
430 FETCH responses" received because a message was expunged and those
431 received because the data actually was NIL. For example, a * 5
432 FETCH (FLAGS ()) response could be received if no flags were set on
433 message 5, or because message 5 was expunged. In a case of potential
434 ambiguity, the client SHOULD issue a command such as NOOP to force
435 the sending of the EXPUNGE responses to resolve any ambiguity.
436
437 Example: (Building upon the scenario outlined in 4.1.)
438
439 <Client #2 attempts to access a mix of expunged and non-expunged
440 messages. Normal data is returned for non-expunged message, "NIL
441 FETCH responses" are returned for expunged messages>
442
443
444
445
446
447
448
449
450Gahrns Informational [Page 8]
451
452RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
453
454
455 C2: B002 FETCH 3:5 ENVELOPE
456 S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
457 S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
458 NIL NIL)
459 S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
460 NIL NIL)
461 S2: B002 OK FETCH Completed
462
463 <Client #2 attempts to FETCH only expunged messages and receives a
464 tagged NO response>
465
466 C2: B002 FETCH 4:7 ENVELOPE
467 S2: B002 NO Messages 4:7 have been expunged.
468
469
4704.1.4 To avoid the situation altogether, the server MAY fail the
471 EXPUNGE of a multi-accessed mailbox
472
473 In some cases, this behavior may not be practical. For example, if a
474 large number of clients are accessing a shared mailbox, the window in
475 which no clients have the mailbox accessed may be small or non-
476 existent, effectively rendering the message unexpungeable.
477
478
4794.2. Storing of expunged messages
480
481 Following are some strategies an IMAP server may choose to use when
482 dealing with a STORE command on expunged messages.
483
484
4854.2.1 If the ".SILENT" suffix is used, and the STORE completed
486 successfully for all the non-expunged messages, the server SHOULD
487 return a tagged OK.
488
489 Example: (Building upon the scenario outlined in 4.1.)
490
491 <Client #2 tries to silently STORE flags on expunged and non-
492 expunged messages. The server sets the flags on the non-expunged
493 messages and returns OK>
494
495 C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
496 S2: B001 OK
497
498
499
500
501
502
503
504
505
506Gahrns Informational [Page 9]
507
508RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
509
510
5114.2.2. If the ".SILENT" suffix is not used, and only expunged messages
512 are referenced, the server SHOULD return only a tagged NO.
513
514 Example: (Building upon the scenario outlined in 4.1.)
515
516 <Client #2 tries to STORE flags only on expunged messages>
517
518 C2: B001 STORE 5:7 +FLAGS (\SEEN)
519 S2: B001 NO Messages have been expunged
520
521
5224.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
523 and non-expunged messages are referenced, the server MAY set the
524 flags and return a FETCH response for the non-expunged messages
525 along with a tagged NO.
526
527 After receiving a tagged NO STORE response, the client SHOULD issue a
528 NOOP command so that it will be informed of any pending EXPUNGE
529 responses. The client may then either reissue the failed STORE
530 command, or by examining the EXPUNGE responses from the NOOP and
531 FETCH responses from the STORE, determine that the STORE failed
532 because of pending expunges.
533
534 Example: (Building upon the scenario outlined in 4.1.)
535
536 <Client #2 tries to STORE flags on a mixture of expunged and non-
537 expunged messages>
538
539 C2: B001 STORE 1:7 +FLAGS (\SEEN)
540 S2: * FETCH 1 FLAGS (\SEEN)
541 S2: * FETCH 2 FLAGS (\SEEN)
542 S2: * FETCH 3 FLAGS (\SEEN)
543 S2: B001 NO Some of the messages no longer exist.
544
545 C2: B002 NOOP
546 S2: * 4 EXPUNGE
547 S2: * 4 EXPUNGE
548 S2: * 4 EXPUNGE
549 S2: * 4 EXPUNGE
550 S2: * 3 EXISTS
551 S2: B002 OK NOOP Completed.
552
553 <By receiving FETCH responses for messages 1:3, and an EXPUNGE
554 response that indicates messages 4:7 have been expunged, the client
555 does not need to re-issue the STORE>
556
557
558
559
560
561
562Gahrns Informational [Page 10]
563
564RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
565
566
5674.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
568 and non-expunged messages are referenced, the server MAY return
569 an untagged NO and not set any flags.
570
571 After receiving a tagged NO STORE response, the client SHOULD issue a
572 NOOP command so that it will be informed of any pending EXPUNGE
573 responses. The client would then re-issue the STORE command after
574 updating its message list per any EXPUNGE response.
575
576 If a large number of clients are accessing a shared mailbox, the
577 window in which there are no pending expunges may be small or non-
578 existent, effectively disallowing a client from setting the flags on
579 all messages at once.
580
581 Example: (Building upon the scenario outlined in 4.1.)
582
583 <Client #2 tries to STORE flags on a mixture of expunged and non-
584 expunged messages>
585
586 C2: B001 STORE 1:7 +FLAGS (\SEEN)
587 S2: B001 NO Some of the messages no longer exist.
588
589 <Client #2 issues a NOOP to be informed of the EXPUNGED messages>
590
591 C2: B002 NOOP
592 S2: * 4 EXPUNGE
593 S2: * 4 EXPUNGE
594 S2: * 4 EXPUNGE
595 S2: * 4 EXPUNGE
596 S2: * 3 EXISTS
597 S2: B002 OK NOOP Completed.
598
599 <Client #2 updates its message list and re-issues the STORE on only
600 those messages that have not been expunged>
601
602 C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
603 (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
604 (\SEEN) S2: B003 OK STORE Completed
605
606
6074.3. Searching of expunged messages ../imapserver/search.go:343
608
609 A server MAY simply not return a search response for messages that
610 have been expunged and it has not been able to inform the client
611 about. If a client was expecting a particular message to be returned
612 in a search result, and it was not, the client SHOULD issue a NOOP
613 command to see if the message was expunged by another client.
614
615
616
617
618Gahrns Informational [Page 11]
619
620RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
621
622
6234.4 Copying of expunged messages
624
625 COPY is the only IMAP4 sequence number command that is safe to allow
626 an EXPUNGE response on. This is because a client is not permitted to
627 cascade several COPY commands together. A client is required to wait
628 and confirm that the copy worked before issuing another one.
629
6304.4.1 The server MAY disallow the COPY of messages in a multi-access
631 mailbox that contains expunged messages.
632
633 Pending EXPUNGE response(s) MUST be returned to the COPY command.
634
635 Example:
636
637 C: A001 COPY 2,4,6,8 FRED
638 S: * 4 EXPUNGE
639 S: A001 NO COPY rejected, because some of the requested
640 messages were expunged
641
642 Note: Non of the above messages are copied because if a COPY command
643 is unsuccessful, the server MUST restore the destination mailbox to
644 its state before the COPY attempt.
645
646
6474.4.2 The server MAY allow the COPY of messages in a multi-access
648 mailbox that contains expunged messages.
649
650 Pending EXPUNGE response(s) MUST be returned to the COPY command.
651 Messages that are copied are messages corresponding to sequence
652 numbers before any EXPUNGE response.
653
654 Example:
655
656 C: A001 COPY 2,4,6,8 FRED
657 S: * 3 EXPUNGE
658 S: A001 OK COPY completed
659
660 In the above example, the messages that are copied to FRED are
661 messages 2,4,6,8 at the start of the COPY command. These are
662 equivalent to messages 2,3,5,7 at the end of the COPY command. The
663 EXPUNGE response can't take place until after the messages from the
664 COPY command are identified (because of the "no expunge while no
665 commands in progress" rule).
666
667
668
669
670
671
672
673
674Gahrns Informational [Page 12]
675
676RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
677
678
679 Example:
680
681 C: A001 COPY 2,4,6,8 FRED
682 S: * 4 EXPUNGE
683 S: A001 OK COPY completed
684
685 In the above example, message 4 was copied before it was expunged,
686 and MUST appear in the destination mailbox FRED.
687
688
6895. Security Considerations
690
691 This document describes behavior of servers that use the IMAP4
692 protocol, and as such, has the same security considerations as
693 described in [RFC-2060].
694
695 In particular, some described server behavior does not allow for the
696 immediate deletion of information when a mailbox is accessed by
697 multiple clients. This may be a consideration when dealing with
698 sensitive information where immediate deletion would be preferred.
699
700
7016. References
702
703 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
704 4rev1", RFC 2060, University of Washington, December 1996.
705
706 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
707 Requirement Levels", RFC 2119, Harvard University, March 1997.
708
709
7107. Acknowledgments
711
712 This document is the result of discussions on the IMAP4 mailing list
713 and is meant to reflect consensus of this group. In particular,
714 Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
715 Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
716 Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
717 Winter were active participants in this discussion or made
718 suggestions to this document.
719
720
721
722
723
724
725
726
727
728
729
730Gahrns Informational [Page 13]
731
732RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
733
734
7358. Author's Address
736
737 Mike Gahrns
738 Microsoft
739 One Microsoft Way
740 Redmond, WA, 98072
741
742 Phone: (206) 936-9833
743 EMail: mikega@microsoft.com
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786Gahrns Informational [Page 14]
787
788