set up for Dovecot redundancy -- store on edge server only if link to backofc server is down, otherwise deliver to final dest?
I run Postfix + Dovecot.
Currently, I've got a cloud-instance of Postfix that handles all the anti-spam/auth/routing. On successful 'pass', it resends email -- over a VPN link -- to a *local* Postfix instance, which then LMTP-delivers to a Dovecot instance on the same box.
Works great.
I'd like to set up some IMAP redundancy, so that if the VPN link is down for any reason, mail is stored/accessible, and -- eventually -- correctly (re)delivered to the local Dovecot instance when the link's up again.
The goal state I'm considering looks like:
@cloud
Postfix
LMTP delivery from Postfix to "Dovecot1"@local
LMTP (re)delivery from "Dovecot1", @cloud, to "Dovecot2"IDEALLY, no IMAP mail should ever be persistently stored on the @cloud Dovecot instance -- unless the VPN link is down. Then, when the VPN link is up again, the @cloud-stored IMAP mail should me 'moved' to the @local instance.
I.e., I do _not_ want a replicated store.
My question is how transparent/automated can this be done?
I'd guess that somewhere in Dovecot's config I need logic that provides the conditional delivery to just @cloud vs 'all the way' to @local ...
Any suggestions as to how to put this VPN-conditional redundancy in place?
Perhaps I misunderstood the constraints, but (for a low nunber od accounts) what would be wrong with simply fetching the mail on the local server from dovecot1 and delivering it to dovecot2 with IMAP idle to prevent delays?
If the VPN link is down mail will stay on dovecot1. You could even configure a postponed deletion (hours or days) so you would be able to access recent mail if dovecot2 is down.
Am 4. Januar 2021 14:52:20 MEZ schrieb PGNet Dev pgnet.dev@gmail.com:
I run Postfix + Dovecot.
Currently, I've got a cloud-instance of Postfix that handles all the anti-spam/auth/routing. On successful 'pass', it resends email -- over a VPN link -- to a *local* Postfix instance, which then LMTP-delivers to a Dovecot instance on the same box.
Works great.
I'd like to set up some IMAP redundancy, so that if the VPN link is down for any reason, mail is stored/accessible, and -- eventually -- correctly (re)delivered to the local Dovecot instance when the link's up again.
The goal state I'm considering looks like:
@cloud
Postfix LMTP delivery from Postfix to "Dovecot1"
@local
LMTP (re)delivery from "Dovecot1", @cloud, to "Dovecot2"
IDEALLY, no IMAP mail should ever be persistently stored on the @cloud Dovecot instance -- unless the VPN link is down. Then, when the VPN link is up again, the @cloud-stored IMAP mail should me 'moved' to the @local instance.
I.e., I do _not_ want a replicated store.
My question is how transparent/automated can this be done?
I'd guess that somewhere in Dovecot's config I need logic that provides the conditional delivery to just @cloud vs 'all the way' to @local ...
Any suggestions as to how to put this VPN-conditional redundancy in place?
On 1/4/21 10:00 AM, Frank-Ulrich Sommer wrote:
Perhaps I misunderstood the constraints, but (for a low nunber od accounts) what would be wrong with simply fetching the mail on the local server from dovecot1 and delivering it to dovecot2 with IMAP idle to prevent delays?
Hm. I'd (only) been thinking abt push from 1->2, not pull from 2->1. hadn't considered 'fetch' -- haven't used it. yet.
I'd always thought of fetch as a target per-mail/per-box tool -- not a "get all mail for all accounts" tools.
Need to read-up on global config, rather than per-account/etc scripting ... And, exactly how the idle works in this case, to eliminate delay when link's up.
If the VPN link is down mail will stay on dovecot1. You could even configure a postponed deletion (hours or days) so you would be able to access recent mail if dovecot2 is down.
Sounds like fetch does a copy, not a move, then. At least by default. And that Dovecot must be told to delete from the source ... again, either via script, or from within Dovecot config.
Now, reading docs @ https://wiki.dovecot.org/Tools/Doveadm/Fetch, &, looking for some examples/scenarios.
participants (2)
-
Frank-Ulrich Sommer
-
PGNet Dev