Implementing redundancy at the mailbox level makes sense, because
that is essentially data at rest.
Implementing redundancy by sharing the email queue appears to make
less sense: it looks like making routers redundant by sharing their
packet queues. Both are essentially handling data in flight.
T
On 24 Mar 2021, at 7:03, Sven Schwedas wrote:
If that's not acceptable, you need some form of file system/block
layer replication (DRBD, Ceph, Gluster, …) to get the spool data to
a spare.
Have you actually used such a storage system for the Postfix queue?
I've used SAN storage (RAID 10 on t
On 24 Mar 2021, at 6:28, Eero Volotinen wrote:
> How about using ceph / glusterfs?
Have you actually used either of those for the Postfix queue?
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
On 24 Mar 2021, at 6:16, Patrick Chemla wrote:
Hi,
Apparently, searching Google, I still can't find a good solution to
build a fault tolerant emails platform.
That is because such systems are typically 'bespoke,' designed to fit
specific circumstances and it isn't in the interest of people
It really depends on what guarantees you need.
Usually on the MTA layer it's fine to just spin up separate instances,
and if one email gets lost in the 5 seconds between its receipt being
acknowledged and it being forwarded to an MDA, c'est la vie.
If that's not acceptable, you need some form
How about using ceph / glusterfs? and then you need some ldap or similar
userdatabase or mysql cluster..
Eero
On Wed 24. Mar 2021 at 12.16, Patrick Chemla
wrote:
> Hi,
>
>
> Apparently, searching Google, I still can't find a good solution to build
> a fault tolerant emails platform.
>
>
> Is th
Hi,
Apparently, searching Google, I still can't find a good solution
to build a fault tolerant emails platform.
Is there any good solution to synchronize 2 emails servers,
including incoming mails, having users connected to any of the
server?
