Re: whitelist_from_rcvd when rDNS fails
I need to whitelist a sender, and I typically use whitelist_from_rcvd, but it's not working in this case, and I suspect because rDNS fails: Received: from ideascollide1.ablehost.com (unknown [208.81.177.83]) Is the next best approach to create a rule that deducts points or is there another way? There aren't any DKIM headers to work with either. meta Received and From header together? On 15.02.12 22:58, Alex wrote: Thanks, that's what I've now done. Wanted to be sure I wasn't missing a more well-defined way to work around this. Maybe spf, but the invalid rdns for 208.81.177.83 makes whiltelist_from_rcvd impossible. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. LSD will make your ECS screen display 16.7 million colors
Re: SPF and DKIM tests by default?
Q: Will some rules not fire if some condition exists based on other rules? A: Correct. There are plenty of rules that build on other rules. We call these meta rules. On 15.02.12 16:08, email builder wrote: Q: Are there any default rules as supplied by sa-update that would prevent SPF rules from firing? you can disable SPF or clear all scores Q: Any other ideas on how to learn what rules are actually being used? huh? Q: Any suggestions as to why SPF rules would not fire on a Gmail message where Gmail uses SPF, my SPF plugin and rule initiation seem to be in place, and a Return-Path header with the envelope from address exists? (please see my previous messages on this thread) I haven't found the headers in apache archive, maybe I didn't search carefully enough, but it's misconfigured trusted_networks and internal_networks what causes SPF to misfire... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows found: (R)emove, (E)rase, (D)elete
Re: warn: config: SpamAssassin failed to parse line, no value provided for body, skipping: body
Hi Kevin McGrail,
Was there any response on the dev list about this? I am not
subscribed to it.
I notice that RCVD_IN_MSPIKE_WL is listed in the updates:
# find -exec grep MSPIKE_WL \{\} \; -ls
meta RCVD_IN_MSPIKE_WLRCVD_IN_MSPIKE_H5 || RCVD_IN_MSPIKE_H4 ||
RCVD_IN_MSPIKE_H3
describe RCVD_IN_MSPIKE_WLMailspike good senders
tflags RCVD_IN_MSPIKE_WLnice net
1313054 -rw-r--r-- 1 root root 2609 Feb 16 06:53
./3.003001/updates_spamassassin_org/20_mailspike.cf
score RCVD_IN_MSPIKE_WL 0.001 -0.010 0.001 -0.010
131619 12 -rw-r--r-- 1 root root11362 Feb 16 06:53
./3.003001/updates_spamassassin_org/72_scores.cf
score RCVD_IN_MSPIKE_WL -0.01
131604 48 -rw-r--r-- 1 root root48281 Feb 16 06:53
./3.003001/updates_spamassassin_org/50_scores.cf
... but spamassassin throws message back:
Feb 16 10:05:01.084 [10573] warn: config: SpamAssassin failed to parse
line, no value provided for body, skipping: body
Feb 16 10:05:01.289 [10573] dbg: config: warning: score set for
non-existent rule *RCVD_IN_MSPIKE_WL*
I did not change it ;)
# grep MSPIKE_WL /etc/spamassassin/local.cf
# echo $?
1
#
The rules are there in
./3.003001/updates_spamassassin_org/20_mailspike.cf
./3.003001/updates_spamassassin_org/72_scores.cf
./3.003001/updates_spamassassin_org/50_scores.cf
I can see scrore for example:
score RCVD_IN_MSPIKE_L4 0.001 0.001 0.001 0.001
score RCVD_IN_MSPIKE_L4 1.7
For the time being I want to work out whether this is a error on the
server, or came via an update.
On 03/02/12 20:39, Kevin A. McGrail wrote:
Can anyone else test with 3.3.1 to see if we are publishing something
that is breaking on 3.3.1? I would guess it might have to do with the
version eval stuff we've been trying to push out.
On 2/3/2012 2:35 PM, Simon Loewenthal wrote:
Yep, fails on standard rules.
( Excuse the slightly messy copy and paste, but I am using ConnectBot on a
smartphone whilst travelling on train. )
# spamassasin -C `pwd` --lint
eb 3 20:27:53.349 [19929] warn: config: SpamAssassin failed to parse line,
no
value provided for body, skipping: body
eb 3 20:27:56.862 [19929] warn: lint: 1 issues detected, please rerun with
debug enabled for more information
--
Dogs are tough.
I've been interrogating this one for hours and he still won't tell me who's
a good boy.
simon@klunky / .co.uk / .org
Kevin A. McGrail kmcgr...@pccc.com wrote:
On 2/3/2012 2:13 PM, Simon Loewenthal wrote:
Version 3.3.1 on Debian Squeeze
Are the standard rules throwing any errors with lint?
For example, spamassassin -C
/var/lib/spamassassin/3.003001/updates_spamassassin_org --lint
regards,
KAM
--
*Kevin A. McGrail*
President
Peregrine Computer Consultants Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422
http://www.pccc.com/
703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-359-8451 (fax)
kmcgr...@pccc.com mailto:kmcgr...@pccc.com
--
PGP is optional: 4BA78604
simon @ klunky . org
simon @ klunky . co.uk
I won't accept your confidentiality
agreement, and your Emails are kept.
~Ö¿Ö~
email address showing in recipients not on server
While checking the stats on a new installation I looked at the recipients list. On the list was an email address that did not reside on my server. Where did it come from? What exactly is it? Any ideas of where it came from and any actions I need to take are appreciated. -- View this message in context: http://old.nabble.com/email-address-showing-in-recipients-not-on-server-tp5398p5398.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: SPF and DKIM tests by default?
On 2/15/2012 7:08 PM, email builder wrote: OK, but: Q: Are there any default rules as supplied by sa-update that would prevent SPF rules from firing? Not that I can think of. Q: Any other ideas on how to learn what rules are actually being used? What I would likely do is save the gmail message to an mbox format file. Then I would run spamassassin -D -t /tmp/mboxfile 21 | grep -i SPF and see what I find. Regards, KAM
Re: email address showing in recipients not on server
On 2/16/2012 6:44 AM, netcapacity wrote: While checking the stats on a new installation I looked at the recipients list. On the list was an email address that did not reside on my server. Where did it come from? What exactly is it? Any ideas of where it came from and any actions I need to take are appreciated. Without an example, your statements are not clear to me. Can you cut and paste what you saw? Regards, KAM
Re: email address showing in recipients not on server
Without an example, your statements are not clear to me. Can you cut and paste what you saw? Regards, KAM I understand. On the server statistics I can see what email addresses are being used and filtered. Since this is a new installation I only have 2 email addresses set up. One that regularly gets SPAM and one that does not. I do this to gauge my settings. When I checked the statistics the two addresses mentioned above were there with their respective stats, but another email address was also there and showed where Spam Assassin filtered and sent ***SPAM*** email. I do not know where this address came from. It is completely foreign. I am wondering if the SPAM catcher address may also have a trojan that resent an email. It was only 1 email sent but it is still disturbing. Do you think if I blacklist the domain of the address it will prevent any others from being sent? I looked up the whois and it is private. I browsed to the domain and got a blank page. -- View this message in context: http://old.nabble.com/email-address-showing-in-recipients-not-on-server-tp5398p6146.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: email address showing in recipients not on server
On 2/16/2012 9:12 AM, netcapacity wrote: Without an example, your statements are not clear to me. Can you cut and paste what you saw? Regards, KAM I understand. On the server statistics I can see what email addresses are being used and filtered. Since this is a new installation I only have 2 email addresses set up. One that regularly gets SPAM and one that does not. I do this to gauge my settings. When I checked the statistics the two addresses mentioned above were there with their respective stats, but another email address was also there and showed where Spam Assassin filtered and sent ***SPAM*** email. I do not know where this address came from. It is completely foreign. I am wondering if the SPAM catcher address may also have a trojan that resent an email. It was only 1 email sent but it is still disturbing. Do you think if I blacklist the domain of the address it will prevent any others from being sent? I looked up the whois and it is private. I browsed to the domain and got a blank page. Couldn't begin to tell you. This sounds like some sort of panel for hosting and is far outside of the SA project.
Re: Some rules I created for suspicious Javascript practices
On 02/15/2012 04:43 PM, Thomas Rutter wrote (as neon_overload):
I have created some rules which I have found to be very effective so
far at identifying a certain type of spam that spamassassin
otherwises cannot detect.
I hereby license them under the WTFPL which is GPL and Apache license
compatible.
I am interpreting that license as rename things and they're essentially
public domain. Rules have been renamed, tweaked, and added to
subversion for testing. After the next ruleqa run (probably tomorrow),
you can see how they perform on the SpamAssassin corpus at
http://ruleqa.spamassassin.org/?srcpath=neon_overload.cf
The new versions, which are Apache License 2.0, are attached. Note that
attribution, though not requested, is present.
Thomas Rutter: If you have any objections to what I did, complain now.
# I hereby license them under the WTFPL which is GPL and Apache license
# compatible. -- Thomas Rutter/neon_overload to SA-users, 2012-02-16 00:43 UTC
#
http://old.nabble.com/Some-rules-I-created-for-suspicious-Javascript-practices-tt3130.html
#
# WTFPL 2.0 basically says rename things and they're essentially public domain
# Rules have been renamed and slightly tweaked
rawbody JS_EXTRA_UNESCAPE
/[+=]\s{0,9}unescape\s{0,9}\(\s{0,9}[']%(?i:6[1-9A-F]|7[0-9A])/
describe JS_EXTRA_UNESCAPE JavaScript: Unnecessary URI escaping
#score LOCAL_UNNECESSARY_UNESCAPE 1.7
rawbody JS_EXTRA_CONCAT
/[+=]\s{0,9}['][a-z0-9]{1,64}[']\+['][a-z0-9]{1,64}[']/i
describe JS_EXTRA_CONCATJavaScript: Unnecessary string concatination
#score LOCAL_UNNECESSARY_STRCONCAT 0.5
rawbody JS_FROMCHARCODE/=\s{0,9}String\.fromCharCode\b/
describe JS_FROMCHARCODEJavaScript: function String.fromCharCode
#score LOCAL_HIDE_FROMCHARCODE 0.7
#rawbody LOCAL_HIDE_URL/h\+tt\+p:\+\//
rawbody JS_CONCATINATED_HTTP
m@(?!http:/)h['+]{0,3}(?:t['+]{0,3}){2}p['+]{0,3}:['+]{0,3}/@
describe JS_CONCATINATED_HTTP Contains concatenated URI like htt+p://...
#score LOCAL_HIDE_URL 0.7
signature.asc
Description: OpenPGP digital signature
overriding rules
Hi SA users,
In the past (3.2.5 or so) I used to be able to use local.cf to override
rule settings like this,
header __RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '127.0.0.[45678]')
header RCVD_IN_PBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '127.0.0.1[01]')
uridnsbl URIBL_SBL` sbl.dnsbl. TXT
(I am changing the host used for lookups to a local host)
but now (3.3.1) those seem to be ignored in favor of the default settings.
Did this behavior change?
I started working on a different solution (proposed by Kevin Olson @
mxtools) of cloning the rules with a different name, changing those, and
disabling the main rules. But the problem with that is that there are lots
of rules that depend on these particular rule names which break. I could
close those as well, but likely there are things that depend on them as
well and the end result is a complete mess that's hard to maintain.
Thanks,
--
Matt Taggart
tagg...@riseup.net
Re: overriding rules
tagg...@riseup.net wrote:
Hi SA users,
In the past (3.2.5 or so) I used to be able to use local.cf to override
rule settings like this,
header __RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '127.0.0.[45678]')
header RCVD_IN_PBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '127.0.0.1[01]')
uridnsbl URIBL_SBL` sbl.dnsbl. TXT
(I am changing the host used for lookups to a local host)
but now (3.3.1) those seem to be ignored in favor of the default settings.
Did this behavior change?
Not that I know of - in fact I do exactly this for Spamhaus here as
well. I also put the local IP and URI blacklists under .dnsbl in the
same rbldnsd instances.
Try a simple rule in local.cf:
body TESTME /./
that should hit on everything. If that doesn't hit, you're looking at
the wrong copy of local.cf.
spamassassin -D should show you the directories SA is reading for your
channel and local rules.
I started working on a different solution (proposed by Kevin Olson @
mxtools) of cloning the rules with a different name, changing those, and
disabling the main rules. But the problem with that is that there are lots
of rules that depend on these particular rule names which break. I could
close those as well, but likely there are things that depend on them as
well and the end result is a complete mess that's hard to maintain.
If your cloned rules work with the alternate zone name, but the altered
stock rule doesn't, you've probably got a typo somewhere.
(I actually override the Spamhaus rules in a local rules channel, which
I set up because I was distributing the rules to 6 machines at the time.
I named starting with zzz to make sure it loaded *after* the stock
rules. The Spamhaus rules have been working for two years like this now.)
-kgd
Re: email address showing in recipients not on server
On 2/16/2012 6:14 AM, Kevin A. McGrail wrote: Couldn't begin to tell you. This sounds like some sort of panel for hosting and is far outside of the SA project. I wonder if perhaps it's logging the TO field as though that has something to do with where the message will be delivered? -- Dave Warren, CEO Hire A Hit Consulting Services http://ca.linkedin.com/in/davejwarren
Re: SPF and DKIM tests by default?
Q: Will some rules not fire if some condition exists based on other rules? A: Correct. There are plenty of rules that build on other rules. We call these meta rules. Q: Are there any default rules as supplied by sa-update that would prevent SPF rules from firing? you can disable SPF or clear all scores The question was *as supplied by sa-update* Q: Any other ideas on how to learn what rules are actually being used? huh? Please read the rest of this thread. Q: Any suggestions as to why SPF rules would not fire on a Gmail message where Gmail uses SPF, my SPF plugin and rule initiation seem to be in place, and a Return-Path header with the envelope from address exists? (please see my previous messages on this thread) I haven't found the headers in apache archive, maybe I didn't search carefully enough, I recommend gmane.org but it's misconfigured trusted_networks and internal_networks what causes SPF to misfire... Thank you sincerely for your help. I can only imagine that SPF wouldn't fire if I accidentally specified Google in one of those settings or had an error in one of them. In this case, those are at their defaults of empty, so I'm hoping there are other suggestions. Thanks again..
Re: SPF and DKIM tests by default?
On 2/16/2012 4:54 PM, email builder wrote: but it's misconfigured trusted_networks and internal_networks what causes SPF to misfire... Thank you sincerely for your help. I can only imagine that SPF wouldn't fire if I accidentally specified Google in one of those settings or had an error in one of them. In this case, those are at their defaults of empty, so I'm hoping there are other suggestions. Thanks again.. Letting trusted_networks empty is not generally a good idea. In particular, if your SA server is using a private IP, it will default to trusting too much. Specify your local networks in trusted_networks and see if that helps your problem. Leaving trusted_networks empty does not mean trust nothing; it means let SA figure out what to trust. -- Bowie
Re: SPF and DKIM tests by default?
On 2/15/2012 7:08 PM, email builder wrote: OK, but: Q: Are there any default rules as supplied by sa-update that would prevent SPF rules from firing? Not that I can think of. Q: Any other ideas on how to learn what rules are actually being used? What I would likely do is save the gmail message to an mbox format file. Then I would run spamassassin -D -t /tmp/mboxfile 21 | grep -i SPF and see what I find. Well, that was actually the other more general question that you kindly already offered your help for - how to determine all rules currently in use at execution time. Short of other opinions, we'll wait to see how the bugzilla item I created progresses. But your advice here is in fact quite useful and may do a fine job at pointing to the issue. Keep in mind, all rules are as given by sa-update. I copied in all the output below but here are what I see as key points by line number: Line 8: Someone earlier pointed out that SA uses this Received-SPF header, but then I think it was you that pointed out that this shouldn't be necessary, and I added that it would seem odd to me if SA didn't also look for the quasi-standard Return-Path header which for some mailers such as Postfix will include the envelope from address. The lack of this header doesn't seem to stop SPF execution though. When I copy my Return-Path header into a Received-SPF header, line 8 becomes two lines: Feb 16 14:19:59.263 [12846] dbg: spf: found a Received-SPF header added by an internal host: Received-SPF: emailbuilde...@gmail.com Feb 16 14:19:59.263 [12846] dbg: spf: could not parse result from existing Received-SPF header I tried this with a couple different formats of email and/or domain name. Not sure what's going on here. The rest of the lines are the same in both cases. Line 12: Any comments why the SPF lookup returns nothing? How can I do this same lookup by hand? Could this be a DNS problem? Line 13: Weren't the last few lines DNS checks already? Line 14: I don't know why this happens. It is true that Postfix relays mail to amavis, then it goes back to Postfix then it is handed off to maildrop for delivery - SA is called from maildrop. So there is some local relaying here, but why does this stop SA from checking the hop from the outside to my Postfix? Is this where having a non-default trusted_networks setting would help? Thanks again for the great help and patience. 1) Feb 16 14:13:17.361 [12806] dbg: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC 2) Feb 16 14:13:17.774 [12806] dbg: config: fixed relative path: /var/lib/spamassassin/3.003001/updates_spamassassin_org/25_spf.cf 3) Feb 16 14:13:17.774 [12806] dbg: config: using /var/lib/spamassassin/3.003001/updates_spamassassin_org/25_spf.cf for included file 4) Feb 16 14:13:17.774 [12806] dbg: config: read file /var/lib/spamassassin/3.003001/updates_spamassassin_org/25_spf.cf 5) Feb 16 14:13:17.894 [12806] dbg: config: fixed relative path: /var/lib/spamassassin/3.003001/updates_spamassassin_org/60_whitelist_spf.cf 6) Feb 16 14:13:17.895 [12806] dbg: config: using /var/lib/spamassassin/3.003001/updates_spamassassin_org/60_whitelist_spf.cf for included file 7) Feb 16 14:13:17.895 [12806] dbg: config: read file /var/lib/spamassassin/3.003001/updates_spamassassin_org/60_whitelist_spf.cf 8) Feb 16 14:13:19.595 [12806] dbg: spf: checking to see if the message has a Received-SPF header that we can use 9) Feb 16 14:13:19.646 [12806] dbg: spf: using Mail::SPF for SPF checks 10) Feb 16 14:13:19.646 [12806] dbg: spf: checking HELO (helo=mail-iy0-f181.google.com, ip=209.85.210.181) 11) Feb 16 14:13:19.648 [12806] dbg: dns: providing a callback for id: 13553/mail-iy0-f181.google.com/SPF/IN 12) Feb 16 14:13:19.984 [12806] dbg: spf: query for /209.85.210.181/mail-iy0-f181.google.com: result: none, comment: , text: No applicable sender policy available 13) Feb 16 14:13:19.988 [12806] dbg: spf: already checked for Received-SPF headers, proceeding with DNS based checks 14) Feb 16 14:13:19.988 [12806] dbg: spf: relayed through one or more trusted relays, cannot use header-based Envelope-From, skipping 15) Feb 16 14:13:19.995 [12806] dbg: spf: def_spf_whitelist_from: already checked spf and didn't get pass, skipping whitelist check 16) Feb 16 14:13:19.997 [12806] dbg: spf: whitelist_from_spf: already checked spf and didn't get pass, skipping whitelist check 17) Feb 16 14:13:25.566 [12806] dbg: timing: total 8235 ms - init: 1912 (23.2%), parse: 1.82 (0.0%), extract_message_metadata: 74 (0.9%), poll_dns_idle: 381 (4.6%), get_uri_detail_list: 1.24 (0.0%), tests_pri_-1000: 27 (0.3%), compile_gen: 171 (2.1%), compile_eval: 39 (0.5%), tests_pri_-950: 9 (0.1%), tests_pri_-900: 9 (0.1%), tests_pri_-400: 8 (0.1%), tests_pri_0: 5996 (72.8%), dkim_load_modules: 33 (0.4%), check_dkim_signature: 11 (0.1%), check_spf: 389 (4.7%), check_dcc: 190 (2.3%), check_razor2: 5003 (60.8%), check_pyzor: 0.54 (0.0%), tests_pri_500: 100 (1.2%), tests_pri_1000: 15
Re: SPF and DKIM tests by default?
On 2/16/2012 4:54 PM, email builder wrote: but it's misconfigured trusted_networks and internal_networks what causes SPF to misfire... Thank you sincerely for your help. I can only imagine that SPF wouldn't fire if I accidentally specified Google in one of those settings or had an error in one of them. In this case, those are at their defaults of empty, so I'm hoping there are other suggestions. Thanks again.. Letting trusted_networks empty is not generally a good idea. In particular, if your SA server is using a private IP, it will default to trusting too much. Specify your local networks in trusted_networks and see if that helps your problem. Leaving trusted_networks empty does not mean trust nothing; it means let SA figure out what to trust. Makes sense, especially if my hunch about the relayed through one or more trusted relays, cannot use header-based Envelope-From, skipping part of the debug output I just sent to this list is on track. Is there a way to set trusted_networks on the command line of the spamassassin command just for testing?
Re: SPF and DKIM tests by default?
On 2/16/2012 4:54 PM, email builder wrote: but it's misconfigured trusted_networks and internal_networks what causes SPF to misfire... Thank you sincerely for your help. I can only imagine that SPF wouldn't fire if I accidentally specified Google in one of those settings or had an error in one of them. In this case, those are at their defaults of empty, so I'm hoping there are other suggestions. Thanks again.. Letting trusted_networks empty is not generally a good idea. In particular, if your SA server is using a private IP, it will default to trusting too much. Specify your local networks in trusted_networks and see if that helps your problem. Leaving trusted_networks empty does not mean trust nothing; it means let SA figure out what to trust. Makes sense, especially if my hunch about the relayed through one or more trusted relays, cannot use header-based Envelope-From, skipping part of the debug output I just sent to this list is on track. Is there a way to set trusted_networks on the command line of the spamassassin command just for testing? This didn't work: spamassassin -D --cf='trusted_networks 127.0.0.1' -t example_email_no_spf 21 | grep -i SPF All my local handoffs are to localhost [127.0.0.1] so I wouldn't know what else to use (it's an all-in-one single server simple system)
Re: White text on white background
On Thu, 16 Feb 2012, JP Kelly wrote: I am getting a bunch of spam with white text on a white background. Any ideas how to catch it? Here is an example: p style=color:#FFF; font-size:1px; width:600px; At the risk of playing whack-a-mole: rawbody HTML_TEXT_WHITE_SHORT /style=color#FFF;/ The short color code is probably unlikely to appear in legitimate HTML styles. There should be stock rules for things like white 1px text, but I'm too lazy to go look right now. :) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Public Education: the bureaucratic process of replacing an empty mind with a closed one. -- Thorax --- 6 days until George Washington's 280th Birthday
Re: Some rules I created for suspicious Javascript practices
Adam Katz-10 wrote:
Thomas Rutter: If you have any objections to what I did, complain now.
That's fine.
I have been hard at work on tweaking these rules and have come up with new
versions which appear more effective. Have not spent much time on
performance though.
New version follows:
# highly suspicious practices
rawbody LOCAL_U_UNESCAPE /[+=(]\s*unescape\s*\(\s*[']%(6[1-9A-F]|7[0-9A])/
describe LOCAL_U_UNESCAPE Suspicious use of JS unescape function
score LOCAL_U_UNESCAPE 1.8
rawbody LOCAL_U_STRCONCAT /[+=(]\s*(['])[a-zA-Z0-9\.]{1,16}\1 ?\+
?\1[a-zA-Z0-9\.]{0,16}\1/
describe LOCAL_U_STRCONCAT Suspicious unnecessary string concatenation
score LOCAL_U_STRCONCAT 0.7
rawbody LOCAL_HIDE_FROMCHARCODE /=\s*String\.fromCharCode\b/
describe LOCAL_HIDE_FROMCHARCODE Obfuscated used of JS fromCharCode function
score LOCAL_HIDE_FROMCHARCODE 0.6
rawbody LOCAL_HIDE_URL /[+=(]\s*(['])(?!http)h(\1 ?\+ ?\1)?t(\1 ?\+
?\1)?t(\1 ?\+ ?\1)?p(\1 ?\+ ?\1)?(?!:\/\/):(\1 ?\+ ?\1)?\/(\1 ?\+ ?\1)?\//
describe LOCAL_HIDE_URL Obfuscated HTTP link eg. 'ht'+'tp:'+'//'
score LOCAL_HIDE_URL 0.9
rawbody LOCAL_JS_REDIR1
/[Ss][Cc][Rr][Ii][Pp][Tt]\s*(type=[^]+\s*)?\s*(window|self|(var\s+)?([a-z]+)\s*=\s*window\s*;?\s*\4)?\.?(location|\[[']location[']\])(\.href)?\s*[=(]/
describe LOCAL_JS_REDIR1 Code for a JS redirect
score LOCAL_JS_REDIR1 0.5
body LOCAL_FILLER_TEXT /([A-Z][a-z]*(\s[a-z]+){4,6}\.?\s?){18}/
describe LOCAL_FILLER_TEXT Long sequence of 5-7 word sentences with capital
only at start
score LOCAL_FILLER_TEXT 0.4
--
View this message in context:
http://old.nabble.com/Some-rules-I-created-for-suspicious-Javascript-practices-tp3130p33340124.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: White text on white background
ok I'm a dummy. How do I implement this? On Feb 16, 2012, at 5:03 PM, John Hardin wrote: rawbody HTML_TEXT_WHITE_SHORT /style=color#FFF;/
Re: White text on white background
Den 2012-02-17 02:12, JP Kelly skrev: How do I implement this? rawbody HTML_TEXT_WHITE_SHORT /style=color#FFF;/ add it to local.cf or user_prefs, its not tested here so it might not work at all it will score default 1.0 if no score is set
Re: White text on white background
No didn't work. with --lint I got: warn: config: invalid regexp for rule HTML_TEXT_WHITE_SHORT: /style=\color: missing or invalid delimiters On Feb 16, 2012, at 7:53 PM, Benny Pedersen wrote: Den 2012-02-17 02:12, JP Kelly skrev: How do I implement this? rawbody HTML_TEXT_WHITE_SHORT /style=color#FFF;/ add it to local.cf or user_prefs, its not tested here so it might not work at all it will score default 1.0 if no score is set
Re: White text on white background
The '#' is a comment character, need to escape it.
Try:
rawbody HTML_TEXT_WHITE_SHORT /style=color\#FFF;/
On Thu, 16 Feb 2012, JP Kelly wrote:
No didn't work.
with --lint I got:
warn: config: invalid regexp for rule HTML_TEXT_WHITE_SHORT: /style=\color:
missing or invalid delimiters
On Feb 16, 2012, at 7:53 PM, Benny Pedersen wrote:
Den 2012-02-17 02:12, JP Kelly skrev:
How do I implement this?
rawbody HTML_TEXT_WHITE_SHORT /style=color#FFF;/
add it to local.cf or user_prefs, its not tested here so it might not work at
all
it will score default 1.0 if no score is set
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: White text on white background
Den 2012-02-17 06:53, JP Kelly skrev: No didn't work. with --lint I got: warn: config: invalid regexp for rule HTML_TEXT_WHITE_SHORT: /style=\color: missing or invalid delimiters ^^ On Feb 16, 2012, at 7:53 PM, Benny Pedersen wrote: Den 2012-02-17 02:12, JP Kelly skrev: How do I implement this? rawbody HTML_TEXT_WHITE_SHORT /style=color#FFF;/ ^^ add it to local.cf or user_prefs, its not tested here so it might not work at all it will score default 1.0 if no score is set rawbody HTML_TEXT_WHITE_SHORT /style=\color#FFF;/ describe HTML_TEXT_WHITE_SHORT rawbody: /style=color#FFF;/ score HTML_TEXT_WHITE_SHORT 0.1
