SpamAssasin - so why it's not optional? and other suggestions

C

ClayRabbit

Verified User
Joined
Jan 3, 2004
Messages
260
Location
Russia
Version 1.225 includes Spamassasin user interface. That's very useful feature, thanks DA.

But why there is no option to turn SpamAssasin completely off for an account?
So customers forced to use SpamAssasin even when they don't want it. And our server will spend system resources on checking mail for such users, when it's not needed by anyone at all!

I suggest, for example, we can use some token file (like ~/.spamassassin/.enabled) and chek this file existence in spamcheck_director section of exim.conf.
So SpamAssassin will run ONLY if user enabled that.

Same thing with Webalizer, for example. Server loaded heavily while it generates daily stats. Why we don't have on/off option for Webalizer stats (turned off by default)? Some webmasters don't need it for their sites - so let's don't waste our CPU time and disk space! :)

And one more thing. I suggest it's better to run spamd with '--socketpath=/var/run/spamd' and spamc with '-U /var/run/spamd' options. Unix sockets connections is faster than tcp/ip isn't it?
 
Last edited:
I agree, but every tool should be optional and we should be able to define paths also.

Plan creation:

[X] spamassassin
[ ] virusblocker
[ ] webmail path : /squirellmail
[X] dbadmin path : /phpmyadmin
[X] stats path : server.com:9999/session.cgi?profile=$DOMAIN
 
Agreed SAhas to be optional. All plugins should be optional. Web stats should be optional.
 
SpamAssassin is optional on a server basis.

By default, exim.conf is delivered with this section:
Code: 
# Spam Assassin
#spamcheck_director:
#  driver = accept
#  condition = "${if and { {!def:h_X-Spam-Flag:} {!eq {$received_protocol}{spam
#  retry_use_local_part
#  transport = spamcheck
#  no_verify
To turn SpamAssassin on, you uncomment all the lines except the first one, the one that says "# Spam Assassin"; you leave that one alone.

Then you restart exim.

To turn off Spam Assassin off, you recomment those lines, and again restart exim.

Jeff
 
It may be possible to set up SpamAssassin as optional on a per user basis.

(Do you mean per mailbox or per user?)

But every implementation of SpamAssassin I've ever seen has done it by just changing the number of "points" needed to a very high number.

Which means that SpamAssassin is still working for the user.

:(

We probably have the resources available now to create a third-party solution to work on a per-mailbox basis, but it would definitely not be cheap; it would be at least us$100 to us$150 per server install. And I'm not sure anyone wants to pay that much.

Jeff
 
SA can and is implemented on a per email box basis in Hsphere and Plesk 7.
 
We probably have the resources available now to create a third-party solution to work on a per-mailbox basis, but it would definitely not be cheap; it would be at least us$100 to us$150 per server install. And I'm not sure anyone wants to pay that much.
Click to expand...

Excuse me Mr. Lasman,

Thats the equivelent of saying that if you have an account for these forums, that you're "opted IN" for a spam mailing list from xyz.com ... If it didn't give you an option to "unsubscribe" - you'd be a bit angry. Another analogy is the Govt's insistance that IE be removed from Windows ... and/or the user be given some method of removing it.

Having a function of the control panel forced ON may not be desired by all parties. They have no option to turn it off, but it wasn't part of the package that they signed up for... so the only choice they have is to either abandon the control panel, or suffer with high server loads because the modified control panel is affecting server performance.

Another example is Installatron. If DA used Installatron in it's next release, but now said it's mandatory for you to offer it... you wouldn't be happy. Installatron is available on a "per domain" basis - thats the way it should be.

Now keep in mind, I'm not "bi**hing" about this... but I can definately see where it should have defaulted to "off" - or made it a plugin where the server administrator could have chosen to install it or not.

Proposing a solution that could potentially cost server administrators THOUSANDS of dollars for an organization with multiple servers is irresponsible. Instead of promoting your company in every post, how about working WITH us to find a amicable solution to this issue?

Respectfully

Joe
 
Last edited:
Sa comes available with Plesk power pack or through 4PSA I believe.
 
It should have been offered as a plugin. Disabling it or not enabling it is not much use if it's already integrated into the skin (which it seems to be)

And to cross-post something from this morning:
I was mulling over this last night....

A couple of things regarding this implementation:
1. This is not per user, but per domain, as DA only has one user per domain

2. If you have a busy server then the load will become an issue as each and every single email will have to be processed by the enduser's rules

3. This may not be compatible with Spam Assassin 3, as the user preferences change quite dramatically


The other question is this:
How do I turn this off completely?

According to this:
http://www.directadmin.com/features.php?id=424

It's an integral part of the skin.
 
hostpc.com said:
Thats the equivelent of saying that if you have an account for these forums, that you're "opted IN" for a spam mailing list from xyz.com ... If it didn't give you an option to "unsubscribe" - you'd be a bit angry. Another analogy is the Govt's insistance that IE be removed from Windows ... and/or the user be given some method of removing it.
Click to expand...
I wish I could understand what you mean. I can't.

SpamAssassin has always come turned off, and it still does. Perhaps they should default it to turned on now that they've got an Interface to control it by domain. But obviously that's something to take up with them, and just as obviously they, for some reason known only to them, haven't seen fit to respond to this thread.
Having a function of the control panel forced ON may not be desired by all parties. They have no option to turn it off, but it wasn't part of the package that they signed up for... so the only choice they have is to either abandon the control panel, or suffer with high server loads because the modified control panel is affecting server performance.
Click to expand...
If you've read my posts on other forums you've seen that I don't believe in SpamAssassin myself, but nevertheless offer it because I have clients who want it. I solve the server load problem the same way many other hosting companies do, and that is by having enough horsepower to run it. I also try to limit the amount of horsepower I need by strongly urging clients to use SpamBlocker rather than SpamAssassin. That may not work for you.

But again, this is something to bring up with the DA staff. Perhaps they should make available a skin without SpamAssassin for those of us who don't want to turn it on. But that needs to be discussed with them.
Another example is Installatron. If DA used Installatron in it's next release, but now said it's mandatory for you to offer it... you wouldn't be happy. Installatron is available on a "per domain" basis - thats the way it should be.
Click to expand...
If you'd read my posts, you'd know you were preaching to the choir.
Now keep in mind, I'm not "bi**hing" about this... but I can definately see where it should have defaulted to "off" - or made it a plugin where the server administrator could have chosen to install it or not.
Click to expand...
As I've said before it's not that simple because turning it on or off requires changes to exim.conf. Once you manage exim.conf through a web-based interface you must manage all of it through a web-based interface. And that severely limits everyone.

If what you want to do is tell DA how to build their system then do so. And this thread may or may not be the best place to do so. But I'm not sure why you're complaining to me.
Proposing a solution that could potentially cost server administrators THOUSANDS of dollars for an organization with multiple servers is irresponsible. Instead of promoting your company in every post, how about working WITH us to find a amicable solution to this issue?
Click to expand...
Or maybe I do. Are you complaining because I propose to spend money to hire a programmer to do it, and then charge for it?

I have almost no personal interest in the solution, since our primary business is NOT webhosting. Our primary business, as you can determine from my signline, is supporting hosting companies in what they need.

It would cost us quite a bit to develop the solution, and we'd also be forced into maintaining alternate skins for DA forever.

So are you suggesting that I should give away my products, which I create to make a living, at no charge?

Do you give away all your hosting for free?

Perhaps.

If indeed this is what concerns you I can easily edit my post, and take out the paragraph offering to create a commercial solution. Then I can make a post in the Advertising Forum.

Then I suppose the only place my paragraph would appear on this forum would be in your quote. Would you then delete the quote from your post? Let me know. If you will, I'll be hapy to delete my original, and move it to the Advertising Forum.

But in my opinion to expect that others may not want to have commercial solutions is a bit short sighted.

Jeff
 
I think more then anything, this may just be an oversight by DA. People were desperate to have an SA interface, they just ofrgot some people may not want it. If every other control panel can offer SA on and off through the control panel, so can DA.
 
Originally posted by jlasman We probably have the resources available now to create a third-party solution to work on a per-mailbox basis, but it would definitely not be cheap; it would be at least us$100 to us$150 per server install. And I'm not sure anyone wants to pay that much.
Click to expand...
I have already described easy way to implement that feature on per-user basis. It's not critical but I believe it must be per-user basis instead of per-domain because:
1) We have username@servername mailbox and i think it's must be affected also.
2) Anyway there is only one ~/.spamassasin/user_prefs file per user (not per domain).
As I've said before it's not that simple because turning it on or off requires changes to exim.conf. Once you manage exim.conf through a web-based interface you must manage all of it through a web-based interface.
Click to expand...
It's simple. It's not reqired to manage exim.conf through a web-based interface. All we need - to add one line to exim.comf - only once.
require_files = "/home/${lookup {$domain} lsearch {/etc/virtual/domainowners} {$value} {$local_part} }/.spamassassin/.enable"
Click to expand...

After that we will able to controll SA on/off with file token.
 
Last edited:
blacknight said:
This still doesn't solve how I can turn this thing off totally and remove any trace of it from the skin.
Click to expand...

http://help.directadmin.com/item.php?id=36
but from end to begin ;)

changes in your /etc/exim.conf

cooment:

# Spam Assassin
#spamcheck_director:
# driver = accept
# condition = "${if and { {!def:h_X-Spam-Flag:} {!eq {$received_protocol}{spam-scanned}} {!eq {$received_protocol}{local}} } {1}{0}}"
# retry_use_local_part
# transport = spamcheck
# no_verify

kill spamd
restart exim

remove page spamassassin from skin
 
You must log in or register to reply here.
Back
Top