Custom Rules

Question asked by Scarab - 11/20/2014 at 12:49 PM

Answered

We get a lot of Spam that is from .link, .mobi, .in, and .pw domains and setup Custom Rules as follows:

Rule Source: Header

Header: Return-Path:

Rule Type: Regular Expression

Weight: 10

Rule Text: *.\.link

.*\.mobi

.*\.in

.*\.pw

Problem is that it isn't catching any of it...so I set up a second, almost identical, Custom Rule as follows:

Rule Source: Header
Header: From:
Rule Type: Regular Expression
Weight: 10
Rule Text: *.\.link
.*\.mobi
.*\.in
.*\.pw

And still nothing is caught.

What am I doing wrong with my rules? I know my REGEX is solid and suspect that I'm doing something wrong with the value in the HEADER field (or do I maybe need to account for angled brackets around the email address in the Rules Text?). Anyone have any helpful hints or pointers?

11 Replies

Reply to Thread

Scarab Replied

7/10/2015 at 12:55 PM

Marked As Answer

I'm beginning to understand why SmarterTools staff is always silent on the subject of Custom Rules in SmarterMail. It is very finicky. After some experimentation I got my rules to work 100% of the time with the following alterations:

Rule Source: Header

Header: Return-Path

Rule Type: Regular-Expression

Weight: (variable based upon your Low/Med/High weights)

Rule Text: .+\.link>$

.+\.mobi>$

.+\.in>$

.+\.pw>$

.+\.rocks>$

.+\.science>$

.+\.work>$

.+\.ninja>$

.+\.cricket>$
.+\.click>$

.+\.party>$

.+\.tk>$

(et cetera for each top-level domain you want to catch)

Using .+ instead of .* shouldn't make too much of a difference, but can in some unique circumstances, but the important missing piece was the ending > before the end of the string $. Not sure why it would work sometimes without with ending > and not other times, but I was able to confirm that was the problem.

The other thing to note is do not put a : at the end of your Header field as the Custom Rules assumes a : and putting one in that field will result in it never matching (as it will be looking for Return-Path::).

The same RegEx above should work with the From or Return-Path fields if you would prefer using those.

Hope this saves someone else some head-scratching frustration in the future.

Bruce Barnes Replied

7/14/2015 at 11:56 AM

We are successfully trapping all of the new domains listed via our antispam settings.

See: SmarterMail Antispam Settings Document for the most current release of the document.

We have ZERO false positives. When a new spammer comes along, we might see a couple of spam messages from them, but the several databases we run are quickly updated.

NOTE: These settings only work if you have all of them properly set - exactly as outlined in the document, IE:

point to your own DNS servers - NOT Google or other busy public servers.
do not allow users to override any of the antispam settings, and
have greylisting setup - not allowing users to disable the greylisting settings.

In every case where I have been asked to troubleshoot, there were external antispam tools setup, which modified the SmarterMail spam settings scores, the greylisting had not been enabled, or the users were allowed to modify their own antispam settings - overriding the master antispam settings.

Allowing users to have input in spam settings is only asking for support headaches.

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting

Jay Mather Replied

2/16/2016 at 2:27 PM

Scarab. Just stumbled across your post here and really grateful for the solution you posted. Last few weeks have seen a massive rise in .top domains sending all sorts of nonsense. SPF was passing and SPAM score was a solid zero in every case! Bayesian Filtering seems helpless against this lot for some reason. Anyway, never been quite sure why SmarterMail doesn't just have a top-level domain-default option for blocked sending domains, but your solution looks like it may well work for us. Nice one.

David Jamell Replied

4/19/2017 at 11:44 AM

I'm running SM 15.5.6222 and cannot for the life of me figure out how to make this work. None of the variations seem to match anything. I've seen similar threads about custom rules and I think I tried everything.

Is there a bug, or am i just doing something wrong?

Employee Replied

4/19/2017 at 12:10 PM

Employee Post

David, I just tried this in the same version, and my custom rule did score a test@test.mobi test message with a 999.

Rule Source: Header
Header: Return-Path
Rule Type: Regular-Expression
Weight: 999
Rule Text: .+\.mobi>$

