General guideline for reducing SPAM on DA servers?

Favorite Anti-SPAM tool for DA?


  • Total voters
    6

WholesaleDialup

Verified User
Joined
Sep 25, 2004
Messages
179
Location
San Antonio, TX
:confused:

I know that anti SPAM configs are often based on the admins personal preferences but..

With that being said, has anyone written a guide or suggestions for best methods for securing a new DA server in terms of SPAM reduction?

Some of the methods I have used in the past and are considering for this new server are:

1- SPAM Assassin:

I love SPAM Assassin but every time I try I have tried to set it up on a DA server, it just never works for me. I follow the instructions provided in the DA knowledgebase but never seem to get it right. Maybe this has gotten easier? I have setup SPAM assassin on NON DA servers a bunch of times and had no issues.

Is SPAM Assassin something I should consider? I know there could be resource concerns and not sure how well it plays with other methods such as Jeff's SPAM Blocker conf file and/or RBL's.

2- RBL's:

Have used them for years and they seem to help a LOT. Personally I would prefer to use the RBL's as only part of the decision to block based on the methods used with SPAM Assassin but as mentioned above, never had any luck with SA on DA.

Also, wondering what the best RBL's are these days. I use SPAM Haus now but that's about it. What others are working for other DA admins? What do you all think of Barracuda's list?

3- Jeff's SPAM Blocker conf file:

I have had this in place V2 forever I think as it is the default install for DA. I looked over the forum and saw mentions of V3, 4 and 5. Should I replace the default file with one of the newer versions? How does this conflict or complement either of the other two methods above?


I don't want to just hammer the server with 12 different methods for fighting SPAM because I want to be careful to not over do it in terms of slowing things down to a crawl because I have so many filters in place. So, I am looking for advice and opinions on which combination of the above 3 tools (or any other suggestions) are working best for current DA admins.

Thanks in advance for any help you can provide.
 
For what it's worth: I believe the poll to be flawed because I think we'd all use multiple solutions. YMMV.

Now moving on...

1. SpamAssassin: I use SpamAssassin. Installing it is sometimes hard, because of the perl requirements, but lately IU've used CentOS and RPMs to cover the prereqs, and it's gotten a lot easier. Use Custombuild2 to install it after the prereqs are satisfied. Note that if/when it fails to start email delivery will immediately break.

2. RBLs: These are the blocklists I currently recommend:
Code:
       cbl.abuseat.org
       bl.spamcop.net
       dnsbl.ahbl.org
       combined.rbl.msrbl.net
       b.barracudacentral.org
       zen.spamhaus.org
       hostkarma.junkemailfilter.com=127.0.0.2
Note that for some of them you may need permission or to pay.

3. SpamBlocker: Version 2 is currently used by DirectAdmin. Version 3 was meant to be a development version, and was finally relseased as Version 4. Version 4 is the current version I supply. Version 5 was meant to be a development version, to be released as Version 6. However I've since decided that John and I will merge our code bases, and I'm going to stop maintaining a separate version.

4. Using SpamAssassin to block rather than to redirect: This was discussed on these forums within the past few days. You didn't mention it, and at this point I'm not recommending it because of the time it holds connections open after the email data is received (which could cause a real disaster if the daemon stops running). But there are reasons to consider it, especially if you rewrite some of the RBL rules with better weighting, and then block on certain weights.

Jeff
 
Jeff,

First, as always you are a valuable member of this forum and to the DA community. Thanks

Yes, my poll is crap :) I just wasn't sure how to create it in a way that would provide any useful feedback.

I have read over and will consider your response, wait for some other responses and then take action on this new box.

Question.. So, you use all those RBLs at once? Do you feel that it slows down things quite a bit to be able to filter against all those RBLs for every connection to Exim? If so, I guess you just feel it's worth the trade-off.

I have been using really just SPAMHAUS for a long time and that seems to get rid of a LOT of mail. I have seen some good things from Barracuda's list though while working on other mail servers for other companies in the past. So, I think I may start by adding Barracuda once I go through their signup process, at least I think I remember they had one.

Thanks again Jeff!
 
That's the order in which I use blocklists, but perhaps I should put SpamHaus first.

Once a blocklist blocks an email, the nextone isn't tried, so there shouldn't be too much extra work for the server if you pick one to run first that (a) is free, and (b) blocks much of the spam.

As I mentioned, only use the ones you register for and in some cases get most of the spam blocked by free ones before moving on to check those which require payments if yoou hit a certain use threshold.

Which SpamHaus list or lists do you use?

Jeff
 
Although I am not focused on spam e-mail related matters yet, I'm very interested in this thread.

I have been just soaking it all into admin mailbox with default CB 1.2 installations, but am almost ready to examine and implement V4 of Jeff's exim.conf configuration.

I've always had some interest in examining the email message (content) source, headers, etc. In the past it was also helpful to have a bit of this trash e-mail to more quickly train bayesian type filtering.

One of my concerns is that I don't [un]knowingly whack my server IP(s) reputations.

With this in mind I'd like to add a related request if it's applicable, about the safety of the different options.

EG: easy - hard to create a bad situation for someone ready to implement optional spam handling methods. Conservative message bounce actions, etc. I'm sort of afraid of sending improper or malicious bounce messages.

..including options present in the basic DA user E-Mail Management unless that strays too much from the topic.

Spam related and hopefully not off topic, it would also be interesting to know if/how admins handle 'non-email' hosting. I have been experimenting with "v=spf1 -all" FWIW. Kind of wish null MX gathered more momentum.
 
Last edited:
I've always had some interest in examining the email message (content) source, headers, etc. In the past it was also helpful to have a bit of this trash e-mail to more quickly train bayesian type filtering.

