New bug with Domain Content Filtering - Move Message Action - Build 9340

Problem reported by Brad Smith - 7/31/2025 at 6:15 AM

Resolved

New bug introduced with build 9340.

If you have a Domain Content Filter with a rule that includes a "Move Message" Action (say, to "Deleted Items"), the message is no longer moved. This worked on previous builds.

Relevant bonus complaint: the docs (help.smartertools.com/smartermail/current/topics/domainadmin/settings/domaincontentfiltering) say that for Move Message, the selected folder would be selected from a dropdown list. This is, in fact, incorrect. There's no dropdown, you have to type in the folder name, surrounded by quotes ("Deleted Items"). That's okay, it can be figured out, but the docs could use tweaking.

16 Replies

Reply to Thread

Brad Smith Replied

7/31/2025 at 7:47 AM

More info:

If I adjust the action to set the folder to Deleted Items, without quotes, it appears the rule starts working, but creates a new DELETED_ITEMS folder.
But if I set it back to "Deleted Items" (quoted), it stops working again.

At least there's a temporary workaround. But this was all working until the new build was installed.

Kyle Kerst Replied

7/31/2025 at 8:24 AM

Employee Post

I was not able to replicate this issue in testing here and I suspect it stems from the folder name including quotes. I know that quotes are not typically allowed in folder names so this is likely the root cause and I recommend correcting that long term. If you need a hand getting that resolved please don't hesitate to reach out to support.

Kyle Kerst

Lead Internal Network/System Administrator

SmarterTools Inc.

smartertools.com

Brad Smith Replied

7/31/2025 at 9:20 AM

The folder in question is THE Deleted Items folder. I want to move flagged messages to that folder. There's no quotes in the folder name.

If you make an action to Move To: Deleted Items (no quotes), instead what happens is a DELETED_ITEMS folder is created and the message moved there.

If you make the action Move To: "Deleted Items" (name is quoted), then the rule ... until this latest build ... correctly moved the message to the actual Deleted Items.

This is a screenshot of the rule that worked until the latest update.

The "Add Text to Subject" works, the Move doesn't.

Note though, all my rules are created under Domain Settings, so the rules apply to all users. I don't have any separate rules for individuals. I'm not certain if that's a factor (though I'll try to set up an individual rule to confirm). It's possible if you're trying to repro via an individual account rule, it's possible you won't.

Kyle Kerst Replied

7/31/2025 at 3:39 PM

Employee Post

I see, that makes sense Brad. Thanks for the clarification! I did some testing with that in mind and was able to reproduce the same behavior in that scenario. I'm going to write up a task for development to take a look at this and I'll get you an update once they've had a chance to review.

Kyle Kerst

Lead Internal Network/System Administrator

SmarterTools Inc.

smartertools.com

Brad Smith Replied

7/31/2025 at 4:52 PM

Awesome! Many thanks. Hopefully an easy fix.

Brad Smith Replied

8/16/2025 at 5:48 AM

I see build 9357 came out (looks like our admin skipped 9350), and Domain Content Filtering is now completely and totally broken. No rules are run at all, it's as if they don't exist. I don't even get the subject labelling.

Derek Curtis Replied

8/19/2025 at 1:34 PM

Employee Post

Hey, Brad. Just to give you a heads up: we were able to replicate this issue. We'll get a fix in for the next Build.

Derek Curtis

CCO

SmarterTools Inc.

www.smartertools.com

Derek Curtis Replied

8/20/2025 at 4:43 PM

Employee Post Marked As Resolution

Just to close this out, we put out a release with a fix for this issue on the 19th. Should be good to go.

Derek Curtis

CCO

SmarterTools Inc.

www.smartertools.com

Brad Smith Replied

8/21/2025 at 4:28 AM

It is indeed back to normal. I did notice that I no longer have to quote "Deleted Items" in my move rules, which is also a good thing. ;-)

Brian Replied

8/21/2025 at 12:32 PM

I think this was broken a while ago. I'm on Build 9294 (Jun 12, 2025), and if I change a content-filtering rule, they don't work properly.

1) I have a list of extensions that I updated yesterday which does NOT include PDF, but today, all emails containing PDF files were getting deleted because it's getting processed by a rule to delete files such as .bat, .com, .exe, etc.

2) Today, during troubleshooting, I changed the rule to move to Junk E-Mail (no quotes) and it made a folder JUNK_EMAIL. WTF?

I guess I'll upgrade and hope for the best.

Brian Replied

8/21/2025 at 1:25 PM

I updated to the August 19, 2025 edition. The file folder naming issue seems to be fixed.

However...

I have a rule where if there is an attachment with a specific extension, I delete the email.

What I'm finding is that with the "Enable Wildcards" enabled, if the specified extention (e.g., bat) is included anywhere in the filename (e.g., batch.pdf), the condition is considered to be true.

I don't think this is correct.

1) You should only be checking the EXTENSION and not the entire filename.

2) I don't think you should be looking for a substring inside the extension but rather you should be matching the entire extension.

3) I thought the wildcard only applied to * and ? characters. I do not have bat* but only bat

Derek Curtis Replied

8/21/2025 at 1:36 PM

Employee Post

Thanks, Brian. We'll get this tested. I'd agree that only the extension should be checked if you're using, for example, *.bat and/or *.BAT as the named extension.

And, just curious: what happens if you exclude the * and just add .BAT/.bat?

Derek Curtis

CCO

SmarterTools Inc.

www.smartertools.com

Tony Scholz Replied

8/21/2025 at 3:55 PM

Employee Post

Hello,

I have created a bug report for this issue with the development team.

Tony Scholz

Lead Network/System Administrator

SmarterTools Inc.

www.smartertools.com

Brian Replied

8/21/2025 at 4:32 PM

I'm not acutally including *.bat but just bat

Brad Smith Replied

8/22/2025 at 4:02 AM

I think the problem is that CONTAINS has an implicit * both before and after. I have a similar problem with domain name conditions. For example, I'd have a rule *.shop, but that will match "myshop.com".

The ideal solution would be to augment the existing CONTAINS option with an ENDSWITH option. That would solve a bunch of problems.

But technically that's a feature enhancement rather than a bug, which shifts things on the priority list, assuming they run like any development team I've been part of. :-)

Brian Replied

8/25/2025 at 8:36 PM

Attachments with extension .DOCX are being considered to match the extension OCX. I have wildcards DISABLED.

I didn't think we used to have dots in front of my extensions but who knows at this point.

.DOCX does not ring true for .OCX.

I guess decide what we should be doing with the dots on extensions. Either you should be comparing the text from the list of extentions to ALL characters in the attachment filename AFTER the last dot OR we should put the dot.

I'm just going to put the . in front of all my extensions for now.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text