Spam with given spampoints not rejected

I'm having this same problem as well on a number of servers. Low scoring spam is going to the spam folder like normal, but high scoring spam is coming (tagged) to my inbox when it should be deleted. This problem just started a few days ago for me as well.

My filter.conf looks like this:

Code: 
0=type=email&[email protected]
high_score=10
high_score_block=yes
where=userspamfolder
 
Last edited:
My filter looks like this:

Code: 
# Exim Filter

# created by DirectAdmin, version 1.32.0
# Do not modify this file as any changes will be
# overwritten when the user makes a change.
# (data is only written to this file, not read)

if error_message then finish endif


if
        $h_X-Spam-Level: contains "**********"
then
        seen finish
endif


if
        $header_from: contains "[email protected]"
then
        seen finish
endif





if
    $h_X-Spam-Status: contains "Yes,"
then
    if
        $local_part is "admin"
    then

        save /home/admin/Maildir/.INBOX.spam/new/ 660
    else
        save /home/admin/imap/$domain/$local_part/Maildir/.INBOX.spam/new/ 660

    endif
    finish
endif

Shouldn't there be something like if score > 10 then delete?
 
Hello,

Can you try manually changing this bit:
Code: 
    endif
    finish
endif
to
Code: 
    endif
    seen finish
endif
to see if that changes anything. (not filters will get overwritten if you change it in DA, but just for testing see if it helps)

Edit: I just checked waaay back in our previous releases and this hasn't be changed for a very long time.. so if something changed and this fixes it, it's not the filter syntax.. it's what's processing the syntax.

John
 
Same problem here SA 3.2.1. We don't use the option high scoring spam, but delete all mail above an assigned score. This doesn't work for all mail (the mail should be deleted because the score is higher then the score 4)

My filter is:
# Exim Filter

# created by DirectAdmin, version 1.30.1
# Do not modify this file as any changes will be
# overwritten when the user makes a change.
# (data is only written to this file, not read)

if error_message then finish endif

if
$h_X-Spam-Status: contains "Yes,"
then
seen finish
endif


#end filter
 
Last edited:
John,

At the webhostingtalk.nl forum there are many posts about this problem, all resulting in spam coming through the spamfilter.

Server details:
- CentOS 4..
- Apache 2.2.8
- DirectAdmin 1.31.5
- Exim 4.67
- MySQL 4.1.21
- dovecot 1.0.13
- Spamassassin 3.2.4

Problem:

Spamassassin is set to delete mail above 4.0 points. Mail with above 15 points should be rejected, but they also come into my mailbox. I believe i'm not experiencing this problem at all servers.

Example of showing up mail in my inbox:

Content analysis details: (19.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
2.0 URIBL_BLACK Contains an URL listed in the URIBL blacklist
[URIs: mexxstyle.cn]


Some other reactions on the dutch webhostingtalk.nl, translated to english:

Arie:
I'm experiencing the same problem since a couple of days.

T.Bloo:
Here also

Bigall:
Only at centos servers, on debian spamassassin works fine.

T.Bloo:
Also only at centos serveres, not at debian.

Arie:
I've got the problem at a debian machine.

Localh:
Also got this problem at a freebsd server, spamassassin version: 3.2.4

MartijnRSD:
Got the same problem, spamassassin version: 3.2.1

Christophe1:
Since 2 days the same problem, spamassassin version 3.1.7 last version directadmin, using a debian machine.
 
Strange, all replys above are from dutch DA users?

Can't find any messages about this problem at webhostingtalk.com
 
I am experiencing the same problem. The From: field in the mails is empty (empty e-mail address, just <>) and it seems that some rule is (or not) triggered.
I have to find more time to have a closer look into the problem.
 
GigaNet said:
I am experiencing the same problem. The From: field in the mails is empty (empty e-mail address, just <>) and it seems that some rule is (or not) triggered.
I have to find more time to have a closer look into the problem.
Click to expand...

Ah that's interesting, all mails in the inbox over here don't have a valid email adres as well, the header is always something like this:

Code: 
From: "Edgar" <>
 
Note that a rejection level greater than 50 doesn't work correctly.
SpamAssassin puts a maximum of 50 "*" in the X-Spam-Level line, and the rather primitive
test checks if the line contains for example 51 "*". This will always fail and as a result
the mail will be delivered.
 
edzelf said:
Note that a rejection level greater than 50 doesn't work correctly.
SpamAssassin puts a maximum of 50 "*" in the X-Spam-Level line, and the rather primitive
test checks if the line contains for example 51 "*". This will always fail and as a result
the mail will be delivered.
Click to expand...

The default setting over here is the "Send the spam to the appropriate users's spam folder." with all spam scoring 4 or higher, I never delete spam right away. Some mails still stay in the inbox though, all of them with this strange from fields but perfectly rewritten subject and the spam mail itself as attachment so there must be something wrong with the filtering as suggested by John.
 
Could be that the line:

if error_message then finish endif

in the filter-file results in skipping the score test. I do not know in what circumstances
"error_message" is filled.
 
edzelf said:
Could be that the line:

if error_message then finish endif

in the filter-file results in skipping the score test. I do not know in what circumstances
"error_message" is filled.
Click to expand...

Hmmm according to the Exim webiste:

http://www.exim.org/exim-html-current/doc/html/filter.html#SEC26

Could it be these spam mails are crafted as mail delivery errors? Nothing in the sample, non filtered spam, mails I got points in this direction unfortunately.
 
Last edited:
I just found out that the exim filter (/etc/virtual/<domain>/filter) is not executed at all in case of a strange "From:"-field like:

From: "German" <>

The field between the angle brackets is normally empty if the mail is a "DELIVERY FAILURE".

It might be a solution to get rid of mails with this empty field by modifying /etc/system_filter.exim, after checking for Delivery failure of course.
 
I'm not dutch and I'm having this problem. ;)

I checked and it looks like all the spam coming through here has malformed From: like everyone else is mentioning.

Does anyone have a fix?

Keefe
 
If the <> addresses are triggering the error_mesage to quit early, then try editing:
Code: 
/usr/local/directadmin/data/templates/filter_base
and change:
Code: 
if error_message then finish endif
to
Code: 
#if error_message then finish endif
then type
Code: 
echo "action=rewrite&value=filter" >> /usr/local/directadmin/data/task.queue
to get rid of it. Wait a few minutes, then double check there is the # in front of it in your /etc/virtual/domain.com/filter files. Once gone, then see if that fixes it. It's likely just a new form of spamming that they've figured out works well.

John
 
It sure looks like a new spam-method!

As a noticed before: the exim filter (/etc/virtual/<domain>/filter) is not executed at all in case of a strange "From:"-field.

The /etc/system_filter.exim however is executed, so the check must be made there in my opinion. I added the following lines to it:

if $h_From: contains "<>"
then
if $reply_address: contains "<>"
then
seen finish
endif
endif

Its under test now (including some logging), and I'll publish the results here within 24 hours.
 
Thank god somebody else is having this problem. I've been fault finding this for ages, have updated everything but the issue remains.

Eagerly awaiting results from the above two posts, with the amount of CASINO spam I am getting I might give one then the other a try to see how it goes....

Update: I have been testing with John from DA's suggestion & so far it seems alright, although wouldn't having exim.conf reject it rather than accept it then filter it be better?
 
Last edited:
You must log in or register to reply here.
Back
Top