Employee Replied

4/20/2017 at 12:02 PM

Employee Post

Hi David. Another thought. You could use SMTP blocking as well. Go to Security >> Advanced Settings >> SMTP Blocking. Add an incoming email address block and enter: "*.TLD" (without the quotes)

David Jamell Replied

4/20/2017 at 1:16 PM

Yes, Rod, I've been using the STMP Blocking for some time. But was intrigued by the possibility of blocking by Reply-To and Return-Path in addition to From.

Or does SMTP Blocking also block Reply-To and Return-Path?

Thanks again Rod.

Employee Replied

4/20/2017 at 1:47 PM

Employee Post

David. No, SMTP blocking would just look at the sending domain in this example. But again, I was able to use Custom Rules against the Return-Path without issue using my example above.

David Jamell Replied

4/24/2017 at 7:55 AM

Hi Rod - This does seem to be working. Just had to wait for the right messages to come through.

Thanks again for your replies.

Andrew Lupton Replied

9/21/2017 at 11:40 AM

If I wanted to catch all instances of a word (sender name) in the return path would the structure for SM be such as .+\nastyword\.+$ ? I'm looking to catch it regardless of the domain. I just am not clear on the syntax for wildcard-word-wildcard-end of string, etc. Sorry, I'm a regex nube. :). It may very well be \^nastyword\.+ for example or /^nastyword/.+ ...Not sure as the examples I have been looking at all show forward slashes. Does it matter to SM?

Steve Gaston Replied

11/27/2020 at 12:31 AM

Hi!

Do these rules still work?

I think they do, but I am not seeing what I expect to see.

For example, I am not seeing any scores being appended to the SMTP delivery log.

Should I not be seeing the name of my custom rule in the logs in the same way the custom rules I have for RBLs and URIBLs appear in the logs ??

[2020.11.20] 10:04:09.285 [104.223.153.228][18328058] rsp: 220 mail.errxxx.com Fri, 20 Nov 2020 09:04:09 +0000 - Smartermail SMTP
[2020.11.20] 10:04:09.285 [104.223.153.228][18328058] connected at 11/20/2020 10:04:09 AM
[2020.11.20] 10:04:09.285 [104.223.153.228][18328058] Country code: US
[2020.11.20] 10:04:09.504 [104.223.153.228][18328058] cmd: EHLO don.drainwood.bid
[2020.11.20] 10:04:09.504 [104.223.153.228][18328058] rsp: 250-mail.errxxx.com Hello [104.223.153.228]250-SIZE 31457280250-AUTH CRAM-MD5250-STARTTLS250-8BITMIME250-DSN250 OK
[2020.11.20] 10:04:09.723 [104.223.153.228][18328058] cmd: MAIL FROM:<22837-1182-64172-6036-andreas=xxxsys.com@mail.drainwood.bid> BODY=8BITMIME
[2020.11.20] 10:04:09.723 [104.223.153.228][18328058] senderEmail(1): 22837-1182-64172-6036-andreas=xxxsys.com@mail.drainwood.bid parsed using: <22837-1182-64172-6036-andreas=xxxsys.com@mail.drainwood.bid>
[2020.11.20] 10:04:11.520 [104.223.153.228][18328058] rsp: 554 Sending address not accepted due to spam filter
[2020.11.20] 10:04:11.520 [104.223.153.228][18328058] Mail rejected due to SMTP Spam Blocking: Reverse Dns Lookup (20,ReverseFailed), GBUDB | +30 (30,failed), SURRIEL | +10 (10,failed), ZEN3 | +10 (10,failed)
[2020.11.20] 10:04:11.738 [104.223.153.228][18328058] cmd: QUIT
[2020.11.20] 10:04:11.738 [104.223.153.228][18328058] rsp: 221 Service closing transmission channel
[2020.11.20] 10:04:11.738 [104.223.153.228][18328058] disconnected at 11/20/2020 10:04:11 AM

Back to Community Threads

Please leave this box unchecked

11 Replies

Reply to Thread

Tags

Related Knowledge Base Articles