Re: Increase in scan time from 3.3 to 3.3.1
On Fri, 11 Jun 2010 17:32:05 -0400 Chris Conn cc...@abacom.com wrote: In a followup to http://www.gossamer-threads.com/lists/spamassassin/users/151470; Is it possible to set the priority on RBL rules to run after rules, or not at all if shortcircuited? RBL test are done in parallel, and they are initiated early so SA can get on with local tests during the DNS lookup. I don't know if what you're asking for is possible, but it doesn't sound like a good idea.
Re: Increase in scan time from 3.3 to 3.3.1
In a followup to http://www.gossamer-threads.com/lists/spamassassin/users/151470; Is it possible to set the priority on RBL rules to run after rules, or not at all if shortcircuited? I tried: priority RCVD_IN_BL_SPAMCOP_NET -300 priority RCVD_IN_XBL -300 priority RCVD_IN_PSBL -300 priority RCVD_IN_UCEPROT1 -300 priority RCVD_IN_BRBL_LASTEXT -300 priority MYCUSTOM -900 yet running it through SA; pts rule name description -- -- 3.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see http://www.spamcop.net/bl.shtml?174.121.191.18] 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [174.121.191.18 listed in psbl.surriel.com] 1.5 RCVD_IN_UCEPROT1 RBL: Appears in uceprotect-1 [174.121.191.18 listed in dnsbl-1.uceprotect.net] 1.6 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [174.121.191.18 listed in bb.barracudacentral.org] 8.0 RCVD_IN_XBLRBL: Received via a relay in Spamhaus XBL [174.121.191.18 listed in zen.spamhaus.org] 0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule [score: 100] 100 MYCUSTOMevaluation of message via MYCUSTOM I don't want to run tons of RBLS on an email that I can already identify and shortcircuit... What am I missing? the shortcircuit plugin is obviously loaded since I am using it on other rulesets. Thanks, Chris
Re: Increase in scan time from 3.3 to 3.3.1
Alex wrote: What would be involved with making the PSBL DNSBL work with v3.2.5? Alex, I'm pretty sure that you are already using PSBL through my khop-bl channel, which adds PSBL, BRBL, Spam-eating Monkey (SEMBLACK), HostKarma/JunkEmailFilter, and, more recently, MSPIKE (as per a request from João) to pre-3.3.0 spamassassin versions. It supports 3.3.0+ and avoids re-defining rules that were incorporated. khop-bl directions: http://khopesh.com/Anti-spam#sa-update_channels
Re: Increase in scan time from 3.3 to 3.3.1
Hi, What would be involved with making the PSBL DNSBL work with v3.2.5? Alex, I'm pretty sure that you are already using PSBL through my khop-bl channel, which adds PSBL, BRBL, Spam-eating Monkey (SEMBLACK), HostKarma/JunkEmailFilter, and, more recently, MSPIKE (as per a request from João) to pre-3.3.0 spamassassin versions. Yes, indeed. Thanks very much for the follow-up. I've disabled it now in my local config. Thanks again, Alex
Re: Increase in scan time from 3.3 to 3.3.1
Alex wrote:
Will the new RBLs in v3.3.1 ever be available/compatible with v3.2.5?
What would be involved with making the PSBL DNSBL work with v3.2.5?
You can certainly add additional RBLs to 3.2.5. For example:
# PSBL easy-on, easy-off blacklist: http://psbl.surriel.com
header RCVD_IN_PSBL eval:check_rbl('psbl', 'psbl.surriel.com.')
describe RCVD_IN_PSBL Received via a relay in PSBL
tflags RCVD_IN_PSBL net
However, you can't use the new DBL list from Spamhaus, as that
*requires* SA 3.3.1:
http://www.spamhaus.org/dbl/
http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20DBL#287
Re: Increase in scan time from 3.3 to 3.3.1
Hi, - Alex mysqlstud...@gmail.com wrote: Hi, Anyway, it'll soon be deprecated in favor of 20_aux_tlds.cf, which is part of the stock rule-set since 3.3.1. Bug 6361. As mentioned in the release announcement. Is the 20_aux_tlds.cf stable and available for use to replace it now? Will the new RBLs in v3.3.1 ever be available/compatible with v3.2.5? What would be involved with making the PSBL DNSBL work with v3.2.5? Ours is not included yet, but feel free to use it if it fits your environment. Implementation details here: http://mailspike.org/ Last statistics from SA rule QA: http://ruleqa.spamassassin.org/20100320-r925566-n/%2FRCVD (rule name T_RCVD_IN_ANBREP_BL) Thanks, Alex -- João Gouveia
Re: Increase in scan time from 3.3 to 3.3.1
On 3/24/10 2:23 PM, Rick Macdougall wrote: Hi, Any one have any idea what might cause an increase of scan times when going from 3.3 to 3.3.1. I've upgraded one server and the average scan time is now 4.3 seconds. The 3 other servers still running 3.3 average 1.38 several more RBL's, check your dns performance? -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __
Re: Increase in scan time from 3.3 to 3.3.1
Rick Macdougall wrote: Any one have any idea what might cause an increase of scan times when going from 3.3 to 3.3.1. I've upgraded one server and the average scan time is now 4.3 seconds. The 3 other servers still running 3.3 average 1.38 All running Centos on exactly the same hardware. (I thought I sent a message on the same subject; looks like I forgot to send it from the right account.) I've seen something similar, however I'm seeing the difference from 3.2.5 to 3.3.x (both 3.3.0 and 3.3.1 show the same slowdown). Average scan times have jumped from just under a second to just under four seconds on the live mail stream, and about the same on a dev machine with a small set of test messages. Different hardware and OS release doesn't make much more than ~1% difference in scan times. SA is installed via script, an initial configuration is set via script, and a set of symlinks are used to manage which version is live. Another script updates all of the rules channels we use (and if anything, that should save a little CPU time because I dropped the SARE 90_2tld channel for 3.3.x). Supporting Perl modules are all packaged (either Debian stock, or local packages). -kgd
Re: Increase in scan time from 3.3 to 3.3.1
On 24/03/2010 2:40 PM, Michael Scheidell wrote: On 3/24/10 2:23 PM, Rick Macdougall wrote: Hi, Any one have any idea what might cause an increase of scan times when going from 3.3 to 3.3.1. I've upgraded one server and the average scan time is now 4.3 seconds. The 3 other servers still running 3.3 average 1.38 several more RBL's, check your dns performance? Hi, We're running DJB's dnscache and I set the score to 0 for the 3 new spamhaus rules. score URIBL_SBL 0 score URIBL_DBL_SPAM0 score URIBL_DBL_ERROR 0 What other new one's were added as I don't see much listed in the Changes file. Regards, Rick
Re: Increase in scan time from 3.3 to 3.3.1
On 24/03/2010 2:40 PM, Michael Scheidell wrote: On 3/24/10 2:23 PM, Rick Macdougall wrote: Hi, Any one have any idea what might cause an increase of scan times when going from 3.3 to 3.3.1. I've upgraded one server and the average scan time is now 4.3 seconds. The 3 other servers still running 3.3 average 1.38 several more RBL's, check your dns performance? Yup, seems to be DNS related I guess. One message that took 5.6 seconds to scan now scans in under 0.5 seconds. Rick
Re: Increase in scan time from 3.3 to 3.3.1
Michael Scheidell wrote: several more RBL's, check your dns performance? Looks like the new PSBL DNSBL is a bit slow. I wonder if the new load from SA 3.3 is the cause? g A quick walk through the SA log shows it isn't helping much here, so I've disabled it locally. I checked out their rsync file, and it's a 27M one-per-line list of IP addresses. It could probably be trivially adjusted to load into rbldnsd. -kgd
Re: Increase in scan time from 3.3 to 3.3.1
On 24/03/2010 4:09 PM, Kris Deugau wrote: Michael Scheidell wrote: several more RBL's, check your dns performance? Looks like the new PSBL DNSBL is a bit slow. I wonder if the new load from SA 3.3 is the cause? g A quick walk through the SA log shows it isn't helping much here, so I've disabled it locally. I checked out their rsync file, and it's a 27M one-per-line list of IP addresses. It could probably be trivially adjusted to load into rbldnsd. -kgd That seems to be the culprit. Every thing looks the same as the older 3.3 servers now. Thanks for the investigation. Regards, Rick
Re: Increase in scan time from 3.3 to 3.3.1
On Wed, 2010-03-24 at 14:44 -0400, Kris Deugau wrote:
[...] that should save a little CPU time because I dropped the SARE
90_2tld channel for 3.3.x
The CPU time saved by dropping that file is negligible, hardly
measurable.
Anyway, it'll soon be deprecated in favor of 20_aux_tlds.cf, which is
part of the stock rule-set since 3.3.1. Bug 6361. As mentioned in the
release announcement.
guenther
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Increase in scan time from 3.3 to 3.3.1
Hi, Anyway, it'll soon be deprecated in favor of 20_aux_tlds.cf, which is part of the stock rule-set since 3.3.1. Bug 6361. As mentioned in the release announcement. Is the 20_aux_tlds.cf stable and available for use to replace it now? Will the new RBLs in v3.3.1 ever be available/compatible with v3.2.5? What would be involved with making the PSBL DNSBL work with v3.2.5? Thanks, Alex
