Mailing List Archive

Hi Jared,

Do you mind if I redirect the below back onto the spamassassin list
and respond to it there?

I'm concerned that I might have a configuration error if a DNSBL
check was done against an IP from a Received header that wasn't the
last external one, as you mention.

Thanks,
Andy

On Thu, Sep 28, 2023 at 12:02:47AM -0400, Jared Hall wrote:
> On 9/27/2023 5:42 PM, Andy Smith wrote:
> > Hi Jared,
> > > > Just under that paragraph I mentioned that the supplier hosts public
> > mailing lists where their employees end others use addresses that I
> > can't predict, so I think this would not work as I'd have to
> > allowlist all mail from all of mimecast's clients.
> > > Thanks,
> > Andy
> Not sure what all that means but it sounds like a SPF/DKIM nightmare. 
> Crazy
> suppliers, but what can you do?
>
> SpamAssassin doesn't arbitrarily pick a header to look at. lastexternal is
> used per the defaults in 20_dnsbl_tests.cf
>
> Header line ordering is a function of the milter.  You didn't say what
> milter you are using.  You'll need a Spamass-milter patch to correct the
> ordering of headers.  Amavisd-new, and MimeDefang work fine as is. 
> The old
> commercial milter-spamc preserved the header order correctly, but puts the
> spamassassin results at the end (bottom) of the existing headers.
>
> That's all I have for now.
>
> I wish you good luck,
>
> -- Jared Hall

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-bounces@redhat.com>)
id 1qlVVV-0001zW-Jc
for andy@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-bounces@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

On 9/28/2023 8:39 AM, Andy Smith wrote:
> 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-bounces@redhat.com>)
> id 1qlVVV-0001zW-Jc
> for andy@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-bounces@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

OK.

1) Are you using native SA or the spamhaus-dqs plugin?

2) What version of SpamAssassin?

3) Parse the message from the command line.  Something like:
'cat message | spamassassin -D &> dbgout.txt'
Then: 'grep external dbgout.txt'

It should show something like "full-external: 170.10.129.124,
66.187.233.73 untrusted: 170.10.129.124, 66.187.233.73 originating:" if
your Internal networks are setup properly in SA.


-- Jared Hall

On 9/27/23 2:15?PM, Andy Smith wrote:
> Hi,

Hi,

> The IP address of a supplier is currently listed by Spamhaus
> SBL-CSS.

Oops.

> How would I go about allowlisting this IP address against DNSBL
> hits? Ideally for a specified range of from addresses and/or
> envelope senders, but for every sender if necessary. I think I would
> be okay with exempting such an IP address from *all* negative DNSBL
> hits, at least temporarily.

I'm not sure what the SpamAssassin approved method is.

But I suspect that you could play some DNS games to make the SBL lookup
for 192.0.2.1 fail by monkeying with the 1.2.0.192.sbl.spamhaus.org
query. Either something like RPZ to make sure that the listed result
never comes back or make it resolve to what you want it to resolve to.



--
Grant. . . .
unix || die

Hello,

On Thu, Sep 28, 2023 at 09:08:30PM -0400, Jared Hall wrote:
> 1) Are you using native SA or the spamhaus-dqs plugin?

Just native SA in spamd mode.

> 2) What version of SpamAssassin?

3.4.2. I know, it's ancient. An upgrade is planned but I'd still
like to know what the behaviour is. I understand if no one wants to
help and if so I might come back with questions after an upgrade.

> 3) Parse the message from the command line.  Something like:
> 'cat message | spamassassin -D &> dbgout.txt'
> Then: 'grep external dbgout.txt'
>
> It should show something like "full-external: 170.10.129.124, 66.187.233.73
> untrusted: 170.10.129.124, 66.187.233.73 originating:" if your Internal
> networks are setup properly in SA.

grep full-external: dbgout.txt

produces 15 lines all of which are identical:

Sep 29 14:36:57.221 [2611] dbg: dns: IPs found: full-external: 170.10.129.124, 66.187.233.73, 10.11.54.8, 10.30.29.100, ::1, 10.11.54.6, 10.11.55.25, 207.211.31.120, 209.85.128.43 untrusted: 170.10.129.124, 66.187.233.73, 207.211.31.120, 209.85.128.43 originating:

(except for timestamps)

66.187.233.73 still seems to be listed in SBL-CSS and ios detected
as such.

I can see from:

grep 73.233.187.66 dbgout.txt

that it does check 66.187.233.73 against all the usual DNSBLs,
e.g.

