Blocklist rule with regular expression not working correctly

I started receiving several spam messages with from addresses like mail1@presskey.info and mail@missedcall.info. I set up a blocklist regular expression rule “^mail.*info$”. It has caught 7 emails but misses some. (Missed includes mail1@presskey.info and a few others that I “trained as spam” because I was busy.)

Thoughts?

I’m running SpamSieve 3.2.2 on macOS 13.7.8, with “Apple Mail - Rescue Good Messages” running in the background to move Spam to Trash, with pMarkSpamMessagesRead : true, pMoveBlueMessagesToTrash : true, and pEnableDebugLogging : true.

I just tested that a ^mail.*info$ regex rule correctly matches a message with sender mail1@presskey.info, so I’m not sure why that didn’t work for you. Perhaps SpamSieve thought the message was good because it also matched an allowlist rule. You can see in the Log window why it predicted each message to be good. Or if it doesn’t say that SpamSieve predicted the message to be good, that points to a setup problem.

I found several mail.*info addresses in the allow list. Wow. Not sure how they got there. Probably operator error. Thanks for the direction toward the Log then allowlist.

So I re-ran SpamSieve on two of the messages (both mail1@presskey.info). They remained in the inbox. I checked the log. It said Predicted: Good (0), then Predicted: Good (1). Summary was “SpamSieve classified this message as Good because this exact message had been trained as Good.” Is there some part of SpamSieve other than the Allowlist and Blocklist, behind the scenes, that may perhaps be hanging onto this email as “good”?

For now, I’ll train it as spam, but I was hoping that just changing the rules, it would no longer be allowed.

The Rule History in the log will show whether the rules got there because of auto-training or manual training or because you created that specific rule. Note that it’s normal and good to have spammy allowlist rules so long as they are disabled. If they were not disabled automatically, that points to operator error (failing to train the mistakes).

Yes, this sounds like you didn’t train the mistakes as spam. Changing the rules is not a substitute for correcting the mistakes. Please see Fixing Uncorrected Mistakes on this page.

Thank you!