Spam Evades BoxTrapper & Global Email Filters
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 postmaster@server.com, though the "Reply To" address is procurementgtscorps@yahoo.com. 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
-
Here's another one: Filter: From Ends With .+@rust Email From: accounts@rust.com Spam is not deleted. 0 -
I can't comment on box trapper, I've never used it. What happens if you set up a filter "if from equals accounts@rust.com", or whatever your full pattern is. 0 -
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. 0 -
I can't comment on box trapper, I've never used it. What happens if you set up a filter "if from equals accounts@rust.com", 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 name@rust with no dot extension. (Heck, even I know how to spoof invalid email addresses from my client email program.) Thanks, Dave0 -
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" postmaster@server.com 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 ) id 1kG81c-00CvS9-Aq for xxxxx; Wed, 09 Sep 2020 14:53:08 -0700 Reply-To: procurementgtscorps@yahoo.com From: David Kim To: xxxxx Subject: Product Inquiry Date: 09 Sep 2020 14:53:14 -0700 Message-ID: <20200909145305.FBAC77A9FA24A865@server.com> 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 : procurementgtscorps@yahoo.com0 -
I've had some issues with ends with myself, when you use contains do you find that it works better/differently? 0 -
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 aldrin.buzz@nasa.com. So blocking "contains" "rust" would also block "rusty@somewhere.com". 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.0 -
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. 0 -
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 ??? 0 -
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. (.+@.+\.) 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, Dave0 -
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 > typically0 -
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.0 -
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.0 -
[QUOTE="cPanelLauren, post: 2786313 (+ 1 more), member: 893463"> 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, Dave0 -
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 postmaster@server.com, though the "Reply To" address is procurementgtscorps@yahoo.com. But I take the filter literally in that the From address is the field to use, not Reply To.
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. Dave0 -
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??? 0 -
-
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. -
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 me@mydomain.com and then me.com@domain.net to ensure that it wouldn't block .com in the email address -
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.
- The full headers
- The review log
- The white/black/ignore lists
0 -
-
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: me@mydomain.com From: postmaster@server.com 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 0 -
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: me@mydomain.com From: postmaster@server.com 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:0 -
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:
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 postmaster@server.com. 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 :) ). Dave0 -
With Lauren's help, I was able to figure out that some filters don't work as I want them. First, 0 -
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 postmaster@server.com 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 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 postmaster@server.com, 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. 0 -
I temporarily removed the filters for 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. 0 -
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.0 -
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. Dave0
Please sign in to leave a comment.
Comments
25 comments