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

[Michael M Slusarz]

Quoting Timo Sirainen <tss at iki.fi>:

> On 13.2.2012, at 23.32, Timo Sirainen wrote:
>
>> Perhaps a way for (trusted) clients to be able to do this? :)
>>
>> a logout save
>> * OK [SAVEDSTATE 1234567890]
>> * BYE logged out
>> a OK
>
> 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.  For a  
disconnected client (e.g. webmail), there's going to necessarily need  
to be startup costs of initializing the session anyway so re-creating  
the state can be buried in this other work.

Re-creating becomes more important when users are doing actions they  
expect immediate (or at least very fast) responses for.  Things like  
listing messages in a mailbox, viewing a message, or polling  
mailboxes.  Saving 50ms per request becomes important in these  
situations since re-creating state now takes 10% of the total request  
time.

So I don't think states don't need a terribly long lifetime.  I almost  
think of something like an internal Dovecot IDLE queue - after a  
logout is received, state is stored for 30 minutes after which it is  
discarded.  (Although not knowing anything about internal Dovecot  
state, don't know if this is overly resource intensive.)

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.

michael