Re: Lint problem with KAM.cf
+1 Same issue here. On 8/30/21 14:31, Rick Cooper wrote: > This have been going on a while but I haven't had time to addresses. > When the KAM rules are updated I see the following lint warning > warn: rules: error: unknown eval 'short_url' for __KAM_SHORT > > Near as I can tell I am running the latest DecodeShortURLs.pm but the site > says it's being merged directly into SA. If I change short_url to > short_url_tests the error goes away but I haven't run it down in the code. I > am running SA 3.4.6 and am wondering if there is a new modual for > DecodeShortURLs that I am missing somewhere? > > Rick Cooper >
Re: Which Net::DSN for SpamAssassin-3.4.1
>
> Net::DNS has had some very good but rather weakly-controlled improvement
> recently, including an API change that got rolled back, so the latest
> (1.06) is probably the best choice (it's what I use.) However, all
> recent versions cause a problem with the released version of SA. The
> patch for that is minor:
>
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223
> https://svn.apache.org/viewvc?view=revision=1691992
>
> --- lib/Mail/SpamAssassin/DnsResolver.pm.orig2015/07/20 18:23:18
> 1691991
> +++ lib/Mail/SpamAssassin/DnsResolver.pm2015/07/20 18:24:481691992
> @@ -592,6 +592,9 @@
>};
>
>if ($packet) {
> +# RD flag needs to be set explicitly since Net::DNS 1.01, Bug 7223
> +$packet->header->rd(1);
> +
># my $udp_payload_size = $self->{res}->udppacketsize;
> my $udp_payload_size = $self->{conf}->{dns_options}->{edns};
> if ($udp_payload_size && $udp_payload_size > 512) {
Okay, thanks for the info! -- Mike
Which Net::DSN for SpamAssassin-3.4.1
Hello all I'm confused ... what is the "recommended" version of Net::DNS to use with an unpatched SpamAssassin-3.4.1? Or are there patches I ought to apply for, say, Net::DNS 1.06? Thanks! -- Mike G.
Re: ancient perl versions
On 12/05/2014 09:38 AM, Noel Butler wrote: pffft I see no problem, as like most developers if you cant reproduce it, then its nothing to bother about, after all this time 2 ppl dont like a font or whatever, your pissing up the wrong tree if you think I have a care factor about changing things when i cant reproduce it. time to move along ... You're reproducing it for me ... e-mails from you have a hard-to-read small font here also. Not from anyone else - just you.
Re: Hacked Wordpress sites Cryptolocker
I'm testing versions that insist on .php and am getting very good results. Thanks to the OP for pointing this out! I'm also getting WP phishing urls that end in /, like so: ... /wp-includes/logs/ Presumably, this is the equivalent of /wp-includes/logs/index.php? -- Mike G
Re: Hacked Wordpress sites Cryptolocker
I'm also getting WP phishing urls that end in /, like so: ... /wp-includes/logs/ spample plz? http://pastebin.com/yBLqTrYP
Re: refusing to untaint
Please open a new bug. I'll try and make it a blocker for 3.4.1 if you open it ASAP. Done. https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7020
Re: refusing to untaint
Please open a new bug. I'll try and make it a blocker for 3.4.1 if you open it ASAP. Done. https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7020 For the list - the error appears to have been caused from an old .pre file that was left in /etc/mail/spamassassin. Removing the .pre files and re-installing SA eliminated the warning. No bug. A configuration issue here. -- Mike G.
refusing to untaint
Hello,
I've installed SpamAssassin-3.4.0 on a couple of machines via the
tarball and
perl Makefile.PL
make
make test
make install
When I run a message through spamassassin -t it gives this warning from
Util.pm
Feb 26 12:19:27.028 [17527] warn: util: refusing to untaint
suspicious path: ${exec_prefix}/lib
This is perl 5, version 18, subversion 1 (v5.18.1) built for
x86_64-linux-thread-multi
I'm guessing that the variable ${exec_prefix} should already have been
evaluated? Can someone tell me what might be the problem?
Thanks!
-- Mike
Re: refusing to untaint
Any chance you can try the very small patch in
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7015 and see if
it's related?
Still the same error after patching:
Feb 26 15:24:07.130 [20964] warn: util: refusing to untaint suspicious
path: ${exec_prefix}/lib
Huh? Variable length lookbehind?
I have a problem with a rule on a newly installed relay on which --lint throws a warning on an old local rule, squawking about Variable length lookbehind not implemented. I simplified the rule trying to discover the problem and it seems to be with the /i modifier: This rule does _not_ provoke the warning: /(?!Best )\bRegards,/ while this does, /(?!Best )\bRegards,/i warn: config: invalid regexp for rule MY_CLOSE: /(?!Best )\bRegards,/i: Variable length lookbehind not implemented in regex m/(?i)(?!Best )\bRegards,/ This is with perl 5.18.1 (openSUSE 13.1) On other boxes - with perl 5.10.0 and perl 5.16.2 - there is no problem and I fail to see that there is any variable length in either regex. Writing the rule like so with an apparently useless /i modifier allows the regex to pass the lint check: /(?![Bb][Ee][Ss][Tt] )\b[Rr][Ee][Gg][Aa][Rr][Dd][Ss],/i Can somebody tell me what the problem might be? Thanks! -- Mike G.
Re: Huh? Variable length lookbehind?
The 'st' is apparently equivalent to some ligature or some other UTF-8 character, so you end up with an alternation of two different lengths, which can't be used for look-behinds. Use a character set modifier /a to restrict the matching to ASCII rules. Search for Character set modifiers in the perlre man page. So something like: /(?!Best )\bRegards,/aai should do with perl = 5.14 . Better yet, avoid lookbehinds. Mark Many thanks Marc - both suggestions solve my problem. -- Mike
Re: X-Relay-Countries
Hmm I would do something like this (untested):
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
I've had to use, IIRC.
X-Relay-Countries =~ /\b(?!US|XX)([A-Z]{2})\b/
Question about TRACKER_ID
Hello folks.
In 20_body_tests.cf (SA 3.3.2) there is this rule:
body TRACKER_ID /^[a-z0-9]{6,24}[-_a-z0-9]{12,36}[a-z0-9{6,24}\s*\z/is
What is the \z in the regex?
This rule matches . Is that as
intended?
Thanks!
-- Mike
Re: Question about TRACKER_ID
Martin Gregorie wrote:
On Fri, 2013-02-08 at 13:26 -0600, Mike Grau wrote:
Hello folks.
In 20_body_tests.cf (SA 3.3.2) there is this rule:
body TRACKER_ID /^[a-z0-9]{6,24}[-_a-z0-9]{12,36}[a-z0-9{6,24}\s*\z/is
What is the \z in the regex?
According to the O'Reilly Camel Book, Programming Perl, \z matches the
last character in a string but offers no additional help. Many
Thanks Martin,
But, is that not \Z (upper case)?
Re: KB_FAKED_THE_BAT
# grep Date: HEADERS | od -a 000 D a t e : sp ht T h u , sp 3 sp M a 020 y sp 2 0 1 2 sp 1 6 : 5 3 : 5 9 sp 040 + 0 7 0 0 nl 046vi H* This has been Russian language spam (charset koi8-r) with various flavors of X-Mailer: The Bat! What version of SpamAssassin are you running? Here's a note from that rule's definition (rulesrc/sandbox/kb/20_header.cf): # NOTE Depends on some header rule code fixes for 3.3.x to remove # the leading space that was showing up in header rules. For # 3.2.x releases the pattern must be changed to /^ \t/. Karsten: Maybe change it to /^ ?\t/ as a workaround? (Yes, I know we've stopped supporting sa3.2.x) In 3.3.2 /var/lib/spamassassin/3.003002/updates_spamassassin_org # grep __KB_DATE_CONTAINS_TAB 72_active.cf header __KB_DATE_CONTAINS_TAB Date:raw =~ /^\t
KB_FAKED_THE_BAT
Hello all, Just an FYI ... The meta rule in 72_active.cf KB_FAKED_THE_BAT is getting circumvented here because the meta rule component header __KB_DATE_CONTAINS_TAB Date:raw =~ /^\t is being evaded by spam that now has a space character before the tab: # grep Date: HEADERS | od -a 000 D a t e : sp ht T h u , sp 3 sp M a 020 y sp 2 0 1 2 sp 1 6 : 5 3 : 5 9 sp 040 + 0 7 0 0 nl 046vi H* This has been Russian language spam (charset koi8-r) with various flavors of X-Mailer: The Bat! -- Mike G.
Re: RP_MATCHES_RCVD
On 07/28/2011 09:28 AM the voices made RW write: There seems to be a consensus that SPF and DKIM passes aren't worth significant scores. So how is it that RP_MATCHES_RCVD, scores -1.2 when it just a circumstantial version of what SPF does explicitly. For me it's hitting more spam that ham, and what's worse, it's mostly hitting low-scoring freemail spam. Is it just me that's seeing this, or is there maybe some kind of bias the test corpora? +1 RP_MATCHES_RCVD hits tons of (snowshoe?) spam here. Different senders different IPs, but often the same /16 or /24 networks. I had some local meta rules that used T_RP_MATCHES_RCVD, but evidently the name was changed to RP_MATCHES_RCVD and the spam started flying in.
FPs on FH_FAKE_RCVD_LINE_B
Hello,
I'm getting a lot of FPs from FH_FAKE_RCVD_LINE_B RCVD line looks faked
(B) since the default score for this rule is a whopping 4.000.
It's matching on this header:
Received: from 68.103.178.110 by webmail.east.cox.net; Mon, 28 Jun 2010
18:02:23 -0400
This rule matches the ISP Cox Communication residential customers using
their webmail service. For now I've made a rule negating
FH_FAKE_RCVD_LINE_B RCVD for Cox, but will someone educate me as to what
it is that makes this header look faked?
For reference, here's the (probably wrapped) rule:
Received =~
/from\s*\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\s*by\s*[a-z0-9.]{4,24}\.[a-z0-9.]{4,36}\.(?:com|net|org|biz);\s*[SMTWF].{2},\s*\d{1,2}\s*[JFMASOND].{2,5}\s*\d{4}\s*\d{2}:\d{2}:\d{2}\s*[-+]\d{4}/i
Thanks!
-- Mike
Re: FPs on FH_FAKE_RCVD_LINE_B
I believe the issue is that there are no brackets around the IP. The line should look like this: Received: from [68.103.178.110] by webmail.east.cox.net; Mon, 28 Jun 2010 18:02:23 -0400 Ah, right! Thanks! ( Drat, sorry about the reply to poster rather than list. )
Re: [sa] Re: Yahoo/URL spam
On 3/23/2010 2:49 PM the voices made Charles Gregory write:
On Tue, 23 Mar 2010, Alex wrote:
This is what I have:
/^[^a-z]{0,10}(http:\/\/|www\.)(\w+\.)+(com|net|org|biz|cn|ru)\/?[^
]{0,20}[a-z]{0,10}$/msi
My bad. I got an option wrong. Please remove the 'm' above.
I always get it backwards. According to 'man perlre' (the definitive
resource for SA regexes!) the 'm' makes '^' match every newline!
We want it to only match the beginning of the body.
So just remove it, and, as noted by others, add the '^' that was
missing... like so
... ]{0,20}[^a-z]{0,10}$/si
Hello,
You might want to change (\w+\.)+ to ([\w-]+\.)+ to account for
domains like polster-jj.de
-- MG
Re: newbie: configure SA to reject spam
tonjg wrote: On 01/13/2010 07:22 PM, tonjg wrote: thanks for your response Ned. your last line describes exactly what I want to do - reject mail, do it at the smtp stage in sendmail - but I don't know how to achieve this. Call spamassassin from within a milter. I use Mimedefang, but there are others.
Re: Rule to catch PO#
On 12/04/2008 01:49 Ray Jette wrote:
A lot of these rules look good but not appear to work for what I am
trying to do. Sorry about all the trouble. I'm not realy that good at
regular expressions but I am learning. Here are some real examples from
my mail server:
* PO1786
* PO 42111
* PO# 314980
* PO#36605
* PO 484579-0
* PO:458121
* PO: 6718972-1
* PO's #47509
* PO#v156-2008-003
* PO-121556
* PO's 47509
Some of these are million's of dollers worth of orders. I can't loose
these. I am trying to create a negative scoring rule. Thanks for any
help you can provide. Please let me know if you need any more information.
Ray Jette
This is pretty general:
/\bPO[#' sv:-]{0,7}[\d-]+/i
Maybe it would hit occasionally on spam, but so what? You can't afford
to loose millions of dollars of orders; you can afford to lower the
score on what might prove to be spam once in a great while.
Re: Rulesemporium
If your IP is blocked, for whatever reason, perhaps a proxy would help you until your IP is unblocked. http://translate.google.com/translate?u=http%3A%2F%2Fwww.rulesemporium.com%2Flangpair=fr%7Cen I bet the 'donate' link would help :-) Hmm, I doubt it, seeing that SARE has received 3 donations in 2007, $90 all total (yet 31k unique ips pull rules from the site every week.. ugh). Anyone want to sell us a VPS on a DDoS proof network for $90? ;) Ka-ching! Ka-ching ka-ching! Hey, it worked here; I'm in. A pay-per-view site, eh? ;) Three donations ... that's pathetic. -- Mike
Re: Rulesemporium
sarcasm A little misinformation tossed to spammers isn't bad here. I hear there's a mirror in Afghanistan too. And by all means.. when you browse the site.. click the stop button in your browser between it's loading each image on each page, then click the start button again. It's tricky, but if you do it just right, you can browse the whole site before the IDS blocks you. /sarcasm The rulesemporium site is great, and much thanks goes to the ninjas who operate it and write the rules, forcing spammers to read harry potter books. Ken Yes, the rulesemporium site _is_ great. As are the rules themselves. That's why I'd like to use my browser and read just one page. Right now all I get (and this is my first attempt to browse the site since yesterday) is Waiting for www.rulesemporium.com I'm not talking about rules_du_jour or sa-update or seeing how fast I can manually click stop or cycle through pages with my browser. I just want to go to the one page I have bookmarked. Isn't that the point of having a website? Allowing people to view your content? I'd say the DDOS is still very effective one way or another. My sympathies to the rulesemporium folks. I wish I could help, but I'm just some slob who wants to view their website. Still waiting ... Mike
Re: Rulesemporium
If your IP is blocked, for whatever reason, perhaps a proxy would help you until your IP is unblocked. http://translate.google.com/translate?u=http%3A%2F%2Fwww.rulesemporium.com%2Flangpair=fr%7Cen I bet the 'donate' link would help :-) Ken Okay, done. We'll see if it helps. Mike
Re: Rulesemporium
Ok, so the word is that the telia link is saturated with traffic from the ddos yet.. I'd like some traceroutes to www.rulesemporium.com for anyone that is having problems. # traceroute www.rulesemporium.com traceroute to www.rulesemporium.com (209.200.135.151), 30 hops max, 40 byte packets 1 a004001.kcc.state.ks.us (192.168.4.1) 0.437 ms 0.099 ms 0.106 ms 2 165.201.4.162 0.763 ms 0.813 ms 0.746 ms 3 165.201.85.201 0.870 ms 0.677 ms 0.780 ms 4 165.201.60.3 1.032 ms 1.149 ms 0.929 ms 5 165.201.254.25 2.071 ms 1.563 ms 2.457 ms 6 165.201.254.10 2.441 ms 2.306 ms 2.260 ms 7 wsip-68-106-191-61.ks.ok.cox.net (68.106.191.61) 3.365 ms 3.314 ms 3.614 ms 8 ip70-183-65-49.ks.ks.cox.net (70.183.65.49) 11.048 ms 10.998 ms 12.317 ms 9 wichdsrj01-ge704.0.rd.ks.cox.net (70.183.71.25) 12.517 ms 15.284 ms 14.833 ms 10 mtc3dsrj02-ge710.0.rd.ok.cox.net (68.1.0.109) 23.132 ms 22.519 ms 23.396 ms 11 ae-2-52.bbr2.Chicago1.Level3.net (4.68.101.33) 57.604 ms ae-2-56.bbr2.Chicago1.Level3.net (4.68.101.161) 55.696 ms ae-2-52.bbr2.Chicago1.Level3.net (4.68.101.33) 53.787 ms 12 as-1-0.mp1.Miami1.Level3.net (64.159.0.1) 85.394 ms 85.578 ms 85.523 ms 13 so-6-0-0.gar1.Miami1.Level3.net (4.68.112.42) 85.479 ms 84.752 ms so-7-0-0.gar1.Miami1.Level3.net (4.68.112.46) 79.211 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
Re: Rulesemporium
On 07/09/2007 04:01 PM the voices made Joe Zitnik write: I can't get here: http://www.rulesemporium.com/rules Is rulesemporium having issues again? I can rarely get there (via a browser). So rarely the site is almost useless.
Re: Catching and stopping 419 spam
I'd like to see other people's states as well. I'm using it to block and my 419 spam is almost completely gone. But I'm wondering what other people's experiences are. FPs here on emails that have been forwarded and have email addresses in the message body. These have all been from cox.net which is listed in FreeMail.pm. cox.net does not offer free email; you have to be a cox customer. -- Mike G
Re: SARE ADULT easily worked around?
Hum. Most of us seem to have been listwashed off the porn lists, so it is kinda hard to adjust the rules! We used to be plagued by pornographic spam, usually obfuscated. Unexpectedly, to me anyway, greylisting virtually eliminated it. -- Mike G
Spam or something else?
Hello. (sendmail-mimdefang-spamassassin) Since this past weekend I been seeing in the mail log: possible SMTP attack: command=HELO/EHLO, count=3 These used to be very rare, but since Saturday there are a great many (for us). For the past few hours, I've been firewalling the offending IPs with iptables as they occur, but so far the supply of IP addresses seems endless. The IPs do seem weighted towards a couple of ISPs in Israel though: No. of ip addresses: KOREA, REPUBLIC OF: 7 RUSSIAN FEDERATION: 12 GERMANY: 17 CHINA: 20 UNITED STATES: 21 CZECH REPUBLIC: 47 ISRAEL: 93 I don't think any of these messages have actually made it as far as getting to SA, but can someone enlighten me as to what this is? -- Mike G
3.1.6, local scores, and sa-update
Since upgrading to SpamAssassin 3.1.6, running sa-update yields # sa-update config: warning: score set for non-existent rule BAYES_50 config: warning: score set for non-existent rule BAYES_05 config: warning: score set for non-existent rule BAYES_00 config: warning: score set for non-existent rule BAYES_40 config: warning: score set for non-existent rule BAYES_60 config: warning: score set for non-existent rule BAYES_95 config: warning: score set for non-existent rule BAYES_99 config: warning: score set for non-existent rule BAYES_20 config: warning: score set for non-existent rule BAYES_80 . . . error: lint check of current site config failed, cannot continue. I assume this is because sa-update now include local site config in sa-update lint checks. Previously I've set some custom scores for stock rules in /etc/mail/spamassassin/whatever.cf without changing the rule definitions or descriptions. Can I not do this and need to define the body BAYES_99 and describe BAYES_99 in wahtever.cf also, or is this a bug in sa-update? Thanks! -- Mike
Rule advice please
Hello.
Following discussions on this list about obfuscating words to avoid spam
detection, and not being a ninja, I'd like some feedback about the
possible efficacy or pitfalls on rules like the following.
As noted in other discussions, words with scrambled letters between the
first and last letter can be caught by checking the permutations of the
letters:
/\ba(?:ess|ess|ses|ses)s\b/i - finds permutations of asses
However, this quickly gets unweildy when building a regex checking all
the permutations of more than 5 letters. Couldn't one use a regex that
simply looks for the letters used and uses a negative look-ahead
assertation to eliminate other words of the same length by first
running the expresssion through a dictionary of words and phrases. For
example, a rule for the word exploited after run through a dictionary
of 617709 words and phrases:
/\b(?!exploited|elliptoid|epitoxoid)e[xploite]{7}d\b/i
or perhaps an additional rule for added letters expploited, etc.
/\b(?!epileptoid)e[xploite]{8}d\b/i
/\be[xploite]{9}d\b/i
or combined:
/\b(?!exploited|elliptoid|epitoxoid|epileptoid)e[xploite]{7,9}d\b/i
Usually the obfusticated word still resembles the word with the meaning
the spammer wants to convey. I doubt the spammer wants to use the word
elliptoid, and anyway, the idea is to use these rules as non-scoring
rules for use with meta rules.
(OBFU_EXPLOIT + RULE1 + RULE2 + RULE3) 1 etc.
or whatever. Thoughts? Other samples:
subject =~ /\b(?!cartoon|croatan|carroon)c[arto]{5}n\b/i
subject =~ /\b(?!downloadable)d[ownladb]{10}e\b/i
subject =~ /\b(?!dripping)d[ripn]{6}g\b/i
subject =~ /\b(?!ejaculating|enunciating)e[jacultin]{9}g\b/i
Of course, you could add 1 and 0 in the character set if the word
contained a o or l, and the like.
-- Mike
Re: Rule advice please
SNIP
subject =~ /\b(?!cartoon|croatan|carroon)c[arto]{5}n\b/i
subject =~ /\b(?!downloadable)d[ownladb]{10}e\b/i
subject =~ /\b(?!dripping)d[ripn]{6}g\b/i
subject =~ /\b(?!ejaculating|enunciating)e[jacultin]{9}g\b/i
You can't use rules like this. The pattern can matches your first
example. Similarly drrg matches the third line.
Yes, but, using meta rules for scoring and assuming we're not talking
about binary data, if I don't want
(HOT DRIPPING WOMEN)
should I want
(HOT DRRG WOMEN)
?
I wouldn't score this high enough to reject the message by itself, but
when combined with all the other SA rules might it not be a indicator
worthy of some scoring?
-- Mike
