I want to clarify here: > 1. write the message - state=0
at state==0, a message doesn't have a valid UID. > 2. wait for token - generate uid, state -> 1 at state==1, a message might have a valid UID, but it isn't proven to be valid- that is, it's still not allowed to be seen by clients. > 3. wait for token to prove validity, state -> 2 (now visible) This way, the token pass always writes the message with a junk UID and state=0, then when it has the token, it moves to state=1 when it sees that same token the second time, it moves to state=2 You can encode the tokens seen in the database so you just say: UPDATE db_tokens SET state=2 WHERE state=1 AND token=? AND host=? UPDATE db_tokens SET uid=?, token=?, state=1 WHERE state < 2 AND host=? whenever you see a token. I might not have specified adequately what the token actually contains: 1. a globally unique random junk-string (big, minimum 128 bytes) 2. a uid number the junk-string (#1) is generated with the token and remains the same as long as the token is valid. It's what my example db_tokens table refers to as "token" UID number is the 31-bit unsigned IMAP UID number. host is the local hosts identifier. Use whatever you like- just so long as two hosts will NEVER use the same value. I hope this gives everyone a good idea on what exactly is going on. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
