Message Filters fail to detect string in base64 encoding
Spammers have been using base64 encoding to beat spam filter making it impossible to filter for a string or using REGEX.
Any suggestions to defeat this tactic.
Most spam messages contain easily identifiable strings and repeating links or phrases but simple string filters are sidelined because the message isn't sent as straight text.
Alla svar (4)
have you tried manually marking such email a junk? if those strings are as easily identified as you suggest Thunderbird should identify them after the first 50 or so manual notifications/decisions. Manual filters to try and manage junk/Spam are never going to work in the long run as it is a war of innovation and the spammers have more money to pay experts to defeat filters than their intended recipients have to pay for counter measures. Hence Thunderbird learning filter. It learns from your decisions..
Thanks for the response Matt. I have been using TB for at least 15 years and am reasonably familiar with its capabilities.
I do consistently mark them and it seems on occasion the spam filter actually catches the offensive messages along with other items which are not spam. But while they are marked as spam, they still wind up inside of my inbox and not in the spam folder. This causes me to deal with a list of messages that have little fireballs next to them. I believe the spam filter is wrong more often than it is right. Thunderbird may learn from my decisions, but that doesn't mean it is interpreting them properly.
I disagree with your premise that since the method will ultimately fail because the spammers are agile enough to design a 'work around', that there is no need to have a necessary tool to defend yourself now.
The actual text is visible in the message viewed in text mode, I never view messages in HTML unless I know the sender and even then I have to make a conscious decision. I have decided that the likelihood that any message that contains links to the storage.googleapis or hubspotfree-hk.net or MKT***.com, etc. is from a spammer or criminal is reasonably high. These strings are usually in the body of the message and contained inside an <href/> link. If the message filter was able to parse the base64 encryption to actually see the string then I could design a filter that actually removed those messages to my spam folder for later review. Or delete them outright.
If TB can display a base64 encryption properly in the preview pane why can't it see inside the same with a message filter?
I will just cut to the chase, the filters have access to the body text of the email, not the source HTML.
Too bad. Seems like a shortcoming.