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

I don't think this is the solution people are looking for. If you edit the skin, you always have to edit the skin with each update.
 
rldev said:
I don't think this is the solution people are looking for. If you edit the skin, you always have to edit the skin with each update.
Click to expand...

Exactly.
If we had one server it would be one thing, but we don't
 
Well I don't see why DA can't make this a plugin. Afterall they should know their plugin system better then anyone. I can live with webalizer right now as not being a plugin, but SA has to be a plugin.
 
rldev said:
Well I don't see why DA can't make this a plugin. Afterall they should know their plugin system better then anyone. I can live with webalizer right now as not being a plugin, but SA has to be a plugin.
Click to expand...

I think
Webalizer and access and error log files especially has to be options because 50% (or more) don't use this
... and this is the reason why we need more HDD space for logs :(
And of course, logs must be including in user's quota!
User must decide if he wants or not to use logs (and space for logs)
 
rushost said:
I think
Webalizer and access and error log files especially has to be options because 50% (or more) don't use this
... and this is the reason why we need more HDD space for logs :(
And of course, logs must be including in user's quota!
User must decide if he wants or not to use logs (and space for logs)
Click to expand...

Under European law we are obliged to retain logs, though for how long is still to be decided.
 
Hello,

Sounds like a couple of people are a bit frustrated, so I'll clarify how we've set it up.

We all know that spamassasin doesn't come enabled on systems, which means the spamd program will not be running. The interface checks to see if it's running before letting the clients into the control panel. If you want it off, then don't run the spamd (and don't enable it in your exim.conf).

Spamassassin is setup per client account, since it's stored in /home/username/.spamassassin/user_prefs. The interface is provided for all domains even though it's only saved in 1 location. There is a difference between domains only in that you can route spam with the first option.

I can look into a "condition" for turning it off. It would be a simple addition to the exim.conf where if the user_prefs file doesn't exist, spamassassin is not run for that user. To turn it off, just delete the user_prefs (ill provide a button for the user).

Spamassassin works fine on a per system-user basis for the time being. We can consider adding it for per-inbox at a later date, but for the time being we'll stick with per client account.

John
 
I think some people may want to charge for spam filtering, hence only a plugin can accomplish this. A admin can assign it to a reseller or hosting plan of choice. It really is desirable that way and I doubt anyone would have a problem with it.
 
Thank you John... glad to see you alive :)

Seriously, that sounds like a solution that could be implemented fairly easily, and without the need for commercial applications and additional charges.

Joe
 
DirectAdmin Support said:
Hello,

To turn it off, just delete the user_prefs (ill provide a button for the user).

John
Click to expand...

and donot forget use spamd without "-c" ;)

But even if I delete the user_prefs, spamassasin continue checking emails with default settings :(
 
rldev said:
I think some people may want to charge for spam filtering, hence only a plugin can accomplish this. A admin can assign it to a reseller or hosting plan of choice. It really is desirable that way and I doubt anyone would have a problem with it.
Click to expand...

Yes it is true and good idea!
..because spamfilters like a php and cgi also using recourses of server and must be chargebly if provider want

(we need turn options for SA in reseller panel, like we have turn on/off option for php and cgi)
 
John

Thank you for the reply, but this still does not address the issue of spamassassin appearing in the skin.
If we manually edit the skin to remove the link our changes will be overwritten with the next update. If SA was being offered via the plugin API we would be able to decide whether to deploy it or not, which would be the ideal solution.
 
Hmmm... I'm not complaining but... Maybe... Maybe i'ts more comfortable to allow SA disabling without deleting user_prefs with all (maybe great list of individually composed) settings. Oh! Maybe just rename, but not delete, huh?! ;)

Yeah, it's difficult to satisfy ClayRabbit. I'll always ask for more... :)
 
rushost said:
(we need turn options for SA in reseller panel, like we have turn on/off option for php and cgi)
Click to expand...
I don't think so...

blacknight, so what's the problem if spamassasin link will be displayed, but spamassasin page will say something like: "This feature is not available" ?
 
ClayRabbit said:
I don't think so...

blacknight, so what's the problem if spamassasin link will be displayed, but spamassasin page will say something like: "This feature is not available" ?
Click to expand...
It will confuse clients and resellers. It's a lot better if they don't see it at all.
 
I'm thinking of adding some basic "if then else" statement scripting to skins which can use tokens. So that hiding buttons will become a breeze, without needing the use of php or perl, which adds overhead for forking etc.. I'd add SA as an option in the user packages, which would then add a token for use in the skins. The if-then-else statment could easily determine if SA is on or off and simply hide the button if it's off. The same could be done for many other buttons.

Re: removing -c with spamd. That isn't require since the "condition" will be looked at before the spamc is run, thus spamd will never be called in the first place.

I've uploaded an updated exim.conf and exim.pl (there was one minor typo in the exim.pl)

http://files.directadmin.com/services/exim.conf
http://files.directadmin.com/services/exim.pl

John
 
blacknight said:
It will confuse clients and resellers. It's a lot better if they don't see it at all.
Click to expand...
Perhaps.

But perhaps it will convince them to buy the option :) .

Thanks for the clarifications, John.

And thanks, clayrabbit, for reminding me of an easy way to do the implementation without changing exim.conf.

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