Re: high cpu load
Finally i found message caused high load. It looks like one message sent all the time from ticket system. Message size is ~4M. We scan messages with this size in amavis. Content of message is complex and has multiple items Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Type: application/pdf Results from debug, with % 1: dbg: rules: timing: Total time: 131.6748 s dbg: rules: [...] rulename ovl(s) max(s) #run %tot dbg: rules: [...] __FILL_THIS_FORM_LONG2 26.3811 26.3811 1 20.04% dbg: rules: [...] __FILL_THIS_FORM_SHORT2 26.3050 26.3050 1 19.98% dbg: rules: [...] __FILL_THIS_FORM_FRAUD_PHISH1 10.0878 10.0878 1 7.66% dbg: rules: [...] __FILL_THIS_FORM_LOAN1 7.2766 7.2766 1 5.53% dbg: rules: [...] __FILL_THIS_FORM_SHORT1 2.3360 2.3360 1 1.77% dbg: rules: [...] __FILL_THIS_FORM_LONG1 2.3051 2.3051 1 1.75% 1.8 FUZZY_XPILLBODY: Attempt to obfuscate words in spam 0.0 FUZZY_CPILLBODY: Attempt to obfuscate words in spam 0.5 FUZZY_VPILLBODY: Attempt to obfuscate words in spam 0.8 HTML_IMAGE_RATIO_02BODY: HTML has a low ratio of text to image area 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 LOTS_OF_MONEY Huge... sums of money Thanks all for the help! 2014-04-24 1:39 GMT+03:00 John Hardin jhar...@impsec.org: On Wed, 23 Apr 2014, Nick I wrote: Another interesting thing. Today when daily cron executed at 5 am load calmed to ~0. As it was before. Sa-update executed at that time. Amavisd has been reloaded at 7 am and load raised back again. Also i see that some messages checked 150329 ms, 158742 ms. But most messages checked ~400ms. I used @debug_recipient_maps and sa_debug but did not see any userful info. Can anyone suggest how to look inside tests_pri_0 ? The first thing you need to do is capture one of the messages that took a very long time to scan, so that it can be tested in a controlled environment. There are tools that will allow you to capture timing data for every rule, and if the message is a spam you could provide it to us for analysis. -- 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 --- Today: Max Planck's 156th birthday
Re: high cpu load
On Thu, 24 Apr 2014, Nick I wrote: Finally i found message caused high load. It looks like one message sent all the time from ticket system. Message size is ~4M. We scan messages with this size in amavis. Content of message is complex and has multiple items Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Type: application/pdf Results from debug, with % 1: dbg: rules: timing: Total time: 131.6748 s dbg: rules: [...] rulename ovl(s) max(s) #run %tot dbg: rules: [...] __FILL_THIS_FORM_LONG2 26.3811 26.3811 1 20.04% dbg: rules: [...] __FILL_THIS_FORM_SHORT2 26.3050 26.3050 1 19.98% dbg: rules: [...] __FILL_THIS_FORM_FRAUD_PHISH1 10.0878 10.0878 1 7.66% dbg: rules: [...] __FILL_THIS_FORM_LOAN1 7.2766 7.2766 1 5.53% dbg: rules: [...] __FILL_THIS_FORM_SHORT1 2.3360 2.3360 1 1.77% dbg: rules: [...] __FILL_THIS_FORM_LONG1 2.3051 2.3051 1 1.75% That's not too surprising if the content is 4MB. Would you be willing to share it with me so that I can try to find the problem with the FILLFORM rules? Alternatively, you might want to configure your system to not scan mails from the ticket system (which I assume is internal and trusted). -- 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 --- Yet another example of a Mexican doing a job Americans are unwilling to do. -- Reno Sepulveda, on UniVision reporters asking President Obama some pointed questions about the BATFE Fast and Furious scandal. --- 693 days since the first successful private support mission to ISS (SpaceX)
Re: high cpu load
On 04/24/2014 04:16 PM, John Hardin wrote: On Thu, 24 Apr 2014, Nick I wrote: Finally i found message caused high load. It looks like one message sent all the time from ticket system. Message size is ~4M. We scan messages with this size in amavis. Content of message is complex and has multiple items Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Type: application/pdf Results from debug, with % 1: dbg: rules: timing: Total time: 131.6748 s dbg: rules: [...] rulename ovl(s) max(s) #run %tot dbg: rules: [...] __FILL_THIS_FORM_LONG2 26.3811 26.3811 1 20.04% dbg: rules: [...] __FILL_THIS_FORM_SHORT2 26.3050 26.3050 1 19.98% dbg: rules: [...] __FILL_THIS_FORM_FRAUD_PHISH1 10.0878 10.0878 1 7.66% dbg: rules: [...] __FILL_THIS_FORM_LOAN1 7.2766 7.2766 1 5.53% dbg: rules: [...] __FILL_THIS_FORM_SHORT1 2.3360 2.3360 1 1.77% dbg: rules: [...] __FILL_THIS_FORM_LONG1 2.3051 2.3051 1 1.75% That's not too surprising if the content is 4MB. Would you be willing to share it with me so that I can try to find the problem with the FILLFORM rules? Alternatively, you might want to configure your system to not scan mails from the ticket system (which I assume is internal and trusted). Why does this smell like replace_tag noise? (I hate that stuff :)
Re: high cpu load
On Thu, 24 Apr 2014, Axb wrote: On 04/24/2014 04:16 PM, John Hardin wrote: On Thu, 24 Apr 2014, Nick I wrote: Finally i found message caused high load. It looks like one message sent all the time from ticket system. Message size is ~4M. We scan messages with this size in amavis. Content of message is complex and has multiple items Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Type: application/pdf Results from debug, with % 1: dbg: rules: timing: Total time: 131.6748 s dbg: rules: [...] rulename ovl(s) max(s) #run %tot dbg: rules: [...] __FILL_THIS_FORM_LONG2 26.3811 26.3811 1 20.04% dbg: rules: [...] __FILL_THIS_FORM_SHORT2 26.3050 26.3050 1 19.98% dbg: rules: [...] __FILL_THIS_FORM_FRAUD_PHISH1 10.0878 10.0878 1 7.66% dbg: rules: [...] __FILL_THIS_FORM_LOAN1 7.2766 7.2766 1 5.53% dbg: rules: [...] __FILL_THIS_FORM_SHORT1 2.3360 2.3360 1 1.77% dbg: rules: [...] __FILL_THIS_FORM_LONG1 2.3051 2.3051 1 1.75% That's not too surprising if the content is 4MB. Would you be willing to share it with me so that I can try to find the problem with the FILLFORM rules? Alternatively, you might want to configure your system to not scan mails from the ticket system (which I assume is internal and trusted). Why does this smell like replace_tag noise? (I hate that stuff :) The FILLFORM rules are complex and inherently repetitive - there's really no other way to detect a form. They've had some minor problems with boundedness in the past, but I thought I had fixed them. Apparently here's another bad case. -- 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 --- Yet another example of a Mexican doing a job Americans are unwilling to do. -- Reno Sepulveda, on UniVision reporters asking President Obama some pointed questions about the BATFE Fast and Furious scandal. --- 693 days since the first successful private support mission to ISS (SpaceX)
Re: high cpu load
On 04/24/2014 04:28 PM, John Hardin wrote: On Thu, 24 Apr 2014, Axb wrote: On 04/24/2014 04:16 PM, John Hardin wrote: On Thu, 24 Apr 2014, Nick I wrote: Finally i found message caused high load. It looks like one message sent all the time from ticket system. Message size is ~4M. We scan messages with this size in amavis. Content of message is complex and has multiple items Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Type: application/pdf Results from debug, with % 1: dbg: rules: timing: Total time: 131.6748 s dbg: rules: [...] rulename ovl(s) max(s) #run %tot dbg: rules: [...] __FILL_THIS_FORM_LONG2 26.3811 26.3811 1 20.04% dbg: rules: [...] __FILL_THIS_FORM_SHORT2 26.3050 26.3050 1 19.98% dbg: rules: [...] __FILL_THIS_FORM_FRAUD_PHISH1 10.0878 10.0878 1 7.66% dbg: rules: [...] __FILL_THIS_FORM_LOAN1 7.2766 7.2766 1 5.53% dbg: rules: [...] __FILL_THIS_FORM_SHORT1 2.3360 2.3360 1 1.77% dbg: rules: [...] __FILL_THIS_FORM_LONG1 2.3051 2.3051 1 1.75% That's not too surprising if the content is 4MB. Would you be willing to share it with me so that I can try to find the problem with the FILLFORM rules? Alternatively, you might want to configure your system to not scan mails from the ticket system (which I assume is internal and trusted). Why does this smell like replace_tag noise? (I hate that stuff :) The FILLFORM rules are complex and inherently repetitive - there's really no other way to detect a form. They've had some minor problems with boundedness in the past, but I thought I had fixed them. Apparently here's another bad case. seems like a LOT of work going on for the results :) score FILL_THIS_FORM1.456 0.001 1.456 0.001 I'd +1 to start from scratch with simpler conditions
Re: high cpu load
On Wed, 23 Apr 2014 02:43:25 +0200 Karsten Bräckelmann wrote: On Tue, 2014-04-22 at 22:31 +0300, Nick I wrote: Here is timing from amavis. tests_pri_0 is around 90% all the time : amavis[26002]: (26002-05) TIMING-SA total 759 ms - parse: 1.92 (0.3%), extract_message_metadata: 31 (4.1%), get_uri_detail_list: 6 I'm not entirely sure about that amavis log-line, but it most likely maps to the SA priorities rules are run at. The text after TIMING-SA looks to be SA's own _TIMING_ tag.
Re: high cpu load
Another interesting thing. Today when daily cron executed at 5 am load calmed to ~0. As it was before. Sa-update executed at that time. Amavisd has been reloaded at 7 am and load raised back again. Also i see that some messages checked 150329 ms, 158742 ms. But most messages checked ~400ms. I used @debug_recipient_maps and sa_debug but did not see any userful info. Can anyone suggest how to look inside tests_pri_0 ? 2014-04-23 14:49 GMT+03:00 RW rwmailli...@googlemail.com: On Wed, 23 Apr 2014 02:43:25 +0200 Karsten Bräckelmann wrote: On Tue, 2014-04-22 at 22:31 +0300, Nick I wrote: Here is timing from amavis. tests_pri_0 is around 90% all the time : amavis[26002]: (26002-05) TIMING-SA total 759 ms - parse: 1.92 (0.3%), extract_message_metadata: 31 (4.1%), get_uri_detail_list: 6 I'm not entirely sure about that amavis log-line, but it most likely maps to the SA priorities rules are run at. The text after TIMING-SA looks to be SA's own _TIMING_ tag.
Re: high cpu load
Nick I skrev den 2014-04-23 19:14: Can anyone suggest how to look inside tests_pri_0 ? disable BodyEVAL plugin as a first step, if load is not low then its not that plugin that causing its problem to take it all, one could test with just check plugin enabled, and add one by one to see with plugin the time killer is in also it was a thing i remember some mails took extramly long scan here, it was at that time a slow regex that was not bounded, so it scanned one big file without limits show spamassassin 21 -D --lint so maillist see if and what perl you have installed and there most other her knows more in detail where to search more for solving there should not be a amavisd problem
Re: high cpu load
On Wed, 23 Apr 2014, Nick I wrote: Another interesting thing. Today when daily cron executed at 5 am load calmed to ~0. As it was before. Sa-update executed at that time. Amavisd has been reloaded at 7 am and load raised back again. Also i see that some messages checked 150329 ms, 158742 ms. But most messages checked ~400ms. I used @debug_recipient_maps and sa_debug but did not see any userful info. Can anyone suggest how to look inside tests_pri_0 ? The first thing you need to do is capture one of the messages that took a very long time to scan, so that it can be tested in a controlled environment. There are tools that will allow you to capture timing data for every rule, and if the message is a spam you could provide it to us for analysis. -- 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 --- Today: Max Planck's 156th birthday
high cpu load
Hi, I use SpamAssassin version 3.3.1 running on Perl version 5.10.1, amavisd-new-2.8.0-8.el6 as before-queue filter. Today for unknown reason i noticed high load on my server. Mail flow is as usual. About 8k in hour checked by amavisd. Here is timing from amavis. tests_pri_0 is around 90% all the time : amavis[26002]: (26002-05) TIMING-SA total 759 ms - parse: 1.92 (0.3%), extract_message_metadata: 31 (4.1%), get_uri_detail_list: 6 (0.8%), tests_pri_-1000: 17 (2.2%), tests_pri_-950: 0.93 (0.1%), tests_pri_-900: 1.00 (0.1%), tests_pri_-400: 0.79 (0.1%), *tests_pri_0: 668 (88.0%)*, check_dkim_signature: 9 (1.2%), check_spf: 364 (47.9%), poll_dns_idle: 338 (44.5%), tests_pri_500: 7 (1.0%), get_report: 0.99 (0.1%) In my another test i see async completed from 0.016 s till 0.174 s. How can i disable/speed up tests_pri_0 ? What is inside tests_pri_0? Thanks.
Re: high cpu load
Have you tried compiling the rules with sa-compile. It speeds up everything. I'm afraid I don't know the answer to what that specific test does. Hi, I use SpamAssassin version 3.3.1 running on Perl version 5.10.1, amavisd-new-2.8.0-8.el6 as before-queue filter. Today for unknown reason i noticed high load on my server. Mail flow is as usual. About 8k in hour checked by amavisd. Here is timing from amavis. tests_pri_0 is around 90% all the time :* *amavis[26002]: (26002-05) TIMING-SA total 759 ms - parse: 1.92 (0.3%), extract_message_metadata: 31 (4.1%), get_uri_detail_list: 6 (0.8%), tests_pri_-1000: 17 (2.2%), tests_pri_-950: 0.93 (0.1%), tests_pri_-900: 1.00 (0.1%), tests_pri_-400: 0.79 (0.1%), *tests_pri_0: 668 (88.0%)*, check_dkim_signature: 9 (1.2%), check_spf: 364 (47.9%), poll_dns_idle: 338 (44.5%), tests_pri_500: 7 (1.0%), get_report: 0.99 (0.1%) In my another test i see async completed from 0.016 s till 0.174 s. How can i disable/speed up tests_pri_0 ? What is inside tests_pri_0? Thanks.
Re: high cpu load
On Tue, 2014-04-22 at 22:31 +0300, Nick I wrote:
I use SpamAssassin version 3.3.1 running on Perl version 5.10.1,
amavisd-new-2.8.0-8.el6 as before-queue filter.
Today for unknown reason i noticed high load on my server. Mail flow
is as usual. About 8k in hour checked by amavisd.
Here is timing from amavis. tests_pri_0 is around 90% all the time :
amavis[26002]: (26002-05) TIMING-SA total 759 ms - parse: 1.92 (0.3%),
extract_message_metadata: 31 (4.1%), get_uri_detail_list: 6 (0.8%),
tests_pri_-1000: 17 (2.2%), tests_pri_-950: 0.93 (0.1%),
tests_pri_-900: 1.00 (0.1%), tests_pri_-400: 0.79 (0.1%), tests_pri_0:
668 (88.0%), check_dkim_signature: 9 (1.2%), check_spf: 364 (47.9%),
poll_dns_idle: 338 (44.5%), tests_pri_500: 7 (1.0%), get_report: 0.99
(0.1%)
In my another test i see async completed from 0.016 s till 0.174 s.
How can i disable/speed up tests_pri_0 ?
What is inside tests_pri_0?
The letter question better be raised before asking how to *disable*
something... ;)
I'm not entirely sure about that amavis log-line, but it most likely
maps to the SA priorities rules are run at. Lower (including negative)
priorities are run prior to higher ones, with 0 being the default
priority level. Thus, this also is the priority of the bulk of the regex
based, CPU-bound general rules.
(a) Check your logs, if there is an sa-update run with a close timely
relation to the increase of CPU load. Both SA update channels, as well
as any third-party update channel (if any).
(b) Carefully review all your custom rules. Recent changes need special
attention.
Even if (in both cases) no changes correlate with the time of load
increase, it still might be a regex based rule in backtrace hell -- now
tripping on a pattern not observed in previous mail flow.
FWIW, custom rules with runaway regex patterns usually is the culprit
for such behavior. Stock SA update channel rules are unlikely, unless
others observe the same load increase.
--
char *t=\10pse\0r\0dtu\0.@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: razor and dcc : high cpu load
Thanks all for tips! Anyway, I disabled fuzzy_ocr plugin and cpu load was reduced to ~2. The results without fuzzy are good enough. But, I'll go to make rcpto checks too, to reject invalid messages during the initial SMTP conversation, which is a good thing... Ollie Acheson escreveu: On Fri, Nov 10, 2006 at 04:12:44PM -0200, Rejaine Monteiro wrote: Ok, validrcptto seems to be nice for me... I just can't forget to insert all -default aliases (qmail-default) and use a validrcptto version with this support (to using with qmail-rocks) Thanks for all tips In case you want to explore other rcpt-checking routines, as well as see some scripts for doing getting addresses from, say, an exchange server that's behind a qmail server, go to http://http.netdevice.com:9080/qmail/rcptck/ Lot's of good alternatives. Ollie Jim Maul escreveu: Rejaine Monteiro wrote: Like a text-file based (it's not a security hole?!) or a ldap-replica on mail-server? I'm searching for more examples and other ideas and find this patch for qmail: http://qmail.jms1.net/patches/validrcptto.cdb.shtml I don't no if this patch is really necessary.. but it's a sugestion too... Anyway... I'll search more and to do many tests... Thanks... First, that was exactly that page/patch that i was referring to. I use it here on my server and know of others who are in the exact same setup as you who also use it. The file is a .cdb file (not text) but even if it was, i fail to see how this is a security hole. There are only a list of accounts or perhaps a wildcard ([EMAIL PROTECTED]) in this cdb file so where is the risk? ldap-replica is way too involved for this function. Use the patch you mentioned, find a way to get qmail-ldap to output a list of addresses, build the cdb file and replicate to the server(s). Thats basically it. -Jim
RE: razor and dcc : high cpu load
I've seen a big CPU load with pyzor, but not with razor or DCC (using dccifd). I'd say disable these checks one at a time to see which one is causing the highest loads on your machine, and if your machine can't quite handle the current load, disable the ones with the highest loads, at least temporarily, until you are back to a level your system can handle. Then you can try to figure out if the results without the checks you disabled are good enough, or if it's worth your time to try and hunt down the issue. (One thing to check for regarding any of the network checks is to be certain your firewall's permitting the traffic; I could easily see a network check failing ungracefully in such a case.) -- John C. Ring, Jr. [EMAIL PROTECTED] Network Engineer Union Switch Signal Inc. If men were angels, no government would be necessary. If angels were to govern men, neither external nor internal controls on government would be necessary. -- James Madison -Original Message- From: Rejaine Monteiro [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 2:27 PM To: users@spamassassin.apache.org Subject: razor and dcc : high cpu load my system had a high cpu load with spamassassin with network tests , dcc + razor and fuzzy_ocr because off this, we are considering disable razor or dcc from tests... but we have doubt about which is better: disable razor or dcc? any recomendations??
Re: razor and dcc : high cpu load
On Fri, Nov 10, 2006 at 04:12:44PM -0200, Rejaine Monteiro wrote: Ok, validrcptto seems to be nice for me... I just can't forget to insert all -default aliases (qmail-default) and use a validrcptto version with this support (to using with qmail-rocks) Thanks for all tips In case you want to explore other rcpt-checking routines, as well as see some scripts for doing getting addresses from, say, an exchange server that's behind a qmail server, go to http://http.netdevice.com:9080/qmail/rcptck/ Lot's of good alternatives. Ollie Jim Maul escreveu: Rejaine Monteiro wrote: Like a text-file based (it's not a security hole?!) or a ldap-replica on mail-server? I'm searching for more examples and other ideas and find this patch for qmail: http://qmail.jms1.net/patches/validrcptto.cdb.shtml I don't no if this patch is really necessary.. but it's a sugestion too... Anyway... I'll search more and to do many tests... Thanks... First, that was exactly that page/patch that i was referring to. I use it here on my server and know of others who are in the exact same setup as you who also use it. The file is a .cdb file (not text) but even if it was, i fail to see how this is a security hole. There are only a list of accounts or perhaps a wildcard ([EMAIL PROTECTED]) in this cdb file so where is the risk? ldap-replica is way too involved for this function. Use the patch you mentioned, find a way to get qmail-ldap to output a list of addresses, build the cdb file and replicate to the server(s). Thats basically it. -Jim -- |---| | Ollie Acheson | | Morristown, NJ| |---|
Re: razor and dcc : high cpu load
Rejaine Monteiro wrote: But I have various servers with qmail-ldap configuration, where the a first server (simple qmail installation, without ldap) receives mails from internet and check domain using rcpthosts only, does spam and virus checks and them forwards the mail to the others qmail-ldap servers using virtualdomains and alias (so, the ldap accounts and mail address are on others servers) One problem with this arrangement is that I cannot do RCPTCHECK, because none of the domains are in locals, but in virtualdomains. I would really like to do RCPTCHECK because of spam, but with that configuration I don't no how to do this... Any ideas??? Generate a list of all valid addresses from the machine that actually has the mailboxes and propagate that list to the machines that actually received the mail so they are aware of which accounts are valid and which are not. This is done pretty easily using qmail.
Re: razor and dcc : high cpu load
Like a text-file based (it's not a security hole?!) or a ldap-replica on mail-server? I'm searching for more examples and other ideas and find this patch for qmail: http://qmail.jms1.net/patches/validrcptto.cdb.shtml I don't no if this patch is really necessary.. but it's a sugestion too... Anyway... I'll search more and to do many tests... Thanks... Jim Maul escreveu: Rejaine Monteiro wrote: But I have various servers with qmail-ldap configuration, where the a first server (simple qmail installation, without ldap) receives mails from internet and check domain using rcpthosts only, does spam and virus checks and them forwards the mail to the others qmail-ldap servers using virtualdomains and alias (so, the ldap accounts and mail address are on others servers) One problem with this arrangement is that I cannot do RCPTCHECK, because none of the domains are in locals, but in virtualdomains. I would really like to do RCPTCHECK because of spam, but with that configuration I don't no how to do this... Any ideas??? Generate a list of all valid addresses from the machine that actually has the mailboxes and propagate that list to the machines that actually received the mail so they are aware of which accounts are valid and which are not. This is done pretty easily using qmail.
Re: razor and dcc : high cpu load
Rejaine Monteiro wrote: Like a text-file based (it's not a security hole?!) or a ldap-replica on mail-server? I'm searching for more examples and other ideas and find this patch for qmail: http://qmail.jms1.net/patches/validrcptto.cdb.shtml I don't no if this patch is really necessary.. but it's a sugestion too... Anyway... I'll search more and to do many tests... Thanks... First, that was exactly that page/patch that i was referring to. I use it here on my server and know of others who are in the exact same setup as you who also use it. The file is a .cdb file (not text) but even if it was, i fail to see how this is a security hole. There are only a list of accounts or perhaps a wildcard ([EMAIL PROTECTED]) in this cdb file so where is the risk? ldap-replica is way too involved for this function. Use the patch you mentioned, find a way to get qmail-ldap to output a list of addresses, build the cdb file and replicate to the server(s). Thats basically it. -Jim
RE: razor and dcc : high cpu load
Like a text-file based (it's not a security hole?!) or a ldap-replica on mail-server? I'm searching for more examples and other ideas and find this patch for qmail: http://qmail.jms1.net/patches/validrcptto.cdb.shtml I don't no if this patch is really necessary.. but it's a sugestion too... Anyway... I'll search more and to do many tests... Thanks... validrcptto patch works very well This patch does wonders for knocking down garbage before it gets into the queue It is based on system that uses qmail and vpopmail etc and generates a txt file that gets turned into a cdb - rh -- Robert - Abba Communications Computer Internet Services (509) 624-7159 - www.abbacomm.net
Re: razor and dcc : high cpu load
Ok, validrcptto seems to be nice for me... I just can't forget to insert all -default aliases (qmail-default) and use a validrcptto version with this support (to using with qmail-rocks) Thanks for all tips Jim Maul escreveu: Rejaine Monteiro wrote: Like a text-file based (it's not a security hole?!) or a ldap-replica on mail-server? I'm searching for more examples and other ideas and find this patch for qmail: http://qmail.jms1.net/patches/validrcptto.cdb.shtml I don't no if this patch is really necessary.. but it's a sugestion too... Anyway... I'll search more and to do many tests... Thanks... First, that was exactly that page/patch that i was referring to. I use it here on my server and know of others who are in the exact same setup as you who also use it. The file is a .cdb file (not text) but even if it was, i fail to see how this is a security hole. There are only a list of accounts or perhaps a wildcard ([EMAIL PROTECTED]) in this cdb file so where is the risk? ldap-replica is way too involved for this function. Use the patch you mentioned, find a way to get qmail-ldap to output a list of addresses, build the cdb file and replicate to the server(s). Thats basically it. -Jim
razor and dcc : high cpu load
my system had a high cpu load with spamassassin with network tests , dcc + razor and fuzzy_ocr because off this, we are considering disable razor or dcc from tests... but we have doubt about which is better: disable razor or dcc? any recomendations??
RE: razor and dcc : high cpu load
Rejaine Monteiro wrote: my system had a high cpu load with spamassassin with network tests , dcc + razor and fuzzy_ocr because off this, we are considering disable razor or dcc from tests... but we have doubt about which is better: disable razor or dcc? any recomendations?? If the decision is between DCC and Razor, I would keep Razor. However, neither one of them should contribute much to a high CPU load. They can cause delays waiting for responses from the servers, but they don't really do enough to raise the load significantly. Fuzzy_ocr or a bad rule is a more likely candidate for eating cpu time. -- Bowie
R: razor and dcc : high cpu load
my system had a high cpu load with spamassassin with network tests , dcc + razor and fuzzy_ocr because off this, we are considering disable razor or dcc from tests... but we have doubt about which is better: disable razor or dcc? Isn't it better to disable fuzzy, instead? Razor and DCC are very good wide-spectrum spam counter-measures. Fuzzy is great, too, but it's purpose is narrower. If you prefer to disable Razor or DCC, I would suggest DCC: it is the one scoring less when hit. Cheers, Giampaolo any recomendations??
RE: razor and dcc : high cpu load
We had that problem in the past until we started using the access list in sendmail to filter out servers that were just hitting us with spam all the time. I still go through our logs daily and add to it as needed. The reduction in load on the server was very dramatic. Since our server is a forwarding server we also reject email addresses in the access list to further drop the load because spamassassin never needs to scan it. Jason Little Network Admin Mint Inc -Original Message- From: Bowie Bailey [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 2:50 PM To: users@spamassassin.apache.org Subject: RE: razor and dcc : high cpu load Rejaine Monteiro wrote: my system had a high cpu load with spamassassin with network tests , dcc + razor and fuzzy_ocr because off this, we are considering disable razor or dcc from tests... but we have doubt about which is better: disable razor or dcc? any recomendations?? If the decision is between DCC and Razor, I would keep Razor. However, neither one of them should contribute much to a high CPU load. They can cause delays waiting for responses from the servers, but they don't really do enough to raise the load significantly. Fuzzy_ocr or a bad rule is a more likely candidate for eating cpu time. -- Bowie
Re: razor and dcc : high cpu load
On Thu, Nov 09, 2006 at 02:57:23PM -0500, Jason Little wrote: We had that problem in the past until we started using the access list in sendmail to filter out servers that were just hitting us with spam all the time. I still go through our logs daily and add to it as needed. The reduction in load on the server was very dramatic. Since our server is a forwarding server we also reject email addresses in the access list to further drop the load because spamassassin never needs to scan it. Jason Little Network Admin Mint Inc I would certainly endorse anything to decrease the incoming load. We use qmail and implemented the goodrctto-12.patch which rejects emails at smtp time that are not in a list of valid recipients. This hugely (80%) decreased the volume of accepted incoming mail which, obviously, hugely decreased the traffic through spamassassin. Ollie -Original Message- From: Bowie Bailey [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 2:50 PM To: users@spamassassin.apache.org Subject: RE: razor and dcc : high cpu load Rejaine Monteiro wrote: my system had a high cpu load with spamassassin with network tests , dcc + razor and fuzzy_ocr because off this, we are considering disable razor or dcc from tests... but we have doubt about which is better: disable razor or dcc? any recomendations?? If the decision is between DCC and Razor, I would keep Razor. However, neither one of them should contribute much to a high CPU load. They can cause delays waiting for responses from the servers, but they don't really do enough to raise the load significantly. Fuzzy_ocr or a bad rule is a more likely candidate for eating cpu time. -- Bowie -- |---| | Ollie Acheson | | Morristown, NJ| |---|
high cpu load and recommend max-children value
Hi I'm runing spamassasin in a mail server P4 CPU 2.80GHz HT - 2G RAM - 2G Swap I'm using qmail + qmail-scanner 2.01 + spamassassin 3.0.4 + clamav My spamassassin contains: razor2 , dcc, fuzzy_ocr, rlb_checks, bayes=yes, autolearn=no, autowhitelist=no (with options -x -u spamd -d -m 5) Qmail-scanner statistics : Average 123 Msgs / 5 min Average 5 Viruses/5min Average 95 Spams/5min But we have some problems with high cpu load and spamd ( cpu load ~ 7, 8, 9) What I'm doing wrong?
