Rogier Krieger wrote:
On 8/12/05, Rogier Krieger <[EMAIL PROTECTED]> wrote:
After deploying spamd as a shield for a non-OpenBSD mail host, I
wonder how to expand this setup to support multiple mailhosts (say
three mx'es mxN).
Although it may be bad form to reply to oneself, any thoughts on how
complicated it would be to create a pfsync-like means of distributing
spamd functionality?
Cheers,
Rogier
Hi,
I have been thinking of doing this on a simplier, semi scalable way...
It's not real time, and will not have 100% consistancey between clients,
but it will be trivial to implement. My "clients" are spread over the
country...so might be interesting to get a variety of different mail
servers added to the white list...
I was going to keep a central "authoritative" spamd system. All the
other systems would be clients...
The first implementation was just going to be the clients sending an
email on a periodic basis to the "main" server. It could be as simple
as a cron job...
spamdb | grep '^WHITE|' | mail -s"spamdb for `uname -n` at `date`"
[EMAIL PROTECTED]
The central host would receive the email, and maybe by procmail, process
the email & update it's spamdb tables. Then, the central mail host
would REPLY to the email with the final spamdb output. This would
propogate changes from other clients back to the originating client.
Advantage: It's pretty trivial to set up, I could probably do it in
under 1 hour. It is initiated by the client. There are no changes
required on the central server when a new client is deployed...
The only catch is that all the clients will NOT be in sync... but they
will be close if the update frequency is say 1/hr.. and for the WHITE
list of spamdb, I figured that was good enough!
Security would need to be addressed, perhaps by using Sendmail's
"access.db" on the central server, but that is a first thought off the
top of my head..
The clients could be made smarter so they only sent the "new" records...
or an empty set if they just wanted the updates from the main server.
It is kind of a hack, but why use a sledgehammer to drive in a tack!
If this is not the functionality you are looking for, maybe you should
clarify... I do not see any point in distributing "GREY" information, as
it is only useful when a connect happens, and the default behavior is
going to be the same as if the client had notification about a "GREY"
connect to a different mail server.
Cheers,
Steve
