On Mon, 2014-10-27 at 20:19 -0700, jdebert wrote:
> On Mon, 27 Oct 2014 15:45:03 -0700 (PDT)
> John Hardin <jhar...@impsec.org> wrote:
> > The apparent culprit is a procmail rule that explicitly passes a
> > message through the mail system again. The message is being scanned
> > twice. If she can either deliver to a local mailbox rather than
> > forwarding to an email address, or modify the procmail rule that
> > calls SA to ignore messages that have already passed through the
> > server once, I think the problem would go away.
>
> It looks as if it's the global procmailrc that always puts all mail,
> even mail between local users through spamassassin. However, I don't
> see how going through spamassassin again will modify the header. It's
It is not the second run that modifies the header. It's the first one.
With the second run classifying the mail as not-spam.
> already modified before the user procmail rule sees it. Something
> appears to be causing the first run of sa to modify the header
> unconditionally. If global procmail actually does the first run.
A system-wide procmail recipe feeds mail to SA.
Then there's a user procmail recipe that forwards mail with a Subject
matching /SPAM/ to another "dedicated spam dump" address with the same
domain, which ends up being delivered to that domain's MX. The same SMTP
server. Now re-processing the original mail (possibly wrapped in an
RFC822 attachment by SA), feeding it to SA due to the system-wide
procmail recipe...
On that second run, the message previously classified spam does not
exceed the threshold. Thus the X-Spam-Status of no, overriding the
previous Status header which is being ignored by SA anyway.
Result: Subject header rewritten by SA, despite final (delivery time)
spam status of no. This thread's Subject.
--
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; }}}
