Am 29.08.2014 um 04:03 schrieb Karsten Bräckelmann: > On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote: >> look at the attached zp-archive and both messages >> produced with the same content before you pretend >> others lying damned - to make it easier i even >> added a config-diff > > But no message diff. ;) > >> and now what? >> >> maybe you should accept that even new users are >> no idiots and know what they are talking about > > Please accept my apologies. It appears something else is going on here, > and you in fact did not lie.
accepted > I'd like to add, though, that I do *not* assume new users to be idiots. > Plus, I generally spend quite some time on helping others fixing their > problems, including new users, as you certainly have noticed. that's why i was really angry because from the other guy which told me multiple times that i should go to the sa-milter list and refered to 8 years old howtos which are wrong and outdated i had expetced that, not from you which was the first constructive my only intention to reply again to that thread was "hey, i found it by myself and if someone else has the same problem now he finds a soultion froma recent year" > 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 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 > 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 > 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. /^X-Spam-Checker-Version/ IGNORE > Definitely involved: Postfix, spamass-milter, SA. And probably some > other tool rewriting the message / reflowing headers, as per some > previous posts (and the X-Spam-Report header majorly inconvenienced by > re-flowing headers). the re-flowing is pretty sure DBMail or more like the gmime library used for split and reconstruct messages in their mime parts to store them seperated and de-duplicated in the database - that's valid and per RFC OK but not nice to read :-) > Regarding SA and the features in question: There is no different > behavior between calling the plain spamassassin script and using > spamc/d. There is absolutely nothing in SA itself that could explain the > discrepancy in Subject rewriting, nor the missing X-Spam-Prev-Subject > header. as said: pretty sure the milter, but i am happy that it works now > My best bet would be on the SA invoking glue, not accepting or > overwriting headers as received by SA. Which tool that actually is, I > don't know. But I'd be interested to hear about it, if you find out. > > (The additional empty line between message headers and body in the case > without X-Spam-Flag header most likely is just copy-n-paste body. Or > possibly another artifact of some tool munging messages.)
signature.asc
Description: OpenPGP digital signature