One of my concerns is that I don't unknowingly whack the IP reputations.
By keeping spam-blocking by Block Lists ahead of SpamAssassin, you can block by reputation before you get to SpamAssassin.

But then running the default SpamAssassin rule sets take a lot of unnecessary machine resources, as they check everything against certain blocklists again, though no mail from senders in those blocklists gets to the servers.

So perhaps the best thing to do is write our own optimized version of SpamAssassin rule sets; I hinted at this in an earlier reply to this threae.

Another would be to block based on total point score based on using SpamAssassin the way it is now, and take out all the blocklists in exim.conf. However we'd have to decide if the current RBL rulesets would be adequate or if we needed to change/add/delete any.

And we might still have problems, because we'd be holding open connections after we receive data, until SpamAssassin decides whether to keep the email or reject it.

Another problem is that many mail servers don't recognize reject after data. so they won't return error information to senders. You may think this is unimportant, but there are problems with it:

RFCs require that all email either be delivered or returned. If you tell the sending server you don't want the email after they're no longer listening, you'e dropping the email without the sender ever knowing. So some mailservers, which will no longer send to servers which reject their email will keep sending, and even more important, false positives may not get reported. If your system calls something spam which is really important email, then don't you want the sender to know?
With this in mind I'd like to add a related request if it's applicable, about the safety of the different options.

EG: easy - hard to create a bad situation for someone ready to implement optional spam handling methods.
If only we could agree on one optimal method of classifying and blocking spam :).
Conservative message bounce actions, etc. I'm sort of afraid of sending improper or malicious bounce messages.
This has been discussed in several threads; I'm not sure if any of it has been well implemented. Anyone care to do the homework and report back? :)
including options present in the basic DA user E-Mail Management unless that strays too much from the topic.
Once I stop maintaining a separate SpamBlocker version and eveyrone migrates to the default DirectAdmin system (or at least almost everyone) it will become easier to include settings, options, etc., inside DirectAdmin.
Spam related and hopefully not off topic, it would also be interesting to know if/how admins handle 'non-email' hosting. I have been experimenting with "v=spf1 -all" FWIW. Kind of wish null MX gathered more momentum.
There are problem with -all. For example, it completely breaks forwarding and it makes it impossible for you to send email from a server other than your own (this can often happen when you're travelling, and when using certain ISPs who invisibly reroute all outgoing email through their own email servers.

Of course without -all SPF is of little help in the anti-spam world.

And it breaks the other use of SPF as well; that of verifying against spoofing (which was the original point of SPF.

A good example is email from PayPal. Youy'd think that PayPal would benefit mot from using -all as it would allow everyone checking against SPF to know if email purporting to be from PayPal is spoofed. But PayPal has had to use ~all as otherwise forwarding of PayPal email simply wouldn't work. People accepting email at an address at their own domain and then forwarding it (for example) to their gmail account, would have it marked as spam.

For what it's worth, here's the PayPal spf record:
Code:
"v=spf1 include:pp._spf.paypal.com include:3rdparty._spf.paypal.com include:3rdparty1._spf.paypal.com include:3rdparty2._spf.paypal.com include:3rdparty3._spf.paypal.com include:c._spf.ebay.com ~all"
That ~all at the end means the rest of it is almost insignificant, though it can be (and possibly is; I'm not sure) checked by SpamAssassin which would give negative points to email coming from those servers to make sure it gets accepted.

Good luck in getting any two people to agree on what does and dosn't work :D.

Jeff
 
Thanks for your input. In reading your reply it seems perhaps I wasn't clear about IP reputation - I was referring to the DA server IPs.

I know anyone can shoot themselves in the foot by accident..

EG: Hypothetical spam prevention system presents advanced option(s) very casually, without bringing attention to actual levity of the choice.

I guess it would be better if asking if there are beginner & advanced solutions where selecting one over the other based on the operators knowledge or skill is to be taken into account -- from an admin perspective and the clients of the admin's services.

I've used some anti-spam accessories that were no-brainers and probably very safe for the hosting provider. I've used SA a while ago, but for instance, can it or any listed options provide 'user' (70yr old webtv user for instance) friendly interface or perhaps better to disable for certain segments of the server population.

..again, both as an end-user and admin perspective. Kind of like, in part, why limiting SSH is logical -- SOP the server admin follows to hinder the user ability to harm admin's ability to provide good service. hehe
 
You may be overthinking the problem. Thousands of users just use the DirectAdmin defaults and they seem to work.

I use my own SpamBlocker 4 exim.conf file, the latest (well not yet as of today) exim.pl file, and default installs of SpamBlocker and ClamAV (both from CustomBuild 2), and they seem to 'just work'.

As a not-far-from-70-year-old, I get your point :).

Jeff
 
Overthinking is one of my specialties. Kind of works well ..err contributes to my life's slow pace, among others things.

I was having trouble making the best choice on that example. Unfortunately age is such a good catch all, whether it be 'acting like a two year old' or the 'old fart' in the car ahead of me -- most people get the right idea. I was unable to discern a common trait appropriate for my example, and the forum.

Although my user experience certainly doesn't number in the thousands, the few known personally to me like to fiddle with stuff and will click whatever [ok] that presents itself, apparently with no thought in some cases.

I read about the horrors of an IP being listed in RBLs. I hope to be able to avoid the worry of that happening. It could take me a long time to get where I am going and don't want to find the need for IPs anytime soon, or cause harm to them for my provider. I'd guess people want to deal with being RBL listed as much as they want spam flowing into their inbox.
 
Back
Top