Hi Hugo, > Have you considered DSPAM instead of spamassassin?
I remember looking at this a few years back and rejecting it. I don't remember why, but I remember I did... > I don't know > spamassassin that well, Here is my rub, because I am familiar with it, and it has served me extremely well over the years. while I am willing to consider alternatives, it doesn't change that I would still rather use the thing I know. its a bugger about the spamc username/email-address thing... > but i'm aware that DSPAM is highly configurable, > supports per user settings, including separate spam dictionaries, > quarantine, etc ... and it's highly accurate if configured/trained right > and it's FAST. I have spent some time today looking over documentation for dspam, I certainly don't find any reason to reject it presently. In fact, it seems to have some very cool features. I will install it to see how it works. Right now I am building a test server, though, so unfortunately I wont' be able to put it under load to test it out. > I would also advise you to setup your content scanning > (spamc, dspam, etc) at the delivery time, and not at message acceptance. > For that particular stage i would advise other tools such as early > talker disconnection, greylisting and helo checking, or even rbls if > that rocks your boat. I do all of these things, too, but on my two busiest servers (couple hundred users each), I still reject between 20 and 50 mails a day on each machine due to spam score being over 10. It is not a lot, but I look at spam filtering like I look at security: there are several layers and several components, each on it's own would be inadequate, but when added together they make a very formidable solution. So I see fair value in dropping these messages at smtp time as one contribution among many to a greater overall solution. But this is not my old system, and one has to be prepared to replace old habits from time to time. I will consider this advice diligently... > Content analysis is usually a costly operation and can lead to false > timouts, when accepting mail, making the remote server retry the > delivery and causing duplicate message delivery. That is interesting. As far as I know, my servers have never experienced that. However, I do agree that scanning/filtering is *very* resource intensive, even for my relatively small amount of users I still need a reasonably decent machine. I have often wondered how much machine I would need to serve mail for a few thousand instead of a few hundred. This tidbit is noted for future reference, when I pick up that size of customer ;) > That said, IMHO i would > leave simscan to work with clamav only and handle spam later in the process. > > Although it's a bit out date, you could take some ideas from a web page > where i explain a possible setup. > > http://hmonteiro.net/howtos/qmail-ldap/start > > That link is for an empty page, but it will show you 4 sub pages on the > left menu regarding several aspects i talk about above. I found your pages when starting the whole qmail-ldap thing. I found your article on using policyd interesting, I may give that a try in the near future as well. For the time being, I am on enough unfamiliar ground as it is... > By no means > that's the only way to setup things, nor it's the best in every case, > but i'm sure it will give you a couple of ideas to work on. Indeed it does. And I would like to express my gratitude that you took the time to share with me, it is very much appreciated... > > Regards, > > Hugo Monteiro. > -- Bob Miller 334-7117/660-5315 http://computerisms.ca b...@computerisms.ca Network, Internet, Server, and Open Source Solutions
