Re: NOTE: Warning to Abusers of Update Servers
On Thu, 23 Nov 2017, Kevin A. McGrail wrote: On 11/23/2017 6:31 PM, Dave Warren wrote: Would more mirrors be useful? I've got a ton of spare upstream bandwidth and am in the progress of setting up a few mirrors for other projects. Sure. Always helps to spread the load more. All you have to do is setup sa-update.XYZ.tld and add an rsync command every 10 minutes. Then we add you to the mirrors list weighted by how much traffic you can bear. As a happy SA user (since more than 15 years) and animated by Dave's offering I have set up also another mirror: http://sa-update.fossies.org If meaningful it may be added initially with a weight=1 (may be increased later). If not that mirror will be simply removed, no problem. By the way, a little bit irritated I was about the large number of mirrored rules tarballs (currently 4413 ones, the oldest from Februar 2007) and the inhomogeneous and at least to me somewhat unexpected file permissions (partly "write" flag for owner removed, partly "write" flag also for group set, partly "execute" flag set for owner or even owner, group and other). Regards Jens
Re: Why doesn't HK_RANDOM_FROM trigger on this email address?
On Mon, 20 Nov 2017, John Hardin wrote: On Mon, 20 Nov 2017, Markus Clardy wrote: Why not just have it be a meta test that doesn't trigger if it contains "sch"? I realize that cuts out things like tjmkln...@fakeemail.com, but it would catch tsjmhw...@fakeemail.com, so maybe a bit better in both catch rate and false positives? Better: /sch[a-z]/ so that it would catch tjmkln...@fakeemail.com Ok, if the "s" was only omitted to avoid FPs for addresses containg the string "sch" (German typical) that seems the better solution compared to my suggestion. Jens
Re: Why doesn't HK_RANDOM_FROM trigger on this email address?
On Sun, 19 Nov 2017, Bill Cole wrote:
On 19 Nov 2017, at 17:11 (-0500), Mark London wrote:
Also, 5 consonants in a row, is unlikely.
Well, F. W. Nietzsche never had kids, but I don't think the surname is
extinct. I'm aware of multiple people with the surname Pietschmann. There is
also a common practice of using a first initial and surname as a username and
many Germanic surnames starting with sch[mlr], so I expect that 5 consonants
in an email address local-part where 'sch' are the middle 3 characters are
quite common.
Although not used currently I had formerly such an assigned accountname
(jschleus). Since I think the avoiding of FPs should take priority over
that of FNs I "vote" for the omitting "s".
Maybe it would be a "compromise" to add another regex with at least the
"s" included but 6 required consonants like
[bcdfgjklmnpqrstvwxz]{6}
Jens
Re: has SA 3.3.1 been recalled?
On Fri, 26 Mar 2010, Daniel Lemke wrote: Mathias Homann wrote: I'm trying to get the 3.3.1 source frm the website, but so far all mirrors replied file not found... what's up with that? Hm for me too... But you can still get it from CPAN: http://search.cpan.org/~jmason/Mail-SpamAssassin-3.3.1/ Or - not an official mirror but with browsing features - via http://www.sfr-fresh.com/unix/misc/Mail-SpamAssassin-3.3.1.tar.gz/ Regards Jens
Re: ABORT Re: PROPOSED: Apache SpamAssassin 3.3.0-rc1.proposed1
Hi Warren, On Sun, 20 Dec 2009, Warren Togami wrote: On 12/18/2009 08:57 PM, Warren Togami wrote: This will be released if we go three days without an objection as per build/README procedure. At that point these archives will be renamed to rc1 and the announcements will go out. Please suggest improvements to this announcement text as well. Hey users list, now would be a very good time to begin testing 3.3.0 if you haven't already. At this point it has been tested in production on many production servers (including my own production server since March 2009), but it is possible we missed a corner case of some non-standard configuration that you folks rely upon. We could use your feedback, even if it is only It works! Now is last chance to complain if you find a problem. All of the Priority P1 blocker bugs targeted for 3.3.0 are now closed. I suspect there might be a few minor things we might want to polish before 3.3.0 final, but otherwise this is VERY CLOSE to what 3.3.0 will be. Warren Togami wtog...@redhat.com I am aborting the release of rc1.proposed1. There is some problem causing spamc/spamd to fail completely. I am attempting to figure this out a possible cause. Downgrading to beta1 seems to fix my server. Good news: The new spamc.c (27863 Bytes) from trunk (rev. 892869) solved that problem (at least for me under openSUSE 11.1). Now mails are processed again using spamc/spamd. Jens
3.3.0-beta1: What is wrong with my usage of SYSCONFDIR
Hi, to install Mail-SpamAssassin SVN versions (and now Mail-SpamAssassin 3.3.0-beta1) I use the command perl Makefile.PL PREFIX=~/sausr_svn SYSCONFDIR=~/saetc_svn but I detect always the following output lines after that command is claiming about some missing only optional modules: warning: some functionality may not be available, please read the above report before continuing! Checking if your kit is complete... Looks good 'SYSCONFDIR' is not a known MakeMaker parameter name. Writing Makefile for Mail::SpamAssassin Makefile written by ExtUtils::MakeMaker 6.42 But after the successive make and make install all seems to work fine (using openSUSE 11.2 with perl v5.10.0). In the generated Makefile I found according lines like # MakeMaker ARGV: (q[PREFIX=~/sausr_svn], q[SYSCONFDIR=~/saetc_svn]) PREFIX = /home/my_account/sausr_svn cd $(DISTVNAME) $(ABSPERLRUN) Makefile.PL PREFIX=~/sausr_svn SYSCONFDIR=~/saetc_svn $(PERLRUN) Makefile.PL PREFIX=~/sausr_svn SYSCONFDIR=~/saetc_svn $(NOECHO) $(PERLRUNINST) \ Makefile.PL DIR= \ MAKEFILE=$(MAKE_APERL_FILE) LINKTYPE=static \ MAKEAPERL=1 NORECURS=1 CCCDLFLAGS= \ PREFIX=~/sausr_svn \ SYSCONFDIR=~/saetc_svn respectively # MakeMaker ARGV: (q[PREFIX=~/sausr_svn], q[SYSCONFDIR=~/saetc_svn]) SYSCONFDIR = /home/my_account/saetc_svn cd $(DISTVNAME) $(ABSPERLRUN) Makefile.PL PREFIX=~/sausr_svn SYSCONFDIR=~/saetc_svn $(NOECHO) $(PERLRUNINST) \ Makefile.PL DIR= \ MAKEFILE=$(MAKE_APERL_FILE) LINKTYPE=static \ MAKEAPERL=1 NORECURS=1 CCCDLFLAGS= \ PREFIX=~/sausr_svn \ SYSCONFDIR=~/saetc_svn So the above error line 'SYSCONFDIR' is not a known MakeMaker parameter name. is only a minor flaw that can be safely ignored? Greetings Jens
Re: How to search the whole body
Hi Patrick,
relaxing from my hassle with the new machine :)
I'd like to set up a rule catching multiple dollar-signs in a message, I
don't see any other way to catch those heavily encrypted pill-emails like
this:
C A aN A DvAN P c cH A RM A oCY
VzA zG _RA - $1.48
C 9a A L u S - $2.24
S0 O M A - $0.65
My idea was to ring the bell, when the dollar-sign appears more than four
times in a single email. As a bayes_00 rule marks it with a -2.5 score I am
clueless what else to do about them. /\${3,}/ oviously won't work :(
I am not a real expert in SA rules but what about
body RULE_NAME /(?:\$.{0,100}){3,}/
Untested! The number of 0 respectively max. 100 characters between the
dollar-signs is a little bit arbitray. Also it may be meaningful to
restrict the type of the arbitrary characters. For more than four
matches within the body (as required in your text) replace 3 by 5.
Greetings
Jens
--
T-Systems Solutions for Research GmbH
Solutions Innovations Commercial ICT, Internet- Intranet-Appl.
Dr. Jens Schleusener
Bunsenstr. 10, D-37073 Göttingen
+49 551 709-2493 (Tel.)
+49 551 709-2169 (Fax)
E-Mail: [EMAIL PROTECTED]
Internet: http://www.t-systems.com
Re: Botnet-0.7 not working
On Fri, 5 Jan 2007, John Rudd wrote: Jens Schleusener wrote: But undefining the variable botnet_pass_trusted I got Forgot to ask this last time: what do you mean undefining? Did you set it to none, like the documentation mentions? or anything else along those lines? Ok, sorry for my incomplete mail (it was a bit late yesterday). The sentence undefining the variable botnet_pass_trusted seems a little bit vague. I tested different values also none but I had the impression it doesn't matter which value I set as long as I avoid one of the parsed values (any, public or private). So even using botnet_pass_trusted or (using quotation marks) botnet_pass_trusted private instead of botnet_pass_trusted private changed the behaviour on my system and let Botnet work. As by Dimitri the Botnet not working-problem on my system also appeared after the upgrade 0.6 - 0.7. The behaviour may be correct (probably as designed) but I have overseen the new functionality. Finally (reffering to my original mail) the term 172.x.x.x was imprecise and mistakable. Concretely the concerning address is 172.21.151.21, an address out of the private address range 172.16.0.0 - 172.31.255.255 (172.16/12 prefix). Greetings Jens P.S.: I will sent more detailed debug information in a personal mail to John Rudd. -- Dr. Jens SchleusenerT-Systems Solutions for Research GmbH Tel: +49 551 709-2493 Bunsenstr.10 Fax: +49 551 709-2169 D-37073 Goettingen [EMAIL PROTECTED] http://www.t-systems.com/
Re: Botnet-0.7 not working
On Thu, 4 Jan 2007, John Rudd wrote: Dimitri Yioulos wrote: First, I wish all a very happy and healthy New Year. I hope this is the proper place to ask this: several days ago, I upgraded to Botnet-0.7 from 0.6; the latter had apparently been working fine with the installed SA 3.1.7. I installed as per instruction (no heavy lifting there). Now, no Botnet rules are ever hit, even though I suspect that some particular spam has been sent via a bot. If I reinstall 0.6, I get rule hits. What have I not done/done wrong? Thanks. Dimitri Do you get much output if you take one of the messages and do this (assuming you're on some form of unix): spamassassin -D $message_file | grep -i botnet I found a similar behaviour as described on a test server. Using spamassassin -D $message_file 21 | grep -i botnet I found that in my case probably the default Botnet.cf configuration line # If there are trusted relays, then look to see if there's a # public IP address; if so, then pass the message through. botnet_pass_trusted public is the causer since the test server receives the mails from a mail relay that uses a private 172.x.x.x address. Debug extract with the default configuration: dbg: Botnet: starting dbg: Botnet: found private trusted dbg: Botnet: skipping But undefining the variable botnet_pass_trusted I got dbg: Botnet: starting dbg: Botnet: get_relay good RDNS dbg: Botnet: IP is '189.156.64.193' dbg: Botnet: RDNS is 'dsl-189-156-64-193.prod-infinitum.com.mx' dbg: Botnet: HELO is '!189.156.64.193!' dbg: Botnet: sender [EMAIL PROTECTED] dbg: Botnet: hit (baddns,client,ipinhostname,clientwords) dbg: rules: ran eval rule BOTNET == got hit Greetings Jens -- Dr. Jens SchleusenerT-Systems Solutions for Research GmbH Tel: +49 551 709-2493 Bunsenstr.10 Fax: +49 551 709-2169 D-37073 Goettingen [EMAIL PROTECTED] http://www.t-systems.com/
