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...@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; }}}
