Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. SpamAssassin>
  3. users
DNSWL_HI testing wrong Received header?
users at spamassassin
Dec 26, 2022, 12:44 PM
Post #1 of 19 (909 views)
Permalink
Hello,

I have lately seen an increase in the number of spam messages passing
spamassassin.  Checking the X-Spam-Status header, I see that the common
reason they are all passing is that they hit the DNSWL_HI test to get a
-5 adjustment to their spam score. However, when I check the IP address
of the server that my domain received the message directly from, that IP
address is not in the DNSWL high trust database.  There are forged
Received headers lower down, for Gmail or Hotmail servers, and I suspect
that those are the IPs being checked in the DNSWL_HI test. Otherwise I
don't know why DNSWL_HI is being triggered.

My second question is where to report an SMTP server that passes SPF,
but is passing spam with forged Received headers.

Here's an example header:

Return-Path: <>
X-Original-To:john@idsfa.net
Delivered-To:john@idsfa.net
Received: from localhost (localhost [127.0.0.1])
by idsfa.net (Postfix) with ESMTP id 29F168C0136
for<john@idsfa.net>; Sun, 22 May 2022 20:12:17 -0700 (PDT)
X-Spam-Flag: NO
X-Spam-Score: 4.319
X-Spam-Level: ****
X-Spam-Status: No, score=4.319 tagged_above=-5 required=6.31
tests=[.ACT_NOW_CAPS=0.1, BAYES_99=3.5, BAYES_999=0.2,
DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_SIZE_LARGE=0.001,
HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1,
PYZOR_CHECK=1.392, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_HI=-5,
RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL=1.31, RDNS_NONE=0.793,
SPF_HELO_PASS=-0.001, T_DATE_IN_FUTURE_96_Q=0.01,
T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Authentication-Results: harlie.idsfa.net (amavisd-new);
dkim=fail (2048-bit key) reason="fail (message has been altered)"
header.d=hotmail.com
Received: from idsfa.net ([127.0.0.1])
by localhost (harlie.idsfa.net [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id GXmcEm9KlHEF for<john@idsfa.net>;
Sun, 22 May 2022 20:12:16 -0700 (PDT)
Received-SPF: Pass (helo) identity=helo; client-ip=85.204.116.245; helo=aznavrchol.cz; envelope-from=<>; receiver=<UNKNOWN>
Authentication-Results: idsfa.net;
dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=hotmail.comheader.i=@hotmail.com header.b="JRELNzNe";
dkim-atps=neutral
Received: from aznavrchol.cz (unknown [85.204.116.245])
by idsfa.net (Postfix) with ESMTP id 2EF948C00FC
for<john@idsfa.net>; Sun, 22 May 2022 20:12:15 -0700 (PDT)
Received: from 10.196.243.97
by atlas113.aol.mail.bf1.yahoo.com with HTTPS; Mon, 16 May 2033 09:37:50 +0000
X-Originating-Ip: [40.92.91.45]
Received-SPF: pass (domain of hotmail.com designates 40.92.91.45 as permitted sender)
Authentication-Results: atlas113.aol.mail.bf1.yahoo.com;
dkim=passheader.i=@hotmail.com header.s=selector1;
spf=pass smtp.mailfrom=hotmail.com;
dmarc=pass(p=NONE) header.from=hotmail.com;
X-Apparently-To:john@idsfa.net; Mon, 16 May 2033 09:37:50 +0000
Re: DNSWL_HI testing wrong Received header? [ In reply to ]
me at junc
Dec 26, 2022, 3:02 PM
Post #2 of 19 (909 views)
Permalink
John Stimson via users skrev den 2022-12-26 21:44:

> My second question is where to report an SMTP server that passes SPF,
> but is passing spam with forged Received headers.
>
> Here's an example header:

Received: from aznavrchol.cz (unknown [85.204.116.245])
by idsfa.net (Postfix) with ESMTP id 2EF948C00FC
for <john@idsfa.net>; Sun, 22 May 2022 20:12:15 -0700 (PDT)

this is not listed in dnswl.org

https://multirbl.valli.org/lookup/85.204.116.245.html

have you setup trusted_networks, internal_networks, msa_networks correct
in spamassassin ?

if you can confirm it uses other headers for dnswl.org then remove this
headers before spamassassin see it, thats the forged header imho X-* and
friends there :=)
Re: DNSWL_HI testing wrong Received header? [ In reply to ]
me at junc
Dec 26, 2022, 3:47 PM
Post #3 of 19 (909 views)
Permalink
John Stimson via users skrev den 2022-12-26 21:44:

> Here's an example header:

X-Originating-Ip: [40.92.91.45]

this header is expanded in spamassassin and sure currently gives
https://dnswl.org/s/?s=1357

i consider trust here not good to use forged header info to whitelist
ips, when this ip is not in recieved header

X-Originating-Ip should not be used for whitelists, only for blacklist
rbl, even on only blacklist its unsafe to use, rules maintainers can
remove it, now that spamassassin 4.0.0 is out :)

read "perldoc Mail::SpamAssassin::Conf" to see how this header is
included, and remove it
RE: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
users at spamassassin
Dec 27, 2022, 7:34 AM
Post #4 of 19 (909 views)
Permalink
I'm sorry; I should have included the version information.

I am running spamassassin with the default installation from kubuntu
18.04 LTS, updated to kubuntu 20.04.  It is version 3.4.4.  It is called
by amavisd-new, also a default installation.

My local.cf sets up the Bayesian classifier and otherwise only has rules
that match text in the headers to reject specific phrases and domain
names.  I have not done anything to set up or otherwise modify
trusted_networks, internal_networks, or msa_networks.  Is there a good
source of documentation for how to do that?  I don't believe it was
included in the Ubuntu howto document for setting up amavisd-new.

I agree with you that the server in the Received header you quoted is
not listed in dnswl.org, and that spamassassin should not be trusting
the headers provided by that server.  I'd like to know how to correct
the error and perhaps even figure out why the standard ubuntu package
doesn't do this correctly.


On 2022/12/26 23:02:30 Benny Pedersen wrote:
> John Stimson via users skrev den 2022-12-26 21:44:
>
> > My second question is where to report an SMTP server that passes SPF,
> > but is passing spam with forged Received headers.
> >
> > Here's an example header:
>
> Received: from aznavrchol.cz (unknown [85.204.116.245])
> by idsfa.net (Postfix) with ESMTP id 2EF948C00FC
> for <jo...@idsfa.net>; Sun, 22 May 2022 20:12:15 -0700 (PDT)
>
> this is not listed in dnswl.org
>
> https://multirbl.valli.org/lookup/85.204.116.245.html
>
> have you setup trusted_networks, internal_networks, msa_networks correct
> in spamassassin ?
>
> if you can confirm it uses other headers for dnswl.org then remove this
> headers before spamassassin see it, thats the forged header imho X-* and
> friends there :=)
>
>
Re: DNSWL_HI testing wrong Received header? [ In reply to ]
me at junc
Dec 27, 2022, 7:45 AM
Post #5 of 19 (909 views)
Permalink
John Stimson via users skrev den 2022-12-27 16:34:
> I'm sorry; I should have included the version information.

