Charles,
Although I understand your reservations, I feel in this case that it's best to
lay it all out there and give it to them, let them do what they do. In my mind
it's nothing more than "Flushing" out the best they can offer and finding the
loopholes, and closing them up.
There are more rules/ways to stop them than they have to defeat the rules and
scoring process, so why not let them show us what they've got, show us where we
need to make adjustments and corrections and in turn we will continue to refine
our process, ever so more, squeezing them out...inch by inch.
We will accomplish that goal much quicker if the spammers show us whereall our
faults lie.
Wes
On Wed, 15 Jul 2009, MrGibbage wrote:
> I wonder if the spammers are reading this forum. That seemed awful fast.
I'm sure they do. But I also suspect that they have a simple 'feedback'
mechanism that let's them know how much of their spew is getting rejected
on their botnets, and when the rejection numbers get too high they try
something new, and keep trying until the rejection numbers drop again.
Then we fix our rules, the rejections go up, and they look for yet another
'trick' to get through. They have the advantage of being able to download their
own copies of spamassassin to 'test' their spew. That's why sometimes you get
'red herrings' from me on this list when I don't share the full details of a
rule. Posting it here almost assures that it will get bypassed. They copy the
rule, then try all sorts of different combinations to bypass it....
Now really, the significant factor here is not that any of these obfuscation
tricks are 'new', but that they are using them to bypass the URIBL rules. I
strongly urge the spamassassin develpopers to consider ways to 'open up' the
way that we can specify what SA will 'consider' a URI, or to be able to
'capture' a value from an obfuscation test, manipulate it into its 'original'
URI and then 'manually' submit it to the URIBL....
Example hypothetical syntax (note that some parentheses are *capturing*):
body FINDURI /(www)(?:obfuscation)(domain)(?:obfuscation)(com|net|org)/i
uribl CHECIT /$1.$2.$3/
Basically, allow a rule to 'capture' one or more 'matches' in Perl variables,
and then feed them to a subsequent rule (in this case, a manual URIBL lookup).
This way, the SA developers don't have to hard-code an ever-changing set of
"URI detection rules" into the core code, but we can still develop on-the-fly
rules that can feed a URI to the URIBL tests....
I've heard people mention 'plugins'. Could I code one that would be
easily 'modifiable' so that (for example) this morning's '[dot]' trick can be
quickly added to my plugin? Is there a good working example of a plugin that
extracts text from a message and feeds it to a URI? I'll work on this!
- C