Sep 29 14:36:57.157 [2611] dbg: check: tagrun - tag RELAYSUNTRUSTEDREVIP is now ready, value: ARY:[124.129.10.170,73.233.187.66,120.31.211.207,43.128.85.209]
Sep 29 14:36:57.157 [2611] dbg: check: tagrun - tag RELAYSEXTERNALREVIP is now ready, value: ARY:[124.129.10.170,73.233.187.66,120.31.211.207,43.128.85.209]
[…]
Sep 29 14:36:57.218 [2611] dbg: async: launching A/73.233.187.66.zen.spamhaus.org for dns:A:73.233.187.66.zen.spamhaus.org
Sep 29 14:36:57.219 [2611] dbg: dns: providing a callback for id: 31199/IN/A/73.233.187.66.zen.spamhaus.org
Sep 29 14:36:57.219 [2611] dbg: async: starting: DNSBL-A, dns:A:73.233.187.66.zen.spamhaus.org (timeout 15.0s, min 3.0s)
Sep 29 14:36:57.378 [2611] dbg: async: calling callback on key dns:A:73.233.187.66.zen.spamhaus.org
Sep 29 14:36:57.378 [2611] dbg: dns: hit <dns:73.233.187.66.zen.spamhaus.org> 127.0.0.3

So this is normal behaviour then, for v3.4.2 at least?

Thanks,
Andy

On 9/29/2023 10:59 AM, Andy Smith wrote:
> Just native SA in spamd mode.
>
> 3.4.2. I know, it's ancient. An upgrade is planned but I'd still
> like to know what the behaviour is. I understand if no one wants to
> help and if so I might come back with questions after an upgrade.
My distro packages stopped at v3.4.2 so I'm on SA v3.4.6 via CPAN. Just
inspecting the comments in DNSEval.pm, you'll need SA version 3.4.4
(minimum).
>> 3) Parse the message from the command line.  Something like:
>> 'cat message | spamassassin -D &> dbgout.txt'
>> Then: 'grep external dbgout.txt'
> grep full-external: dbgout.txt
>
> produces 15 lines all of which are identical:
>
> Sep 29 14:36:57.221 [2611] dbg: dns: IPs found: full-external: 170.10.129.124, 66.187.233.73, 10.11.54.8, 10.30.29.100, ::1, 10.11.54.6, 10.11.55.25, 207.211.31.120, 209.85.128.43 untrusted: 170.10.129.124, 66.187.233.73, 207.211.31.120, 209.85.128.43 originating:
Good.  SA core is functioning properly and detecting, in order, the
untrusted IPs.
> I can see from:
>
> grep 73.233.187.66 dbgout.txt
>
> that it does check 66.187.233.73 against all the usual DNSBLs,
> e.g.
>
> Sep 29 14:36:57.218 [2611] dbg: async: launching A/73.233.187.66.zen.spamhaus.org for dns:A:73.233.187.66.zen.spamhaus.org
> Sep 29 14:36:57.219 [2611] dbg: dns: providing a callback for id: 31199/IN/A/73.233.187.66.zen.spamhaus.org
> Sep 29 14:36:57.219 [2611] dbg: async: starting: DNSBL-A, dns:A:73.233.187.66.zen.spamhaus.org (timeout 15.0s, min 3.0s)
> Sep 29 14:36:57.378 [2611] dbg: async: calling callback on key dns:A:73.233.187.66.zen.spamhaus.org
> Sep 29 14:36:57.378 [2611] dbg: dns: hit <dns:73.233.187.66.zen.spamhaus.org> 127.0.0.3
>
> So this is normal behaviour then, for v3.4.2 at least?
No, this is NOT normal behavior.  In your case SA has the correct IP
addresses, properly orders and reverses the IP octets, but the output of
the DNSEval.pm module is incorrect.  While the main files are DNSEval.pm
and 20_dnsbl_tests.cf, there are other moving parts, like AskDNS.

The code for the current versions of DNSEval.pm is clean, much more
code-function oriented, and less-prone to race conditions.  This actual
comment in SA 3.4.2's DNSEval.pm module says it all:

"# Very hacky stuff and direct rbl_evals usage for now, TODO rewrite
everything"

An upgrade is in order.

-- Jared Hall

Hello,

On Sat, Sep 30, 2023 at 11:52:13AM -0400, Jared Hall wrote:
> On 9/29/2023 10:59 AM, Andy Smith wrote:
> > 3.4.2. I know, it's ancient. An upgrade is planned but I'd still
> > like to know what the behaviour is. I understand if no one wants to
> > help and if so I might come back with questions after an upgrade.
> My distro packages stopped at v3.4.2 so I'm on SA v3.4.6 via CPAN. Just
> inspecting the comments in DNSEval.pm, you'll need SA version 3.4.4
> (minimum).

[…]

> The code for the current versions of DNSEval.pm is clean, much more
> code-function oriented, and less-prone to race conditions.  This actual
> comment in SA 3.4.2's DNSEval.pm module says it all:
>
> "# Very hacky stuff and direct rbl_evals usage for now, TODO rewrite
> everything"
>
> An upgrade is in order.

Okay, thanks Jared! I'll work on that and see what it looks like
after an upgrade.

Thanks,
Andy