[Dovecot] dovecot backend on director ?

[Timo Sirainen]

On 4.12.2012, at 19.33, Thomas Hummel wrote:

> Hello Timo,
> 
> The last time I checked my understanding about director was that :
> 
> 1. backend/"real" imap servers should not be on the same host (or the same dovecot instance) to
>   avoid proxying loops.
> 
> Is it still the case with the latest 2.1 stable release ? Is there a plan to be
> able to run director and real server on the same host, thus requiring only 2
> hosts instead of 4 to have load balancing and a redundant director ?

Either:

a) Run two Dovecot instances with different base_dirs and different TCP ports. This has been used by several installations.

b) One Dovecot instance with proxy_maybe. I'm not completely sure if this works. I think it does.

> 2. director itself was not able or meant to check if one of the real server was
>   down (some script was pointed long time ago in this list).
> 
> Same questions.

This probably not happening anytime soon. It's not always obvious if a backend server is down or just heavily loaded. Better to use an external script that can be tweaked.

> 3. you'll have to use dovecot lmtp instead of let's say procmail. Would deliver
>   be still a choice or is lmtp the only deliver compatible choice ?
> 
> In what case would lmtp be more useful than deliver ? To have some sort of
> "remote LDA" ?

With LMTP the mailbox access is done by the proper server. With LDA it's always done by the server that runs the LDA, again causing all the troubles that director is supposed to prevent. I've had some thoughts about changing dovecot-lda to be LMTP client by default, but that hasn't happened yet. It wouldn't be difficult to write a separate LMTP client binary (and there probably already are those).

> By the way, what gets indexed on deposit on the mailbox since, by definition,
> the user has not done any request yet ?

Dovecot's caching decisions are remembered. So it adds those headers/etc that the user's current client(s) are interested in. http://wiki2.dovecot.org/Design/Indexes/Cache has some details about the cache decisions.