On Wed, 31 Dec 2003, Arnt Gulbrandsen wrote: > a) make a simple ghost message (e.g. one with no body and a simple default set > of headers).
This is the least bad of the choices that you made, but there is another choice, which is to keep the message around until it is expunged. Think of what happens when you delete a file that something else has opened. That other entity doesn't suddenly start getting errors; it continues to be able to read and write the file. > (In fact, WU-imapd will > forcibly disconnect clients for lesser offenses.) UW (not "WU") imapd only forcibly disconnects when an attempt is made to multiply-open a mailbox which is in a format does not support multiple-open -- that is, traditional UNIX format. The idea is that if you have an old session lying around, you shouldn't be forbidden from starting a new one and instead the old one should be killed. > > My answer would be the following: I'd do the expunge immediately to the > > message store. I then postpone the expunge messages as required by the specs > > for Client A. Any request to FETCH/STORE/SEARCH would be answered with a > > tagged NO response then (as described in RFC2180 4.1.2) until the EXPUNGE > > could be delivered. > It makes sense to me, but it's not compatible with the existing RFC. If you > had suggested this before RFC 1730/2060 were published, it might have become > part of the protocol, at least if Mark likes it. But now I guess it's too > late. I don't think that it's a good idea, and I would have opposed it. It creates needless error conditions for clients. If you can't keep the message data around for the benefit of other sessions, then simply forbid shared expunge. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
