Spam Evades BoxTrapper & Global Email Filters

[d_j_wills]

This indicates that the filter worked and the messaged was saved to /dev/null which indicates it was deleted.

Uh, no it doesn't. It means the TEST for the filter worked. But clearly, the actual filter DID NOT work because the actual email went into my inbox.

Sorry, sometimes I can be dense, but in this case I believe I am right. Please tell me where I'm wrong.

I don't need to see your domain name, or any server information. If you're trying to block .rust domains I want to see if anything .rust exists on that list and it shouldn't be an issue to obfuscate your personal domain names and IP's in a forum post but leave the spam info up - you can even change the IP's there if you like. You can also send a direct message by clicking on my profile link in my post and then click "start a conversation"

All of the items I requested in terms of box trapper should be present within cPanel>>Email>>Box Trapper>>Manage (next to the email account in question). The interface looks as follows:
<snip>

Yes, I believe I know how to use the manage tools.

Let's look at the one email that I've shown with the test *should* go to /dev/null but doesn't. This is [email protected].

Here is the results of a find in Chrome inside of the whitelist for the email address which received the spam (with private info removed):



So you can see that the first part of that address just does not exist in the whitelist. If I search on server.com, that doesn't exist either (though I won't post that picture). I believe I understand everything you're saying, yet either I am completely bonkers or you don't believe me (or, unfortunately, both ).

Dave

 

[d_j_wills]

With Lauren's help, I was able to figure out that some filters don't work as I want them. First,

 

[d_j_wills]

With Lauren's help (THANKS LAUREN), I was able to filter out most of the spam I was getting.

I was not able to determine why email from [email protected] evaded BoxTrapper and ended up in my inbox. But Lauren pointed out why my "From" "ends with" "server.com" didn't work. The from address was actually <[email protected]> and it turns out that the trailing '>' is needed for the "ends with". I receive mail from other bogus TLDs such as .buzz and some end with ".buzz" and some with ".buzz>". Since I don't have any control over how that '>' gets on the end of the address, I found the only way to insure all the bogus domains are sent to /dev/null is to build both "ends with" filters. Once I did this with [email protected], the spam from that address gets dumped before it has a chance to evade BoxTrapper.

Next, I was not able to create matches regex filters that were reliable. There were a few discussed here and in other threads. Without the "ends with" the filters were still too generic and ended blocking valid emails which had the regex string in the middle. Also, the '$' to terminate the regex string did not work, for example " \^*.rust$" did not block email from the TLD .rust. I don't know why, though " \^*.rust>$" may work for the same reason as above.

d.

 

[d_j_wills]

I temporarily removed the filters for <[email protected]> to see if that spam would still get through BoxTrapper.

It does.

I confirmed that this address is not on my white list (as well as ignore or black lists).

Maybe I shouldn't care since I can install the filters, but then again, this spammer has figured out how to fool BoxTrapper.

And if that spam can fool BoxTrapper, can it also fool the filters?

I recreated the filter From ends with server.com and tested. It does not filter the spam.

I then recreated the filter From ends with server.com> and tested. That does filter the spam (though I have seen instances where the test indicates the spam will go to /dev/null yet it is still delivered to the Review Queue of BoxTrapper).

Go figure.

d.

 

[cPanelLauren]

Well, Box Trapper's primary function is to queue mail in a box while waiting response from a user. This means that if you removed the filters the mail would be put into BoxTrapper's review queue (i.e., that's the behavior I would expect to see). I don't believe this to be fooling BoxTrapper, unless it makes it through the review queue and into the mail box, is that what's happening?

I then recreated the filter From ends with server.com> and tested. That does filter the spam (though I have seen instances where the test indicates the spam will go to /dev/null yet it is still delivered to the Review Queue of BoxTrapper).

For this, it's difficult to tell you specifically why without the filter text and the headers of the email.

 

[d_j_wills]

Well, Box Trapper's primary function is to queue mail in a box while waiting response from a user. This means that if you removed the filters the mail would be put into BoxTrapper's review queue (i.e., that's the behavior I would expect to see). I don't believe this to be fooling BoxTrapper, unless it makes it through the review queue and into the mail box, is that what's happening?


For this, it's difficult to tell you specifically why without the filter text and the headers of the email.

Yes, that's exactly what I'm saying. If there is no filter to block this specific spam, it never ends up in the BoxTrapper review queue and always goes directly into my inbox. (I use an email client so the spam gets downloaded from my server to my PC.) That is what's so confusing. It not only appears to be bypassing BoxTrapper, it is bypassing BoxTrapper. Weeks ago I asked my hosting company if there was something special about server.com that would allow it to bypass, but they said no.

WRT a filter test showing spam goes to /dev/null yet the spam ends up in BoxTrapper, I've seen this happen a bunch of times but not in the past few days. When it happens again, I'll capture as much info as I can and post it here.

Thanks again.

Dave