How to set default spamassassin settings for existing users in the latest DirectAdmin?

David Victor

Verified User
Joined
Nov 6, 2019
Messages
20
Hell everyone,

I know we can still use the deprecated way of doing this (which is nicely explained in: https://forum.directadmin.com/threads/enable-spamassassin-for-all-users.46983/) but since DA version 1.669 the spamassassin defaults are officially defined inside the /usr/local/directadmin/data/templates/custom/spam_defaults.json. Therefore the nice script provided by Stunshot in the aforementioned forum post officially is no longer the way to go.
Do you guys and gals have any idea how to utilize the /usr/local/directadmin/data/templates/custom/spam_defaults.json file to make sure the values inside are also applied to existing users?

All suggestions are welcome, and if I suddenly have an epiphany I will share it with you ofcourse!
 
but since DA version 1.669 the spamassassin defaults are officially defined inside the /usr/local/directadmin/data/templates/custom/spam_defaults.json.
Just upping this post again, because in fact this is not the case and I'm wondering some things too.
The /custom/spam_defaults.json file is to -override- the default settings which will be created by Direcatadmin.

But in spite of other default templates, the default settings created are -not- present in the same file in the default /template directory of Directadmin. So if these are the defaults, where are they coming from or are they hardcoded into DA?

Which rises the question, exactly which are the defaults created by DA or are these mentioned in the docs the defaults.

However, another question rises too. This json file seems to be a combination of the filter and filter.conf file, but does not have the content of the user_prefs file.

I do have the old way in place just created a testuser and my scripts was used, nothing was overwritten. So good thing is this still works perfectly.

So I presume the new way is only used when no scripts are present? And if that is the case, seems we still need the scripts to make some custom user_prefs for the home directory right?

I'm probably confusing something or it might only be working when then scripts are not present. But I use the script for the user_prefs.
Or can we now customise the filter and filter.conf file by creating that custom .json file and still use the user_create_post.sh script for custom user_prefs defaults?

@zEitEr you have a clue on this maybe? About user_prefs and where the defaults of the .json are stored, hardcoded or not?
 
@zEitEr you have a clue on this maybe? About user_prefs and where the defaults of the .json are stored, hardcoded or not?

Actually never used spam_defaults.json before. It seems the things change, so we will need to use new options instead of old ones. Anyway the default values can be seen on a clean system in DirectAdmin interface only, I believe, as they are hardcoded.

The docs https://docs.directadmin.com/change...nning-will-be-activated-by-default-if-allowed say:

If a User is created with the spam option set to ON, this change will now activate Spam Scanning for the User's by default. If the User then creates a second domain, it will use the settings from the first/main domain from the account.
 
this change will now activate Spam Scanning for the User's by default.
Yes that is what I read too, but as you can read from my reply, I created a test user and the settings in my scripts were used and not the hardcoded scanning values.
Anyway, since the scripts still work and are not overwritten by the hardcoded values, we don't really have to change anything.
 
Well it can't really or at least not part of it as the new style has no solution yet for a custom user_prefs file server wide.
 
Sorry, can't agree with you. DirectAdmin developers are on their way to unify everything and get rid of old style. It is only a matter of time, when they finish the process. In a year - two, you might find it not working any linger.

I will be OK, if I'm wrong though)
 
Sorry, can't agree with you.
LoL, sorry, I think we do agree. I ment to say that some script must be kept working until another solution is found to be able to provide custom user_prefs files for Spamassassin, so in this way part of it can not stop working until that moment.

But I'm sure with the work they will do they will find a solution for this or maybe some custom scripts might keep working (or options added to a .json file or whatever).
So yes at a certain point, it's evident that current scripts won't be working anymore.
 
Back
Top