all versions do in this case here the same

> I am running spamassassin with the default installation from kubuntu
> 18.04 LTS, updated to kubuntu 20.04.  It is version 3.4.4.  It is
> called by amavisd-new, also a default installation.

good and stable

> My local.cf sets up the Bayesian classifier and otherwise only has
> rules that match text in the headers to reject specific phrases and
> domain names.  I have not done anything to set up or otherwise modify
> trusted_networks, internal_networks, or msa_networks.  Is there a good
> source of documentation for how to do that?  I don't believe it was
> included in the Ubuntu howto document for setting up amavisd-new.

good

> I agree with you that the server in the Received header you quoted is
> not listed in dnswl.org, and that spamassassin should not be trusting
> the headers provided by that server.  I'd like to know how to correct
> the error and perhaps even figure out why the standard ubuntu package
> doesn't do this correctly.

its a standard missconfigure :)

in shell: perldoc Mail::SpamAssassin::Conf | grep clear

ip headers it to be cleared

> On 2022/12/26 23:02:30 Benny Pedersen wrote:
>> John Stimson via users skrev den 2022-12-26 21:44:
>>
>> > My second question is where to report an SMTP server that passes SPF,
>> > but is passing spam with forged Received headers.
>> >
>> > Here's an example header:
>>
>> Received: from aznavrchol.cz (unknown [85.204.116.245])
>> by idsfa.net (Postfix) with ESMTP id 2EF948C00FC
>> for <jo...@idsfa.net>; Sun, 22 May 2022 20:12:15 -0700 (PDT)
>>
>> this is not listed in dnswl.org
>>
>> https://multirbl.valli.org/lookup/85.204.116.245.html
>>
>> have you setup trusted_networks, internal_networks, msa_networks
>> correct
>> in spamassassin ?
>>
>> if you can confirm it uses other headers for dnswl.org then remove
>> this
>> headers before spamassassin see it, thats the forged header imho X-*
>> and
>> friends there :=)
>>
>>
RE: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
users at spamassassin
Dec 27, 2022, 10:04 AM
Post #6 of 19 (909 views)
Permalink
On 2022/12/26 23:47:41 Benny Pedersen wrote:

