On 30.5.2012, at 20.20, Cyrus Daboo wrote: >>> So Arnt tells me. >> >> If I can implement it this way without violating the spec: >> >> 1. Verify that ACLs allow expunge, fail if not >> 2. Do atomic UID COPY without enforcing quota limits >> 3. Expunge the messages >> [4. If expunge for some strange reason fails now, there are probably >> duplicates now. I'm not sure if I want to bother fixing that situation. >> It should "never" happen anyway.] >> >> then I could add it to Dovecot pretty much immediately. > > So if the expunge does fail, how are you going to report that to the client? > Arnt's current spec does not show any * N EXPUNGE responses coming back, so I > am assuming that the client is supposed to implicitly assume the expunges > took place, which would cause a problem if they did not take place. But that > seems wrong to me - shouldn't UID MOVE cause * N EXPUNGE to be sent for each > message that was actually moved?
I assumed that this was a bug in the example and was going to report it as some point. I think the EXPUNGE/VANISHED replies should be sent in any case, even if MOVE was required to be fully atomic. Otherwise if the UID MOVE command sends an untagged FETCH/EXPUNGE reply it wouldn't be obvious if the sequence number referred to the state before or after the MOVE expunges. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
