Spammers have found a way around the filters!

[grey-hame]

This is Not Good. I just got a result for a search for "word1 word2 word3" with the name

Crack for - word3 word2 word1.zip

with a file size of 111K. The thing is, zips should be blocked by the "bogus files" filter in this instance and this one is showing up anyway ("bogus files" seems to be the one that filters file types that don't fit the query).

It gets worse: I tried several regexp security rules to block it and none worked:

^Crack for - .*\.zip
^Crack for - .*\.zip$
^(Crack for - ).*\.zip$
^(Crack for - )

So, it looks like a (almost certainly malware-distributing) spammer has discovered a way to make Shareaza not filter a query hit they send.

This foretells a monstrous flood of unblockable spam results in the near future, as soon as whatever technique they've discovered becomes widespread knowledge among p2p spammers.

Which in turn means you'd better release 2.5.2.0 with the filtering bug fixed ASAP. (The bug in question being whatever is causing this particular search result to not be subjected to filtering. I am now using 2.5.1.0.)

[cyko_01]

[ocexyz]

[mojo85]

Confirm what? It works for you or doesn't?

[ocexyz]

[grey-hame]

Consider that with my usual filters, I normally see none of the .zip extension spam that gets returned for every gnutella query one makes, yet this one somehow snuck through. *Something* is wrong.

[grey-hame]

Found another one. "foo bar baz(192k 44100 stereo).snd" in response to one of my queries, doesn't get clobbered by a security rule using .*(\(192k 44100 stereo\)\.snd)$ even though it obviously should.