Spam Evades BoxTrapper & Global Email Filters

[d_j_wills]

I'm stumped. I got the spam shown below (with personal info deleted). I have a Global Email Filter "From" "ends with" "server\.com" (As I understand, the '.' is a regex character that matches any single character. So the '\' turns the match to the actual dot character. I've also tried this without the escape and that doesn't appear to work either.)

Then, as I understand, the only way email can get through BoxTrapper is if the "From" address is in the white list. That spam was neither flagged by BoxTrapper nor in the white list. How can that happen? The "From" address is [email protected], though the "Reply To" address is [email protected]. But I take the filter literally in that the From address is the field to use, not Reply To.

I've been getting spam from this address for some weeks and I don't understand why filters and BoxTrapper aren't working.

Any ideas?

Thanks,

Dave

 

[d_j_wills]

Here's another one:

Filter: From Ends With [email protected]

Email From: [email protected]

Spam is not deleted.

 

[keat63]

I can't comment on box trapper, I've never used it.
What happens if you set up a filter "if from equals [email protected]", or whatever your full pattern is.

 

[cPanelLauren]

Hi @d_j_wills

Can you show us the actual filter text and the headers for the message that got through? Just change references to your own domain and IP's before submitting it.

 

[d_j_wills]

I can't comment on box trapper, I've never used it.
What happens if you set up a filter "if from equals [email protected]", or whatever your full pattern is.

Can't do because the variances are infinite. Replace "accounts" with any infinite number of bogus email users. What's even worse about rust is, the spam often comes with just [email protected] with no dot extension. (Heck, even I know how to spoof invalid email addresses from my client email program.)

Thanks,

Dave

 

[d_j_wills]

Hi @d_j_wills

Can you show us the actual filter text and the headers for the message that got through? Just change references to your own domain and IP's before submitting it.

The spam is below.

And I think this shows how/why BoxTrapper fails. Doing a test on"

[email protected]

I get one hit:

Sub-condition is true: $header_from: ends server.com

and the end condition:

Save message to: /dev/null 0660

Yet that spam ended up in my inbox, never reaching the BoxTrapper review queue. And the answer to your next question is, no, that email address is not in my white list.

Thanks,

Dave

Received: from [193.169.253.117] (port=50160 helo=server.com)
by xxxxxx with esmtp (Exim 4.93)
(envelope-from <[email protected]>)
id 1kG81c-00CvS9-Aq
for xxxxx; Wed, 09 Sep 2020 14:53:08 -0700
Reply-To: [email protected]
From: David Kim<[email protected]>
To: xxxxx
Subject: Product Inquiry
Date: 09 Sep 2020 14:53:14 -0700
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
X-BoxTrapper-Match: errmsg: mailer/postmaster


Dear dave,

We are Interested in buying your product



Kindly send your company's latest catalog and your best price list.

Also send us more information about your company for our ref. with your conditions and terms as below,
*Delivery time
*Payment term ( LC or TT )
*Minimum order quantity

Best Regards

David Kim

(Export Director)
GLOBAL TRADING AND SOURCING CORPORATION (GTS)


Building No 5EA, Office No 414, Dubai Airport Free Zone,

P.O Box No 371056, Dubai, UAE
Call : +971 4 2591443 | Fax : +971 4 2508429
Email : [email protected]

 

[cPanelLauren]

I've had some issues with ends with myself, when you use contains do you find that it works better/differently?

 

[d_j_wills]

I've had some issues with ends with myself, when you use contains do you find that it works better/differently?

Nah. That is much more complicated. As I posted in a different thread, something like "contains" ".buzz" trying to block the TLD "buzz" would also block legitimate email from someone like [email protected]. So blocking "contains" "rust" would also block "[email protected]". IOW, I'd have to have apriori knowledge of everyone who might want to email me in order to design the filter.

The bigger question for cPanel is, why does what I've given you not work? You haven't addressed that overriding issue.

Thanks.

 

[keat63]

There was a lengthy thread a few weeks ago regarding some of these filters not working as expected, but I'm not sure there was ever a resolution.
As a web site owner, there's going to be very little that you can do inside the bowels of Cpanel/WHM.

Me personally, I'd raise a support ticket with your hosts.
Not exctly helpful, but might be quicker than trying to figure this yourself.

 

[keat63]

Just had a crazy idea.
Would filtering act before box trapper.
But the filter doesn't work, so is passing the message to the inbox and thus bypassing box trapper ???

 

[d_j_wills]

Just had a crazy idea.
Would filtering act before box trapper.
But the filter doesn't work, so is passing the message to the inbox and thus bypassing box trapper ???

On your other post, I believe I was in on that (or a similar) thread. My hosting company is just as flummoxed as I am, though they gave me one filter that appears to work just fine. ([email protected]+\.<domain>) At least, I've not seen any valid email in Track Delivery that this filter would have blocked.

Besides, what I'm pointing out does appear to be cPanel problems.

WRT filtering before BoxTrapper, I am certain this is true. Otherwise there would be a ton of spam to look over in the Review Queue.

Thanks,

Dave

 

[cPanelLauren]

regex would work I believe and I believe I did resolve that thread @keat63 if it's the same one I'm thinking of.


So the regex to match only the end of it would be something like:

\^*.rust$

So the rule would be "From matches regex \^*.rust$"


Also if you do "ends with .rust>" instead of just . rust I wonder if it'd work better. Since the from headers contain that > typically

 

[cPanelLauren]

Besides, what I'm pointing out does appear to be cPanel problems.

Actually, not really, it's the very specific language of the filter syntax here that gets them passed through, which is why I think the regex solution is better. If you say "ends with .com" and really the from header ends with ".com>" it's is not equal to a match according to exim.

 

