Hello,
On Thu, Sep 28, 2023 at 06:48:54AM -0400, Jared Hall wrote:
> Do you mind if I redirect the below back onto the spamassassin list
> and respond to it there?
Well I was going to do that, but fair enough!
> On Thu, Sep 28, 2023 at 12:02:47AM -0400, Jared Hall wrote:
> > SpamAssassin doesn't arbitrarily pick a header to look at. lastexternal is
> > used per the defaults in 20_dnsbl_tests.cf
Okay so here is what I have:
Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124])
by barenjager.bitfolk.com with esmtps
(TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from <linux-lvm-boun...@redhat.com>)
id 1qlVVV-0001zW-Jc
for a...@strugglers.net; Wed, 27 Sep 2023 14:27:18 +0000
Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73])
by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
us-mta-473-x2wpeAY1NVC4XPDK8dEpYA-1; Wed, 27 Sep 2023 10:27:10 -0400
In the SpamAssassin report is:
* 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
* [66.187.233.73 listed in zen.spamhaus.org]
barenjager.bitfolk.com is my MX which is running spamassassin called
from Exim using its built in means of calling out to SA from the
check_data ACL:
acl_check_data:
# …
warn message = X-barenjager.bitfolk.com-Spam-Report: $spam_report
spam = Debian-exim:true/defer_ok
What I gathered from Jared's reply is that SA shouldn't be doing
DNSBL checks against all of the IPs in all of the Received headers,
only the lastexternal one.
Here though, the lastexternal one should be 170.10.129.124 as that
is not in my internal_networks, but it seems to have done a check of
the one before it, 66.187.233.73, and found it in Spamhaus SBL-CSS.
Is that expected?
I guess I can allowlist from SPF as the envelope sender will be the
mailing list in question (linux-lvm-boun...@redhat.com) and it did
get a "SPF_PASS SPF: sender matches SPF record" so redhat.com must
have mimecast's relays correctly in it.
Thanks,
Andy
