https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7348

--- Comment #6 from Reindl Harald <[email protected]> ---
it is above a trusted-received header, in fact it's on top of the message when
handover to the milter happens and if that received header would not be there
and trusted all the DNSBL won't work too

"It shouldn't prevent SPF working though. It should fall-back to doing its own
lookup" is what i expressed with "even if it would not re-use the
"Received-SPF" header - since it was inserted by the MTA before passing the
message to the milter it is 100% sure in the local resolver cache and
dns-timeouts or errors are practically not possible at that stage"

so there are two anchors which should make SPF_PASS successful:

* the fact that's the response is in the DNS cache
* the fact of the poliycd-header with made 
  sure it's in the DNS cache since policyd is running 
  long before milters
_________________________________

Name:   mail-gw.thelounge.net
Address: 10.0.0.19

clear_trusted_networks
trusted_networks 10.0.0.0/24
internal_networks 10.0.0.0/24

Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
 client-ip=198.2.182.53; helo=mail53.suw15.mcsv.net;
 envelope-from=bounce-mc.us13_59462513.501201-checkin=thelounge.net@mail53.s
    uw15.mcsv.net; [email protected]
Received: from mail53.suw15.mcsv.net (mail53.suw15.mcsv.net [198.2.182.53])
    by mail-gw.thelounge.net (THELOUNGE GATEWAY) with ESMTP id 3sPYXJ39pvz9c9
    for <[email protected]>; Wed, 31 Aug 2016 20:17:52 +0200 (CEST)

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to