Helmut, All I can say is that I considered DSPAM for 5 or 6 years and it seemed impregnable, which may be why there's not a lot of help out there and the reason the mailing list is quiet, as the documentation doesn't lend itself to newbies, until I came across this <https://qmail.jms1.net/dspam/> site. I was forced to find a spam solution for a client and after searching for help and studying DPSAM thoroughly for a week or two deployed it on my own and then a client's--after great success on my own. There were a couple hiccups but we haven't looked back. I now use my own script to install it (and everything else necessary) from EPEL and create the database in MySQL. I've read that PostgreSQL is better suited to DSPAM and I might try it later. At my own site, I no longer get spam. At the client's site spam is no longer a problem either.
In my setup DSPAM is called in the domain .qmail-default file and I use the user's .qmail and a maildrop file to send marked spam to each user's 'spam' folder in their Maildir directory. It was very easy to train--spam only, no ham training--and now user's inboxes aren't cluttered with spam (this is very nice when using a small interface like a phone) and there are hardly any false positives to speak of. My clients are very pleased with it. I will be putting DSPAM on another site when I upgrade that site from CentOS 4 to CentOS 5 or 6 as DSPAM needs a newer MySQL release. With my script, installation takes about a minute, more or less. In my experience, the promise of the DSPAM developers was right on the money. It has worked 'as advertised.' I would however like to find a different way of implementing it, maybe sometime during SMTP server delivery, or I may have to investigate its use with simscan or even the Dovecot lda. Eric B. On 3/12/2014 9:45 PM, Helmut Fritz wrote: > I had never heard of DSPAM before, took a look at it. Looks very > interesting, especially the individual email account quarantine that they > can manage via web - much like Barracuda (which my exchange users like). > > However, the last news post and release was in April 2012, documentation is > next to nothing (although readme is pretty detailed, just not quite > enough)(but the linuxwall wiki probably has the mostest - how's that Eric! - > but is external to the project and says it must interface with postfix), and > there *seem* to be plenmty of unanswered threads in the archive of the > dspam-user list. > > I would argue caution, unless someone on this list knows somebody 'over > there' and knows better than is apparent at first blush. > > By comparison, despite many people arguing that qmail is obsolete, > deprecated, discontinued, or what have you at least this list is very active > and people help each other quite a lot. If I am off base, that is fine - I > just took a quick look at the DSPAM project. > > -----Original Message----- > From: Eric Shubert [mailto:[email protected]] > Sent: Wednesday, March 12, 2014 5:54 PM > To: [email protected] > Subject: [qmailtoaster] Re: Battle SPAM--best practices > > On 03/12/2014 11:24 AM, Eric Broch wrote: >> On 3/12/2014 11:52 AM, Jim Shupert wrote: >>> what might be some wisdom on SPAM >>> Best practices - gotchas - options - real world experiences That work >>> >>> thanks >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: >>> [email protected] >>> For additional commands, e-mail: >>> [email protected] >>> >> I implemented DSPAM at home and on one client site and it practically >> eliminated spam. >> >> --------------------------------------------------------------------- > I do like what I've seen of DSPAM, and would like to include it in QMT > eventually. I don't expect that to be next in line, although the more people > who use it, the more sooner it'll be incorporated. I wasn't the first to use > spamdyke with QMT, and now it's finally a 'stock' > component. BL, this is a community driven project (I hope). > > -- > -Eric 'shubes' > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
