On Thu, 2006-09-14 at 10:19 +0200, Lars Kneschke wrote: > Aaron Stone <[EMAIL PROTECTED]> schrieb: > >> Ok. I changed my code. But should not change that value at least on > >>delete? > > > >Nope, I don't think so. When UIDVALIDITY changes, it means all UID's that > >you have cached must be thrown away and you have to find out what the new > >UID's are for the messages in the mailbox. > Unfortunaly it does not seem to be documented really good in the RFC. But > it is also not important for me, as i now query the number of messages and > nextuid. That solves the problem for me.
RFC 2060 is gibberish. UIDVALIDITY is needed because UIDs must be strictly increasing. The right way to get UIDs should have been "x FETCH 1:* UID" and let UIDs be binary string, but it's much too late now. Now, I recommend that servers make FETCH+ENVELOPE fast, and client implementers should use: "x FETCH 1:* ENVELOPE" Use a hash of the envelope response as the unique identifier. I'd recommend servers give out the capability "FETCH-IS-FAST" for interactive IMAP clients. Implementing RFC 2060 in this way makes it much easier to synchronize email knowledge, and would greatly simplify distributed IMAP services... > >There's an interesting extension, too: RFC 4315, UIDPLUS. I don't think > >it's implemented in DBMail (?). > Not when having a look at the capabilities. Nobody has a meaningful implementation of UIDPLUS. Furthermore UIDPLUS is extremely complicated. Furthermore, FETCH+ENVELOPE is already supported. I don't think non-interactive IMAP clients should ever bother with UID/UIDVALIDITY. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
