hostkarma false positive
Another FP on hostkarma: bsmtp5.bon.at[195.3.86.187] Please investigate and fix. And put them on YELLOW, they are an ISP here in Austria. Please check bsmtp[1-9] also. -- mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services http://it-management.at Tel: 0660 / 415 65 31 // Wir haben zwei Häuser zu verkaufen: // http://zmi.at/langegg/ // http://willhaben.at/iad/realestate/object?adId=15306857 signature.asc Description: This is a digitally signed message part.
Re: hostkarma false positive
On 11.1.2010 10:35, Michael Monnerie wrote: Another FP on hostkarma: bsmtp5.bon.at[195.3.86.187] Please investigate and fix. And put them on YELLOW, they are an ISP here in Austria. Please check bsmtp[1-9] also. Hello. Your PGP key has expired, my software says. Just FYI. -- http://www.iki.fi/jarif/ You will step on the night soil of many countries. signature.asc Description: OpenPGP digital signature
Re: hostkarma false positive
On Mon, 11 Jan 2010 09:35:37 +0100 Michael Monnerie michael.monne...@is.it-management.at wrote: Another FP on hostkarma: bsmtp5.bon.at[195.3.86.187] Please investigate and fix. And put them on YELLOW, they are an ISP here in Austria. Please check bsmtp[1-9] also. It's also listed in: 195.3.86.187BLACKLISTED:ips.backscatterer.org -- Multi-platform Freeware IP Blacklist checker http://www.spampig.org.uk/dnsblcheck.php
pill image spam learns to walk
Hi there We've been getting a few of these leaking through in the past couple of weeks. http://pastebin.com/m574da717 They aren't triggering (enough) network rule matches, contain a bayes-killer, and even FuzzyOCR can't manage the swirly image trick they pull. Has anyone come up with a way to fight these? (I've actually added all the phrases that occur in this image to FuzzyOCR - didn't help) Thanks -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: Documentation spamc -L is wrong
On Sunday January 10 2010 09:06:21 Cecil Westerhof wrote: Later on in the manpage it says: EXIT CODES By default, spamc will use the 'safe fallback' error recovery method. That means, it will always exit with an exit code if 0, even if an error was encountered. If any error occurrs, it will simply pass through the unaltered message. The -c and -E options modify this; instead, spamc will use an exit code of 1 if the message is determined to be spam. It looks like this is correct and the earlier statement not. Would the following change to spamc.pod make it correct? =item B-L Ilearn type, B--learntype=Itype Send message to spamd for learning. The Clearn type can be either spam, ham or forget. The exitcode for spamc will be set to 5 if the message -was learned, or 6 if it was already learned. +was learned, or 6 if it was already learned, under a condition that +a B--no-safe-fallback option is selected too. Mark
Re: pill image spam learns to walk
- Mike Cardwell spamassassin-us...@lists.grepular.com wrote: | On 11/01/2010 10:22, Jason Haar wrote: | Hi there | | We've been getting a few of these leaking through in the past couple | of | weeks. | | http://pastebin.com/m574da717 | | They aren't triggering (enough) network rule matches, contain a | bayes-killer, and even FuzzyOCR can't manage the swirly image trick | they | pull. Has anyone come up with a way to fight these? (I've actually | added | all the phrases that occur in this image to FuzzyOCR - didn't help) | | I just copied and pasted that out of pastebin into a little project | I've | been working on. Here's the result: | | http://spamalyser.com/v/6xnb26gp/mime | | Unlike with pastebin, it mime decodes emails and you can see the | decoded | image at the bottom of that page. | That is awesome, Mike! really helps to visualise. -- Thanks - Phil
Re: hostkarma false positive
Folks, can you please report this to these lists. This mailing list is *not* for reporting FPs on RBLs! Thanks. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: About upgrading
From: Alex mysqlstud...@gmail.com Date: Sat, 9 Jan 2010 21:13:24 -0500 sa-learn --dump magic gives: 0.000 0 3 0 non-token data: bayes db version 0.000 0 57538 0 non-token data: nspam 0.000 0 74876 0 non-token data: nham 0.000 0 166338 0 non-token data: ntokens 0.000 0 1257478501 0 non-token data: oldest atime 0.000 0 1263049426 0 non-token data: newest atime 0.000 0 1263049538 0 non-token data: last journal sync atime 0.000 0 1263044805 0 non-token data: last expiry atime 0.000 0 5529600 0 non-token data: last expire atime delta 0.000 0 1868 0 non-token data: last expire reduction count Your database has 166338 tokens which is larger than the default bayes_expiry_max_db_size 15. The last expiration ran this morning at 8:46. You could try letting the bayes database get larger and turn off bayes_auto_expire. If you turn off bayes_auto_expire you'll have to add something to cron to periodically expire tokens. bayes_auto_expire is fine for lower volumes of email, but can get in the way with higher volumes. Also, what is the drawback with using auto_expire on larger volumes? Is it the locking delay and preventing learning new messages during that time? If you were to put it in cron to manually do an expiry, how often should it be run? You have an exclusive lock when doing expiration. Expiration presumably takes longer on larger volumes, but it is still pretty fast. Running expiration daily or weekly should be more than sufficient. Is there anything that should be tested prior to making this change, or is it pretty benign? Yes - turning off bayes_auto_expire is pretty benign. You may not need to make this type of change. The default options for bayes work fine for lower email volumes. I suppose you could take the ntokens value before, and subtract it from the after value to see how many tokens were expired, right? It would be interesting to see how many tokens are expired on a regular basis, but not sure that's very useful, just interesting. sa-learn tells how many tokens were deleted you when you do --force-expire, for example: expired old bayes database entries in 152 seconds 1516428 entries kept, 115692 deleted token frequency: 1-occurrence tokens: 73.76% token frequency: less than 8 occurrences: 16.19% -jeff
Re: pill image spam learns to walk
scores these new tests on 3.3.0 * 1.0 FORGED_TBIRD_IMG_SIZE Likely forged Thunderbird image spam * 1.0 FORGED_TBIRD_IMG_ARROW Likely forged Thunderbird image spam and you could add, say 4.0, for each mail coming thru your SF.net alias and not coming from SF. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: hostkarma false positive
Fixed Michael Monnerie wrote: Another FP on hostkarma: bsmtp5.bon.at[195.3.86.187] Please investigate and fix. And put them on YELLOW, they are an ISP here in Austria. Please check bsmtp[1-9] also.
Re: hostkarma false positive
Christian Brel wrote: On Mon, 11 Jan 2010 09:35:37 +0100 Michael Monnerie michael.monne...@is.it-management.at wrote: Another FP on hostkarma: bsmtp5.bon.at[195.3.86.187] Please investigate and fix. And put them on YELLOW, they are an ISP here in Austria. Please check bsmtp[1-9] also. It's also listed in: 195.3.86.187BLACKLISTED:ips.backscatterer.org Backscatterer.org isn't a real blacklist. They have us blacklisted as well. Anyone using them is making a serious mistake.
Re: pill image spam learns to walk
On Mon, 11 Jan 2010, Mike Cardwell wrote: : I just copied and pasted that out of pastebin into a little project I've : been working on. Here's the result: : http://spamalyser.com/v/6xnb26gp/mime Question: What does spamalyzer do with an HTML message part? It is of concern (naturally) that implanted malicious scripts not be rendered whole and complete - C
Re: hostkarma false positive
On Mon, 2010-01-11 at 06:46 -0800, Marc Perkel wrote: Christian Brel wrote: It's also listed in: 195.3.86.187BLACKLISTED:ips.backscatterer.org Backscatterer.org isn't a real blacklist. They have us blacklisted as well. Anyone using them is making a serious mistake. It's probably worth a point or so for blocking useless bounces: meta RCVD_IN_BACKSCATTER_RELAY (__BOUNCE_FROM_DAEMON __RCVD_IN_BACKSCATTER) ! __RCVD_IN_UCEWHITE tflags RCVD_IN_BACKSCATTER_RELAYnet describe RCVD_IN_BACKSCATTER_RELAY received from a host that does a lot of backscatter score RCVD_IN_BACKSCATTER_RELAY 1.30 -- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX www.austinenergy.com
Re: hostkarma false positive
On Mon, 11 Jan 2010 06:46:55 -0800 Marc Perkel m...@perkel.com wrote: Christian Brel wrote: On Mon, 11 Jan 2010 09:35:37 +0100 Michael Monnerie michael.monne...@is.it-management.at wrote: Another FP on hostkarma: bsmtp5.bon.at[195.3.86.187] Please investigate and fix. And put them on YELLOW, they are an ISP here in Austria. Please check bsmtp[1-9] also. It's also listed in: 195.3.86.187BLACKLISTED:ips.backscatterer.org Backscatterer.org isn't a real blacklist. They have us blacklisted as well. Anyone using them is making a serious mistake. mus...t try and resist tem..tation.. Neither is the rest of UCEProtect... Damn it came out, I tried to stop it..
Re: pill image spam learns to walk
On 11/01/2010 14:55, Charles Gregory wrote: On Mon, 11 Jan 2010, Mike Cardwell wrote: : I just copied and pasted that out of pastebin into a little project I've : been working on. Here's the result: : http://spamalyser.com/v/6xnb26gp/mime Question: What does spamalyzer do with an HTML message part? It is of concern (naturally) that implanted malicious scripts not be rendered whole and complete Presently it renders them as plain text. I'm fully aware of the potential problems with it. Ideally I'd like to be able to render those parts as HTML, but I need to be 100% sure that I've stripped out anything dangerous (including embedded remote content by default) first. It's on the ToDo List page. I'm also aware of the issues surrounding people potentially uploading images and then linking to them from spam websites or spam. That's why I've put http referer restrictions in place. -- Mike Cardwell: UK based IT Consultant, LAMP developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/blog/ Spamalyser : Spam Tool - http://spamalyser.com/
REMINDER: 3.3.0 final cut January 15th, 2010
This is a reminder that the 3.3.0 final cut is scheduled for Friday, January 15th. http://tinyurl.com/yd8n96m Please review the bugs. Only priority P1 bugs are considered blockers for 3.3.0. Warren Togami wtog...@redhat.com On 12/29/2009 07:27 AM, Justin Mason wrote: +1. I expect there'll be a lot more tickets at that point, but that happens every release; most SA users tend to wait for the GA. --j. On Mon, Dec 28, 2009 at 00:44, Warren Togamiwtog...@redhat.com wrote: I would like to propose a cut date for 3.3.0 final release. Friday, January 15th, 2010 would give us a total of 3 weeks of validation of 3.3.0-rc1. At that point we will cut a proposed tarball for 3.3.0 and and call for the 3 votes necessary for release. http://tinyurl.com/yd8n96m Bugs targeting 3.3.0, P1 priority are considered release blockers. Please promote additional bugs to P1 if you believe they must be fixed before release. Any objections to this proposed cut date? Warren Togami wtog...@redhat.com
spamassassin bug
At the suggestion of a local user I ran 'sa-update -D' to bring my Slackware-12.2 system running SA-3.2.5 up to date. Instead, I just dug myself a hole and fell in by running the above. Sigh. What I see as a result is: [6753] error: check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. My Google search found one thread on this subject from 2007, but he was running amavisd, too, and it could not find the *.pre files. No help for me there. In /etc/mail/spamassassin/rules/ I have init.pre, v310.pre, and v312.pre files. SA has been running so I am totally clueless why this attempted update finds an error that prevents /usr/bin/spamd from starting again. Perhaps someone here can tell me how to resolve this problem so I can once again invoke spamd. Rich
Re: spamassassin bug
On 01/11/2010 11:07 AM, Rich Shepard wrote: At the suggestion of a local user I ran 'sa-update -D' to bring my Slackware-12.2 system running SA-3.2.5 up to date. Instead, I just dug myself a hole and fell in by running the above. Sigh. What I see as a result is: [6753] error: check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. My Google search found one thread on this subject from 2007, but he was running amavisd, too, and it could not find the *.pre files. No help for me there. In /etc/mail/spamassassin/rules/ I have init.pre, v310.pre, and v312.pre files. SA has been running so I am totally clueless why this attempted update finds an error that prevents /usr/bin/spamd from starting again. Perhaps someone here can tell me how to resolve this problem so I can once again invoke spamd. Rich Try wiping out /var/lib/spamassassin/*, does spamassassin work then? Warren
Re: spamassassin bug
On Mon, 11 Jan 2010, Warren Togami wrote: Try wiping out /var/lib/spamassassin/*, does spamassassin work then? Warren, I don't have a spamassassin directory in /var/lib/. Rich
Re: spamassassin bug
Quoting Rich Shepard rshep...@appl-ecosys.com: On Mon, 11 Jan 2010, Warren Togami wrote: Try wiping out /var/lib/spamassassin/*, does spamassassin work then? Warren, I don't have a spamassassin directory in /var/lib/. Rich Sorry but I must insert a smiley... :)
Re: About upgrading
Hi, Thanks for the information on bayes and sa-learn. Very helpful. Best, Alex I suppose you could take the ntokens value before, and subtract it from the after value to see how many tokens were expired, right? It would be interesting to see how many tokens are expired on a regular basis, but not sure that's very useful, just interesting. sa-learn tells how many tokens were deleted you when you do --force-expire, for example: expired old bayes database entries in 152 seconds 1516428 entries kept, 115692 deleted token frequency: 1-occurrence tokens: 73.76% token frequency: less than 8 occurrences: 16.19% -jeff
Re: pill image spam learns to walk
On 01/11/2010 05:22 AM, Jason Haar wrote: Hi there We've been getting a few of these leaking through in the past couple of weeks. http://pastebin.com/m574da717 They aren't triggering (enough) network rule matches, contain a bayes-killer, and even FuzzyOCR can't manage the swirly image trick they pull. Has anyone come up with a way to fight these? (I've actually added all the phrases that occur in this image to FuzzyOCR - didn't help) Unless you changed the headers, it looks like it came from an IP with no reverse DNS entry. This is easy enough to stop dead in it's tracks at your MTA. If there isn't any reverse DNS, the chances of it being a legitimate mail server are pretty slim. Terry
Re: spamassassin bug
Rich Shepard wrote on Mon, 11 Jan 2010 08:07:40 -0800 (PST): In /etc/mail/spamassassin/rules/ I have init.pre, v310.pre, and v312.pre files. which would be a non-default location. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Hi, Unless you changed the headers, it looks like it came from an IP with no reverse DNS entry. This is easy enough to stop dead in it's tracks at your MTA. If there isn't any reverse DNS, the chances of it being a legitimate mail server are pretty slim. Yes, but not enough to categorically block all incoming mail based on that, though. At least in my environment, all it would take is one customer to call and complain, and force me to have to do even more work to make them an exception and exclude them from this filter. Thanks, Alex
Re: pill image spam learns to walk
HI, * 1.0 FORGED_TBIRD_IMG_SIZE Likely forged Thunderbird image spam * 1.0 FORGED_TBIRD_IMG_ARROW Likely forged Thunderbird image spam and you could add, say 4.0, for each mail coming thru your SF.net alias and not coming from SF. Just to clarify, you're referring to this, right: Received: from mx.sourceforge.net by mailsrv1.trimble.co.nz (envelope-from f...@ef- How would add the rule you are suggesting? It would be specific to sourceforge.net, and have a table where its authoritative IP and MX are stored, right? Thanks, Alex
Re: pill image spam learns to walk
Terry Carmen wrote: On 01/11/2010 05:22 AM, Jason Haar wrote: Hi there We've been getting a few of these leaking through in the past couple of weeks. http://pastebin.com/m574da717 They aren't triggering (enough) network rule matches, contain a bayes-killer, and even FuzzyOCR can't manage the swirly image trick they pull. Has anyone come up with a way to fight these? (I've actually added all the phrases that occur in this image to FuzzyOCR - didn't help) Unless you changed the headers, it looks like it came from an IP with no reverse DNS entry. This is easy enough to stop dead in it's tracks at your MTA. If there isn't any reverse DNS, the chances of it being a legitimate mail server are pretty slim. This is the WRONG way to do this - it amazes me that in 2010 on an anti-spam mailing list that we have people making such statements. The SMTP RFC 2821 does NOT mandate the existence of a PTR record for an SMTP sender. The DNS RFC 1912 also does not mandate a corresponding PTR for a mailserver hostname. Implies, yes, but there's no requirement. There is a very good reason for this.* Blocking at the MTA based on the lack of a PTR record is incorrect. The correct way is to assign a spam score in SA to hosts lacking a PTR, the same way you do to mail that contains HTML, etc. Ted * The reason this is NOT mandated anywhere is because if it was then sites running multiple mailing domains on a single server could easily overflow the DNS UDP packet space with a list of PTR's for the server - causing the resolver to exceed 512 bytes on the DNS UDP response, or causing a switch to TCP - either of which can break some firewalls. For example the Cisco PIX came standard out-of-the-box with a DNS filter that blocked DNS UDP packets larger than 512.
Re: pill image spam learns to walk
On 01/11/2010 12:42 PM, Ted Mittelstaedt wrote: Terry Carmen wrote: On 01/11/2010 05:22 AM, Jason Haar wrote: Hi there We've been getting a few of these leaking through in the past couple of weeks. http://pastebin.com/m574da717 They aren't triggering (enough) network rule matches, contain a bayes-killer, and even FuzzyOCR can't manage the swirly image trick they pull. Has anyone come up with a way to fight these? (I've actually added all the phrases that occur in this image to FuzzyOCR - didn't help) Unless you changed the headers, it looks like it came from an IP with no reverse DNS entry. This is easy enough to stop dead in it's tracks at your MTA. If there isn't any reverse DNS, the chances of it being a legitimate mail server are pretty slim. This is the WRONG way to do this - it amazes me that in 2010 on an anti-spam mailing list that we have people making such statements. The SMTP RFC 2821 does NOT mandate the existence of a PTR record for an SMTP sender. The DNS RFC 1912 also does not mandate a corresponding PTR for a mailserver hostname. Implies, yes, but there's no requirement. There is a very good reason for this.* Blocking at the MTA based on the lack of a PTR record is incorrect. The correct way is to assign a spam score in SA to hosts lacking a PTR, the same way you do to mail that contains HTML, etc. SA is great software, but scanning is not a lightweight process. If I can ditch millions of spams before they ever hit SA, and need to manually whitelist a couple of IPs, that's a great deal as far as I'm concerned. Every reasonable ISP I've seen has managed to assign a PTR record for their mail server. I don't care if it exactly every (or any) domain they transport mail for, as long as it exists. Sure, it's possible to break things if you work at it hard enough, but generally speaking, I don't care. Terry
Re: pill image spam learns to walk
On 01/11/2010 12:57 PM, Terry Carmen wrote: exactly every (or any) domain Should be exactly *matches* every (or any) domain -- Terry Carmen CNY Support, LLC 315.382.3939 http://cnysupport.com
Re: spamassassin bug
On Mon, 11 Jan 2010, Kai Schaetzl wrote: In /etc/mail/spamassassin/rules/ I have init.pre, v310.pre, and v312.pre files. which would be a non-default location. Kai, Almost all SA-related files are in /etc/mail/spamassassin/; that's where the Slackware package installs everything. If this is a non-default location, where should they be? FWIW, that's were everything's been for years and I've had no problems until yesterday when running sa-learn kicked up that error. Thanks, Rich
Re: spamassassin bug
Quoting Rich Shepard rshep...@appl-ecosys.com: On Mon, 11 Jan 2010, Kai Schaetzl wrote: In /etc/mail/spamassassin/rules/ I have init.pre, v310.pre, and v312.pre files. which would be a non-default location. Kai, Almost all SA-related files are in /etc/mail/spamassassin/; that's where the Slackware package installs everything. If this is a non-default location, where should they be? FWIW, that's were everything's been for years and I've had no problems until yesterday when running sa-learn kicked up that error. Thanks, Rich find / -name spamassassin -print
Re: spamassassin bug
On Mon, 11 Jan 2010, David Michaels wrote: find / -name spamassassin -print /etc/mail/spamassassin /etc/mail/spamassassin/blib/script/spamassassin /etc/mail/spamassassin/spamassassin /opt/src/slackbuilds/spamassassin /usr/bin/spamassassin /usr/share/spamassassin Rich
Re: spamassassin bug
On Mon 11 Jan 2010 07:01:04 PM CET, Rich Shepard wrote In /etc/mail/spamassassin/rules/ I have init.pre, v310.pre, and v312.pre files. which would be a non-default location. Almost all SA-related files are in /etc/mail/spamassassin/; that's where the Slackware package installs everything. If this is a non-default rules dir error location, where should they be? FWIW, that's were everything's been for years and I've had no problems until yesterday when running sa-learn kicked up that error. spamassassin 21 -D --lint | less -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: spamassassin bug
On Mon, 11 Jan 2010, Benny Pedersen wrote: rules dir error Benny, Should I copy the .pre files to /usr/share/spamassassin? spamassassin 21 -D --lint | less I can post the results, but the final error still is: check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. What plugin do I need to have loaded to resolve this error? Rich
Re: About upgrading
On Mon, 11 Jan 2010 08:54:20 -0500 Jeff Mincy j...@delphioutpost.com wrote: You have an exclusive lock when doing expiration. Expiration presumably takes longer on larger volumes, but it is still pretty fast. Running expiration daily or weekly should be more than sufficient. AFAIK the exclusive lock is only against learning and database maintenance operations (sync, backup, etc), at least that's my experience based on what happens when stale lockfiles get left-behind. Mail continues to get processed by spamd, and gets classified by Bayes - the only difference is that you see autolearn=unavailable in the X-SPAM-STATUS header. There's no reason to lock bayes completely because expiry writes-out a new database file and does a swap-over. And because the writes go to a different db file they don't even interfere with spamd read-locking (in some cases it might even speed-up spamd as it turns-off autolearning). I do wonder whether there's any real-basis to the idea that autoexpiry isn't industrial-strength. I don't use expiry any more, but when I did, it didn't seem like a big deal at 200,000 tokens, and it's O(N) so millions of tokens shouldn't be too bad either.
Fake mailing list spam
Since I, like I suppose a lot of people, exempt mailing lists from spam checks, I've seen a lot of these messages getting through in the last few days: http://pastebin.com/m499e172e I have been bouncing these to gmail, but I know that's useless. Not sure what do do since I don't want to scan mailing-lists. -- Anybody who tells me what happens to me after I'm dead is either a liar or a fool because they DON'T KNOW --Stephen Fry
Re: spamassassin bug
On Mon 11 Jan 2010 08:07:12 PM CET, Rich Shepard wrote Should I copy the .pre files to /usr/share/spamassassin? no do not copy, edit the files in there place where thay got installed spamassassin 21 -D --lint | less I can post the results, but the final error still is: check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. What plugin do I need to have loaded to resolve this error? where is your pre files located ? if thay are in /etc/mail/spamassassin/rules ? output from --lint tells where thay should be the above error says me you dont have any pre files loaded at all check plugin is optional, but some code have it required, this might be a bug ?, others please comment on this here also in less press s for save and pastebinn it if more help is needed -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Fake mailing list spam
On Mon 11 Jan 2010 08:19:13 PM CET, LuKreme wrote I have been bouncing these to gmail, but I know that's useless. Not sure what do do since I don't want to scan mailing-lists. send this mail to maillist-owner and or abuse at google, seem this maillist have a spammer connected on this maillist where you recieve the spam from a valid maillist at google, so report it as spam to them -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: spamassassin bug
On Mon, 11 Jan 2010, Benny Pedersen wrote: no do not copy, edit the files in there place where thay got installed Benny, OK. where is your pre files located ? if thay are in /etc/mail/spamassassin/rules ? /etc/mail/spamassassin/rules output from --lint tells where thay should be I don't see this: [r...@salmo /etc/postfix]# spamassassin --lint [22649] warn: netset: cannot include 127.0.0.1/32 as it has already been included check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. the above error says me you dont have any pre files loaded at all What do I do to load them? Thanks, Rich
RE: spamassassin bug
check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. What plugin do I need to have loaded to resolve this error? It looks like you are missing the v320.pre file, which contains loadplugin Mail::SpamAssassin::Plugin::Check along with several other important loadplugin lines.
RE: spamassassin bug
On Mon 11 Jan 2010 08:45:40 PM CET, Rosenbaum, Larry M. wrote check: no loaded plugin implements 'check_main': cannot scan! at /usr/lib/perl5/vendor_perl/5.10.0/Mail/SpamAssassin/PerMsgStatus.pm line 164. What plugin do I need to have loaded to resolve this error? It looks like you are missing the v320.pre file, which contains loadplugin Mail::SpamAssassin::Plugin::Check along with several other important loadplugin lines. mv /etc/mail/spamassassin/rules /etc/mail/spamassassin no ? installer build error maybe -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
RE: spamassassin bug
On Mon, 11 Jan 2010, Rosenbaum, Larry M. wrote: It looks like you are missing the v320.pre file, which contains Larry, Yes, that's true. I have v310.pre and v312.pre. loadplugin Mail::SpamAssassin::Plugin::Check along with several other important loadplugin lines. So I found and downloaded v320.pre into /etc/mail/spamassassin/rules and still get the error. What have I missed in getting SA to see the new .pre file is now present and calls for the check_main to be run? Thanks, Rich
RE: spamassassin bug -- RESOLVED!
On Mon, 11 Jan 2010, Benny Pedersen wrote: mv /etc/mail/spamassassin/rules /etc/mail/spamassassin no ? Benny: You and Larry gave me the solution. I found v320.pre and put it in /etc/mail/spamassassin/rules. Then, based on your suggestion above, I copied it up one directory level to /etc/mail/spamassassin. Now everything's working. It was the missing v320.pre file, and the .pre files need to be in /etc/mail/spamassassin and not the rules subdirectory. Many thanks to everyone! Rich
Re: Fake mailing list spam
On Jan 11, 2010, at 12:38, Benny Pedersen m...@junc.org wrote: google, seem this maillist have a spammer connected on this maillist where you recieve the spam from a valid maillist at google, so report it as spam to them I never subscribed to the list in question. I am, in fact, not subscribed to any googlelists on this account.
RE: spamassassin bug
On Mon, 11 Jan 2010, Rich Shepard wrote: So I found and downloaded v320.pre into /etc/mail/spamassassin/rules and still get the error. What have I missed in getting SA to see the new .pre file is now present and calls for the check_main to be run? Putting them into the rules subdirectory under /etc/mail/spamassassin does not sound right, as has been stated before. Benny _almost_ gave you the right thing to do. Try this: spamassassin --lint -D config (--lint by itself is quiet) and look for lines like this: [22650] dbg: config: using /etc/mail/spamassassin for site rules pre files [22650] dbg: config: read file /etc/mail/spamassassin/init.pre [22650] dbg: config: read file /etc/mail/spamassassin/v310.pre [22650] dbg: config: read file /etc/mail/spamassassin/v312.pre [22650] dbg: config: read file /etc/mail/spamassassin/v320.pre What do you get? -- 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 --- No representation without taxation! --- 6 days until Benjamin Franklin's 304th Birthday
exchange bounces from chrisrobin.hundredacrewood.local
Original-Envelope-ID: c=US;a= ;p=HUNDREDACREWOOD;l=CHRISROBIN-100111200457Z-1594 Reporting-MTA: dns; chrisrobin.hundredacrewood.local Final-Recipient: RFC822; imceaex-_o=hundredacrewood_ou=first+20administrative+20group_cn=recipients_cn=spamassassin849bbb2d4bc147862176109e81ca5068034...@willspc.net Action: failed Status: 5.1.1 X-Supplementary-Info: X-Display-Name: SpamAssassin seems a brokken exchange bounce back email from maillist ?, is the problem linux/windows cr/lf related ? (sa rules names as recipient in the above) or is it just to blame exchange here ? :) -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Fake mailing list spam
On Mon 11 Jan 2010 09:14:06 PM CET, LuKreme wrote google, seem this maillist have a spammer connected on this maillist where you recieve the spam from a valid maillist at google, so report it as spam to them I never subscribed to the list in question. I am, in fact, not subscribed to any googlelists on this account. so report that someone else have done it for you :) -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Fake mailing list spam
LuKreme wrote on Mon, 11 Jan 2010 13:14:06 -0700: I never subscribed to the list in question. I am, in fact, not subscribed to any googlelists on this account. Report the abuse to Google and reject any mail from @listserv.bounces.google.com So, Google allows non-opt-in mailing lists like Yahoo does. Great :-( I've got a few of these last year from several Yahoo mailing lists that had only been set up to spam. Mailing-list names just contained a few random characters and the target public seems to have been Chinese. I submitted several nasty comments via their reporting mechanism and it stopped after a few weeks. Don't know if they simply put my mail address on a no-go list or if they changed something with the lists or the spammer just stopped using them. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Terry Carmen wrote on Mon, 11 Jan 2010 12:08:16 -0500: Unless you changed the headers, it looks like it came from an IP with no reverse DNS entry. Yeah, his own delivery chain. Not really a candidate for blocking ;-) Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Ted Mittelstaedt wrote on Mon, 11 Jan 2010 09:42:25 -0800: This is the WRONG way to do this It's the right way. The FP rate is almost zero and it encourages the few offending ones to quickly add rDNS, really quick. * The reason this is NOT mandated anywhere is because if it was then sites running multiple mailing domains on a single server could easily overflow the DNS UDP packet space with a list of PTR's for the server - We are not talking about adding PTR for all domains, just for exactly *one*. And that doesn't even need to resolve back and forth. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: spamassassin bug -- RESOLVED!
How come that you messed this up with regards to that arbitrary rules directory? Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Alex wrote on Mon, 11 Jan 2010 12:38:29 -0500: Just to clarify, you're referring to this, right: Received: from mx.sourceforge.net by mailsrv1.trimble.co.nz (envelope-from f...@ef- How would add the rule you are suggesting? It would be specific to sourceforge.net, and have a table where its authoritative IP and MX are stored, right? I would rather look for To: *...@users.sourceforge.net and score if the From is not from sourceforge.net (meta-rule). This indicates that it is an external mail that was sent to an SF users alias. I've personally not ever gotten a legitimate mail to this alias from outside of SF (and I think SF admin/dev/news mail uses the target address directly, anyway, and not the alias). So, depending on what you get over this route you may either score or drop completely. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Fake mailing list spam
On Mon, 11 Jan 2010, LuKreme wrote: : I never subscribed to the list in question. I am, in fact, not : subscribed to any googlelists on this account. I'm not an expert on googlegroups headers, but these 'look right'. So I'm inclined to agree that this is just an abused group and not spam that is 'faking' being from the group. I would blacklist the specific group (List-ID: header should do the trick) and report the spam to Google. - Charles
Re: pill image spam learns to walk
Kai Schaetzl wrote: Ted Mittelstaedt wrote on Mon, 11 Jan 2010 09:42:25 -0800: This is the WRONG way to do this It's the right way. The FP rate is almost zero and it encourages the few offending ones to quickly add rDNS, really quick. * The reason this is NOT mandated anywhere is because if it was then sites running multiple mailing domains on a single server could easily overflow the DNS UDP packet space with a list of PTR's for the server - We are not talking about adding PTR for all domains, just for exactly *one*. And that doesn't even need to resolve back and forth. Clearly you fail to understand anything, here. PTR's are not mandated because the standard has to apply to all sites, both sites with multiple domains and sites without. It does not mean that because it's not mandated that it's a bad idea to add a PTR record. It simply means that sites WITHOUT a PTR are still fully compliant mailers. The entire point of SA is to filter based on fuzzy logic, meaning that the sender's mail is only wrong based on an arbitrary standard that the person running SA pulls out of their ass. A no PTR rule is EXACTLY the kind of fuzzy decision that SA is designed to make decisions on. That is where that kind of rule belongs. Your advice is kind of like the guy who puts a spoiler on a sports car that is never driven faster than 100mph. The spoiler, Spamassassin in this case, is an expensive, gas-mileage sucking dunsel that is only there because of the bragging rights the guy gets by having it there, it does absolutely nothing to help the car. In fact, anyone who knows anything about fast cars, looks at the thing and thinks how gay is that? and what a moron the idiot driving it is. If you want to build a mailserver WITHOUT SA, then sure, go ahead and add in rules like no PTR to the MTA - because you cannot do it any other way. But don't spend the money and CPU cycles putting SA on a mailserver and then have it sit there doing nothing, like that spoiler on the ass-end of a trans-am. In other words, be a professional not a bozo! Ted
Re: [sa] segmentation fault on startup
If it was me I'd build gdbm and then build perl 5.8.8 and make sure it's
only using gdbm, not Berkeley DB (if he has that on his system)
Ted
Charles Gregory wrote:
I don't know that it applies to specifically spamassassin, but I used to
run into considerable nuisance with seg faults on Solaris when the
parameters of scripts were a specific number of bytes - I think around
multiples of 32. So you might achieve joy by adjusting the length of a
filename somewhere on the path to spamassassin. Particularly where
invoking privileged ('op') processes.
Hope this helps!
- C
On Sun, 10 Jan 2010, Robert P. Weaver wrote:
: I am hoping someone can offer me some advice that will help
: resolve this problem.
:
:
:
: I recently installed SpamAssassin on my Solaris server with the
: intention of filtering the incoming email with procmail (I have a Postfix
: mail server). However I never got that far. When I first tested SpamAssassin
: it worked on the first invocation but failed with a segmentation fault on
: every subsequent invocation. I can make it work again by deleting the
: “.spamassassin” subdirectory in my home directory.
:
:
:
: Below is a bunch of diagnostic information including the fatal
: call (run with - -lint -D). Any help would be appreciated.
:
:
:
: Bob Weaver
:
: rwea...@mordor.org
:
:
:
: $ uname -a
:
: SunOS sauron 5.10 Generic_118822-11 sun4u sparc SUNW,UltraAX-i2
:
:
:
: $ perl -v
:
: This is perl, v5.8.7 built for sun4-solaris
:
:
:
: $ spamassassin -V
:
: SpamAssassin version 3.2.5
:
: running on Perl version 5.8.7
:
:
:
: The call:
:
:
:
: $ spamassassin -D --lint
:
: [28414] dbg: logger: adding facilities: all
:
: [28414] dbg: logger: logging level is DBG
:
: [28414] dbg: generic: SpamAssassin version 3.2.5
:
: [28414] dbg: config: score set 0 chosen.
:
: [28414] dbg: util: running in taint mode? yes
:
: [28414] dbg: util: taint mode: deleting unsafe environment variables,
: resetting PATH
:
: [28414] dbg: util: PATH included '/usr/local/bin', keeping
:
: [28414] dbg: util: PATH included '/usr/local/sbin', keeping
:
: [28414] dbg: util: PATH included '/usr/bin', keeping
:
: [28414] dbg: util: PATH included '/usr/sfw/bin', keeping
:
: [28414] dbg: util: PATH included '.', which is not absolute, dropping
:
: [28414] dbg: util: PATH included '/usr/sfw/sbin', keeping
:
: [28414] dbg: util: PATH included '/opt/sfw/bin', keeping
:
: [28414] dbg: util: PATH included '/opt/sfw/sbin', keeping
:
: [28414] dbg: util: PATH included '/usr/ccs/bin', keeping
:
: [28414] dbg: util: PATH included '/usr/openwin/bin',
: keeping
: [28414] dbg: util: final PATH set to:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sfw/bin:/usr/sfw/sbin:/opt/sfw
: /bin:/opt/sfw/s
:
: bin:/usr/ccs/bin:/usr/openwin/bin
:
: [28414] dbg: dns: no ipv6
:
: [28414] dbg: dns: is Net::DNS::Resolver available? yes
:
: [28414] dbg: dns: Net::DNS version: 0.65
:
: [28414] dbg: diag: perl platform: 5.008007 solaris
:
: [28414] dbg: diag: module installed: Digest::SHA1, version 2.12
:
: [28414] dbg: diag: module installed: HTML::Parser, version 3.64
:
: [28414] dbg: diag: module installed: Net::DNS, version 0.65
:
: [28414] dbg: diag: module installed: MIME::Base64, version 3.05
:
: [28414] dbg: diag: module installed: DB_File, version 1.811
:
: [28414] dbg: diag: module installed: Net::SMTP, version 2.31
:
: [28414] dbg: diag: module installed: Mail::SPF, version v2.007
:
: [28414] dbg: diag: module not installed: Mail::SPF::Query ('require' failed)
:
: [28414] dbg: diag: module installed: IP::Country::Fast, version 604.001
:
: [28414] dbg: diag: module not installed: Razor2::Client::Agent ('require'
: failed)
:
: [28414] dbg: diag: module not installed: Net::Ident ('require' failed)
:
: [28414] dbg: diag: module not installed: IO::Socket::INET6 ('require'
: failed)
:
: [28414] dbg: diag: module not installed: IO::Socket::SSL ('require' failed)
:
: [28414] dbg: diag: module installed: Compress::Zlib, version 2.023
:
: [28414] dbg: diag: module installed: Time::HiRes, version 1.66
:
: [28414] dbg: diag: module not installed: Mail::DomainKeys ('require' failed)
:
: [28414] dbg: diag: module not installed: Mail::DKIM ('require' failed)
:
: [28414] dbg: diag: module installed: DBI, version 1.609
:
: [28414] dbg: diag: module installed: Getopt::Long, version 2.34
:
: [28414] dbg: diag: module installed: LWP::UserAgent, version 5.834
:
: [28414] dbg: diag: module installed: HTTP::Date, version 5.831
:
: [28414] dbg: diag: module installed: Archive::Tar, version 1.54
:
: [28414] dbg: diag: module installed: IO::Zlib, version 1.10
:
: [28414] dbg: diag: module installed: Encode::Detect, version 1.01
:
: [28414] dbg: ignore: using a test message to lint rules
:
: [28414] dbg: config: using /etc/mail/spamassassin for site rules pre files
:
:
Re: pill image spam learns to walk - best way to block it - hostkarma
For what it's worth my Lunk Email Filter service block 100% of virus generated spam such as this pill image spam. But anyone can tap into this for free by doing 2 things. First - add tarbaby.junkemailfilter.com as you highest numbered MX record. Second - use the hostkarma.junkemailfilter.com black list. To be really effective you need to do both. Bot spam tends to spam all MX records and focuses on the highest MX. So using us as the highest MX lets us harvest your spam bot info. Then when you use our black list - it's tuned to the spambots that are spamming you. So it becomes even more effective. And spam attempts to our tarbaby server is a spam that you're not getting not need to use your resources to block. So a significant amount of your spam will just go away. We catch spam bots on the first attempt and within 2 minutes they are listed in our black list. Here's the info on these lists: http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists Feel free to use it.
Re: pill image spam learns to walk
Ted Mittelstaedt wrote on Mon, 11 Jan 2010 15:27:07 -0800: It simply means that sites WITHOUT a PTR are still fully compliant mailers. This has nothing to do with RFC-compliance, but with policy, well accepted policy. If you can't understand that I can't help. No need to shoot this out. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Kai Schaetzl wrote: Ted Mittelstaedt wrote on Mon, 11 Jan 2010 15:27:07 -0800: It simply means that sites WITHOUT a PTR are still fully compliant mailers. This has nothing to do with RFC-compliance, but with policy, well accepted policy. Policy that should be handled in SA and not the MTA, which I've said twice now. If you can't understand that I can't help. You cannot help someone when you have no real grasp of the topic under discussion. No need to shoot this out. Well, let's see. I say it is wrong to tell people to make PTR checks in the MTA when they have SA running, and to make them in SA. Then I explain why you shouldn't do them in the MTA and cite facts to back up my statements. You know you can't argue against facts, and you know your wrong, and rather than just man up and admit it, you try to cover it up by making the false claim that I am advising to not make PTR checks at all. You repeat this false claim multiple times to make yourself believe it, and maybe to attempt to get me to forget what I said, and adopt your false claim and start arguing for it. No wonder you don't want to get into a shooting match. You know you were caught, and your outgunned. Ted Kai
Re: pill image spam learns to walk
Jason Haar wrote: They aren't triggering (enough) network rule matches, contain a bayes-killer, and even FuzzyOCR can't manage the swirly image trick they pull. Has anyone come up with a way to fight these? Jason, thanks for the cheerful Subject. I needed that today. :) I'm catching all of these, with decent scores (15+). Here's a few easy things you might score on (up to about 2.5 each): 1. non-huge image which does _NOT_ have an HTML part (this will also help with the lonely girl spams; it's highly unusual for images to be attached to pure text emails; usually only Nerds send pure text, and our most typical image attachment is a GIF/PNG screenshot, or a somewhat large JPEG) 2. metas for images that have hit any reliable blocklist (I have found Barracuda very helpful - it definitely has a high FP rate, so score low if you don't have a decent false positives pipeline) 3. botnet test 4. metas for images sent from/thru unusual nations These may not be as easy, however may be of :) interest to our resident developers: 5. all of these have a real name in the From header, with most being a single word, which is very unusual (note also that _NONE_ have a real name in the To header, which I do score, but that has a high FP rate so I can not recommend it unless you have a solid FP pipeline) 6. size of the JPEG header (this may be easy to add to ImageInfo) I just noticed #6 now, after dumping some image properties for wavy vs non-wavy spam images, and was surprised by it. It never occurred to me to export file hdr size - by now, I :) should have KNOWN better, and should have added export of ALL properties to my image properties test last time this sort of thing happened. I'll fix that next version. :) Here's the properties of my last few days of wavy images: 1 MP#2(jpeg): Area=100804 Density=9.85 bytes=10854(hdr:623,dat:10231) (319x316) 1 MP#2(jpeg): Area=103152 Density=9.32 bytes=11688(hdr:623,dat:11065) (336x307) 1 MP#2(jpeg): Area=103206 Density=5.05 bytes=21045(hdr:623,dat:20422) (309x334) 1 MP#2(jpeg): Area=104304 Density=5.33 bytes=20176(hdr:623,dat:19553) (318x328) 1 MP#2(jpeg): Area=107584 Density=5.58 bytes=19896(hdr:623,dat:19273) (328x328) 1 MP#2(jpeg): Area=108072 Density=9.51 bytes=11982(hdr:623,dat:11359) (342x316) 1 MP#2(jpeg): Area=109472 Density=5.24 bytes=21501(hdr:623,dat:20878) (352x311) 1 MP#2(jpeg): Area= 81104 Density=4.40 bytes=19067(hdr:623,dat:18444) (296x274) 1 MP#2(jpeg): Area= 87809 Density=5.69 bytes=16064(hdr:623,dat:15441) (317x277) 1 MP#2(jpeg): Area= 95142 Density=5.41 bytes=18223(hdr:623,dat:17600) (303x314) 1 MP#2(jpeg): Area= 97148 Density=4.96 bytes=20208(hdr:623,dat:19585) (326x298) The interesting column is hdr:623. If you're using ImageInfo, the other numbers are useful for limiting your metas to the total size range typical of these. The first column is the number of occurrences. Here's the properties of all NON-wavy spam images from the same period: 3 MP#2(jpeg): Area=115062 Density= 4.36 bytes=27110(hdr:735,dat:26375) (254x453) 1 MP#2(jpeg): Area=120300 Density= 6.40 bytes=19185(hdr:387,dat:18798) (300x401) 2 MP#2(jpeg): Area=166410 Density=11.62 bytes=14700(hdr:383,dat:14317) (430x387) 1 MP#2(jpeg): Area=166704 Density= 8.55 bytes=19891(hdr:398,dat:19493) (453x368) 1 MP#2(jpeg): Area=197735 Density=13.10 bytes=15476(hdr:380,dat:15096) (355x557) 1 MP#2(jpeg): Area=240800 Density=14.59 bytes=16901(hdr:392,dat:16509) (700x344) 1 MP#3(jpeg): Area=197735 Density=13.10 bytes=15476(hdr:380,dat:15096) (355x557) 17 MP#3(jpeg): Area=239500 Density= 5.53 bytes=43685(hdr:406,dat:43279) (479x500) I dumped the last month's worth of ham image properties from my most diverse domain, and did find a handful which had that same hdr size (623), however they all had vastly different areas and/or occurred with multiple images. I'll check a few more domains and months' worth, before using that for real. I expect to score this in the 2 to 3 range. Mike Cardwell wrote: Presently it renders them as plain text. I'm fully aware of the potential problems with it. Ideally I'd like to be able to render those parts as HTML, but I need to be 100% sure that I've stripped out anything dangerous (including embedded remote content by default) first. It's on the ToDo List page. Nice job Mike! :) I wrestled with that same issue when I added direct viewing of HTML content to my offline analysis/FP-pipeline/MassChecks tool. Originally, I was using an ActiveX wrapper around IE, which (of course) made me nervous. I added some VERY simple, crude tag stripping (script, iframe, style), but was never happy with it. I ended up switching to an open source HTML rendering component which :) lacked support for all the scary stuff. Whatever you decide to do, please do post more about it, and q'pla! I'm also aware of the issues surrounding people potentially uploading images and then linking to them from
Re: Interesting Low Scoring SPAM with odd script
Christian Brel wrote: http://pastebin.com/m66a5a2ae Anyone seen script like that? Yeah, I saw a couple of those last week. /Per Jessen, Zürich
Re: spamassassin bug
On Mon, 11 Jan 2010, Warren Togami wrote: Try wiping out /var/lib/spamassassin/*, does spamassassin work then? On 11.01.10 08:28, Rich Shepard wrote: I don't have a spamassassin directory in /var/lib/. FreeBSD uses /var/db/spamassassin. Or do: # grep LOCAL_STATE_DIR `whichspamassassin spamd` -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer.