[cPanelLauren]

Just had a crazy idea.
Would filtering act before box trapper.
But the filter doesn't work, so is passing the message to the inbox and thus bypassing box trapper ???

That's actually exactly how it works. The filtering occurs prior to the handoff to boxtrapper, so if you're discarding the message it'll never hit the BT approval queue. If it does make the approval queue you know that the filter didn't pick it up/didn't see a match.

 

[d_j_wills]

So the regex to match only the end of it would be something like:

\^*.rust$

So the rule would be "From matches regex \^*.rust$"


Also if you do "ends with .rust>" instead of just . rust I wonder if it'd work better. Since the from headers contain that > typically

Actually, not really, it's the very specific language of the filter syntax here that gets them passed through, which is why I think the regex solution is better. If you say "ends with .com" and really the from header ends with ".com>" it's is not equal to a match according to exim.

OK, I'll try the \^*.rust$. But I thought we went through this a few weeks ago and it didn't work. I'll report back.

On your last statement, here is my problem. Trying to decipher what all the possible permutations of regex statements are or should be should IMO be completely independent of the filter. So, again, IMO, the filter content should have the literal statement. How the technical implementation of that filter works should be completely unknown (and not cared about) by the user. For instance, if one wanted to block all email from the domain .rust, all s/he would need to do is have the filter "From" "ends with" ".rust" i.e., the user should not have to care about escaping the dot (and in this particular case, the "ends with" is explicit and the '$' should be completely redundant and not specified by the user. Also, the trailing '>' is an artifact of email systems, not from the user. So that also should not be part of the filter process.

The big difference here is I believe the cPanel tools should be geared to the end user, not a developer. The tools may make perfect sense to a developer and not necessarily (or sometimes at all) to the user.

Again, just my opinion.

Thanks,

Dave

 

[d_j_wills]

<snip>

Then, as I understand, the only way email can get through BoxTrapper is if the "From" address is in the white list. That spam was neither flagged by BoxTrapper nor in the white list. How can that happen? The "From" address is [email protected]ver.com, though the "Reply To" address is [email protected]. But I take the filter literally in that the From address is the field to use, not Reply To.

<snip>

I think one of my two original problems has been ignored. How can a spam get through BoxTrapper and be delivered to my inbox, as described above? this has nothing to do with filters not working. I can only see a failure on BoxTrapper's side to cause this.

Dave

 

[d_j_wills]

WOW!!! Just 40 minutes after I re-addressed the ignored issue, I got another spam that is identical to the one posted previously, except for some of the numbers in the header.

*** Why is BoxTrapper failing by letting spam get through to my inbox rather than putting it into the Review Queue???

 

[cPanelLauren]

1. I think one of my two original problems has been ignored. How can a spam get through BoxTrapper and be delivered to my inbox, as described above? this has nothing to do with filters not working. I can only see a failure on BoxTrapper's side to cause this.
   Dave

   
   I don't think it was being ignored, just the focus was the filter for the moment. My approach was to handle the filters then the box trapper issue, which is the order mail is being received.
   
   

2. OK, I'll try the \^*.rust$. But I thought we went through this a few weeks ago and it didn't work. I'll report back.

   If it didn't work I'm unaware of why it didn't. I tested it before I gave it to you in both instances and it worked fine. I used .com in my test and sent an email from [email protected] and then [email protected] to ensure that it wouldn't block .com in the email address
   
   

3. The big difference here is I believe the cPanel tools should be geared to the end user, not a developer. The tools may make perfect sense to a developer and not necessarily (or sometimes at all) to the user.

I don't disagree with you but it's not a bug, it's an area for improvement though definitely.


For the two messages that made it through the box trapper queue, can you show the following:

• The full headers
• The review log
• The white/black/ignore lists

 

[d_j_wills]

Hi Lauren,

In reply:

1. OK. Thanks.

2. If you go back to the old thread I posted to, you will see that I did report that the Filter Test would often report delivery to /dev/null even though spam matching that filter test would still go through to BoxTrapper. I have lost confidence that the filter test works 100%. Regardless, I will report back should I get any spam through the filter. Hopefully, not.

3. OK, we agree. Yes, it is not a bug and my statement didn't call it a bug.

With regards to the full headers, review log, and white/black/ignore lists, I would happily share them with you if you give me a way to contact you directly so I do not post private information here. The full header of the 2nd email is nearly identical to the first (which is posted here previously), except the port, the time and the message ID numbers are different. I don't see an option for review log in cPanel, but if you tell me what the file is, I can sort through to find it. Here's a picture of the Track Delivery entry (with my email address removed)



and as I said before, there is no entry in the BoxTrapper review queue. The filter we've mostly discussed is for TLDs and not specific domains such as server.com. I think I mentioned that the dot escape character confuses me so my filter of "ends with" "server.com" may not be correct.

Oh, and finally, I did run the following test:

To: [email protected]
From: [email protected]
Subject: test

This is a test message.

And here is the result:

Save message to: /dev/null 0660
Filtering set up at least one significant delivery or other action.
No other deliveries will occur.

So the filter appears to have worked, the spam email bypassed BoxTrapper without getting into the Review Queue, and then it was delivered to my inbox.

Thanks,

Dave

 

[cPanelLauren]

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

Oh, and finally, I did run the following test:

To: [email protected]
From: [email protected]
Subject: test

This is a test message.

And here is the result:

Save message to: /dev/null 0660
Filtering set up at least one significant delivery or other action.
No other deliveries will occur.

With regards to the full headers, review log, and white/black/ignore lists, I would happily share them with you if you give me a way to contact you directly so I do not post private information here.

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: