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?