Hi

I have set a filter for some words in the body, but some spams are not filtered and marked for deletion even though I can see this word in the preview. If I send normal mail to my address with this word, then it is filtered OK. How is it possible?

Karel

Look at the source of the e-mail (right click and select view complete header) spammers do tricks to get around simple filters.

Look around here with the search function on the FireTrust catagory for "gary filters" and you will find some good discussion and sample filters.

Well, it seems that your filter is working correctly, as you have tested it for yourself. Are you absolutely sure the words in the filter and the body are _exactly_ the same? (Look into the HTML). There isn't a dot or space in it you might have overseen?

Hugh

I was looking at the mail and the word Enlargement was written as

E<kehejlbcuqxcn>nl<khoejladpwslyp>arg<kfntuzbcoyml>em<kgkkmlgdeqz>e<kfrnvwvabwitlsp>n<koguobsroxvhibi>t

so the body filter will not recognize it.

But what I meant was, when in the MWP's preview window I see the word "Enlargement' displayed correctly, why it is not filtered. Or how can I set a filter for the text in the preview window.

Karel

The trick is to write a filter that looks for a string of several nonsense characters enclosed in angle brackets. In a sense, this makes filtering a great deal easier -- you don't need a list of keywords and their mis-spelled variants (such as enlargement/enlargment). And you can be reasonably certain none of your friends would send a message to you like that, whereas a filter on enlargement might filter someone intersted in photography.

There have been several posts that discuss filters of this type. Off the top of my head, I'd create the filter this way (untested):

Body contains RegEx <[a-z]{5,}>

Of course, filters that rely on the message body need to download the message body....

That is the purpose of these kind of tricks.

Possibly as some have suggested mailwasher could implement an optional HTML stripping function for their filters. It would apply the filter conditions after first removing any html code. This wouldn't be clear cut as there is no positive way to tell HTML from normal text, just guesses that can be made based on probability.

Ikeb, Yes the browsers do treat tags within the angle brackets different from normal text. But what they do is just ignore any text within the angle brackets that does not parse correctly into an expected format. To display an angle bracket in HTML you have to escape it or use a char entity.

Without building a more complete HTML parser into MW dealing with the bogus HTML tags problem will be tricky. Just dropping anything between angle brackets for e-mail with a MIME type of HTML would work for mailwasher but might cause problems when a mail program sends mail without the proper MIME settings.

If you NEVER have to send or request a code snippet, that regular expression should work fine, at least until MW learns to ignore stuff between brackets when filtering.

That would be the proper way to do it, not use the occurrence of text between brackets as a trigger.

Possibly you could rewrite that expression so that the filter ignores the brackets and anything that might be in between them, including foreign characters and smileys or high ASCII stuff.

DearWebby, I'm confused. The Regular Expression TimeGhost suggested is intended to key on the nonsense characters between the <> brackets. Your comments seem to suggest that the filter should do something else. Or am I missing something?

Ikester, he is proposing to use the occurrence of brackets and western alphabet characters as a trigger to delete mail.

If somebody sends him a tech support question and has an example of HTML in it, that would trigger the filter, the mail would be deleted, and the sender would think he is being ignored. The same would occur with mathematical formulas. They should not trigger a deletion and blacklisting.

Instead of using that as a trigger, the brackets and the stuff between them should simply be ignored for filtering purposes. That way the spread words will be shrunk together and can be seen by the filter the same way you see them in the list.

Ideally, that shrinking should be done at the program level and prefaced to any filter, not manually added as an "OR" choice to a filter.

Again, I'm not a filter expert here... but wouldn't just ignoring the brackets and the text between them make it easy to give us a spam surprise by just putting brackets around it with a non html mime type?