Re: [sa] Re: NO_RELAYS spam

[Charles Gregory <cg...@hwcn.org>]

On Fri, 18 Jun 2010, Randy Ramsdell wrote:
> I have no problem going over there but I am not convinced that the 
> Amavis program is the problem. The header field is changed by 
> spamassassin. Doesn't the email simply get handed to Spamassasin by 
> Amavis where the headers are modified by spam report etc...?

The headers are missing.
Spamassassin records this fact, but is not responsible for it.
So find out what happens to your message BEFORE spamassassin is called.
Amavis is just a suggested starting place. And if it is to blame, someone 
on their list will reocgnize your query as soon as you post it.

Suggestion: After each step of your mail processing, if you can, save a 
copy of the mail to a log file. At least that way you get a quick overview 
of *which* component removes those headers....

- C

Re: NO_RELAYS spam

[Randy Ramsdell <rr...@activedg.com>]

Karsten Bräckelmann wrote:
> On Fri, 2010-06-18 at 23:54 +0200, Karsten Bräckelmann wrote:
>   
>> Your issue is kind of weird and far less than common. Read, I cannot
>> recall coming across such a report *ever* on this list.
>>
>> Thus, the collective list's lack of pin-pointing the cause with the info
>> given. The very reason we need you to dig deeper, provide debug logs,
>> header dumps at all stages -- or any evidence at all this might be SA.
>>     
>
> Randy, any results? Did you find the cause for the issue?
>
>
>   
At this time, I have not. Since the messages are originally scanned with 
all the headers in tact and not having the time, I will look into this 
later. I am still not sure how to go about troubleshooting this however.

Thanks,
RCR

Re: NO_RELAYS spam

[Karsten Bräckelmann <gu...@rudersport.de>]

On Fri, 2010-06-18 at 23:54 +0200, Karsten Bräckelmann wrote:
> Your issue is kind of weird and far less than common. Read, I cannot
> recall coming across such a report *ever* on this list.
> 
> Thus, the collective list's lack of pin-pointing the cause with the info
> given. The very reason we need you to dig deeper, provide debug logs,
> header dumps at all stages -- or any evidence at all this might be SA.

Randy, any results? Did you find the cause for the issue?


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: NO_RELAYS spam

[Karsten Bräckelmann <gu...@rudersport.de>]

On Fri, 2010-06-18 at 13:33 -0400, Randy Ramsdell wrote:
> Charles Gregory wrote:
> > On Fri, 18 Jun 2010, Randy Ramsdell wrote:
> > > I have no problem going over there but I am not convinced that the 
> > > Amavis program is the problem. The header field is changed by 
> > > spamassassin. Doesn't the email simply get handed to Spamassasin by 
> > > Amavis where the headers are modified by spam report etc...?

No. While (I believe) Amavis actually can use spamd, it is most common
not using it. Amavis uses its own instance of SA, *similar* to what
spamd does. Also, in that case, SA doesn't add headers, but Amavis code
does.

Moreover, SA generally does not modify any headers but the Subject if
specifically configured to do so, and there are a very few rarely-used
options for rewriting (two) other headers. None of these ever harms
Received headers.


> > Suggestion: After each step of your mail processing, if you can, save 
> > a copy of the mail to a log file. At least that way you get a quick 
> > overview of *which* component removes those headers....
> 
> Not exactly. Spamassassin sees the original messages including the 
> received headers, then it modifies those headers with its information. I 
> see these issues when running subsequent tests with spamassasin. So this 
> is why I am not convinced that spamassassin is not causing the problem. 
> Just clarifying the issue here. So it could be amavis, spamassassin or 
> postfix but I am leaning towards spamassassin at the moment.

I don't see how SA could do this, and believe it must be something else.
But hey, that's just an as uneducated guess as yours. And it doesn't get
us closer to the culprit.


> From an earlier post in which I wrote:  ( You see that the original 
> scan saw the headers, but after delivery they were gone. )

> Original rules hit.
> 
> X-Spam-Status: No, score=-0.394 tagged_above=-9999 
> required=5tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 
> RCVD_IN_SORBS_WEB=0.619,URG_BIZ=1.585]

Note that this header has been added by Amavis, *not* SA. Despite you
repeating it is SA adding the headers. And your claim of using spamd,
which is rather unlikely when using Amavis.

Are you really using spamd with Amavis?


> After running spamassassin -D
> 
> X-Spam-Status: No, score=4.2 required=5.0 
> tests=AWL,BAYES_80,HTML_MESSAGE,NO_RECEIVED,NO_RELAYS,TO_MALFORMED,URG_BIZ 
> autolearn=no version=3.2.5

So, yeah -- we do know that the Received headers have been present when
the incoming mail initially has been passed to Amavis (and its SA
instance). What we do *not* know is, where exactly after that headers
get lost. Some verbose logging of headers before and after *all*
following stages will be necessary.

Also it is left kind of unclear, how and where you got the mail with the
headers lost for re-feeding to SA. From your description I assume you
got it by directly snipering a raw message file out of the Dovecot
Maildir backend storage. But that's just a guess, unless you can confirm
the exact steps you did that.


Your issue is kind of weird and far less than common. Read, I cannot
recall coming across such a report *ever* on this list.

Thus, the collective list's lack of pin-pointing the cause with the info
given. The very reason we need you to dig deeper, provide debug logs,
header dumps at all stages -- or any evidence at all this might be SA.

  guenther


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: [sa] Re: NO_RELAYS spam

[Randy Ramsdell <rr...@activedg.com>]

Charles Gregory wrote:
> On Fri, 18 Jun 2010, Randy Ramsdell wrote:
>> I have no problem going over there but I am not convinced that the 
>> Amavis program is the problem. The header field is changed by 
>> spamassassin. Doesn't the email simply get handed to Spamassasin by 
>> Amavis where the headers are modified by spam report etc...?
>
> The headers are missing.
> Spamassassin records this fact, but is not responsible for it.
> So find out what happens to your message BEFORE spamassassin is called.
> Amavis is just a suggested starting place. And if it is to blame, 
> someone on their list will reocgnize your query as soon as you post it.
>
> Suggestion: After each step of your mail processing, if you can, save 
> a copy of the mail to a log file. At least that way you get a quick 
> overview of *which* component removes those headers....
>
> - C
Not exactly. Spamassassin sees the original messages including the 
received headers, then it modifies those headers with its information. I 
see these issues when running subsequent tests with spamassasin. So this 
is why I am not convinced that spamassassin is not causing the problem. 
Just clarifying the issue here. So it could be amavis, spamassassin or 
postfix but I am leaning towards spamassassin at the moment.

 From an earlier post in which I wrote:  ( You see that the original 
scan saw the headers, but after delivery they were gone. )

Example:

Original rules hit.

X-Spam-Status: No, score=-0.394 tagged_above=-9999 
required=5tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 
RCVD_IN_SORBS_WEB=0.619,URG_BIZ=1.585]

After running spamassassin -D

X-Spam-Status: No, score=4.2 required=5.0 
tests=AWL,BAYES_80,HTML_MESSAGE,NO_RECEIVED,NO_RELAYS,TO_MALFORMED,URG_BIZ 
autolearn=no version=3.2.5