> X-Originating-Ip should not be used for whitelists, only for blacklist
> rbl, even on only blacklist its unsafe to use, rules maintainers can
> remove it, now that spamassassin 4.0.0 is out :)
>
> read "perldoc Mail::SpamAssassin::Conf" to see how this header is
> included, and remove it

Thanks -- I found a mechanism that empties the list of headers used to
determine the originating IP.  I added this line to my local.cf:

clear_originating_ip_headers

Upon restarting the amavisd-new service, the messages that got through
before no longer trigger the DNSWL_HI test.  I hope that's what you had
in mind!

I am looking forward to having time to update to Kubuntu 2022.04 LTS and
getting spamassassin 4.0.
Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
uhlar at fantomas
Dec 27, 2022, 10:20 AM
Post #7 of 19 (909 views)
Permalink
>On 2022/12/26 23:47:41 Benny Pedersen wrote:
>> X-Originating-Ip should not be used for whitelists, only for blacklist
>> rbl, even on only blacklist its unsafe to use, rules maintainers can
>> remove it, now that spamassassin 4.0.0 is out :)
>>
>> read "perldoc Mail::SpamAssassin::Conf" to see how this header is
>> included, and remove it

man Mail::SpamAssassin::Conf

works too on Debian and should work on Debian-based distributions, Ubuntu including



On 27.12.22 13:04, John Stimson via users wrote:
>Thanks -- I found a mechanism that empties the list of headers used to
>determine the originating IP.? I added this line to my local.cf:
>
>clear_originating_ip_headers

I recommend checking:

trusted_networks
clear_trusted_networks

internal_networks
clear_internal_networks

these to be set up properly instead of just clear_originating_ip_headers

- you should still check them, as they give you opportunity to check proper
headers in DNS, not just in DNSWL.

spamassassin -D metadata,netset,received-header < mail

should produce nice output of header processing


>Upon restarting the amavisd-new service, the messages that got through
>before no longer trigger the DNSWL_HI test.? I hope that's what you
>had in mind!
>
>I am looking forward to having time to update to Kubuntu 2022.04 LTS
>and getting spamassassin 4.0.



--
Matus UHLAR - fantomas, uhlar@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.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".
RE: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
users at spamassassin
Dec 27, 2022, 2:28 PM
Post #8 of 19 (909 views)
Permalink
I have a single SMTP server with single public IP address.  I have set

trusted_networks my.ip.num.ber

internal_networks my.ip.num.ber

and removed the clear_originating_ip_headers line.  I also added the line

add_header all RelaysUntrusted _RELAYSUNTRUSTED_

based on the suggestion in the TrustPath documentation at
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath

The documentation there only suggests setting my trusted_networks and
internal_networks, not clearing either of them.


Now, when I manually check the messages, the X-Spam-RelaysUntrusted:
header displays the mail host that my server received the message from.
That seems proper. HOWEVER, even though that is supposed to be the host
used for all IP based checks, DNSWL_HI is being triggered. The first
untrusted host is not in the dnswl.org high confidence list. However the
IP in X-Originating-Ip: is listed in dnswl.org's high confidence list. 
I don't know why spamassassin would use that header, though, since it is
below the Received: line for the first untrusted relay.

