On 12/07/2024 17:38, James Cook via dovecot wrote:
Replication is in the current dovecot version but will go away in 2.4.
The doveadm sync feature is staying. So with some work you can set it up what you are requesting.
I used to use replication and now I'm thinking about using sync but have not implemented it. The following are thoughs on it.
There are some points to be addressed that are outside dovecot. I think you'd have to make sure that your sync happened frequently enough that you could live with losing the emails that arrives bewteen syncs for example.
I have been thinking of writing a hacky delivery script that passes the email on to dovecot-lda, then runs doveadm sync, and only returns success after the sync is done (or after a timeout). No idea what problems I will run into, but the idea is to never accept an email until it's guaranteed replicated.
That would tend to lead to a requirement to sync more frequently and reduce risk of email loss. But then you'd need to avoid more than one sync being active simultaneously (that is my assumption that this would not work, but I don't know if it is a real problem).
Doesn't the -l option protect against simultaneous syncs? Just based on reading the doveadm-sync man page. (I guess it could cause a problem if you start sync processes more quickly than they can finish.)
NB I'm just running a one-person email server so don't take my ideas too seriously :)
Hi James
I want to avoid the -1 parameter because it doesn't do deletes in the target. It might not be an issue, but I'd like to keep the target the same as the source. I don't know if it would protect against simultaneous jobs, but I dont' know even if that is an issue. I was making the assumption it could be so I plan to avoid it somehow.
As for the lda to doveadm sync script, I have been wondering too about how to close the gap for emails arriving between syncs, even though the risk might not be so significant.
With delivering to two dovecot servers before accepting the email, either one going down will stop email delivery. That's an inconvenience but without necessarily introducing risks for losing the emails. Ultimately it depends on where those undelivered emails are being kept in the meantime (presumably MTA queue) and whether they are safer there than being delivered to a single instance. Though that is related only to the downtime. When both are up the risk would be mitigated by the solution.
Other idea I was thinking of is a replicated file system. That could make emails available in real time to both dovecot instances assuming a functionality to sync to disk on both/multiple nodes before replying back to dovecot to accept the email. I believe there would still need to be only one dovecot instance active at a time. However, I have heard of but don't know personally of horror stories about email outages on clustered file systems, which leads me to believe that there would still be sufficient residual risk to require a backup copy of the mailboxes with doveadm sync or other tools.
John
John