Re: application/octet-stream Content-Type used to obfuscate terse .RTF spam

2009-06-01 Thread Bob Proulx
John Hardin wrote: Does this catch it? mimeheader __UNSPEC_BINARY_ATTACH Content-Type =~ /application\/octet-stream/i meta MIME_BINARY_ONLY (__CTYPE_MULTIPART_MXD __UNSPEC_BINARY_ATTACH !__ANY_TEXT_ATTACH) scoreMIME_BINARY_ONLY 2.00 describe MIME_BINARY_ONLY Unspecified

Re: Filtering through mailing lists

2009-06-01 Thread Matus UHLAR - fantomas
On 29.05.09 17:26, Garik wrote: I have a situation where by mail passes through a mailing list and then goes on to the destination mailbox that's subscribed in the mailing list. Here's my problem: SpamAssasin checks the emails going through the mailing list for SPAM and adds the subject

Re: application/octet-stream Content-Type used to obfuscate terse .RTF spam

2009-06-01 Thread Matus UHLAR - fantomas
On 31.05.09 21:25, Chip M. wrote: Mildly redacted sample posted here: http://puffin.net\software\spam\samples\0005_rtf.txt and the plain body, after decoding to plain text (purely for convenience): http://puffin.net\software\spam\samples\0005_body.txt Address Not Found

Re: twitter spam why RCVD_IN_DNSWL?

2009-06-01 Thread Michael Scheidell
On 28-May-2009, at 14:57, Michael Scheidell wrote: why does a company that is so easy to spam through get a -8 point pass? Because the only way to get a message from twitter is to 1) have an account on twitter 2) have someone who YOU ARE FOLLOWING send a direct message to you 3) have

Re: application/octet-stream Content-Type used to obfuscate terse .RTF spam

2009-06-01 Thread John Hardin
On Mon, 1 Jun 2009, Bob Proulx wrote: However playing wack-a-mole with each new type isn't productive. Perhaps this following, completely untested, would be the better way to go. Just look for any multipart message that doesn't have any text parts. That actually sounds best to me. -- John

Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
I'm running SA-3.2.5 on Slackware-12.2 and encountering false positives on messages that have not before been seen as spam by SA. Specifically, the daily postfix mail log summary report and the daily logwatch report are marked at spam; they are sent by root to me as a user. Because

Re: Identifying Source of False Positives

2009-06-01 Thread McDonald, Dan
On Mon, 2009-06-01 at 09:28 -0700, Rich Shepard wrote: I'm running SA-3.2.5 on Slackware-12.2 and encountering false positives on messages that have not before been seen as spam by SA. Specifically, the daily postfix mail log summary report and the daily logwatch report are marked at spam;

Re: Identifying Source of False Positives

2009-06-01 Thread Charles Gregory
On Mon, 1 Jun 2009, Rich Shepard wrote: messages that have not before been seen as spam by SA. Specifically, the daily postfix mail log summary report and the daily logwatch report are marked at spam; Well, firstly, examine the mail full headers. There should be an X-Spam-Status header listing

Re: Identifying Source of False Positives

2009-06-01 Thread John Hardin
On Mon, 1 Jun 2009, Rich Shepard wrote: I'm running SA-3.2.5 on Slackware-12.2 and encountering false positives on messages that have not before been seen as spam by SA. Specifically, the daily postfix mail log summary report and the daily logwatch report are marked at spam; they are sent by

sa-update not updating since March 30.

2009-06-01 Thread Ernie Dunbar
We have a cron job that runs every day to update the spamassassin rules, but there have been no new updates since March 30. When I run it manually with the -D (debug) flag, I get this output: [24667] dbg: logger: adding facilities: all [24667] dbg: logger: logging level is DBG [24667] dbg:

Re: sa-update not updating since March 30.

2009-06-01 Thread John Hardin
On Mon, 1 Jun 2009, Ernie Dunbar wrote: We have a cron job that runs every day to update the spamassassin rules, but there have been no new updates since March 30. That's because there haven't been any updates recently. There's no firm schedule for releases of updates. -- John Hardin

Re: sa-update not updating since March 30.

2009-06-01 Thread McDonald, Dan
On Mon, 2009-06-01 at 11:26 -0700, Ernie Dunbar wrote: We have a cron job that runs every day to update the spamassassin rules, but there have been no new updates since March 30. Correct. updates_spamassassin_org has not been updated since March 30. I have seen updates on

Re: Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
On Mon, 1 Jun 2009, Charles Gregory wrote: Well, firstly, examine the mail full headers. There should be an X-Spam-Status header listing the tests that matched on the e-mail. Charles/Dan/John: I certainly managed to forget this. I just ran /etc/cron.daily/1pflogsumm and looked at the

Re: sa-update not updating since March 30.

2009-06-01 Thread Ernie Dunbar
John Hardin wrote: On Mon, 1 Jun 2009, Ernie Dunbar wrote: We have a cron job that runs every day to update the spamassassin rules, but there have been no new updates since March 30. That's because there haven't been any updates recently. There's no firm schedule for releases of

Re: sa-update not updating since March 30.

2009-06-01 Thread John Hardin
On Mon, 1 Jun 2009, Ernie Dunbar wrote: John Hardin wrote: On Mon, 1 Jun 2009, Ernie Dunbar wrote: We have a cron job that runs every day to update the spamassassin rules, but there have been no new updates since March 30. That's because there haven't been any updates recently. There's no