On 2022/12/27 18:20:35 Matus UHLAR - fantomas wrote:
> >On 2022/12/26 23:47:41 Benny Pedersen wrote:
> On 27.12.22 13:04, John Stimson via users wrote:
> >Thanks -- I found a mechanism that empties the list of headers used to
> >determine the originating IP.  I added this line to my local.cf:
> >
> >clear_originating_ip_headers
>
> I recommend checking:
>
> trusted_networks
> clear_trusted_networks
>
> internal_networks
> clear_internal_networks
>
> these to be set up properly instead of just clear_originating_ip_headers
>
> - you should still check them, as they give you opportunity to check
proper
> headers in DNS, not just in DNSWL.
Re: DNSWL_HI testing wrong Received header? [ In reply to ]
me at junc
Dec 28, 2022, 1:28 AM
Post #9 of 19 (909 views)
Permalink
John Stimson via users skrev den 2022-12-27 23:28:
> I have a single SMTP server with single public IP address. I have set
> trusted_networks my.ip.num.ber

this can have all external trusted ips aswell, but minimal it should be
a list of ips you have ssh root access on, nothing more nothing less

> internal_networks my.ip.num.ber

should have all "ip addr show" listed

> and removed the clear_originating_ip_headers line. I also added the
> line

this is safe to keep so ips only is in recieved headers, not any other
bogus ips, it have nothing to do with trusted_networks anyway

> add_header all RelaysUntrusted _RELAYSUNTRUSTED_

good to see so you can track errors later :=)

> based on the suggestion in the TrustPath documentation at
> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath

dokumention assume all do the same errors as dokumention describe, while
sane configs is more or less expirence, the expirences cant be readed in
books sadly

> The documentation there only suggests setting my trusted_networks and
> internal_networks, not clearing either of them.

so why is clearing supported ?

> Now, when I manually check the messages, the X-Spam-RelaysUntrusted:
> header displays the mail host that my server received the message
> from. That seems proper. HOWEVER, even though that is supposed to be
> the host used for all IP based checks, DNSWL_HI is being triggered.
> The first untrusted host is not in the dnswl.org high confidence list.
> However the IP in X-Originating-Ip: is listed in dnswl.org's high
> confidence list. I don't know why spamassassin would use that header,
> though, since it is below the Received: line for the first untrusted
> relay.

problem with additional header trust is that we dont know if its forged
or not, with only recieved header it know what it forged, thats my point
of why is it default trusted headers from untrusted sources ?

>
> On 2022/12/27 18:20:35 Matus UHLAR - fantomas wrote:
>> >On 2022/12/26 23:47:41 Benny Pedersen wrote:
>> On 27.12.22 13:04, John Stimson via users wrote:
>> >Thanks -- I found a mechanism that empties the list of headers used
> to
>> >determine the originating IP. I added this line to my local.cf:
>> >
>> >clear_originating_ip_headers

keep this option in local.cf

>>
>> I recommend checking:
>>
>> trusted_networks
>> clear_trusted_networks
>>
>> internal_networks
>> clear_internal_networks
>>
>> these to be set up properly instead of just
> clear_originating_ip_headers
>>
>> - you should still check them, as they give you opportunity to check
> proper
>> headers in DNS, not just in DNSWL.
Re: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
uhlar at fantomas
Dec 28, 2022, 4:45 AM
Post #10 of 19 (909 views)
Permalink
On 27.12.22 17:28, John Stimson via users wrote:
>I have a single SMTP server with single public IP address.? I have set
>
>trusted_networks my.ip.num.ber
>
>internal_networks my.ip.num.ber
>
>and removed the clear_originating_ip_headers line.? I also added the line
>
>add_header all RelaysUntrusted _RELAYSUNTRUSTED_
>
>based on the suggestion in the TrustPath documentation at
>https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath
>
>The documentation there only suggests setting my trusted_networks and
>internal_networks, not clearing either of them.
>
>
>Now, when I manually check the messages, the X-Spam-RelaysUntrusted:
>header displays the mail host that my server received the message
>from. That seems proper. HOWEVER, even though that is supposed to be
>the host used for all IP based checks, DNSWL_HI is being triggered.

have you reloaded amavisd?

