rfc2180.txt (24750B)
1 2 3 4 5 6 7 Network Working Group M. Gahrns 8 Request for Comments: 2180 Microsoft 9 Category: Informational July 1997 10 11 12 IMAP4 Multi-Accessed Mailbox Practice 13 14 Status 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 20 1. 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 58 Gahrns Informational [Page 1] 59 60 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 61 62 63 2. 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 83 3. 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 91 3.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 114 Gahrns Informational [Page 2] 115 116 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 117 118 119 3.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 170 Gahrns Informational [Page 3] 171 172 RFC 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 188 3.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 208 3.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 226 Gahrns Informational [Page 4] 227 228 RFC 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 256 4. 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 269 4.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 282 Gahrns Informational [Page 5] 283 284 RFC 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 295 4.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 338 Gahrns Informational [Page 6] 339 340 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 341 342 343 4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox, 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 394 Gahrns Informational [Page 7] 395 396 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 397 398 399 4.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 450 Gahrns Informational [Page 8] 451 452 RFC 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 470 4.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 479 4.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 485 4.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 506 Gahrns Informational [Page 9] 507 508 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 509 510 511 4.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 522 4.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 562 Gahrns Informational [Page 10] 563 564 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 565 566 567 4.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 607 4.3. Searching of expunged messages 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 618 Gahrns Informational [Page 11] 619 620 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 621 622 623 4.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 630 4.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 647 4.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 674 Gahrns Informational [Page 12] 675 676 RFC 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 689 5. 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 701 6. 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 710 7. 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 730 Gahrns Informational [Page 13] 731 732 RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 733 734 735 8. 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 786 Gahrns Informational [Page 14] 787