On Tue, 13 Jan 2004 16:02:36 -0600, "Dallas L. Engelken" <[EMAIL PROTECTED]> writes:
> > body JAVASCRIPT_ENCODING_1 /\b(?:\d{1,3}[\s\,]+){8}/
> > describe JAVASCRIPT_ENCODING_1 Contains comma seperated
> > ascii representations score 0.1 # you can score this by
> > itself if you want.
> >
> > body JAVASCRIPT_ENCODING_2 /document\.write/i
> > describe JAVASCRIPT_ENCODING_2 contains document.write
> > score 0.1
> >
> > meta JAVASCRIPT_ENCODING (JAVASCRIPT_ENCODING_1 &&
> > JAVASCRIPT_ENCODING_2) describe JAVASCRIPT_ENCODING Uses
> > Javascript ascii encoding to hide text score 2.0
> >
> > i didnt run against my corpus, just use at your own risk :)
> >
>
> okay, so i did... i see no reason to use these rules, unless this
> becomes a common tactic.
And even then. I occasionally put in CSV in email when I'm emailling
researchc results. I think its much better to catch the javascript
stuff like document.write(). Email *should* be easy to analyze and
simple. If a newsletter wants to be dynamic, it should be a
website. I'd leave the 'document.write' rule in, with a low score, so
that future mass-checks will notice if it starts to used/abused.
The only other option is to run a javascript interpreter, because
there are a near-infinite number of ways javascript could be used to
create text.
Scott
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