>The first untrusted host is not in the dnswl.org high confidence list.
>However the IP in X-Originating-Ip: is listed in dnswl.org's high
>confidence list.? I don't know why spamassassin would use that header,
>though, since it is below the Received: line for the first untrusted
>relay.

SA will use this header if it trusts server that set the header.
This should not be your case.

do you have anything set in amavis' home directory?
usually ~amavis/.spamassassin

>On 2022/12/27 18:20:35 Matus UHLAR - fantomas wrote:
>> >On 2022/12/26 23:47:41 Benny Pedersen wrote:
>> On 27.12.22 13:04, John Stimson via users wrote:
>> >Thanks -- I found a mechanism that empties the list of headers used to
>> >determine the originating IP.? I added this line to my local.cf:
>> >
>> >clear_originating_ip_headers
>>
>> I recommend checking:
>>
>> trusted_networks
>> clear_trusted_networks
>>
>> internal_networks
>> clear_internal_networks
>>
>> these to be set up properly instead of just clear_originating_ip_headers
>>
>> - you should still check them, as they give you opportunity to check
>proper
>> headers in DNS, not just in DNSWL.

--
Matus UHLAR - fantomas, uhlar@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.
Linux IS user friendly, it's just selective who its friends are...
RE: Re: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
users at spamassassin
Dec 28, 2022, 5:50 AM
Post #11 of 19 (909 views)
Permalink
Updates:

On 2022/12/28 12:45:48 Matus UHLAR - fantomas wrote:

> have you reloaded amavisd?

I restarted the amavisd-new.service and spamassassin.service after
editing /etc/spamassassin/local.cf

> do you have anything set in amavis' home directory?
> usually ~amavis/.spamassassin

~amavis/.spamassassin contains a file user.prefs that has only comment
lines.  Could /etc/spamassassin/local.cf be ignored when spamassassin is
invoked by amavis?  On the incoming mail , the X-Spam-RelaysUntrusted:
header is not being added for messages that are not flagged as spam.

There is another strange thing: I received two messages today that
triggered the RCVD_IN_DNSWL_HI test, but there was no X-Originating-IP:
header -- re-running the message through spamassassin from the command
line, the IP number from the first untrusted Received line was
specifically listed as being in lists.dnswl.org, even though a manual
test at the dnswl.org web site showed that the same IP was not in their
list.
Re: DNSWL_HI testing wrong Received header? [ In reply to ]
sausers-20150205 at billmail
Dec 28, 2022, 7:07 AM
Post #12 of 19 (909 views)
Permalink
On 2022-12-28 at 08:50:35 UTC-0500 (Wed, 28 Dec 2022 08:50:35 -0500)
John Stimson via users <john@idsfa.net>
is rumored to have said:

> Updates:
>
> On 2022/12/28 12:45:48 Matus UHLAR - fantomas wrote:
>
>> have you reloaded amavisd?
>
> I restarted the amavisd-new.service and spamassassin.service after
> editing /etc/spamassassin/local.cf
>
>> do you have anything set in amavis' home directory?
>> usually ~amavis/.spamassassin
>
> ~amavis/.spamassassin contains a file user.prefs that has only comment
> lines.  Could /etc/spamassassin/local.cf be ignored when spamassassin
> is invoked by amavis?  On the incoming mail , the
> X-Spam-RelaysUntrusted: header is not being added for messages that
> are not flagged as spam.
>
> There is another strange thing: I received two messages today that
> triggered the RCVD_IN_DNSWL_HI test, but there was no
> X-Originating-IP: header -- re-running the message through
> spamassassin from the command line, the IP number from the first
> untrusted Received line was specifically listed as being in
> lists.dnswl.org, even though a manual test at the dnswl.org web site
> showed that the same IP was not in their list.

Perhaps your DNS resolution is to blame. Are you using a local recursive
resolver that does no forwarding?



--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Re: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
uhlar at fantomas
Dec 28, 2022, 7:09 AM
Post #13 of 19 (909 views)
Permalink
>On 2022/12/28 12:45:48 Matus UHLAR - fantomas wrote:
>
>> have you reloaded amavisd?

On 28.12.22 08:50, John Stimson via users wrote:
>I restarted the amavisd-new.service and spamassassin.service after
>editing /etc/spamassassin/local.cf

spamassassin service is not needed when you use amavis, you can stop and
disable it.


