Hi,

TMDA has been an inspiration to me.  With just a few hours of installation
work, my SPAM rate went to 0!  Miracle product!

In the organization that employs me, because of the clear effectiveness of
TMDA, we are going to deploy a similar approach.  The design of TMDA is so
good that however we implement our approach, we can reuse the TMDA design.
We will most likely roll our own version of TMDA in 'C'.  Due to our
organizational setup (users don't have shell accounts on the mail server),
we will change it so that users administer their settings by e-mail
(interacting with the servers).

We do, however, have one situation that I'm not sure how best to handle.  We
have two front-end mail servers, one primary and one backup.  Either machine
may go down for maintenance or just plain fail.  We would like to implement
a TMDA clone on the front-end mail servers.  These front-end machines
distribute e-mail to other mail servers internally.

How would you recommend handling the database consistency between the two
machines?  The approach that I had in mind was to have each machine just
handle its own whitelists and so forth, the way TMDA does now.  I would also
have each machine NFS mount the other machine's databases read-only.  So
each machine could both read and modify its own databases, but could only
_read_ the databases of other machines.  When a mail comes in, a machine
would first check its own whitelists.  If nothing was there, it would then
check the NFS-mounted remote whitelists and honor those.

So what should happen is that being on the whitelist of either machine would
cause either machine to allow a mail from you without a confirmation.

Can somebody recommend a better database coherency protocol that that would
allow the TMDA-style approach to be extended to a group of N cooperating
front-end machines?  I'm open for all ideas and discussion on this matter.

Thank you, Dave.

_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users

Reply via email to