Re: Poor performance with v3.2.0
Am Dienstag, 8. Mai 2007 20:09:42 schrieb Rosenbaum, Larry M.: I am getting really poor performance with v3.2.0 compared with v3.1.8. So do we. I'm quite sorry to bring this subject up again, but bayes expire is no explanation for us. We are running spamd 3.1x on a cluster of Debian Linux boxes, configured to do no outbound DNS, RBLs, bayes, SPF, whatever. It should simply do it's rules and nothing else. Usually I keep the boxes running on a load of about 5 and it was all quite well balanced. Yesterday I tried to switch to 3.2, configured likewise and had to downgrade soon afterwards for the load was exceeding 13. Same amount of email, same loadbalancing, same hardware. Of course, a new version with lots more rules is bound to be slower but that's really a killer for us since it effectively prevents us from upgrading at all. Is there any way to configure it so it may still yield OK results but be a bit, well, modest? Thanks... Stephan signature.asc Description: This is a digitally signed message part.
Re: SPF custom rule
Bret Miller wrote: Thanks for the info Bret. What I've come up with is this: header _FROM_DOMAIN From ~= /example\.com/i header _SPF_TRUE /\bSPF_FAIL\b/ meta DOMAIN_SPF_TRUE (_FROM_DOMAIN_SPF_TRUE) score DOMAIN_SPF_TRUE 10.0 Will this work? Kinda, with few changes: header __FROM_DOMAIN From ~= /\bexample\.com\b/i header __SPF_TRUE ALL ~= /\bSPF_FAIL\b/ This will make sure you get example.com and not myexample.communists. However, the From header is *really* easy to spoof, so this isn't much of a check. You would probaly be better off looking for the host name in one of the received headers. You also need to give a target to the second header test. I used "ALL" to search all of the headers for the string you want. However, if you know the name of the header you are looking for, you could better do something like header __SPF_CHECKSPF_FAIL:Exists Assuming the header was named "SPF_FAIL" Note also you want two leading underscores, not one, on those meta parts, so the final line becomes: meta DOMAIN_SPF_TRUE (__FROM_DOMAIN __SPF_TRUE) Loren Hi Loren Thank you very much. I'll give it a try. The final filter will then look like this? header __FROM_DOMAIN From ~= /\bexample\.com\b/i header __SPF_TRUE ALL ~= /\bSPF_FAIL\b/ meta DOMAIN_SPF_TRUE (__FROM_DOMAIN__SPF_TRUE) score DOMAIN_SPF_TRUE 10.0 Just a question though.. This whole process happens in Spamassassin... Will there be a SPF_FAIL in the header already at the time of this check?? I get the feeling there won't.. If the SPF test is happening in SA anyway, then you can reduce this to two rules: header __FROM_DOMAIN From ~= /\bexample\.com\b/i meta DOMAIN_SPF_TRUE (__FROM_DOMAINSPF_FAIL) score DOMAIN_SPF_TRUE 10.0 SPF_FAIL is part of the standard rule set in 25_spf.cf. No sense in checking the condition twice. Bret The rule works 100%. Had to tweak it a bit and clean out some syntax errors, but it works. :) header __DOMAIN_FROM From =~ /\bexample\.com\b/i meta DOMAIN_SPF_TRUE (__DOMAIN_FROM (SPF_SOFTFAIL || SPF_FAIL)) score DOMAIN_SPF_TRUE 5.0 Thanks for all the help . Regards JvdW
Re: UTF-8/SA WORKAROUND only - NOT - a fix..
Kevin W. Gagel writes: Thanks for straightening me out on that Vincent. Folks - for completeness here are some instructions for the WORKAROUND. Locate your Message.pm module and edit the section in the begining as indicated below. I have been running this now for a couple of hours with no adverse affects (that I can see at the moment). PS Thanks [EMAIL PROTECTED] for your help. I'm up and running without any further errors. - Forwarded Message - Vincent, Where in the Message.pm module do I but use bytes? Right here (below) and do I just add it below the warnings line with a ; ending it? Yes, you are right, after use warnings;. I ran SA3.2 on my site with use bytes; added, no problem so far. But it seems SA developers did not mention this, they might have their reasons (break normalize_charset for one reason). Yes, exactly -- breaking one of the major 3.2.0 features is not a good thing. :( --j. ---paste--- package Mail::SpamAssassin::Message; use strict; use warnings; use Mail::SpamAssassin; use Mail::SpamAssassin::Message::Node; use Mail::SpamAssassin::Message::Metadata; use Mail::SpamAssassin::Constants qw(:sa); use Mail::SpamAssassin::Logger; use vars qw(@ISA); ---end paste--- = Vincent Li http://bl0g.blogdns.com = Kevin W. Gagel Network Administrator Information Technology Services (250) 562-2131 local 448 My Blog: http://mail.cnc.bc.ca/blogs/gagel --- The College of New Caledonia, Visit us at http://www.cnc.bc.ca Virus scanning is done on all incoming and outgoing email. Anti-spam information for CNC can be found at http://avas.cnc.bc.ca ---
malformed UTF-8 warning and SARE rules
SARE guys -- any chance those rules could be simply zeroed out (ie. replaced with meta NAMEOFRULE (0) or similar) in the short term, until they're fixed properly? I'm seeing increasing amounts of problems caused by this bug around the web -- specifically, log partitions filling up due to the error messages. I suspect it may also be contributing to at least some of the 3.2.0 causes slowdown reports, since that amount of syslog traffic would definitely impact system performance. (The alternative is to do a 3.2.1 release which catches this bug somehow at runtime, and disables the rules in code; or to simply suggest that people seeing the bug stop using the affected rulesets.) --j.
Re: check mx and compare sender ip address ??
Yesy you're rigth . Most large domains have separate MTA's for sending and receiving mail. i will try Whitelist_from_rcvd as soon as possible Matt Kettler [EMAIL PROTECTED] wrote: Gokhan ALKAN wrote: I have received some mails that from domain and return-path domain is different and from domain is in whitelist nowadays. So spamassassin decide mail that is ham . because of user_in_whilist rule. Rule 1: DO NOT use whitelist_from unless you have NO other options. Use whitelist_from_rcvd or whitelist_from_spf instead. Whitelist_from is an evil hack of last resort. Rule 2: this is particularly important for your own domain, as this is an obvious target for spammers to try. These alternate versions require more than just a From: or Return-Path: header match to cause whitelisting. Whitelist_from_rcvd will match a combination of a From: header, and has a second parameter that will check the reverse-dns lookup of the host delivering it to a trusted mailserver. whitelist_from_spf will use SPF records, and will only match if the mail is also sent by a server that passes the SPF records of the domain. can i block this spam that check mx records as from domain and compare sender ip address ? But why would that be effective? Most large domains have separate MTA's for sending and receiving mail, thus none of their mail will come from a MTA that matches the MX record. This feature would only be useful for small-shops, and only if you know for sure the small shop uses the one server does it all setup, and that you know the admin will call you and let you know if he decides to change it. My work domain serves a reasonably small population of users, but for quite a while had a separate sending and receiving MTA. However, I recently folded that back in on one host, but might split it back out at any moment. - Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games.
Re: High FP rate with 3.2 ??
Yet Another Ninja writes: On 5/8/2007 7:18 PM, Kelsey Cummings wrote: Is anyone else seeing an increased FP rate after upgrading to 3.2? I've got a number of reports coming in like: AXB_XMID_1212, which defaults to 3.899 and was causing a fair amount of legitimate mail to one of our customers to fail Replace 'AXB_XMID_1212' with a handful of other rules with substantial scores and the reports are pretty much all the same. One rule with a high score matching on HAM with a couple of minor low scoring rules pushing the message over the edge. #counts AXB_XMID_1212 260s/0h of 19804 corpus (15215s/4589h) 5/10/07 AXB_XMID_1212 -- suggested score: 1.666 (of 5) #counts AXB_XMID_1212 272s/1h of 9297 corpus (4867s/4430h) 05/10/07 AXB_XMID_1212 -- suggested score: 1.311 (of 5) I wonder why it was scored so high... score AXB_XMID_1212 3.899 3.899 3.899 3.496 # n=2 JM? I suspect it was the only rule hitting the spam it hit with few/zero FPs. take a look on the ruleqa site... --j.
Check ip by perl
Hello I need to check only ip for DNSBL lists and get score. When I do # spamassassin test.EML I get X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on hs1.host.net.ua X-Spam-Level: *** X-Spam-Status: Yes, score=11.9 required=5.0 tests=AWL,HELO_DYNAMIC_IPADDR2, RCVD_IN_DSBL,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL autolearn=no version=3.1.8 X-Spam-Report: * 3.2 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [201.13.140.1 listed in dnsbl.sorbs.net] * 1.8 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [http://dsbl.org/listing?201.13.140.1] * 3.1 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL But can I just check ip and get score? I do not need check hole letter. Can I do this by perl (by Spammassassin module) or how? Thanks a lot. -- View this message in context: http://www.nabble.com/Check-ip-by-perl-tf3720592.html#a10410108 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Catching mail sent from number addresses?
Hello! Perhaps i overlooked some test i could use for giving extra scores to mail sent from addresses like this: X-Envelope-From: [EMAIL PROTECTED] e.g. i would think it useful if i could add a check for: address contains 4 or more digits, give it some extra score 1.x Perhaps someone is using such a rule already? -- Greetings MH Dont send mail to: [EMAIL PROTECTED] --
Re: malformed UTF-8 warning and SARE rules
I'm hoping I can get to this a in a day or two Justin. I started on it a few days ago and had the editor I was using decide that it didn't like high-byte characters and crash, and I haven't had time to get back and do it again. SOmething about a 16-hour a day day job and two side jobs that take about 8 and 4 hours a day each respectively. :-( Loren
Re: Catching mail sent from number addresses?
X-Envelope-From: [EMAIL PROTECTED] e.g. i would think it useful if i could add a check for: address contains 4 or more digits, give it some extra score 1.x I'd sure want to masscheck the rule before using it, but you could proibably do something like header X-Envelope-From:addr =~ /[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@/ Or the like. Loren
off on holidays ;)
Hi all -- I'm off shortly on 2 weeks vacation until May 24. see you then, and good luck with that 3.2.x bug list ;) --j.
Spamd logs
Hi All, I saw the mention earlier about spamd logs and thought I'd check mine. In 12 hours it has achieved the impressive, if very worrying size of 1.8 Gb. A check back over the last few days show similarly sized logs. My system lint's clean. and sa-compile ran fine after I removed the rules that were throwing an error (and mucked about getting ImageInfo working without erroring). Will dropping the -s /var/log/spamd.log from /init.d/spamassassin stop logging? I know that's not an ideal solution but it's certainly preferable to multi Gb log files. This isn't going to kill my hdd or fill it, but it's certainly not going to be helping matters. All help gratefully received. Kind regards Nigel.
Re: Spamd logs
On Thu, 10 May 2007 12:01:53 +0100, Nigel Frankcom [EMAIL PROTECTED] wrote: Hi All, I saw the mention earlier about spamd logs and thought I'd check mine. In 12 hours it has achieved the impressive, if very worrying size of 1.8 Gb. A check back over the last few days show similarly sized logs. My system lint's clean. and sa-compile ran fine after I removed the rules that were throwing an error (and mucked about getting ImageInfo working without erroring). Will dropping the -s /var/log/spamd.log from /init.d/spamassassin stop logging? I know that's not an ideal solution but it's certainly preferable to multi Gb log files. This isn't going to kill my hdd or fill it, but it's certainly not going to be helping matters. It seems spamd -s null in the init.d will stop logging (http://spamassassin.apache.org/full/3.2.x/doc/spamd.html) but, even if the rules are erroring, are they actually doing anything to catch spam? Is it better to remove the rules or kill the logging? Thoughts anyone? Kind regards Nigel
Re: Spamd logs
On Thu, 10 May 2007 12:28:31 +0100, Nigel Frankcom [EMAIL PROTECTED] wrote: On Thu, 10 May 2007 12:01:53 +0100, Nigel Frankcom [EMAIL PROTECTED] wrote: Hi All, I saw the mention earlier about spamd logs and thought I'd check mine. In 12 hours it has achieved the impressive, if very worrying size of 1.8 Gb. A check back over the last few days show similarly sized logs. My system lint's clean. and sa-compile ran fine after I removed the rules that were throwing an error (and mucked about getting ImageInfo working without erroring). Will dropping the -s /var/log/spamd.log from /init.d/spamassassin stop logging? I know that's not an ideal solution but it's certainly preferable to multi Gb log files. This isn't going to kill my hdd or fill it, but it's certainly not going to be helping matters. It seems spamd -s null in the init.d will stop logging (http://spamassassin.apache.org/full/3.2.x/doc/spamd.html) but, even if the rules are erroring, are they actually doing anything to catch spam? Is it better to remove the rules or kill the logging? Correction: The change I've made to disable logging is in /etc/sysconfig/spamassassin It seems to have stopped the logging at least, I'm unsure of what other problems it may create. KR Nigel
RE: Poor performance with v3.2.0
Took 10 mins on my 2.8gh 512mb ram, with a bunch of sares rules. You using .12.0 of re2c? Yes. I think most of the time is spent in the rule extraction steps and the gcc compiles, and not in the re2c steps. (gcc is v3.4.6) Yes, you are right, after use warnings;. I ran SA3.2 on my site with use bytes; added, no problem so far. But it seems SA developers did not mention this, they might have their reasons (break normalize_charset for one reason). Yes, exactly -- breaking one of the major 3.2.0 features is not a good thing. :( Where can I find documentation on what normalize_charset does?
Re: Spamd logs
On Thu, 10 May 2007 12:39:51 +0100, Nigel Frankcom [EMAIL PROTECTED] wrote: On Thu, 10 May 2007 12:28:31 +0100, Nigel Frankcom [EMAIL PROTECTED] wrote: On Thu, 10 May 2007 12:01:53 +0100, Nigel Frankcom [EMAIL PROTECTED] wrote: Hi All, I saw the mention earlier about spamd logs and thought I'd check mine. In 12 hours it has achieved the impressive, if very worrying size of 1.8 Gb. A check back over the last few days show similarly sized logs. My system lint's clean. and sa-compile ran fine after I removed the rules that were throwing an error (and mucked about getting ImageInfo working without erroring). Will dropping the -s /var/log/spamd.log from /init.d/spamassassin stop logging? I know that's not an ideal solution but it's certainly preferable to multi Gb log files. This isn't going to kill my hdd or fill it, but it's certainly not going to be helping matters. It seems spamd -s null in the init.d will stop logging (http://spamassassin.apache.org/full/3.2.x/doc/spamd.html) but, even if the rules are erroring, are they actually doing anything to catch spam? Is it better to remove the rules or kill the logging? Correction: The change I've made to disable logging is in /etc/sysconfig/spamassassin It seems to have stopped the logging at least, I'm unsure of what other problems it may create. Duh me! - Perl was 5.8.5 (coulda sworn I updated it but apparently not). On CentOS enabling centosplus in the yum config allowed me to update Perl to 5.8.8. It seems to have gone in without a hitch and logs don't seem to be running away now. That said I did move out some of the rules that were apparently causing a problem. HTH someone else. KR Nigel
RE: Poor performance with v3.2.0
On Thu, 10 May 2007, Rosenbaum, Larry M. wrote: Took 10 mins on my 2.8gh 512mb ram, with a bunch of sares rules. You using .12.0 of re2c? Yes. I think most of the time is spent in the rule extraction steps and the gcc compiles, and not in the re2c steps. (gcc is v3.4.6) Yes, you are right, after use warnings;. I ran SA3.2 on my site with use bytes; added, no problem so far. But it seems SA developers did not mention this, they might have their reasons (break normalize_charset for one reason). Yes, exactly -- breaking one of the major 3.2.0 features is not a good thing. :( Where can I find documentation on what normalize_charset does? % perldoc Mail::SpamAssassin::Conf ... normalize_charset ( 0 | 1) (default: 0) Whether to detect character sets and normalize message content to Unicode. Requires the Encode::Detect module, HTML::Parser version 3.46 or later, and Perl 5.8.5 or later.
Re: Poor performance with v3.2.0
Well, here, P4 HT 3.06 GHz, 2 GB RAM (just added 1GB, wanted to test performance) Debian Sarge pretty standard, Perl 5.8.8 from Backports, SA 3.2.0 from source, re2c 0.12.0 from source, a bunch of SARE and openprotect rules, several plugins, sa-compile delivered this: # time sa-compile real2m37.209s user2m17.220s sys 0m14.943s Plus, seems like SA isn't putting that much extra stress on my servers, scantimes reported by Amavis are pretty much the same as before the upgrade from 3.1.8 (from Debian backports), and top shows a load index of 0.45-0.66 vs 0.22-0.33 before upgrading (Note: This reports came from the 1 GB RAM setup). I guess the extra amount of rules got compensated with the performance boost from sa-compile... Luix 2007/5/10, Duane Hill [EMAIL PROTECTED]: On Thu, 10 May 2007, Rosenbaum, Larry M. wrote: Took 10 mins on my 2.8gh 512mb ram, with a bunch of sares rules. You using .12.0 of re2c? Yes. I think most of the time is spent in the rule extraction steps and the gcc compiles, and not in the re2c steps. (gcc is v3.4.6) Yes, you are right, after use warnings;. I ran SA3.2 on my site with use bytes; added, no problem so far. But it seems SA developers did not mention this, they might have their reasons (break normalize_charset for one reason). Yes, exactly -- breaking one of the major 3.2.0 features is not a good thing. :( Where can I find documentation on what normalize_charset does? % perldoc Mail::SpamAssassin::Conf ... normalize_charset ( 0 | 1) (default: 0) Whether to detect character sets and normalize message content to Unicode. Requires the Encode::Detect module, HTML::Parser version 3.46 or later, and Perl 5.8.5 or later. -- - GNU-GPL: May The Source Be With You... Linux Registered User #448382. -
sa-stats and no spamd logs.
HI, is there a way to extract statistics as with sa-stats from spamassassin, even if spamd is not used (so no logs spamd format), and it is used spamassassin from amavis-new instead. anybody have a similar need? Or .. logs in sql and php... thanks in advance -- View this message in context: http://www.nabble.com/sa-stats-and-no-spamd-logs.-tf3722909.html#a10417475 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
status SA 3.2.0 on Mac
I was asked how the update was working on the Mac. Since I added use bytes; I haven't received any timeouts. Below are sample run times for the last few messages. The system is a Mac mini, PPC, 1.42GHz G4, 512MB DRAM. Mac OS X Server, 10.4.9, latest updates. ClamAV manually updated to 0.90.2 (run as clamd) SA manually updated to 3.2.0 SARE rules using sa-update plus a few I wrote. Several domains supported, web and e-mail. Not a huge amount of e-mail. Zen RBL in Postfix. May 10 09:43:43 interstellar.com /usr/bin/amavisd[24855]: (24855-03) TIMING [total 17856 ms] - SMTP EHLO: 5 (0%), SMTP pre-MAIL: 2 (0%), SMTP pre-DATA-flush: 4 (0%), SMTP DATA: 6 (0%), body_hash: 2 (0%), mime_decode: 61 (0%), get-file-type2: 48 (0%), decompose_part: 2 (0%), parts_decode: 11 (0%), AV-scan-1: 393 (2%), spam-wb-list: 3 (0%), SA msg read: 5 (0%), SA parse: 16 (0%), SA check: 17230 (96%), update_cache: 4 (0%), fwd-connect: 15 (0%), fwd-mail-from: 2 (0%), fwd-rcpt-to: 4 (0%), write-header: 11 (0%), fwd-data: 3 (0%), fwd- data-end: 14 (0%), fwd-rundown: 3 (0%), main_log_entry: 5 (0%), update_snmp: 2 (0%), unlink-2-files: 4 (0%), rundown: 2 (0%) May 10 09:43:48 interstellar.com /usr/bin/amavisd[24434]: (24434-17) TIMING [total 23594 ms] - SMTP EHLO: 6 (0%), SMTP pre-MAIL: 2 (0%), SMTP pre-DATA-flush: 4 (0%), SMTP DATA: 2 (0%), body_hash: 2 (0%), mime_decode: 25 (0%), get-file-type1: 45 (0%), decompose_part: 3 (0%), parts_decode: 0 (0%), AV-scan-1: 20 (0%), spam-wb-list: 3 (0%), SA msg read: 3 (0%), SA parse: 11 (0%), SA check: 22581 (96%), update_cache: 3 (0%), fwd-connect: 36 (0%), fwd-mail-from: 2 (0%), fwd-rcpt-to: 4 (0%), write-header: 12 (0%), fwd-data: 3 (0%), fwd- data-end: 46 (0%), fwd-rundown: 4 (0%), main_log_entry: 5 (0%), update_snmp: 2 (0%), unlink-1-files: 768 (3%), rundown: 2 (0%) May 10 09:43:51 interstellar.com /usr/bin/amavisd[24855]: (24855-04) TIMING [total 8026 ms] - SMTP EHLO: 6 (0%), SMTP pre-MAIL: 2 (0%), SMTP pre-DATA-flush: 4 (0%), SMTP DATA: 3 (0%), body_hash: 2 (0%), mime_decode: 22 (0%), get-file-type1: 97 (1%), decompose_part: 9 (0%), parts_decode: 0 (0%), AV-scan-1: 64 (1%), spam-wb-list: 32 (0%), SA msg read: 4 (0%), SA parse: 37 (0%), SA check: 7696 (96%), update_cache: 4 (0%), fwd-connect: 13 (0%), fwd-mail-from: 1 (0%), fwd-rcpt-to: 4 (0%), write-header: 6 (0%), fwd-data: 1 (0%), fwd-data- end: 6 (0%), fwd-rundown: 3 (0%), main_log_entry: 5 (0%), update_snmp: 2 (0%), unlink-1-files: 2 (0%), rundown: 2 (0%) May 10 09:43:52 interstellar.com /usr/bin/amavisd[24434]: (24434-18) TIMING [total 3322 ms] - SMTP EHLO: 5 (0%), SMTP pre-MAIL: 2 (0%), SMTP pre-DATA-flush: 4 (0%), SMTP DATA: 2 (0%), body_hash: 2 (0%), mime_decode: 34 (1%), get-file-type2: 42 (1%), decompose_part: 3 (0%), decompose_part: 9 (0%), parts_decode: 0 (0%), AV-scan-1: 259 (8%), spam-wb-list: 3 (0%), SA msg read: 8 (0%), SA parse: 8 (0%), SA check: 2891 (87%), update_cache: 3 (0%), fwd-connect: 14 (0%), fwd- mail-from: 1 (0%), fwd-rcpt-to: 5 (0%), write-header: 5 (0%), fwd- data: 1 (0%), fwd-data-end: 5 (0%), fwd-rundown: 3 (0%), main_log_entry: 5 (0%), update_snmp: 2 (0%), unlink-2-files: 4 (0%), rundown: 1 (0%) --- Jerry Durand, Durand Interstellar, Inc. Los Gatos, California, USA tel: +1-408-356-3886, USA Toll Free: 866-356-3886 www.interstellar.com, skype: jerrydurand -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand
Re: Catching mail sent from number addresses?
Hello! Perhaps i overlooked some test i could use for giving extra scores to mail sent from addresses like this: X-Envelope-From: [EMAIL PROTECTED] e.g. i would think it useful if i could add a check for: address contains 4 or more digits, give it some extra score 1.x Perhaps someone is using such a rule already? -- Greetings MH Hi Matthias, some mail systems (e.g. hotmail) tend to have lots of valid users with that style of addresses. So if you add a rule to consider these as spam, you would need to add a whitelist of mail domains where that is normal... Wolfgang
RE: Poor performance with v3.2.0
From: Loren Wilton [mailto:[EMAIL PROTECTED] Subject: Re: Poor performance with v3.2.0 It would be interesting on some system experiencing this slowdown to put 'use bytes' back into SA and see what happens with the performance. This wouldn't be any sort of a solution, but it would be an interesting data point. Interesting indeed. I added use bytes and performance is much improved. It's approximately back to where it was with v3.1.8. So what does this all mean? In case it matters, here's the output of perl -V: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.9, archname=sun4-solaris uname='sunos email 5.9 generic_118558-39 sun4u sparc sunw,sun-fire-v210 ' config_args='-Dcc=gcc -d' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.9' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at May 4 2007 15:28:54 @INC: /usr/local/lib/perl5/5.8.8/sun4-solaris /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.5 /usr/local/lib/perl5/site_perl .
Re: Poor performance with v3.2.0
Rosenbaum, Larry M. writes: From: Loren Wilton [mailto:[EMAIL PROTECTED] Subject: Re: Poor performance with v3.2.0 It would be interesting on some system experiencing this slowdown to put 'use bytes' back into SA and see what happens with the performance. This wouldn't be any sort of a solution, but it would be an interesting data point. Interesting indeed. I added use bytes and performance is much improved. It's approximately back to where it was with v3.1.8. So what does this all mean? Did you have a massive volume of Malformed UTF-8 warning messages in the syslog output? I have a theory that this would indeed cause major slowdowns, since every warning message has to be transmitted via UDP to the syslogd daemon, who then writes it synchronously to disk. That is a pretty slow operation, and causes I/O. --j. In case it matters, here's the output of perl -V: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.9, archname=sun4-solaris uname='sunos email 5.9 generic_118558-39 sun4u sparc sunw,sun-fire-v210 ' config_args='-Dcc=gcc -d' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.9' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at May 4 2007 15:28:54 @INC: /usr/local/lib/perl5/5.8.8/sun4-solaris /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.5 /usr/local/lib/perl5/site_perl .
RE: Poor performance with v3.2.0
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Did you have a massive volume of Malformed UTF-8 warning messages in the syslog output? No, I upgraded Perl to v5.8.8, which got rid of the warning messages but there was still a performance problem. Adding use bytes seems to have fixed the performance problem. I have a theory that this would indeed cause major slowdowns, since every warning message has to be transmitted via UDP to the syslogd daemon, who then writes it synchronously to disk. That is a pretty slow operation, and causes I/O.
Re: Poor performance with v3.2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Mason wrote: Rosenbaum, Larry M. writes: From: Loren Wilton [mailto:[EMAIL PROTECTED] Subject: Re: Poor performance with v3.2.0 It would be interesting on some system experiencing this slowdown to put 'use bytes' back into SA and see what happens with the performance. This wouldn't be any sort of a solution, but it would be an interesting data point. Interesting indeed. I added use bytes and performance is much improved. It's approximately back to where it was with v3.1.8. So what does this all mean? Did you have a massive volume of Malformed UTF-8 warning messages in the syslog output? I have a theory that this would indeed cause major slowdowns, since every warning message has to be transmitted via UDP to the syslogd daemon, who then writes it synchronously to disk. That is a pretty slow operation, and causes I/O. --j. In case it matters, here's the output of perl -V: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: If he is getting the UTF-8 error, this would indeed be odd, since he is using perl-5.8.8 which supposedly handles those regexps which causes the error. What SARE rules are you running Larry? - -- -Doc Penguins: Do it on the ice. 8:44am up 4 days, 16:55, 17 users, load average: 0.18, 0.30, 0.37 SARE HQ http://www.rulesemporium.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org iD8DBQFGQ2F5qOEeBwEpgcsRAkb1AJ9w8NMLub62N0wOyjbr2Ar8I0zTxACfc1/c u4cH8vGFdpmOTFxuK0qAl3E= =iViW -END PGP SIGNATURE-
Re: 3 spamc questions, version 3.2
On 9 May 2007 at 22:34, Matt Kettler wrote: Date sent: Wed, 09 May 2007 22:34:48 -0400 From: Matt Kettler [EMAIL PROTECTED] Subject:Re: 3 spamc questions, version 3.2 To: .rp [EMAIL PROTECTED] Copies to: users@spamassassin.apache.org .rp wrote: I just switched from using spamassassin to spamc in our procmail. * is there an equivalent of 'spamassassin -d' for spamc? Do you really mean spamassassin -D? -d does markup stripping, -D does debugging. NO, I really mean -d . no one has ideas why the SA3.2 is complaining about having rights to the .spamassassin file when the same non-root user is being used for spamd and spamc ?
RE: Poor performance with v3.2.0
-Original Message- From: Doc Schneider [mailto:[EMAIL PROTECTED] If he is getting the UTF-8 error, this would indeed be odd, since he is using perl-5.8.8 which supposedly handles those regexps which causes the error. What SARE rules are you running Larry? /usr/local/spamassassin/70_sare_adult.cf /usr/local/spamassassin/70_sare_bayes_poison_nxm.cf /usr/local/spamassassin/70_sare_evilnum0.cf /usr/local/spamassassin/70_sare_evilnum1.cf /usr/local/spamassassin/70_sare_evilnum2.cf /usr/local/spamassassin/70_sare_genlsubj0.cf /usr/local/spamassassin/70_sare_genlsubj1.cf /usr/local/spamassassin/70_sare_header0.cf /usr/local/spamassassin/70_sare_header1.cf /usr/local/spamassassin/70_sare_html0.cf /usr/local/spamassassin/70_sare_html1.cf /usr/local/spamassassin/70_sare_obfu.cf /usr/local/spamassassin/70_sare_oem.cf /usr/local/spamassassin/70_sare_random.cf /usr/local/spamassassin/70_sare_specific.cf /usr/local/spamassassin/70_sare_spoof.cf /usr/local/spamassassin/70_sare_stocks.cf /usr/local/spamassassin/70_sare_unsub.cf /usr/local/spamassassin/70_sare_uri0.cf /usr/local/spamassassin/70_sare_uri1.cf /usr/local/spamassassin/70_sare_whitelist_rcvd.cf /usr/local/spamassassin/70_sare_whitelist_spf.cf /usr/local/spamassassin/70_zmi_german.cf /usr/local/spamassassin/72_sare_bml_post25x.cf /usr/local/spamassassin/72_sare_redirect_post3.0.0.cf /usr/local/spamassassin/99_sare_fraud_post25x.cf also clamav, Botnet, and FuzzyOcr, and some local rules.
Re: Poor performance with v3.2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rosenbaum, Larry M. wrote: -Original Message- From: Doc Schneider [mailto:[EMAIL PROTECTED] If he is getting the UTF-8 error, this would indeed be odd, since he is using perl-5.8.8 which supposedly handles those regexps which causes the error. What SARE rules are you running Larry? /usr/local/spamassassin/70_sare_adult.cf /usr/local/spamassassin/70_sare_bayes_poison_nxm.cf /usr/local/spamassassin/70_sare_evilnum0.cf /usr/local/spamassassin/70_sare_evilnum1.cf /usr/local/spamassassin/70_sare_evilnum2.cf /usr/local/spamassassin/70_sare_genlsubj0.cf /usr/local/spamassassin/70_sare_genlsubj1.cf /usr/local/spamassassin/70_sare_header0.cf /usr/local/spamassassin/70_sare_header1.cf /usr/local/spamassassin/70_sare_html0.cf /usr/local/spamassassin/70_sare_html1.cf /usr/local/spamassassin/70_sare_obfu.cf /usr/local/spamassassin/70_sare_oem.cf /usr/local/spamassassin/70_sare_random.cf /usr/local/spamassassin/70_sare_specific.cf /usr/local/spamassassin/70_sare_spoof.cf /usr/local/spamassassin/70_sare_stocks.cf /usr/local/spamassassin/70_sare_unsub.cf /usr/local/spamassassin/70_sare_uri0.cf /usr/local/spamassassin/70_sare_uri1.cf /usr/local/spamassassin/70_sare_whitelist_rcvd.cf /usr/local/spamassassin/70_sare_whitelist_spf.cf /usr/local/spamassassin/70_zmi_german.cf /usr/local/spamassassin/72_sare_bml_post25x.cf /usr/local/spamassassin/72_sare_redirect_post3.0.0.cf /usr/local/spamassassin/99_sare_fraud_post25x.cf also clamav, Botnet, and FuzzyOcr, and some local rules. New versions of some of those rules will be released soon. I'm working on getting them all fixed. 8*) - -- -Doc Penguins: Do it on the ice. 8:44am up 4 days, 16:55, 17 users, load average: 0.18, 0.30, 0.37 SARE HQ http://www.rulesemporium.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org iD8DBQFGQ2W8qOEeBwEpgcsRAiY3AJ9v8Ecj08MTIz2feSciYojB/4x+5ACeOfos ZAK1UuA7fl9jTfGLW69+bRM= =jUc+ -END PGP SIGNATURE-
Re: Poor performance with v3.2.0
What's this use bytes thing and where do you add it and what does it do?
Re: Poor performance with v3.2.0
At 12:27 PM 5/10/2007, Marc Perkel wrote: What's this use bytes thing and where do you add it and what does it do? It's a temporary workaround for the UTF-8 problem. You add it after the use warnings; in the file message.pm. Mine is located in: /system/library/perl/extras/5.8.6/mail/spamassassin your's may differ. If you have Perl 5.8.8, you don't need to do this. When the SARE rules are updated, you can remove it. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand
Re: Poor performance with v3.2.0
On Thu, May 10, 2007 at 12:58:17PM -0700, Jerry Durand wrote: If you have Perl 5.8.8, you don't need to do this. When the SARE rules are updated, you can remove it. Alternately you can stop using the rules that have the problem, which would be easier. -- Randomly Selected Tagline: Hard where? Soft where? pgphUsxpDGC87.pgp Description: PGP signature
Re: Poor performance with v3.2.0
Justin Mason wrote: I have a theory that this would indeed cause major slowdowns, since every warning message has to be transmitted via UDP to the syslogd daemon, who then writes it synchronously to disk. That is a pretty slow operation, and causes I/O. Just a guess: if strings being processed (mail contents or rules or whatever) happen to get their utf8 flag set, Perl string operations become significantly slower - as documented. I haven't noticed performance degradation with SA under amavisd-new (perhaps I wasn't paying attention, or it pays off that we are careful never to let bytes become Perl characters unexpectedly), but it would be worth checking at a couple of places within SA is strings suddenly became utf8-flagged, which may happen as a result of some concatenations or other string operations, or I/O from UTF8 file handles. To test a string for utf8 flag, use function: Encode::is_utf8($string). An observation that 'use bytes' speeds things up, seems to confirm my suspicions. Mark
Problem with Custom Spamassassin Rule
I'm running SA 3.2.0 and am trying to write a custom spamassassin rule to deal with some recent spam I've been seeing that has 10 additional spaces in the To: header. For example: To: [EMAIL PROTECTED] So, I would like to write a rule that looks for at least two contiguous spaces before the email address brackets in the To: header. Accordingly, it seems that the following should work: header LOCAL_XTRA_SPACES_IN_TO To =~ /\s\s+/ score LOCAL_XTRA_SPACES_IN_TO 0.1 0.1 0.1 0.1 However, when I test this rule, I don't get a hit. Can anybody please tell me what I'm doing wrong? Thanks, Bryan
Re: sa-stats and no spamd logs.
Hi, try Amavis Logwatch, by Mike Capella. It's working great here, and you could run it from logwatch, or standalone: http://www.mikecappella.com/logwatch It's pretty straightforward to install and run, and it gives you lots of info about Amavis performance, as well as antivirus antispam statistics... Luix 2007/5/10, mbano [EMAIL PROTECTED]: HI, is there a way to extract statistics as with sa-stats from spamassassin, even if spamd is not used (so no logs spamd format), and it is used spamassassin from amavis-new instead. anybody have a similar need? Or .. logs in sql and php... thanks in advance -- View this message in context: http://www.nabble.com/sa-stats-and-no-spamd-logs.-tf3722909.html#a10417475 Sent from the SpamAssassin - Users mailing list archive at Nabble.com. -- - GNU-GPL: May The Source Be With You... Linux Registered User #448382. -
Re: Poor performance with v3.2.0
On Thu, May 10, 2007 at 12:27:38PM -0700, Marc Perkel wrote: What's this use bytes thing and where do you add it and what does it do? #! /usr/bin/perl use Google; -- Matthew Newton [EMAIL PROTECTED] UNIX and e-mail Systems Administrator, Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, [EMAIL PROTECTED]
Re: Problem with Custom Spamassassin Rule
Bryan K. Walton wrote: I'm running SA 3.2.0 and am trying to write a custom spamassassin rule to deal with some recent spam I've been seeing that has 10 additional spaces in the To: header. For example: To: [EMAIL PROTECTED] So, I would like to write a rule that looks for at least two contiguous spaces before the email address brackets in the To: header. Accordingly, it seems that the following should work: header LOCAL_XTRA_SPACES_IN_TO To =~ /\s\s+/ score LOCAL_XTRA_SPACES_IN_TO 0.1 0.1 0.1 0.1 However, when I test this rule, I don't get a hit. Can anybody please tell me what I'm doing wrong? You'll have to use To:raw =~ to prevent the extra whitespace from being removed and even that might not work. I think we fixed it so that it does though. Daryl
Re: 3 spamc questions, version 3.2
.rp wrote: On 9 May 2007 at 22:34, Matt Kettler wrote: Date sent: Wed, 09 May 2007 22:34:48 -0400 From: Matt Kettler [EMAIL PROTECTED] Subject:Re: 3 spamc questions, version 3.2 To: .rp [EMAIL PROTECTED] Copies to: users@spamassassin.apache.org .rp wrote: I just switched from using spamassassin to spamc in our procmail. * is there an equivalent of 'spamassassin -d' for spamc? Do you really mean spamassassin -D? -d does markup stripping, -D does debugging. NO, I really mean -d . spamc doesn't have the equivalent to spamassassin's -d. spamc doesn't markup (or remove markup) from mail. Continue to use spamassassin -d where you were before. no one has ideas why the SA3.2 is complaining about having rights to the .spamassassin file when the same non-root user is being used for spamd and spamc ? If I had to guess I'd say that the non-root user doesn't have rights to the .spamassassin file, which is actually a directory, or at least should be. Check your filesystem permissions. Daryl
Re: Problem with Custom Spamassassin Rule
On Thu, May 10, 2007 at 06:36:05PM -0400, Daryl C. W. O'Shea wrote: You'll have to use To:raw =~ to prevent the extra whitespace from being removed and even that might not work. I think we fixed it so that it does though. Thank you every body that replied. To:raw =~ was the fix that fixed it. Cheers, Bryan
sa-compile on Solaris (Re: ANNOUNCE: Apache SpamAssassin 3.2.0 available)
Duane Hill wrote: 2) In the Makefile, it states sa-compile doesn't work on FreeBSD and Solaris if you elect to use it and try doing a 'make' from the port directory. Can anyone tell me what is supposed to be broken on Solaris concerning sa-compile? I built SA 3.2.0 using the package from pkgsrc on Solaris 10, NetBSD 3.1 and Debian Sarge and sa-compile (using re2c 0.12.0) worked the same for all three machines. ciao Klaus
RE: Poor performance with v3.2.0
#! /usr/bin/perl use Google; Matthew, Sometimes it is hard for them to do if they are... $ cd /pub $ more beer Then they would tend to #! /usr/bin/perl use Bathroom; - rh -- Abba Communications Spokane, WA www.abbacomm.net
Re: Poor performance with v3.2.0
Interesting indeed. I added use bytes and performance is much improved. It's approximately back to where it was with v3.1.8. So what does this all mean? Well first, do you have the SARE rules installed that are throwing errors? If so, this might only mean that the errors have vanished. If you don't have the SARE or other rules throwing errors about high bit problems, then this possibly indicates that the Unicode regex handling in Perl is slower than the Ascii regex handling in Perl. This would not particularly surprise me at all, which is why I was hoping that maybe a few people would try this experiment. Loren - Original Message - From: Rosenbaum, Larry M. [EMAIL PROTECTED] To: users@spamassassin.apache.org Sent: Thursday, May 10, 2007 10:57 AM Subject: RE: Poor performance with v3.2.0 From: Loren Wilton [mailto:[EMAIL PROTECTED] Subject: Re: Poor performance with v3.2.0 It would be interesting on some system experiencing this slowdown to put 'use bytes' back into SA and see what happens with the performance. This wouldn't be any sort of a solution, but it would be an interesting data point. Interesting indeed. I added use bytes and performance is much improved. It's approximately back to where it was with v3.1.8. So what does this all mean? In case it matters, here's the output of perl -V: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.9, archname=sun4-solaris uname='sunos email 5.9 generic_118558-39 sun4u sparc sunw,sun-fire-v210 ' config_args='-Dcc=gcc -d' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.9' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at May 4 2007 15:28:54 @INC: /usr/local/lib/perl5/5.8.8/sun4-solaris /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.5 /usr/local/lib/perl5/site_perl .
Re: SpamAssassin removing X-Spam-Flag header
SpamAssassin is configured to add the header when it's spam and not when it's ham. you can change that add this add_header all Flag _YESNOCAPS_ and it will keep the header in both cases. On May 4, 2007, at 4:51 AM, BrianSebby wrote: We recently put an Ironport anti-spam appliance in front of our SpamAssassin installation for evaluation, and I have noticed a problem. I configured the Ironport to add the X-Spam-Flag: YES header to messages that it determines to be spam, as we have already trained our user population to look for that header to redirect their spam messages to a separate folder. After doing some tests, however, I discovered a problem. It looks like SpamAssassin removes that header if it does not determine that the message is spam. Is there a way to configure SpamAssassin to leave that header alone if it already exists? We are using SpamAssassin 3.1.8, which is launched via spampd, the spam proxy daemon, which gets the messages delivered to it from postfix. Thanks, Brian Sebby -- View this message in context: http://www.nabble.com/SpamAssassin- removing-X-Spam-Flag-header-tf3689152.html#a10313831 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: SpamAssassin removing X-Spam-Flag header
We recently put an Ironport anti-spam appliance in front of our SpamAssassin installation for evaluation, and I have noticed a problem. I The Ironport machine is SA in disguise. So you effectively have two copies of SA in series. You porbably understand this, but I'm just mentioning it to be sure. SA begins scanning a message by first removing any previous markup it may have inserted. In this case, the second SA will remove all of the markup beginning with X-Spam that the Ironport SA installed. You can't keep SA from doing this. But you may be able to use procmail or some other integration tool to change the Ironport X-Spam-xxx headers to X-Ironport-Spam-xxx headers or the like. These won't be X-Spam headers, so they won't get stripped in the second SA instance. Loren - Original Message - From: Robert Nicholson [EMAIL PROTECTED] To: BrianSebby [EMAIL PROTECTED] Cc: users@spamassassin.apache.org Sent: Thursday, May 10, 2007 9:21 PM Subject: Re: SpamAssassin removing X-Spam-Flag header SpamAssassin is configured to add the header when it's spam and not when it's ham. you can change that add this add_header all Flag _YESNOCAPS_ and it will keep the header in both cases. On May 4, 2007, at 4:51 AM, BrianSebby wrote: We recently put an Ironport anti-spam appliance in front of our SpamAssassin installation for evaluation, and I have noticed a problem. I configured the Ironport to add the X-Spam-Flag: YES header to messages that it determines to be spam, as we have already trained our user population to look for that header to redirect their spam messages to a separate folder. After doing some tests, however, I discovered a problem. It looks like SpamAssassin removes that header if it does not determine that the message is spam. Is there a way to configure SpamAssassin to leave that header alone if it already exists? We are using SpamAssassin 3.1.8, which is launched via spampd, the spam proxy daemon, which gets the messages delivered to it from postfix. Thanks, Brian Sebby -- View this message in context: http://www.nabble.com/SpamAssassin- removing-X-Spam-Flag-header-tf3689152.html#a10313831 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Big quantity of spams ...
Hi A small problems ;=) Before, my spamassassin server are in front ends .. all messages going directly to my spamassassin server and the result are very good. Now, it's a smtp relay server that receive the email and after sent to my spamassassin (the relay don't have filter or other,, it's only smtp) After this change, i receive 2x of spams ... and i don't have change the spamassassin config or other Anyone know Why ? Thanks bye
