> Shouldn't UID be changed if _anything_ changes in message header or > body?
I don't understand why? It's certainly not necessary. The main concern seems to be client caching rules, and perhaps this is what's broken. > Because of current caching rules. Two possible ways to support updating > messages in backwards compatible way: Here's where I think explicitly stating messages are immutable is actually a disservice: just because clients have been implmented this way until now doesn't mean future generations of clients need to be implemented this way forever. This is software after all, things change. > 1. Change the UID, but add some way for new clients to find out what > it's old UIDs were. > 2. Change UIDVALIDITY if something is updated, and add some way for new > clients to invalidate cache only for changed messages. I think there is another passive option that uses currently defined FLAGs that will be safely ignored by current clients. That is, if a message changes, it switches the \Unseen flag. True, current clients will not be smart enough to flush their caches and FETCH again, but newer clients will be. I don't think enabling this feature for all IMAP clients built until now is feasible, rather, the goal would simply be not to break all IMAP clients built until now. JM
