Rangi Biddle
2006-10-27 07:06:35 UTC
Hi Guys,
Well I thought I would put my 2 cent's in to this conversation as I've
successfully implemented DSpam into my qmail toaster install but had a
couple of issues that need to be addressed if considering putting DSpam into
the current toaster.
First issue I had was initially deciding on how to integrate DSpam (as is
been mentioned already) and how best to manage it. This basically came down
to what the customers wanted which was to leave dealing with marking which
messages are spam to the systems administrators. Really sucks of course
considering that a simple error in marking a email for a client would then
cause them to not get the email and getting a real earful.
Second issue I had was mainly the limitations of where I could implement
DSpam into the current toaster setup. With the current toaster there were
issues with using either procmail or maildrop as LMTP or LDA which seemed to
cause messages to be lost in the void when mail was being delivered (with
catchall's and actual virtual user accounts). There has been discussion
already on this list about integrating DSpam with simscan which has been
done already, but, for an earlier version than what is being used at
present. The patch that is also available still isn't bug free and as
mentioned only works with version 1.1 of simscan. This is the best approach
(I believe) to integrating DSpam into the current toaster as even before
mail is accepted for delivery DSpam must allow it to pass. This
unfortunately was not how I implemented DSpam. I eventually ended up
setting up DSpam as a relay on an aliased interface on the same box which
would then send mail after it had passed through back to the other IP on the
same host. This is working ok but would prefer the simscan integration.
There was however one issue that was a nightmare to deal with, especially
after the mail server went live. This was getting the administration panel
for DSpam working. Now this wasn't a DSpam issue but more of an apache one
as the minimum GID of a group that is allowed to suexec CGI scripts was >=
1000 and vpopmail has a GID of 89. Hmmm, what to do here? I had to
recompile vpopmail (after editing spec file) for the adjustment and then
rebuild any other RPM that was dependant on vpopmail and finally changing
ownership of all the various files/directories that vpopmail had some type
of ownership of. After a long ordeal the finished product was well worth
it. I have gone that little bit further with DSpam and have setup another
system that now does all the relaying separately to the Qmail Toaster and
just has messages for legitimate users being passed to the actual mail
server which further reduces the load of the mail server instead of bouncing
messages back and forth. As someone has asked or mentioned about
implementing ClamAV into DSpam this really wasn't very difficult. All I
merely had to do was install the clamav RPM and configure clamav to listen
for TCP connections, uncomment a few lines in the dspam.conf file (ClamAV
relevant sections), update clamav db using freshclam and finally starting
clamav and restarting DSpam (if already running before installing ClamAV).
messages (for my own email account) that were spam, I logged into the
administration panel and marked these messages and a few others that had
gotten through and well I haven't seen messages of those type come back
through again. Similarly, other admin members did the same after showing
them what to do and voila same thing for them as well - less spam. Over the
course of the next few days we have had significant drop in spam coming
through which for me was a wet dream come true considering the levels of
spam that were originally getting through even with spamassassin being set
to "Super Paranoid Level". But all in all my hat is off to the folks over
at nuclear elephant. Much thanks to everyone hear as well for the qmail
toaster project and their input.
Rangi
Well I thought I would put my 2 cent's in to this conversation as I've
successfully implemented DSpam into my qmail toaster install but had a
couple of issues that need to be addressed if considering putting DSpam into
the current toaster.
First issue I had was initially deciding on how to integrate DSpam (as is
been mentioned already) and how best to manage it. This basically came down
to what the customers wanted which was to leave dealing with marking which
messages are spam to the systems administrators. Really sucks of course
considering that a simple error in marking a email for a client would then
cause them to not get the email and getting a real earful.
Second issue I had was mainly the limitations of where I could implement
DSpam into the current toaster setup. With the current toaster there were
issues with using either procmail or maildrop as LMTP or LDA which seemed to
cause messages to be lost in the void when mail was being delivered (with
catchall's and actual virtual user accounts). There has been discussion
already on this list about integrating DSpam with simscan which has been
done already, but, for an earlier version than what is being used at
present. The patch that is also available still isn't bug free and as
mentioned only works with version 1.1 of simscan. This is the best approach
(I believe) to integrating DSpam into the current toaster as even before
mail is accepted for delivery DSpam must allow it to pass. This
unfortunately was not how I implemented DSpam. I eventually ended up
setting up DSpam as a relay on an aliased interface on the same box which
would then send mail after it had passed through back to the other IP on the
same host. This is working ok but would prefer the simscan integration.
There was however one issue that was a nightmare to deal with, especially
after the mail server went live. This was getting the administration panel
for DSpam working. Now this wasn't a DSpam issue but more of an apache one
as the minimum GID of a group that is allowed to suexec CGI scripts was >=
1000 and vpopmail has a GID of 89. Hmmm, what to do here? I had to
recompile vpopmail (after editing spec file) for the adjustment and then
rebuild any other RPM that was dependant on vpopmail and finally changing
ownership of all the various files/directories that vpopmail had some type
of ownership of. After a long ordeal the finished product was well worth
it. I have gone that little bit further with DSpam and have setup another
system that now does all the relaying separately to the Qmail Toaster and
just has messages for legitimate users being passed to the actual mail
server which further reduces the load of the mail server instead of bouncing
messages back and forth. As someone has asked or mentioned about
implementing ClamAV into DSpam this really wasn't very difficult. All I
merely had to do was install the clamav RPM and configure clamav to listen
for TCP connections, uncomment a few lines in the dspam.conf file (ClamAV
relevant sections), update clamav db using freshclam and finally starting
clamav and restarting DSpam (if already running before installing ClamAV).
From what I have experienced so far, with DSpam, any further spam fights
(not the canned kind) we will most certainly win. After receiving a fewmessages (for my own email account) that were spam, I logged into the
administration panel and marked these messages and a few others that had
gotten through and well I haven't seen messages of those type come back
through again. Similarly, other admin members did the same after showing
them what to do and voila same thing for them as well - less spam. Over the
course of the next few days we have had significant drop in spam coming
through which for me was a wet dream come true considering the levels of
spam that were originally getting through even with spamassassin being set
to "Super Paranoid Level". But all in all my hat is off to the folks over
at nuclear elephant. Much thanks to everyone hear as well for the qmail
toaster project and their input.
Rangi