<html><head></head><body>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?<br><br>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.<br><br><div class="gmail_quote">Am 4. Januar 2021 14:52:20 MEZ schrieb PGNet Dev <pgnet.dev@gmail.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">I run Postfix + Dovecot.<br><br>Currently, I've got a cloud-instance of Postfix that handles all the anti-spam/auth/routing.<br>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.<br><br>Works great.<br><br>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.<br><br>The goal state I'm considering looks like:<br><br>@cloud<br><br> Postfix<br> LMTP delivery from Postfix to "Dovecot1"<br><br>@local<br><br> LMTP (re)delivery from "Dovecot1", @cloud, to "Dovecot2"<br><br>IDEALLY, no IMAP mail should ever be persistently stored on the @cloud Dovecot instance -- unless the VPN link is down.<br>Then, when the VPN link is up again, the @cloud-stored IMAP mail should me 'moved' to the @local instance.<br><br>I.e., I do _not_ want a replicated store.<br><br>My question is how transparent/automated can this be done?<br><br>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 ...<br><br>Any suggestions as to how to put this VPN-conditional redundancy in place?<br></pre></blockquote></div></body></html>