Re: ImageInfo in two .pre files
On Mon, 18 Jun 2007, Chris wrote: I happened to notice that I had the above plugin uncommented in v312.pre and v320.pre. I haven't noticed any problems but could this cause the plugin to be loaded twice? I have SA v3.2 running here and only show ImageInfo in v320.pre. I would think you would be able to safely remove it from v312.pre. Had you added the plugin before upgrading to v3.2.x?
FuzzyOCR errors
Rarely hear from this utility since it only kicks in for marginal cases. This is what I got yesterday: Jun 18 22:55:53 d_baron spamd[5673]: FuzzyOcr: Errors in Scanset ocrad Jun 18 22:55:53 d_baron spamd[5673]: FuzzyOcr: Return code: 512, Error: ocrad: maxval 255 in ppm P6 file. Jun 18 22:55:53 d_baron spamd[5673]: FuzzyOcr: Skipping scanset because of errors, trying next... Jun 18 22:55:54 d_baron spamd[5673]: FuzzyOcr: Errors in Scanset ocrad-invert Jun 18 22:55:54 d_baron spamd[5673]: FuzzyOcr: Return code: 512, Error: ocrad: maxval 255 in ppm P6 file. Jun 18 22:55:54 d_baron spamd[5673]: FuzzyOcr: Skipping scanset because of errors, trying next... Any ideas?
Re: emails to non existent recipients -- netzero.com fixed this problem?
Please note that of course, I can only speak for myself and the system I am responsible for. I really don't know if netzero.com uses a similar system or not. I have no idea what basis their blocking has, nor do I know whether it's in any way sensible or not. Granted, but it seems to me that it is very much easier to detect these violations at the destination that at the source. The implication is that we must keep count of every failed recipient for every sender on our domain If mail from your network is sent through your SMTP server that info should be in your logs. If not, you might have to ask the admins of the system that blocked you for info about it. If you had been blocked here and asked us for the reason, I would check the database to see what kind of behaviour resulted in the block, and wether the block was still in place. Our temporary blocks based on these kind of things has a time window of a few minutes, so once you asked us the block would most probably be gone allready. And they don't tend to actually stop mail sent from retrying mail servers to legitimate users. /Jonas -- Jonas Eckerman, FSDB Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
SA 3.2.1 on FreeBSD
This is just FYI. I just upgraded SA from 3.2.0 to 3.2.1 using FreeBSD's portupgrade tool and I have not seen any issues. I also noticed re2c went from 0.12.0 to 0.12.1. That upgraded as well without any issues. After upgrading both, I re-ran sa-compile and restarted the spamd daemon. Everything seems to be working fine. I did notice two small things that don't affect the operations of SA: 1) When spamd starts now, it doesn't give feedback that it is loading the compiled rules. That's fine. I do see in the logs where the compiled rules are being loaded. 2) The warnings are still there when using sa-compile. body_0.xs:67: warning: ISO C90 forbids mixed declarations and code
Force install 3.2.1 failed
I install SA via cpan, so bug 5010 was there preventing it. I tried two cases on separate machines. 1st one I hit ctrl-C while in testing phase, closed cpan shell, and went to .cpan/build/SpamAssassin* directory. Changed the ownership of all file to -R spam:spam which is an ordinary user there, and executed make test. Went thru. Then chowned everything again to -R root:root, and said make install. Installed. 2nd machined went with cpan force install Mail::SpamAssassin. Installed. Neither of these worked. No error messages, but they just did not catch any tests, and all mail, spam or ham, went as 0 points. Ok, failure. Donwloaded 3.2.0 tarball from apache web site (sourceforge) and installed as root to both these machines, now it works as expected. 3.2.1 just does not make it. spamassassin -D --lint didn't tell me anything specific when trying with 3.2.1. Loaded all kinds of tests, but everything scored as 0. No error messages at all though. Just 0 scores. Platforms Linux Red Hat 7.3 and Linux Debian Etch.
FuzzyOCR points limit?
I'd like to see a feature on FuzzyOCR to cap the points it adds. Sometimes it really goes wildwhere it's a false positive and adds over 40 points. I'd like to cap it at 8 or so.
RE: FuzzyOCR points limit?
I'd like to see a feature on FuzzyOCR to cap the points it adds. Sometimes it really goes wildwhere it's a false positive and adds over 40 points. I'd like to cap it at 8 or so. You can use a hack in the mean time: http://www200.pair.com/mecham/spam/capFuzzy.txt Gary V _ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_June07
Re: My Newly Expanded DNS Blacklist - Who wants to try it?
John Rudd wrote: If you're going to do this, I would suggest that instead of counting to X hits on your low priority MX's and then blacklisting the IP, do this: Count on all of your MX's, and look for a ratio between hits on low priority MX's and hits on high priority MX's. IFF the high priority MX hit rate is 0, then just do a simple count on the hits against the low priority MX's. IF the highr priority MX hit rate is 0, then do (low priority hit rate) / (high priority hit rate), and look for a number = something like 10. That way, senders that might sequentially try your servers, due to problems, or even just because they roll through the servers over time, wont get tagged. OK - I've implemented an interesting trick that solves the problem. I'm using the Exim RateLimit logic that only allows 1 hit per 20 seconds to be counted. Thus if a high priority MX is hit then that creates a 20 second window where hitting my fake MX records don't count. I've noticed in my logs that most servers will zip through all MX records (now 10) in less than a second or two. This trick also prevents multiple hits on fake MX records from being counted multiple times. With this new trick along with a few others I no longer get any bot spam at all. I'm still tweaking and testing but this is looking really good.
Re: Update directory
On Tue, 2007-06-19 at 18:03 +, Duane Hill wrote: On Tue, 19 Jun 2007, Robert Fitzpatrick wrote: Can someone tell me for sure which way this needs to be and how to get sa-update to look at /usr/local/share/spamassassin again if that is what I need to do? I'm using FreeBSD here and as of SA 3.2.0, /var/db/spamassassin/the_version is where rules should show up after sa-update is ran without the --updatedir parameter. Prior, it placed the rules in /var/lib/spamassassin/the_version. Thanks, yes, actually, the first time it happened, it was /var/lib now that you mention it. /usr/local/share/spamassassin has the potential for getting overwritten on future updates. Therefore it would be advisable not to make changes within. So, I should move my core rules to /var/db/spamassassin/the_version after setting up SA from the ports system? The issue is debug does not seem to find my core rules under /usr/share, there is no mention of them in the debug output. -- Robert
Re: Update directory
So, I should move my core rules to /var/db/spamassassin/the_version after setting up SA from the ports system? The issue is debug does not seem to find my core rules under /usr/share, there is no mention of them in the debug output. -- Robert No. Once sa-update has updated /var/db/spamassassin/the_version, spamassassin SA no longer uses the rules sets in /usr/share. The new rule sets replace them. You get a complete new set of rules. Gary V _ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_June07
Re: Update directory
On Tue, 19 Jun 2007, Robert Fitzpatrick wrote: On Tue, 2007-06-19 at 18:03 +, Duane Hill wrote: On Tue, 19 Jun 2007, Robert Fitzpatrick wrote: Can someone tell me for sure which way this needs to be and how to get sa-update to look at /usr/local/share/spamassassin again if that is what I need to do? I'm using FreeBSD here and as of SA 3.2.0, /var/db/spamassassin/the_version is where rules should show up after sa-update is ran without the --updatedir parameter. Prior, it placed the rules in /var/lib/spamassassin/the_version. Thanks, yes, actually, the first time it happened, it was /var/lib now that you mention it. /usr/local/share/spamassassin has the potential for getting overwritten on future updates. Therefore it would be advisable not to make changes within. So, I should move my core rules to /var/db/spamassassin/the_version after setting up SA from the ports system? The issue is debug does not seem to find my core rules under /usr/share, there is no mention of them in the debug output. You shouldn't have to move anything. The rules in /usr/local/share/spamassassin are not read in if rules exist in /var/db/spamassassin/the_version.
RE: Update directory
On Tue, 2007-06-19 at 18:03 +, Duane Hill wrote: On Tue, 19 Jun 2007, Robert Fitzpatrick wrote: Can someone tell me for sure which way this needs to be and how to get sa-update to look at /usr/local/share/spamassassin again if that is what I need to do? I'm using FreeBSD here and as of SA 3.2.0, /var/db/spamassassin/the_version is where rules should show up after sa-update is ran without the --updatedir parameter. Prior, it placed the rules in /var/lib/spamassassin/the_version. Thanks, yes, actually, the first time it happened, it was /var/lib now that you mention it. /usr/local/share/spamassassin has the potential for getting overwritten on future updates. Therefore it would be advisable not to make changes within. So, I should move my core rules to /var/db/spamassassin/the_version after setting up SA from the ports system? The issue is debug does not seem to find my core rules under /usr/share, there is no mention of them in the debug output. Depends on what you mean by core rules. Assuming the ones that came with SpamAssassin, you don't do anything with those. SA just picks them up automatically from the update directory. If you're talking about rules you added, then those should be in /etc/mail/spamassassin. Bret
Any way to bypass authenticated users?
fc4, sendmail, sa 3.0.6, spamass-milter some clients get mail rejected from my server (which they are using to send) because sa is checking all mail. I use smtp auth - Is there any way to bypass SA if they have been authenticated?
Re: Any way to bypass authenticated users?
On Tue, 19 Jun 2007, Bazooka Joe wrote: fc4, sendmail, sa 3.0.6, spamass-milter some clients get mail rejected from my server (which they are using to send) because sa is checking all mail. I use smtp auth - Is there any way to bypass SA if they have been authenticated? Q'n'D: look at what a Received: header generated by your box for an authenticated client looks like, and write a header rule to match it, and score that rule -20 or so. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- An operating system design that requires a system reboot in order to install a document viewing utility does not earn my respect. --- 15 days until The 231st anniversary of the Declaration of Independence
Re: Any way to bypass authenticated users?
On Tue, Jun 19, 2007 at 05:02:28PM -0700, John D. Hardin wrote: Q'n'D: look at what a Received: header generated by your box for an authenticated client looks like, and write a header rule to match it, and score that rule -20 or so. Even better: set that rule to shortcircuit. Best: configure your mail system to not call SA for people that you don't want scanned (this is not the best place to ask though since it's a mail server/milter question). -- Randomly Selected Tagline: The only time a dog gets complimented is when he doesn't do anything. -- C. Schulz pgpdcSWPZaaX8.pgp Description: PGP signature
Re: ImageInfo in two .pre files
On Tuesday 19 June 2007 4:44 am, Duane Hill wrote: On Mon, 18 Jun 2007, Chris wrote: I happened to notice that I had the above plugin uncommented in v312.pre and v320.pre. I haven't noticed any problems but could this cause the plugin to be loaded twice? I have SA v3.2 running here and only show ImageInfo in v320.pre. I would think you would be able to safely remove it from v312.pre. Had you added the plugin before upgrading to v3.2.x? Yes, I'd added it quite a while back, not sure when but it was last year sometime. -- Chris KeyID 0xE372A7DA98E6705C pgpMtIDyEUFVF.pgp Description: PGP signature
