ClamAV and SpamAssassin installed and maintained by DirectAdmin

I

IT_Architect

Verified User
Joined
Feb 27, 2006
Messages
1,094
ClamAV and SpamAssassin installed and maintained by DirectAdmin

Thoughts:
If there is something needs to be done almost every time, it shouldn't need to be done at all. If almost everybody is installing ClamAV and SpamAssassin, then it should be part of custombuild and the update process.

Aside from our own e-commerce sites, if our web hosting customer's sites were down for a week, they wouldn't even notice. It would be someone else who would alert them. When there is a problem with their e-mail, we'll hear about it in 5 minutes. E-mail is what is critical to their day-to-day business.

Current Situation
Currently, ClamAV, SpamAssassin, and updates from DirectAdmin create an high-maintenance situation. Here are the reasons.

1. I set up the chron to tell me when updates are needed, but I loathe seeing them. About two-thirds of the time they overwrite my exim.conf files. Then I need to:
a. Add ClamAV again
b. Uncomment the SpamAssassin lines.
c. Adjust parameters such as message_size_limit etc.

2. Over the past months, I've noticed that SpamAssassin scores are higher. Customers are raising their spam thresholds or turning it off. On new sites, they are score incoming messages quite high. After hours of analyzing, it appeared the new sites scored incoming e-mails alarmingly high, while established sites leveraged their Bayesian data to reduce the scores, but they were still much higher than they once were. The reason this time seems to come from the old rules no longer working well because some of the sites it used for checking are no longer available on the web. Having up-to-date rules I'm finding is more important than an up-to-date SpamAssassin. However, even after DA install, and enabling SpamAssassin manually according to the How To, it still doesn't leave me in a position to run sa-update. There is more that you need to manually install, and fight errors to get it to work.

Suggestion:
1. Have ClamAV and SpamAssassin install and be ready to go when you do a custombuild install.
2. Add sa-update to the chron options.
3. Have DirectAdmin maintain the exim.conf. Have a file that can be included that contains admin overrides for things such as message_size_limit etc. That way we can leverage improvements from updates without disabling the anti-virus and anti-spam.

Thanks!
 
We'd love to be able to add an antispam feature or an antivirus application from custombuild as long as we can choose which one.
We just don't see the value of using SpamAssassin when there are tools like dspam out there that are doing the same job while using less resources.

"./build antispam dspam" would build dspam, uncomment the required sections in exim.conf, add a DA compatible dspam.conf file, build the database and modify the spam page to let users manage the way they want DA to handle their spam.

Same for any other solution.
 
1. Currently, what we have to maintain our servers up to date discourages admins from using it. The core of the problem revolves around the maintenance of exim.conf during an update. Often, the file is replaced, and you automatically lose Anti-Virus, Anti-Spam, and necessary E-mail overrides, such as message size limits. A new strategy is needed here during the update process in order to make server software updates practical.

2. In very few instances would admins install DirectAdmin and not use the e-mail portion. Thus, installing some form of auto-maintaining Anti-Virus and Anti-Spam are a base requirements.

3. The manual install procedures shown in the How To for SpamAssassin does not include installing the tools necessary to keep it up to date nor a chron procedure. These should also be added.

Other: I would estimate that many admin's opinions of the effectiveness of SpamAssassin are colored by the lack of automatic updating of the rules. Whatever anti-spam system is used, we cannot expect it to maintain its effectiveness if it does not receive timely updates. Almost without a doubt, many are being affected by issues such as http://groups.google.com/group/linux...0c97eb62641887 and very likely many more like it before and since that updated rules have long since addressed.
 
Here are just 2 examples of how a SpamAssassin without updates doesn't work:
1. Fall of last year said to raise the score up to 2.4 points http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/490c97eb62641887
2. The 2010 bug that hit at the beginning of the year that raises scores by up to 3.4 points https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269.

I have 3 installs of FreeBSD 64. SA-Update doesn't work on any of them so I cannot use the update tool. There is no approved procedure to even get it working with DA without risking the DA setup.

SpamAssassin is on 3.3.1 and we're on 3.2.5. The fixes are late in getting back-ported back to 3.2.5, an admission from the maintainers.
 
I'm still waiting for an exmple of exactly what, done to update exim, causes a rewrite of exim.conf. I've never seen it so I can't fix it.

Jeff
 
jlasman said:
I'm still waiting for an exmple of exactly what, done to update exim, causes a rewrite of exim.conf. I've never seen it so I can't fix it.Jeff
Click to expand...
DA has some recommended procedures to assist you in keeping your servers up to date which can be found here on step 3: http://help.directadmin.com/item.php?id=247. About 2/3rds of the time you end up with a brand new exim.conf. I'm running FreeBSD 7.x 64 if that matters. I suppose when they need to do and update they need to do an update, but what happens without intelligent management of this file, the update leaves the server with no Anti-Virus, no Anti-Spam, and lost user settings to where users can't send and receive their larger attachments anymore.
 
Last edited:
The only code which could cause the problem on your linked page is:
Code: 
cd /usr/local/directadmin/custombuild
./build update
./build all d
I've asked smtalk (Martynas) to look at this thread and let us know if there's a way to make sure that it doesn't update exim.conf. My belief is that it reallly should never update exim.conf, as exim.conf should remain fully customizable by the user. Let's see how he responds.

Jeff
 
Mail options:
exim - install/update Exim using "./build exim" or "./build all". Possible values: yes/no (default: no). This option is only available from CustomBuild 1.2.
mail-header-patch - use PHP mail() header patch whith PHP installation/update. Possible values: yes/no (default: yes). No longer available since PHP 5.3.0.
dovecot - install/update Dovecot using "./build dovecot" or "./build all". Possible values: yes/no (default: yes).
eximconf - update exim configuration file (/etc/exim.conf) using "./build exim_conf" or "./build all". Possible values: yes/no (default: no).
Click to expand...

Isn't that what setting "exim_conf=no" in the options.conf file used for?

David
 
Should be. I think the problem may be that the first time it's run (by installation?) it's set to yes. Anyone care to check?

Jeff
 
You must log in or register to reply here.
Back
Top