>> do you have anything set in amavis' home directory?
>> usually ~amavis/.spamassassin
>
>~amavis/.spamassassin contains a file user.prefs that has only comment
>lines.? Could /etc/spamassassin/local.cf be ignored when spamassassin
>is invoked by amavis??

no, it's being used, but amavis won't notice the change until you reload
amavis (not spamassassin/spamd)

> On the incoming mail , the
>X-Spam-RelaysUntrusted: header is not being added for messages that
>are not flagged as spam.
>
>There is another strange thing: I received two messages today that
>triggered the RCVD_IN_DNSWL_HI test, but there was no
>X-Originating-IP: header -- re-running the message through
>spamassassin from the command line, the IP number from the first
>untrusted Received line was specifically listed as being in
>lists.dnswl.org, even though a manual test at the dnswl.org web site
>showed that the same IP was not in their list.

how do you use amavisd, do you use amavisd-milter?


--
Matus UHLAR - fantomas, uhlar@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.
Despite the cost of living, have you noticed how popular it remains?
RE: Re: Re: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
users at spamassassin
Dec 28, 2022, 9:55 AM
Post #14 of 19 (909 views)
Permalink
On 2022/12/28 15:09:36 Matus UHLAR - fantomas wrote:
> spamassassin service is not needed when you use amavis, you can stop and
> disable it.

Good to know.

On 2022/12/28 15:09:36 Matus UHLAR - fantomas wrote:
> >~amavis/.spamassassin contains a file user.prefs that has only comment
> >lines.  Could /etc/spamassassin/local.cf be ignored when spamassassin
> >is invoked by amavis?
>
> no, it's being used, but amavis won't notice the change until you reload
> amavis (not spamassassin/spamd)

I had definitely restarted the amavisd-new service.

On 2022/12/28 15:09:36 Matus UHLAR - fantomas wrote:
> how do you use amavisd, do you use amavisd-milter?

Postfix uses it as a content filter.  It is configured as described
here: https://help.ubuntu.com/community/PostfixAmavisNew

On 2022/12/28 15:07:31 Bill Cole wrote:

>Perhaps your DNS resolution is to blame. Are you using a local recursive
>resolver that does no forwarding?

The machine has bind9 running locally to provide DNS for its own domain,
and uses it for name resolution.  Bind9 is configured to use OpenDNS and
Google as forwarders.
Re: DNSWL_HI testing wrong Received header? [ In reply to ]
darkdevil at darkdevil
Dec 28, 2022, 10:13 AM
Post #15 of 19 (909 views)
Permalink
John,

No offence meant, but I would like to suggest you to also look at your
mail client and/or mail server configuration, especially some silly
"privacy" filters touching on headers.

It looks like something in your set up is preventing the two headers
References, and In-Reply-To from your client, to pass through.

This has "only" caused six different threads so far, - see
https://i.imgur.com/Mifw9kz.png

Den 28-12-2022 kl. 18:55 skrev John Stimson via users:
> On 2022/12/28 15:07:31 Bill Cole wrote:
>
>> Perhaps your DNS resolution is to blame. Are you using a  local
>> recursive
>> resolver that does no forwarding?
>
> The machine has bind9 running locally to provide DNS for its own
> domain, and uses it for name resolution.  Bind9 is configured to use
> OpenDNS and Google as forwarders.

^

Here you have the error. Stop that Google/OpenDNS stuff, as well as any
other public / shared resolvers.

DNS queries for DNS based reputation lists as these will need to pass
through directly.


Sounds like a PEBKAC.

->
https://cwiki.apache.org/confluence/display/spamassassin/CachingNameserver

> NOTE: A local DNS caching server should not forward to other DNS
> servers to ensure your queries are not combined with others.

--
Med venlig hilsen / Kind regards,
Arne Jensen
Re: Re: Re: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
uhlar at fantomas
Dec 28, 2022, 10:16 AM
Post #16 of 19 (909 views)
Permalink
On 28.12.22 12:55, John Stimson via users wrote:
>The machine has bind9 running locally to provide DNS for its own
>domain, and uses it for name resolution.?

This is the problem:

> Bind9 is configured to use
>OpenDNS and Google as forwarders.

BIND does NOT need forwarders and by using it, you mostprobably have created
this problem.

