SpamBlocker 3.2.4-RC now ready for testing

Status
Not open for further replies.
DirectAdmin Support said:
Hi Jeff,

I believe it would be something like:
Code: 
condition = "${if exists{/etc/virtual/${domain}}{no}{yes}}"
where the negation is done by flipping the no and yes around. So if the path exists, the condition returns no (false) so the acl fails and isn't used.

John
Click to expand...
This is correct and I'm testing it. I don't get enough spam any more though, so it may take a while...
I'm not sure the brackets are required around "domain".
 
interfasys said:
Suggestion: Make the link between /etc/virtual/domains and /etc/virtual/use_rbl_domains the default behavior and introduce an exception file.
We only remove a few domains that absolutely don't want to use RBLs
Click to expand...
It's a good idea, and I'll consider it.

Jeff
 
DirectAdmin Support said:
Hi Jeff,

I believe it would be something like:
Code: 
condition = "${if exists{/etc/virtual/${domain}}{no}{yes}}"
where the negation is done by flipping the no and yes around. So if the path exists, the condition returns no (false) so the acl fails and isn't used.

John
Click to expand...

I tested the following
deny senders = :
message = We don't host the recipient domain
hosts = !+relay_hosts
condition = "${if exists{/etc/virtual/$domain}{no}{yes}}"
!authenticated = *
Click to expand...

And it doesn't work with bounce messages with no sender (<>)
The error message is
invalid "condition" value ""no""

Edit: I wonder if this has something to do with the fact that the recipient's mailbox was full...
Click to expand...
 
Last edited:
That's weird. Try taking out the quotes:
Code: 
condition = ${if exists{/etc/virtual/$domain}{no}{yes}}
John
 
DirectAdmin Support said:
That's weird. Try taking out the quotes:
Code: 
condition = ${if exists{/etc/virtual/$domain}{no}{yes}}
John
Click to expand...

This seems to be working, haven't seen that error message again. Will keep monitoring.

While on the subject, DA still doesn't support disabling the mail system on a per domain level if I'm not mistaken. We can choose whether a domain is local or not and that removes it from /etc/virtual, but it would be great if we could disable the mail system in a package or in the domain admin part.
Also, sometimes a user can add aliases, but doesn't want to receive emails on them because it just multiplies the amount of spams by the amount of alias. So, it would be great to be able to disable the mail system when creating an alias. An inactive alias file can be created in /etc/virtual and used by exim.
 
Last edited:
DirectAdmin Support said:
Actually, even simpler is to check to see if /etc/virtual/domain.com exists. If it does then the domain has data here. No parsing, no reading files, just check if the path exists and you'll know if the domain has local data regardless of MX records and contents of the "domains" file.

John
Click to expand...

Just a reminder that this probably doesn't work with the current DA version since a domain name can be removed from /etc/virtual/domains and still exist as a folder in /etc/virtual
 
I tested this one out.. It did not work, there was nothing to be found in the logs. 15 minutes later, I gave up and reverted it back. That mail arrived immediately afterwards. (it was sent from my gmail).

Any tips?
 
Hi Jeff,

Any idea yet when a final release is available?
 
No. I managed to get completely sidetracked with a lot of other issues. I'm probably going to have to look through some threads to see where we stand on a lot of issues/requests.

I'm going to look through what I'm using personally on the server for nobaloney.net; that appears to be working very well; perhaps I'll release that.

Jeff
 
Jeff,

Have you solved the backscatterer problems yet? I recognize it isn't all in your court to solve but I was hoping that it was finally solved. It is becoming such a big issue with our clients.
 
I'm honestly not sure where we stand on that; perhaps everyone who's already mentioned a solution could post to this thread so I'll have only one place to look. I'd really like to finalize this next version, and I'd like to have backscatter protetion in it.

Jeff
 
bayes_00

Hello,

After I changed to 3.2.4 RC it had been a huge rase on incoming spam mails. I don't know if it's been related, it might be because of the bayes_00 scoring negative points. I wrote spam check status below.

X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on name.server34.com
X-Spam-Level:
X-Spam-Status: No, score=0.2 required=3.0 tests=BAYES_00,HTML_MESSAGE,
MIME_BASE64_TEXT,URIBL_RHS_DOB autolearn=no version=3.2.5
Click to expand...
 
SpamBlocker doesn't touch SpamAssassin at all; it runs what you've got.

Did you carefully go through the SpamBlocker Technology exim.conf file to make sure the settings make sense for you? Did you read the readme, and look for all the EDIT lines which indicate either mandatory or optional edits?

Jeff
 
Thank you Jeff, I did check all EDIT lines and made everything work for me. I'm sorry to bother you because I don't think it's spamblocker anymore. I restored the old exim.conf file and nothing changed since then. I'm nearly sure that the bayes_00 thing is the problem with scores negative points. Is there something like a database for bayes and is there a way to flush it.

Thanks
Engin
 
Unfortunately I don't know much about SpamAssassin; I simply use it's defaults after the mail goes through my SpamBlocker Technology exim.conf file. Hopefully someone else will respond.

Jeff
 
I'm back to 3.2.4 conf now and nothing else to disable bayes. I don't even even now if it's useful.
 
enginaar said:
Hello,

After I changed to 3.2.4 RC it had been a huge rase on incoming spam mails. I don't know if it's been related, it might be because of the bayes_00 scoring negative points. I wrote spam check status below.
Click to expand...


I experienced a similar issue for one of my users (Im still running Spamblocker 2)

It seems that bayes autolearn=ham feature got corrupted by some spam emails that managed to look legitimate enough to get past the spam filters.

You have two options:
1) For each domain that is effected, go through their spam folder and find messages with autolearn=ham Now run sa-learn to mark those as spam to get bayes to learn its mistakes.

Example of using sa-learn:
sudo -u username -H sa-learn --dump magic
sudo -u username -H sa-learn --no-sync --showdots --spam /home/username/imap/domain.com/user/Maildir/.INBOX.spam/cur/
sudo -u username -H sa-learn --sync
sudo -u username -H sa-learn --dump magic

Use the outputs from dump magic to compare the tokens before and after.

2) Now if you have lots of domains that are experiencing this issue, it might be best to simply erase the bayes database for those domains. I believe you can do this by logging into directadmin CP, logging in as that user. Somewhere in spamassassin settings.

---

I also created a temporary rule in /etc/mail/spamassassin/local.cf
score BAYES_00 -0.5

To make the BAYES_00 have less weight while the issue gets sorted out.
 
Status
Not open for further replies.
Back
Top