On Tue, 21 Jul 2009, twofers wrote:
.... 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.  

Because we CAN'T. While the spammers are free to try ANY obfuscation or filter-dodging technique imaginable, we are always constrained to avoid false positives. So any time we share our 'good ideas' with them, they come closer to their 'goal' of finding the 'perfect' way to spam that we cannot filter...

And as a side note, I've noticed that I might have a rule in place, like my original, simple 'shopXX' rule, and it worked for me for a couple of weeks, until people started posting rules for it here. Then the more-complex obfuscations started....

Further to my original post, I haven't read all of today's mail yet, but
I suspec there is not an answer yet to this question, but I wish to reiterate it, with a further comment. The comment is that I was looking at plugins and noticed that there was one to follow URI's that appear to be redirects, and 'add' the target URI to the internal list of URI's to be run through the URIBL. I tried to look at the script to see if I could modify it to my purpose, but just can't figure it out. (sigh)

But it would be a good starting basis for the plugin I am hoping to see.

Original request:
.... 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 CHECKIT /$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

Reply via email to