remove forwarders statement.
--
Matus UHLAR - fantomas, uhlar@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.
Save the whales. Collect the whole set.
Re: DNSWL_HI testing wrong Received header? [ In reply to ]
sausers-20150205 at billmail
Dec 28, 2022, 10:35 AM
Post #17 of 19 (909 views)
Permalink
On 2022-12-28 at 12:55:20 UTC-0500 (Wed, 28 Dec 2022 12:55:20 -0500)
John Stimson via users <john@idsfa.net>
is rumored to have said:
[...]
>
> On 2022/12/28 15:07:31 Bill Cole wrote:
>
>> Perhaps your DNS resolution is to blame. Are you using a local
>> recursive
>> resolver that does no forwarding?
>
> The machine has bind9 running locally to provide DNS for its own
> domain, and uses it for name resolution.  Bind9 is configured to use
> OpenDNS and Google as forwarders.

That's unfit for use with SA or anything else that uses DNSBLs. Many
DNSBLs intentionally do not provide useful service to the free open
resolvers. In the past some free DNS providers have also done things
that are harmful for mail servers, such as replacing NXDOMAIN replies
with default A responses. (I don't know if OpenDNS or Google is doing
that by default now.)

There's not really much gained by forwarding for a mail server, because
a local DNS cache will be MUCH faster on hits and will be fed by what
your mail server asks for, rather than by random other people browsing
the web.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Re: Re: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
jhardin at impsec
Dec 28, 2022, 1:28 PM
Post #18 of 19 (909 views)
Permalink
On Wed, 28 Dec 2022, Matus UHLAR - fantomas wrote:

> On 28.12.22 12:55, John Stimson via users wrote:
>> The machine has bind9 running locally to provide DNS for its own domain,
>> and uses it for name resolution.?
>
> This is the problem:
>
>> Bind9 is configured to use OpenDNS and Google as forwarders.
>
> BIND does NOT need forwarders and by using it, you mostprobably have created
> this problem.
>
> remove forwarders statement.


You can also set up per-DNSBL forwarding suppression while still
forwarding for other lookups:


// Don't forward DNSBL/URIBL lookups to ISP
zone "list.dnswl.org" IN {
type forward;
forward first;
forwarders { };
};

zone "multi.uribl.com" IN {
type forward;
forward first;
forwarders { };
};

...etc. for all DNSBL subdomains.



--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
These Sarah Brady types must be educated to understand that
because we have an armed citizenry, that a dictatorship has not
yet happened in America. These anti-gun fools are more dangerous
to Liberty than street criminals or foreign spies.
-- Theodore Haas, Dachau survivor
-----------------------------------------------------------------------
942 days since the first private commercial manned orbital mission (SpaceX)
Re: Re: Re: Re: Re: DNSWL_HI testing wrong Received header? [ In reply to ]
uhlar at fantomas
Dec 28, 2022, 6:27 PM
Post #19 of 19 (909 views)
Permalink
>>On 28.12.22 12:55, John Stimson via users wrote:
>>>The machine has bind9 running locally to provide DNS for its own
>>>domain, and uses it for name resolution.?

>On Wed, 28 Dec 2022, Matus UHLAR - fantomas wrote:
>>This is the problem:

>>>Bind9 is configured to use OpenDNS and Google as forwarders.

>>BIND does NOT need forwarders and by using it, you mostprobably have
>>created this problem.
>>
>>remove forwarders statement.

On 28.12.22 13:28, John Hardin wrote:
>You can also set up per-DNSBL forwarding suppression while still
>forwarding for other lookups:
>
>
> // Don't forward DNSBL/URIBL lookups to ISP
> zone "list.dnswl.org" IN {
> type forward;
> forward first;
> forwarders { };
> };
>
> zone "multi.uribl.com" IN {
> type forward;
> forward first;
> forwarders { };
> };
>
> ...etc. for all DNSBL subdomains.

while technically possible, it's really useless - as I said, BIND can
perfectly resolve by itself, it's afaik most used DNS server.

forwarding to open resolvers just opens your DNS to possible problems with
new and new zones.

--
Matus UHLAR - fantomas, uhlar@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.
LSD will make your ECS screen display 16.7 million colors

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal