MUf> This was the point. If the line that should be matched with the rule is the
MUf> first one, AND the check is done before MTA adds Received: line (which is
MUf> case when the milter is used), this is an issue of the intermediate program
MUf> that feeds mail to spamassassin.
MUf> Now, Rainer, can you confirm this is the case?
On 07.02.14 15:11, Rainer Fügenstein wrote:
what I can tell is the following:
- spamass-milter 0.3.1 is in use. this seems to be the most current
version.
- if I understand this conversation correctly: the line
"Received: from [192.168.5.238] (xyz.example.com [90.217.201.80])"
has already been passed to spamassassin (or been "virtually created"
when the regex rules are applied, but the following lines
(authenticated bits=0)
by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VEsVIv028654
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
haven't. does this make sense? is this how SA is implemented?
It's the whole _first_ multi-line Received: header (pardon - not line) that
is faked by spamass-milter when passing to spamd and the one you see is
added by sendmail later. So, spamd apparently sees something different than
you do.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton
