Spam with given spampoints not rejected

[nieuwhier]

Its under test now (including some logging), and I'll publish the results here within 24 hours.

Hi Edzelf. Are you saying that Johns suggestion is not working because it is not executed or do I misunderstand you ?

(I just added Johns suggestion as a first step)

 

[edzelf]

Good news. During the last 10 hours the script caught 80 spammails of this type.
I know that this is a work-around because there shouldn't be a reason why the the exim filter (/etc/virtual/<domain>/filter) isn't executed for these kind of mails.

So add the next lines (with proper indents of course) in the /etc/system_filter.exim file,just before the line
"### Version history":

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

I hope that someone else will improve the silly asterisks-counting method to delete high-score spam in the exim filter (/etc/virtual/<domain>/filter)....

 

[MartijnHOS]

If the <> addresses are triggering the error_mesage to quit early, then try editing:

/usr/local/directadmin/data/templates/filter_base

and change:

if error_message then finish endif

to

#if error_message then finish endif

then type

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

Hi John,

The line wasn't there without purpose.(?) Is it a good solution to just disable the line?

 

[GigaNet]

If the <> addresses are triggering the error_mesage to quit early, then try editing:

/usr/local/directadmin/data/templates/filter_base

>cut<

This works. Looks to be a decent solution. The offending mails are now discarded. As far as I can judge, forged undeliverables will be treated the same way.

Henk

 

[GigaNet]

Hi John,

The line wasn't there without purpose.(?) Is it a good solution to just disable the line?

Hi Martijn,

As far as I can see, if the message looks to be an error message, the instructions below:

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

are not executed, as the filter finishes, because the error condition apparently exists with these mails.

When removing the line, execution continues and because the X-Spam-Status header contains "Yes,", the mail is treated that way.

Please correct me if I am wrong.

Henk

 

[edzelf]

Maybe I'm wrong, but I found out earlier that the filter (/etc/virtual/<domain>/filter) is not executed at all in case of a strange "From:"-field.

I had added a logging to this filter and there was no reporting in case of the "<>"-mails.

So changing this filter will not work, although miracles happen sometimes....

 

[duncan]

Perhaps a dumb question - but can anyone tell why this problem suddenly cropped up?

Was it a DA update gone bad? And if so, wouldn't they fix it?

 

[DirectAdmin Support]

Hello,

We have not changed anything regarding the filters or anything in DA regarding exim. It's likely a change in the spam being sent out.

The blank from <> address seems like a suspect cause for it, in combination with the error_message check. Try removing the error_message check in your filters.
eg: http://www.directadmin.com/forum/showpost.php?p=131783&postcount=38

John

 

[damn]

Just confirming that I coded in John's suggestion and it works fine.

This is likely to be something that exists in many exim setups, and spammers found a way to exploit that.

However, I still think that a better solution is not to accept the mail at all, rather than accept it then delete it.

So I would imagine that a change to exim.conf to not accept it would be a slightly better solution?

 

[DirectAdmin Support]

Hello,

Note, that if you deny all <> emails, then you're also going to be blocking any valid bounce emails. I'd sooner let spamassassin decide what is spam and what isn't, since that's it's job. If you block all bounce emails (<>) then users will never know if an email they had sent out didn't arrive to it's destination, so using the removal of the "error_message" line is probably a safer alternative.

John

 

[damn]

Fair enough, I thought that bounce emails would be from somebody, like [email protected] but I just checked headers of a legit bounce and it is from <> like you said.

Current solution working nicely

 

[nobaloney]

Check the RFCs ; Mailer Daemon error reports are supposed to come from an empty sender (<>).

Both John and I agree that we can't just block all email from empty senders; I sure wish we could .

Jeff