Am 30.08.2014 um 00:35 schrieb Karsten Bräckelmann: > On Fri, 2014-08-29 at 12:02 +0200, Reindl Harald wrote: >> Am 29.08.2014 um 04:03 schrieb Karsten Bräckelmann: > >>> Now, moving forward: I've had a look at the message diffs. Quite >>> interesting, and I honestly want to figure out what's happening. >> >> it looks really like spamass-milter is responsible >> >> in the second version below it whines it can't extract >> the score to decide if it's above reject and so it >> really looks like the milter heavily relies on headers > > Yay for case in-sensitive parsing... > >> found that out much later last night by plaing with headers in general >> >> spamass-milter[14891]: Could not extract score from <Yes: Score=5.7, >> Tag-Level=5.0, Block-Level=10> >> >> add_header all Status _YESNO_, score=_SCORE_, tag-level=_REQD_, >> block-level=10 >> add_header all Status _YESNO_, Score=_SCORE_, Tag-Level=_REQD_, >> Block-Level=10 > > If you use the SA default Status header, or at least the prefix > containing score and required, is header rewriting retained by the > milter without the Flag header? > > add_header all Status "_YESNO_, score=_SCORE_ required=_REQD_ ..."
yes, that's what i tried to express "score=" instead of "Score=" is liked by the milter well, no big deal, i would have preferred it "score" or "Yes/No" also starzing lowercase :-) > Given that log line, a likely explanation simply is that the milter > needs to determine the spam status, to decide which SA generated headers > to apply to the message. Your choice of custom Status header is not what > the milter expects, and thus needs to resort to the simple Flag header. > > (Note the comma after yes/no, but no comma between score and required.) it's really only s versus S in score, tried it out before my post >>> First of all, minus all those different datetime strings, IDs and >>> ordering, the real differences are >>> >>> -Subject: [SPAM] Test^M >>> -X-Spam-Flag: Yes^M >>> >>> +Subject: Test^M >>> >>> So it appears that only the sample with add_header spam Flag has the >>> Subject re-written. >> >> correct >> >>> However, there's something else going on. When re-writing the Subject >>> header, SA adds an X-Spam-Prev-Subject header with the original. Which >>> is clearly missing. >> >> the version is killed in smtp_header_checks which is also >> the reason that i started to play around with headers >> >> nobody but me has a reason to know exact versions of running software > > Previous-Subject, not Version. i saw that somewhere in the debug options and wondered too but i referred to the SA version header because doc says you can't remove it and so i explained why it's not there > I mentioned this specifically, because the absence of the Previous > Subject header with Subject rewrite clearly shows, SA generated headers > are not unconditionally added to the message, but single headers are > cherry picked. > > IOW, header rewriting does work without the Flag header. It is the glue > that decides whether to inherit the rewritten header, and outright > ignores the Previous Subject header. yep - as said: the intention of my post to that topic was only to make public how i fixed it before someone in the future wastes his time with outdated google hits mentioning no longer existing options which are not the reason in that case well, now i know that the milter relies on SA generated headers which was totally unexpected and i work with a lot of server software for many years - give me my daily WTF :-) >>> Thus, something else has a severe impact on which headers are added or >>> modified. In *both* cases, there is at least one SA generated header >>> missing and/or SA modified header not preserved
signature.asc
Description: OpenPGP digital signature
