You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Daniel Draes <da...@draes.net> on 2005/02/15 19:30:33 UTC
Wierd Problem identifying Spam
Hi folks,
I ahve a pretty wierd problem here and cannot figure out why.
Here is my system:
SuSe 9.2
Postfix 2.0.19
SpamAssassin 2.64
SA is runnung as deamon, and postfix is connecting correctly to the
assigned TCP port.
Here is what happens:
SA gets the mail and checks it nicely. However, applying points to the
mail seems to fail somehow. For example I have mails where the subjects
will be rewritten according my confing with '*****SPAM*****' but the
SA-Spam-Status Flag states:
No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham
version=2.64
The mail itself however says:
Content analysis details: (7.8 points, 5.0 required)
So having a procmail-rule for X-Spam-Level doesn't really help.
Any ideas whats wrong with my setup?
THX!
Daniel
Re: Wierd Problem identifying Spam
Posted by Theo Van Dinter <fe...@kluge.net>.
On Tue, Feb 15, 2005 at 07:30:33PM +0100, Daniel Draes wrote:
> Any ideas whats wrong with my setup?
My guess is that you're running the message through SpamAssassin twice. The
first time marks it up appropriately, then the second time sees a
substantially different message and marks it up differently, leading to
confusing results.
--
Randomly Generated Tagline:
"First learn computer science and all the theory. Next develop a
programming style. Then forget all that and just hack."
- George Carrette
Re: Wierd Problem identifying Spam
Posted by Daniel Draes <da...@draes.net>.
Some more ideas....
I have confixx installed, and my email is forwarded through a virtual
user table. That means my account xyz@domaind.de will be forwarded to
user@localhost. Does that actually mean the mail will be passed to
postfix again (and therefor to SA as well??)
That could be my problem than. But how to solve it?
>
>>> Anyways, shouldn't SA be intelligent enough to scan mails only once
>>> by seeing the X-flags and stop further processing?
>>>
>>
>>
>> Since the X-Spam-* headers can be forged, we ignore them.
>>
>>
>>
> Thanks, I almost expected that. That leaves my problem back to
>
> - Why is SA scanning my mails twice even though procmail does not
> invoke SA
> - Is he really scanning twice? How can I verify that?
>
>
> Daniel
Re: Wierd Problem identifying Spam
Posted by Daniel Draes <da...@draes.net>.
>>Anyways, shouldn't SA be intelligent enough to scan mails only once by
>>seeing the X-flags and stop further processing?
>>
>>
>
>Since the X-Spam-* headers can be forged, we ignore them.
>
>
>
Thanks, I almost expected that. That leaves my problem back to
- Why is SA scanning my mails twice even though procmail does not invoke SA
- Is he really scanning twice? How can I verify that?
Daniel
Re: Wierd Problem identifying Spam
Posted by Theo Van Dinter <fe...@kluge.net>.
On Wed, Feb 16, 2005 at 11:21:53PM +0100, Daniel Draes wrote:
> Anyways, shouldn't SA be intelligent enough to scan mails only once by
> seeing the X-flags and stop further processing?
Since the X-Spam-* headers can be forged, we ignore them.
--
Randomly Generated Tagline:
"Kluge.net belongs to Theo, my ex-roommate from Worcester, who I can say
with some measure of admiration, is insane."
- Alan Caulkins, http://www.maxint.net/~fatman/
Re: Wierd Problem identifying Spam
Posted by Daniel Draes <da...@draes.net>.
Hi,
nobody any more help here?
I am glad to provide more details about my config if needed.
Anyways, shouldn't SA be intelligent enough to scan mails only once by
seeing the X-flags and stop further processing?
Thx,
Daniel
>
>> Usually that means the message has been double-scanned..
>>
>> First at the MTA layer, where it got tagged as spam and encapsulated.
>> The encapsulation also winds up creating new headers for the message.
>>
>> The second time it got called at the MDA layer (ie: procmail) and the
>> new headers resulted in a lower score that wasn't spam. The second
>> scan over-writes all the X-Spam headers with the new status, but
>> doesn't modify the subject and body that were tagged by the previous
>> run.
>
>
> Hmm. I thought something like this.... Can you help me finding out if
> and when why?
>
> Here is the relevant part of my postfix setup:
> smtp inet n - n - - smtpd
> -o content_filter=spamassassin
> [...]
> spamassassin unix - n n - - pipe
> user=nobody argv=/usr/bin/spamc -f -e
> /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>
>
>
> There is no further processing mail with SA through procmail (I
> checked that already).
>
> THX!
>
> Daniel
>
Re: Wierd Problem identifying Spam
Posted by Daniel Draes <da...@draes.net>.
Hi,
> Usually that means the message has been double-scanned..
>
> First at the MTA layer, where it got tagged as spam and encapsulated.
> The encapsulation also winds up creating new headers for the message.
>
> The second time it got called at the MDA layer (ie: procmail) and the
> new headers resulted in a lower score that wasn't spam. The second
> scan over-writes all the X-Spam headers with the new status, but
> doesn't modify the subject and body that were tagged by the previous run.
Hmm. I thought something like this.... Can you help me finding out if
and when why?
Here is the relevant part of my postfix setup:
smtp inet n - n - - smtpd
-o content_filter=spamassassin
[...]
spamassassin unix - n n - - pipe
user=nobody argv=/usr/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
There is no further processing mail with SA through procmail (I checked
that already).
THX!
Daniel
Re: Wierd Problem identifying Spam
Posted by Matt Kettler <mk...@evi-inc.com>.
At 01:30 PM 2/15/2005, Daniel Draes wrote:
>Here is what happens:
>SA gets the mail and checks it nicely. However, applying points to the
>mail seems to fail somehow. For example I have mails where the subjects
>will be rewritten according my confing with '*****SPAM*****' but the
>SA-Spam-Status Flag states:
>No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham
>version=2.64
>
>The mail itself however says:
>
>Content analysis details: (7.8 points, 5.0 required)
>
>So having a procmail-rule for X-Spam-Level doesn't really help.
>
>Any ideas whats wrong with my setup?
Usually that means the message has been double-scanned..
First at the MTA layer, where it got tagged as spam and encapsulated. The
encapsulation also winds up creating new headers for the message.
The second time it got called at the MDA layer (ie: procmail) and the new
headers resulted in a lower score that wasn't spam. The second scan
over-writes all the X-Spam headers with the new status, but doesn't modify
the subject and body that were tagged by the previous run.