[Dovecot] IMAP-proxy or not with sogo webmail and dovecot backend

[Timo Sirainen]

On 14.2.2012, at 5.30, Michael M Slusarz wrote:

>> Actually, this could probably be safely implemented by sending all of the state to the client as a string:
>> 
>> * OK [SAVEDSTATE base64-encoded-state]
>> 
>> There isn't a whole lot of state to be saved really. Mailbox GUID, UIDVALIDITY, HIGHESTMODSEQ gives the mailbox state. Then you have the language/etc. states. Clients could restore their earlier state from days ago, as long as Dovecot still has the necessary .log records available (similar to how QRESYNC works).
> 
> Given that it is not *that* expensive to re-create the state, I don't think the ability to recreate state from several days ago would be worth the effort of storing in the log/index files.

There wouldn't be *any* additional state stored. All the necessary state is already stored to .log files for other purposes. The base64-encoded-state would be a self-contained description of the IMAP connection's entire state.

> As for base-64-encoded state: if other IMAP servers ever wanted to implement a similar protocol trying to coordinate the data structure would be a nightmare.  Keeping it to something like a MODSEQ value would hide the state ID -> data abstraction entirely within dovecot.  And would allow you to change your mind in the future if
> you come up with a better way to represent state.

The client doesn't need to care about the data structure. The client simply reads a string and sends it later back to server if it wants to restore that state. Only the server needs to verify that the string looks reasonable. The same string wouldn't be sent to a different server implementation, so there wouldn't be any interoperability issues. Each server can implement it in whatever way they want to (although there should be some checks in case the same string is sent to different versions of the same server).