Spamassasin Blacklist Value Increase + Spamassasin Updates

[inquis]

Hi I recently found out that Spamassasin only allows 100 unique blacklist enteries and to modify it, one would

Connect to the database as root and input

~# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa

and then input

mysql> replace into misc values('spamfilter_max_addr_list_length',150);

150 being an example amount which can be amended as needed.

I done this before updating Spamassasin and it seems this change was erased and the list built up erased as well.

Is it possible to retain this value or hardcore this value in when any update for Spamassasin is applied ?

Is it possible to create some type of self healing rule or somthing that does this sort of thing so it retains this info ?

[scott]

If there is some kind of log event that would indicate the condition, we can do a SH rule for it. Oh, or I suppose another way would be to put a "watch" rule on a specific file to detect when it changes, then use that to trigger a SH event. Havent tried that method yet, but we do custom email notifications for files now.

[faris]

The 100 item limit is Plesk-specific in the Plesk database. I don't see why a SpamAssassin code update would have any effect on this, unless we are talking about a microupdate from Parallels or a psa-spamassassin update from parallels?

Or have I misunderstood what's doing on?

[inquis]

well I am not sure whats going on, hence my question

[faris]

hehe

OK....

It is most unfortunate that the Plesk devs have imposed a 100 address limit via a setting in the database. This seems oddly small to me.

If my guess is correct and when you perform certain Plesk updates that setting gets reverted to 100, I think we are a bit stuck. I don't think we'll find any way to stop that setting reverting, and I'm not sure that it would be sensible to have an ASL self-healing rule that fiddles with a Plesk database settings (just my personal opinion).

So, if it was me, I'd be looking for a way around the problem. For example, I have a special file in /etc/mail/spamassassin/89_custom.cf where I put all my little additions. In my case they are mainly whitelists and special rules.

This file obviously has global effect, which might not be what you want. In any case, SpamAssassin isn't the best place to blacklist something, in my opinion, because SpamAssassin is quite resource-intensive on the scale of things.

So another way around the problem might be to use SpamDyke in conjunction with HaggyBear's SpamDyke Control Panel for Plesk. This has per-domain(*) sender/recipient email address whitelist/blacklist facilities and the added benefit of reducing server load massively because the blacklisting happening with minimum CPU load and the message never gets to SpamAssassin if it is blacklisted.

Individual customers can be given access to control blacklists and whitelists for their domains and other settings via Plesk itself too. There is no practical limit to the number of blacklist/whitelist entries.

(*) We do not allow our Plesk users access to SpamDyke settings, but the option is there. I've never played with it, however. Note also that we are talking about per-domain settings. This means you, the Plesk admin, can blacklist and therefore block an address globally to all domains via SpamDyke, or your customer can blacklist and block an address on his domain only. You can't block at an individual mailbox level. i.e. john@domain.tld can't have different settings to jane@domain.tld -- the settings are at a domain.tld level.

[scott]

For what its worth, the blacklist code in spamassasin is extremely efficient. It happens before any other checks, and I remember when I first started doing tests with it years ago I had from-line blacklists several million lines long. Even that didnt add more than a second or two to the overall process time.

[inquis]

Hi Faris,

I am happy with spamassasin, once the limit is lifted it can work on a global / per domain > per mailbox scale with a much needed *@doman.tld schema that kills off most spam from the type that rotate alpha numeric variation outgoing from a particular domain to defeat spam catchers.

Not going to give clients access to something like that as it probably would cause trouble ;0)

As per my initial mulling's is some type of check that the limit is xxxx and if not raise it back to xxx, feasible in any way shape or form, even if its a switched off by default type of option or rule.

I am a little bit apphrehensive to get other bits of software into play as the idea of keeping plesk as self contained as possible make more sense to us than adding on extra bit of stuff that essentially does the same thing

Could a cron script do this or create a backup of the blacklist file for safe keep-keepy ?

[inquis]

For what its worth, the blacklist code in spamassasin is extremely efficient. It happens before any other checks, and I remember when I first started doing tests with it years ago I had from-line blacklists several million lines long. Even that didnt add more than a second or two to the overall process time.

I find it works well with asl and even with a couple of hundred entries its doesn't flag too badly.

[biggles]

hehe

So another way around the problem might be to use SpamDyke in conjunction with HaggyBear's SpamDyke Control Panel for Plesk. This has per-domain(*) sender/recipient email address whitelist/blacklist facilities and the added benefit of reducing server load massively because the blacklisting happening with minimum CPU load and the message never gets to SpamAssassin if it is blacklisted.

Individual customers can be given access to control blacklists and whitelists for their domains and other settings via Plesk itself too. There is no practical limit to the number of blacklist/whitelist entries.

(*) We do not allow our Plesk users access to SpamDyke settings, but the option is there. I've never played with it, however. Note also that we are talking about per-domain settings. This means you, the Plesk admin, can blacklist and therefore block an address globally to all domains via SpamDyke, or your customer can blacklist and block an address on his domain only. You can't block at an individual mailbox level. i.e. john@domain.tld can't have different settings to jane@domain.tld -- the settings are at a domain.tld level.

+1 on this. Works extremely well!

[breun]

I'd notify Parallels and explain the situation to them. They might just change the limit.