[Dovecot] [ Re: best practises for mail systems]

[Matthias-Christian Ott]

On 2012-06-05 23:43, Timo Sirainen wrote:
> On 5.6.2012, at 23.33, Michescu Andrei wrote:
> 
>>> I agree, in practice this is not an issue compared to the unavailability
>>> of the service, but on longer IMAP sessions (e.g. transferring a big
>>> file) the connection loss is noticeable.
>>
>> It is noticeable for somebody that really waits for a large email.
> 
> And there is actually some (any!) way this could be avoided?... One server dies, another continues sending the mail?

Yes, there is. You have to replicate the entire state of the IMAP
session (protocol states, buffers, TLS state etc.) and the TCP state of
the connection. The state of the IMAP session is (in theory) easily
replicable (although you probably have to rely on internals of the TLS
implementation; OpenSSL can serialise TLS sessions from/into ASN.1 via
i2d_SSL_SESSION, though this is meant to resume session via TLS) and for
TCP there is RTCP [1]. RTCP intercepts the TCP session is able to
recover the TCP state. It works without any modification of the
operating system (at the moment limited to Linux).

If this would be implemented in Dovecot it would really set it apart
from other IMAP servers and software that I've seen so far. Being able
to transparently handle failover of a TCP connection is unique.

> I have had some thoughts about transferring idling Dovecot connections between processes / servers so that clients wouldn't notice it, but I haven't even thought about moving active (long-running) connections.

Load rebalancing would probably be another feature that separates
Dovecot from other IMAP servers.

Regards,
Matthias-Christian

[1] http://rtcp.sourceforge.net/