I prefer scanning during the smtp session as well, as it elimintates the
bounce and possible backscatter.
I don't recall for sure off hand which of SA or DSPAM is better at
global vs user oriented scanning. My thinking was to do the global scan
during smtp, and user scan (along with filtering) during delivery.
With spamdyke now being able to handle authentication (and I expect user
verification), it might be practical to put the user oriented scan up
front during smtp. That would be ideal. Then we would probably just go
with one over the other.
If DSPAM can be easily configured to do global and/or user targeted
scanning, we might go with that. I'm not necessarily adverse to
switching from SA to DSPAM. This would need to happen in conjunction
with replacing simscan though, as I don't believe simscan has a DSPAM
configuration. Or does it?
Thanks.
--
-Eric 'shubes'
On 03/13/2014 09:32 AM, Helmut Fritz wrote:
Yeah really - I would like to test it, but I think I prefer it as the smtp
proxy. I would like to run it on the same machine as qmailtoaster.
-----Original Message-----
From: Eric Shubert [mailto:[email protected]]
Sent: Thursday, March 13, 2014 4:21 AM
To: [email protected]
Subject: [qmailtoaster] Re: Battle SPAM--DSPAM
Helmut, mostest I like. :)
EricB, have you shared your script somewhere yet, or did I miss it?
Good points, both of you.
I think DSPAM is most suitably implemented in the delivery process.
While maildrop is included in the COS6 release of QMT, it is being
deprecated. QMT will be using dovecot's LDA along with sieve in the not too
distant future (fairly high priority). This will allow QMT to do server-side
filtering, which I think will be a big boon. It would be most appropriate to
consider 'official' DSPAM inclusion (at least an option for it) at that
time, or shortly thereafter.
I wouldn't look toward doing much with simscan. That is likely to be
replaced (distant future, low priority) with amavisd-new. Jake had taken a
look at this some time ago.
Has anyone else out there implemented DSPAM with QMT yet?
Thanks.
--
-Eric 'shubes'
On 03/13/2014 12:06 AM, Eric Broch wrote:
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
