Thanks for the help. Splitting out the spam scanning was quite easy (as
you indicated).
I added the following switch to the ./configure on simscan
--enable-spamc-args="-d 10.x.x.x,127.0.0.1"
Which allows spamc to call the remote machine and still use the
localhost as a fallback in case something goes wrong.
Of course I had to set up spamassassin on the remote machine, which
requires the switches -i 10.x.x.x to allow it to listen on the interface
and -A 10.x.x.y to allow the mail server to query it.
After all that, it seems to be working ok. However, I do get this in the
logs.
spamd: handle_user unable to find user: 'clamav'
And I notice that in the original toaster, my spamd was reporting
queries from the individual vpopmail users. Now everything is reporting
as being queried by clamav. I don' think this is causing a problem, but
want to make sure I'm not losing any email. All the test messages seem
to work properly.
Thanks,
Gary
Bill Shupp wrote:
On Apr 24, 2008, at 10:22 AM, Harm van Tilborg wrote:
Hi Bill,
What exactly is the benefit of using clamd-stream-client?
What we do is we have seperate boxes that receive e-mail (6 systems
in total), which are announced as four different MX hosts. They all
do spam (spamassassin) and virus (clam) scanning, and forward e-mail
(if it contains no viruses, and a spam score lower then 15) to the
MTA servers.
If such MX servers (as we call it) fails, there are 5 servers left to
replace this one. So concurrency is quite spread out. However, MTA
servers are all single, we are still looking for a good solution to
this...
It just depends how you want to scale your infrastructure. By
segregating scanning from smtp, you can put more horsepower behind the
scanning segment, and less behind the smtp part. So I think it's more
flexible. But it's also more complex than what you're doing.
However, if you're using NFS for chkuser lookups, your method might be
more taxing on the NFS box. Both solutions will likely work fine,
though.
Regards,
Bill