Re: [sa] Re: Identifying Source of False Positives

2009-06-01 Thread Charles Gregory
On Mon, 1 Jun 2009, Rich Shepard wrote: * 2.5 EMPTY_BODY BODY: Message has subject but no body There is certainly body content in the message; it's not empty so I don't understand the 2.5 on that third test. I also don't know where the 3.5 on the second test arises. Just to be

Re: Identifying Source of False Positives

2009-06-01 Thread John Hardin
On Mon, 1 Jun 2009, Rich Shepard wrote: Here are the headers: From r...@salmo.appl-ecosys.com Mon Jun 1 11:25:44 2009 Return-Path: r...@salmo.appl-ecosys.com X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.2.5-ph20040310.0 (2008-06-10) on salmo.appl-ecosys.com X-Spam-Level:

Re: [sa] Re: Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
On Mon, 1 Jun 2009, Charles Gregory wrote: Just to be clear, are you looking at the body in the actual rejected message, Charles, Yes. The body consists of the mail log summary. First guess, look at the procmail code that 'chooses' to run spamassassin. Have you used an 'h' where you

Re: Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
On Mon, 1 Jun 2009, John Hardin wrote: If these are system-generated messages, something is improperly training SA that they are spam. Do you use autolearn? John, No. Once a week or so I run sa-learn specifying spam on the spam-uncaught mbox file. Less frequently I run it on mail list

Re: Identifying Source of False Positives

2009-06-01 Thread Bowie Bailey
Rich Shepard wrote: Here are all headers from the mail log summary: From r...@salmo.appl-ecosys.com Mon Jun 1 11:25:44 2009 Return-Path: r...@salmo.appl-ecosys.com X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.2.5-ph20040310.0 (2008-06-10) on salmo.appl-ecosys.com X-Spam-Level:

Re: Identifying Source of False Positives

2009-06-01 Thread John Hardin
On Mon, 1 Jun 2009, Rich Shepard wrote: On Mon, 1 Jun 2009, John Hardin wrote: If these are system-generated messages, something is improperly training SA that they are spam. Do you use autolearn? John, No. Once a week or so I run sa-learn specifying spam on the spam-uncaught mbox file.

Re: [sa] Re: Identifying Source of False Positives

2009-06-01 Thread Charles Gregory
First guess, look at the procmail code that 'chooses' to run spamassassin. Have you used an 'h' where you meant to use an 'H', thereby feeding *only* the header to spamassassin? ## Call SpamAssassin : 0fw: spamassassin.lock * 256000 | spamassassin Is there anywhere in the procmail

Re: [sa] Re: Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
On Mon, 1 Jun 2009, Charles Gregory wrote: Is there anywhere in the procmail recipe *above* this one that some specila condition has been specified as: :0fwh ...which has the effect of 'filtering' the message down to just its headers? It wouldn't necessarily have to be a recent change to

Re: Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
On Mon, 1 Jun 2009, Bowie Bailey wrote: Your biggest problems here are BAYES_99 and EMPTY_BODY. To fix the Bayes problem, sa-learn some of these messages as ham. Make sure you are learning as the right user... Bowie, I just did this on a run from this morning. I'll do so again tomorrow

Re: Identifying Source of False Positives

2009-06-01 Thread Theo Van Dinter
fwiw, even if there isn't a blank line, SA will figure it out (though it'll trigger a MISSING_HB_SEP rule hit). As for the debug output ... it depends, how did you run the command (ie: what was the command you tried). My guess is you did something like spamassassin -D filename, where filename

Re: Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
On Mon, 1 Jun 2009, John Hardin wrote: And I assume you look at the sapm-uncaught file before learning it? Yes. The messages in there are those I deliberately move there after they've ended up in my inbox because neither the postfix filters nor the spamassassin rules caught them. If some

Re: Identifying Source of False Positives

2009-06-01 Thread Rich Shepard
On Mon, 1 Jun 2009, Theo Van Dinter wrote: My guess is you did something like spamassassin -D filename, where filename gets treated as the argument to -D, so then it was waiting for input. Theo, Yes, this is what I did. If this is the case, try spamassassin -D filename /dev/null. :)

Re: Identifying Source of False Positives

2009-06-01 Thread John Hardin
On Mon, 1 Jun 2009, Rich Shepard wrote: On Mon, 1 Jun 2009, John Hardin wrote: Have you kept your spam and ham corpa? I'm not sure. The spam comes from the spam-uncaught file which is cleared each time it's run. Pity. If you're manually training it's a very good idea to retain your

Re: Plugin/TVD.pm

2009-06-01 Thread Philip Prindeville
Yup, that's the beast. Missed the news that it had become part of 3.2. Excellent. Thanks. Theo Van Dinter wrote: That depends, what's TVD.pm? ;) Doing a quick search shows http://mail-archives.apache.org/mod_mbox/spamassassin-users/200603.mbox/%3c20060316233124.gv22...@kluge.net%3e which

Re: twitter spam why RCVD_IN_DNSWL?

2009-06-01 Thread LuKreme
On 1-Jun-2009, at 05:52, Michael Scheidell wrote: I don't follow anyone on twitter. Went to their web site for the first time last week to look for their complaint address. I've never seen a mail from twitter that was not directed to my twitter account. I searched the entire mailspool for