Differences between revisions 2 and 3
Revision 2 as of 2007-06-27 14:35:32
Size: 1117
Editor: TimoSirainen
Comment:
Revision 3 as of 2007-06-27 14:35:54
Size: 1150
Editor: TimoSirainen
Comment:
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:
[http://mailman1.u.washington.edu/pipermail/imap-protocol/2007-May/000562.html Not necessarily the ideal order] [http://mailman1.u.washington.edu/pipermail/imap-protocol/2007-May/000562.html The above order isn't the ideal from IMAP protocol point of view]

Multi-Accessed Mailbox Practice

[http://www.faqs.org/rfcs/rfc2180.html RFC 2180] explains the issues.

Expunges

  1. Keep the message around until there are no sessions that see it. This is the preferred behavior.
  2. Give some dummy replies for the message. Such as empty flags, and other fields being NILs or whatever is legal for the field. The downside to this is that it violates the IMAP protocol if the client had already asked something about this message.
  3. Don't return the FETCH reply for the message at all and return a tagged NO reply. Doing this makes some clients ask the same message range over and over again infinitely. This could be avoided also: http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-September/000281.html

  4. Disconnect the client anytime you can't handle the request. I used to do this but it was annoying when it happened.
  5. Don't allow EXPUNGE until there's only session. I think this is the worst of the possibilities.

[http://mailman1.u.washington.edu/pipermail/imap-protocol/2007-May/000562.html The above order isn't the ideal from IMAP protocol point of view]

None: MultiAccessPractices (last edited 2010-03-23 12:59:50 by p5098ab40)