Mailing List Archive

RCVD_IN_DNSWL_HI false positives
Hi all,

Because of RCVD_IN_DNSWL_HI a bunch of SEO type stuff is getting
through. Strangely the domains are not listed in www.dnswl.org like
the one below is "fixtheweberrors.online":

IP address 173.82.162.98 is not whitelisted at dnswl.org.

Most of it is .online stuff. What am I missing? How can
RCVD_IN_DNSWL_HI be added if it's not in dnswl.org? Or maybe it was
and has since been removed? I find that hard to believe since
dnswl.org looks like it only has records for bigger sites.

Thanks,
Mike

Received: from [96.47.229.26] (unknown [96.47.229.26])
by shenzi.fixtheweberrors.online (Postfix) with ESMTPA id 3651DA77B;
Tue, 11 May 2021 22:17:27 -0400 (EDT)
Received: from shenzi.fixtheweberrors.online
(shenzi.fixtheweberrors.online [173.82.162.98])
by mail.ioplex.com (Postfix) with ESMTPS id 5090B11B9
for <sales@ioplex.com>; Wed, 12 May 2021 01:25:07 -0400 (EDT)

X-Spam-Report:
* -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high
* trust
* [173.82.162.98 listed in list.dnswl.org]
* 3.0 BAYES_95 BODY: Bayes spam probability is 95 to 99%
* [score: 0.9888]
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
* 0.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in digit
* (catherinebrooke321[at]gmail.com)
* 0.0 RCVD_IN_MSPIKE_L5 RBL: Very bad reputation (-5)
* [173.82.162.98 listed in bl.mailspike.net]
* 0.5 MISSING_MID Missing Message-Id: header
* 0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted
* 2.1 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
> Am 12.05.2021 um 21:02 schrieb Michael B Allen <ioplex@gmail.com>:

> X-Spam-Report:
> * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high
> * trust
> * [173.82.162.98 listed in list.dnswl.org]

173.82.162.98 is not in the dnswl.org database.

It’s likely you’re using one of the nameservers who are not only blocked from using dnswl.org free nameserver infrastructure, but where we needed to use additional methods to make them stop (ab)using our nameservers (namely, returning a „_HI“ result in the hope that whoever is responsible will finally notice).

— Matthias

--
Matthias Leisi
Katzenrütistrasse 68, 8153 Rümlang
Mobile +41 79 377 04 43
matthias@leisi.net
Skype matthias.leisi
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Wed, May 12, 2021 at 5:01 PM Matthias Leisi <matthias@leisi.net> wrote:
> > Am 12.05.2021 um 21:02 schrieb Michael B Allen <ioplex@gmail.com>:
>
> > X-Spam-Report:
> > * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high
> > * trust
> > * [173.82.162.98 listed in list.dnswl.org]
>
> 173.82.162.98 is not in the dnswl.org database.
>
> It’s likely you’re using one of the nameservers who are not only blocked from using dnswl.org free nameserver infrastructure, but where we needed to use additional methods to make them stop (ab)using our nameservers (namely, returning a „_HI“ result in the hope that whoever is responsible will finally notice).

Hi Matthias,

That is unfortunate. It's not entirely crystal clear to me that
deliberately returning false positives that allow potentially
destructive SPAM to get through filters is a good way to enforce usage
policy.

Mike
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On 2021-05-12 23:01, Matthias Leisi wrote:
>> Am 12.05.2021 um 21:02 schrieb Michael B Allen <ioplex@gmail.com>:
>
>> X-Spam-Report:
>> * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/,
>> high
>> * trust
>> * [173.82.162.98 listed in list.dnswl.org]
>
> 173.82.162.98 is not in the dnswl.org database.
>
> It’s likely you’re using one of the nameservers who are not only
> blocked from using dnswl.org free nameserver infrastructure, but where
> we needed to use additional methods to make them stop (ab)using our
> nameservers (namely, returning a „_HI“ result in the hope that whoever
> is responsible will finally notice).

would it not make sense to enable dnssec on dnswl.org nameservers ?

sorry for asking, i dont know much about dns servers
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
Hi!

I would suggest to follow rfc’s. So return 127.0.0.1 for example. Or don’t answer at all. Deliberate giving ‘yes to any request’ is something I can understand you would do but it’s plain wrong.

Thanks,
Raymond Dijkxhoorn

> Op 12 mei 2021 om 23:17 heeft Michael B Allen <ioplex@gmail.com> het volgende geschreven:
>
> ?On Wed, May 12, 2021 at 5:01 PM Matthias Leisi <matthias@leisi.net> wrote:
>>>> Am 12.05.2021 um 21:02 schrieb Michael B Allen <ioplex@gmail.com>:
>>>
>>> X-Spam-Report:
>>> * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high
>>> * trust
>>> * [173.82.162.98 listed in list.dnswl.org]
>>
>> 173.82.162.98 is not in the dnswl.org database.
>>
>> It’s likely you’re using one of the nameservers who are not only blocked from using dnswl.org free nameserver infrastructure, but where we needed to use additional methods to make them stop (ab)using our nameservers (namely, returning a „_HI“ result in the hope that whoever is responsible will finally notice).
>
> Hi Matthias,
>
> That is unfortunate. It's not entirely crystal clear to me that
> deliberately returning false positives that allow potentially
> destructive SPAM to get through filters is a good way to enforce usage
> policy.
>
> Mike
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
Hi Benny,

It’s the authoritive nameserver giving that answer. With likely a view or acl response. So adding dnssec would not make much of a difference here.

Thanks,
Raymond Dijkxhoorn

> Op 12 mei 2021 om 23:24 heeft Benny Pedersen <me@junc.eu> het volgende geschreven:
>
> ?On 2021-05-12 23:01, Matthias Leisi wrote:
>>>> Am 12.05.2021 um 21:02 schrieb Michael B Allen <ioplex@gmail.com>:
>>> X-Spam-Report:
>>> * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high
>>> * trust
>>> * [173.82.162.98 listed in list.dnswl.org]
>> 173.82.162.98 is not in the dnswl.org database.
>> It’s likely you’re using one of the nameservers who are not only
>> blocked from using dnswl.org free nameserver infrastructure, but where
>> we needed to use additional methods to make them stop (ab)using our
>> nameservers (namely, returning a „_HI“ result in the hope that whoever
>> is responsible will finally notice).
>
> would it not make sense to enable dnssec on dnswl.org nameservers ?
>
> sorry for asking, i dont know much about dns servers
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On 2021-05-12 23:30, Raymond Dijkxhoorn wrote:

> It’s the authoritive nameserver giving that answer. With likely a view
> or acl response. So adding dnssec would not make much of a difference
> here.

so dnssec is brokken ?

auth dnsservers or not, problem is when other dns servers cache
possitive results imho, and continue keep it, while negative expires
fast, but dns servers should relly expire on soa changes no matter ttl
is not expired

i am still no expert, just trying to understand the problem

i hate to see qname minimalzion in bind9 turned on by default, while
there is no fix for this on rbldnsd

would rbldnsd update dlz in bind9 redis in someway, i know it could dump
dns data as bind9 zone, but it would be nice to see it update dlz zone
database, to atleast make qname problem go away
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
> That is unfortunate. It's not entirely crystal clear to me that
> deliberately returning false positives that allow potentially
> destructive SPAM to get through filters is a good way to enforce usage
> policy.

We use the „return hi“ in cases where long times of using other methods does not reduce the query load on the free nameservers.

— Matthias
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
> I would suggest to follow rfc’s. So return 127.0.0.1 for example. Or don’t answer at all. Deliberate giving ‘yes to any request’ is something I can understand you would do but it’s plain wrong.

We do follow RFCs, and have a number of methods (not returning an answer, returning REFUSED etc). But you’d be surprised how long some admins do not act… In these cases (ie consistent query volumes way above the limits, and prolonged times of inactio), returning a „hi“ result is the last option. This has been the case for maybe 10 or so years.

— Matthias
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
Hi Benny,

The operator of the specific rbl is doing this, on purpose. Can’t make it more clear then that.

Dnssec would not add anything here.

Thanks,
Raymond Dijkxhoorn

> Op 13 mei 2021 om 00:01 heeft Benny Pedersen <me@junc.eu> het volgende geschreven:
>
> ?On 2021-05-12 23:30, Raymond Dijkxhoorn wrote:
>
>> It’s the authoritive nameserver giving that answer. With likely a view
>> or acl response. So adding dnssec would not make much of a difference
>> here.
>
> so dnssec is brokken ?
>
> auth dnsservers or not, problem is when other dns servers cache possitive results imho, and continue keep it, while negative expires fast, but dns servers should relly expire on soa changes no matter ttl is not expired
>
> i am still no expert, just trying to understand the problem
>
> i hate to see qname minimalzion in bind9 turned on by default, while there is no fix for this on rbldnsd
>
> would rbldnsd update dlz in bind9 redis in someway, i know it could dump dns data as bind9 zone, but it would be nice to see it update dlz zone database, to atleast make qname problem go away
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
Hello Matthias,

As a operator of a RBL I am way to familiar with this. We also see people still looking up domains on zones we phased out over 10 years ago. So not surprised at all…

But if people are seeing things listed they should not I am reluctant saying it’s wrong to do that.

Thanks,
Raymond Dijkxhoorn

> Op 13 mei 2021 om 00:12 heeft Matthias Leisi <matthias@leisi.net> het volgende geschreven:
>
> ?
>>
>> I would suggest to follow rfc’s. So return 127.0.0.1 for example. Or don’t answer at all. Deliberate giving ‘yes to any request’ is something I can understand you would do but it’s plain wrong.
>
> We do follow RFCs, and have a number of methods (not returning an answer, returning REFUSED etc). But you’d be surprised how long some admins do not act… In these cases (ie consistent query volumes way above the limits, and prolonged times of inactio), returning a „hi“ result is the last option. This has been the case for maybe 10 or so years.
>
> — Matthias
>
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Wed, May 12, 2021 at 6:10 PM Matthias Leisi <matthias@leisi.net> wrote:
>
> > That is unfortunate. It's not entirely crystal clear to me that
> > deliberately returning false positives that allow potentially
> > destructive SPAM to get through filters is a good way to enforce usage
> > policy.
>
> We use the „return hi“ in cases where long times of using other methods does not reduce the query load on the free nameservers.

I don't understand the technical details of all of this but what about
sending an error response just under the typical retry interval? If
you want to annoy someone, make it the one DNS server operator and not
the hundreds of SA endpoints using it. A lot of smaller companies like
me (I'm just me!) just use their hosting company DNS (linode for me)
and are completely oblivious as to what dnswl even is.

Maybe you would prefer that SA disable dnswl lookups in the default
config? Folks who are fluent in such things and have their own DNS
server will know how to flip it on.

Mike
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
Den 13-05-2021 kl. 02:19 skrev Michael B Allen:
> On Wed, May 12, 2021 at 6:10 PM Matthias Leisi <matthias@leisi.net> wrote:
>>> That is unfortunate. It's not entirely crystal clear to me that
>>> deliberately returning false positives that allow potentially
>>> destructive SPAM to get through filters is a good way to enforce usage
>>> policy.
>> We use the „return hi“ in cases where long times of using other methods does not reduce the query load on the free nameservers.
> I don't understand the technical details of all of this but what about
> sending an error response just under the typical retry interval? If
> you want to annoy someone, make it the one DNS server operator and not
> the hundreds of SA endpoints using it. A lot of smaller companies like
> me (I'm just me!) just use their hosting company DNS (linode for me)
> and are completely oblivious as to what dnswl even is.

See:
https://www.mail-archive.com/users@spamassassin.apache.org/msg107949.html
<https://www.mail-archive.com/users@spamassassin.apache.org/msg107949.html>

And then try to understand how DNS works:

You're sending a query, for example to Quad 9 's resolver, on it's IP
address 9.9.9.9, and in this example, from a location in Denmark.

$ dig TXT o-o.myaddr.l.google.com @9.9.9.9
o-o.myaddr.l.google.com. 47     IN      TXT     "188.122.68.219"

This reveals that Google sees the DNS request as coming from 188.122.68.219.

188.122.68.219 is owned/operated by i3d.net, and according to the public
information, that IP address seems to be a part of their
network/infrastructure in Germany.


So here, you're technically hiding behind someone else's identity (IP
address) to perform the query towards the final network, as they are
literally your middleman here.

No DNSBL/WL can see through your "middleman" and detect your
personal(/organisational) quota independently, when you're all hiding
behind the same "middleman".

The only thing being seen here, is the IP address of that particular
"middleman", and as such, all queries behind that middleman are all
being aggregated together, towards the total limit of 100'000 queries/24h.


Things such as e.g. trying to reach out to i3d.net's abuse desk, from
the example shown above, where the originating IP belongs their
organisation, doesn't work, at all.

See:

-> https://www.dnswl.org/?p=120 <https://www.dnswl.org/?p=120>
-> https://www.dnswl.org/?p=118 <https://www.dnswl.org/?p=118>
-> https://www.dnswl.org/?p=183 <https://www.dnswl.org/?p=183>


>
> Maybe you would prefer that SA disable dnswl lookups in the default
> config? Folks who are fluent in such things and have their own DNS
> server will know how to flip it on.

May I ask if you are actually reading and following the documentation
about the things you run?

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

It is not only just the best practice with a local resolver, but is as
close as it can be to "mandatory" with many block/welcome lists, such as
e.g. URIBL, Spamhaus, and several others.

At the link above, you want to make sure you catch the "NOTE:"-line.


In the past, I saw Spamhaus being criticized, apparently for something
that sounded like dropping queries with a firewall, which would lead to
long timeouts, causing the originating mail server to give up before the
responses were received, essentially leading to mails being deferred and
(sometimes) lost.

Such query dropping does (unfortunately) also means the queries often
will be magnified, as e.g. Linode's resolver in your case, will just try
another authoritative server for the zone.


That "returnhi" option is only used for a minority, and only in the very
extreme cases where other attempts have been tried, but with no positive
success for a long while, - which is also being mentioned in the link
from the top of this post.

In the end, there is no perfect solution that simply works for everyone,
and everything, at once.

It would of course be nice, ... if there was...

--
Med venlig hilsen / Kind regards,
Arne Jensen
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Wed, May 12, 2021 at 10:26 PM Arne Jensen <darkdevil@darkdevil.dk> wrote:
> Den 13-05-2021 kl. 02:19 skrev Michael B Allen:
> > On Wed, May 12, 2021 at 6:10 PM Matthias Leisi <matthias@leisi.net> wrote:
> >>> That is unfortunate. It's not entirely crystal clear to me that
> >>> deliberately returning false positives that allow potentially
> >>> destructive SPAM to get through filters is a good way to enforce usage
> >>> policy.
> >> We use the „return hi“ in cases where long times of using other methods does not reduce the query load on the free nameservers.
> > I don't understand the technical details of all of this but what about
> > sending an error response just under the typical retry interval? If
> > you want to annoy someone, make it the one DNS server operator and not
> > the hundreds of SA endpoints using it. A lot of smaller companies like
> > me (I'm just me!) just use their hosting company DNS (linode for me)
> > and are completely oblivious as to what dnswl even is.
>
> See:
> https://www.mail-archive.com/users@spamassassin.apache.org/msg107949.html
> <https://www.mail-archive.com/users@spamassassin.apache.org/msg107949.html>
>
> And then try to understand how DNS works:

I understand how DNS works as well as most I at least.

I do not understand why the default SA configuration uses dnswl but
then when someone does not read every minutia of documentation about
every possible option, SPAM is then used as a stick to get people to
change or pay for the service but not before being browbeaten about
not knowing how this convoluted mess works.

It is not completely trivial setup a caching name server. I literally
have two accounts so it's at least a serious nuisance.

> In the past, I saw Spamhaus being criticized, apparently for something
> that sounded like dropping queries with a firewall, which would lead to
> long timeouts, causing the originating mail server to give up before the
> responses were received, essentially leading to mails being deferred and
> (sometimes) lost.
>
> Such query dropping does (unfortunately) also means the queries often
> will be magnified, as e.g. Linode's resolver in your case, will just try
> another authoritative server for the zone.

Then like I suggested, instead of dropping entirely, maybe a delay
just under the retry interval would make all the difference.
Presumably dnswl is custom code? You could have a large array of
structs with ip and stats pre populated with pass entries for the paid
folk. When a request comes in, you hash the addr to get the right
bucket. If they're paid they pass. If not, you update the stats and if
they're over whatever limit everything from that server goes into a
500ms delay queue. You respond with success to keep the offensive DNS
server at arms length but passivated but the SA endpoint gets an
answer of "blocked".

Sending false positives that allows SPAM though is a bad way to enforce policy.

Mike
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Thu, 13 May 2021 00:11:52 +0200
Matthias Leisi wrote:


> We do follow RFCs, and have a number of methods (not returning an
> answer, returning REFUSED etc). But you’d be surprised how long some
> admins do not act… In these cases (ie consistent query volumes way
> above the limits, and prolonged times of inactio), returning a „hi“
> result is the last option.

But, presumably, you can't tell the difference between that case and a
new user connecting to shared cache.

Maybe they could just be blocked in the firewall.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On May 13, 2021, at 12:14 AM, Michael B Allen <ioplex@gmail.com> wrote:
> It is not completely trivial setup a caching name server. I literally
> have two accounts so it's at least a serious nuisance.

It's pretty simple to install unbound and set it up on most systems.

> Sending false positives that allows SPAM though is a bad way to enforce policy.

It sounds like they've tried other options but didn't get a response from abusive users so this is the 'last resort' option.

--
Daniel J. Luke
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
> Maybe they could just be blocked in the firewall.

This would multiply the traffic due to retries.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
>> Maybe they could just be blocked in the firewall.

On 13.05.21 16:44, Matthias Leisi wrote:
>This would multiply the traffic due to retries.

I agree. URIBL provides special result URIBL_BLOCKED, maybe that would be a
way (with high TTL)

But I'm afraid top abusers could still need to get false positives in order
to stop.
--
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.
Quantum mechanics: The dreams stuff is made of.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
I wonder if it would be sensible for spamassassin to have a
configuration option for all default-on dnsrbls (one option, applying to
all):

disabled
auto
enabled

where the default is auto, and auto means "enabled if resolver is
127.0.0.1, ::1 or localhost, else disabled".
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On 2021-05-13 19:34, Greg Troxel wrote:
> I wonder if it would be sensible for spamassassin to have a
> configuration option for all default-on dnsrbls (one option, applying
> to
> all):
>
> disabled
> auto
> enabled
>
> where the default is auto, and auto means "enabled if resolver is
> 127.0.0.1, ::1 or localhost, else disabled".

rfc 1700 enforcement ?

if this is global it does no good, but if it is added pr rule, it could
be usefull, but i fear it will delay releases of spamaassassin 4.0.0

i see still some mx have 127.0.0.1, it would be nice to see more dns
servers supported nullMX :/

would be nice spamassassin have default rules for this
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Thu, May 13, 2021 at 01:34:37PM -0400, Greg Troxel wrote:
>
> I wonder if it would be sensible for spamassassin to have a
> configuration option for all default-on dnsrbls (one option, applying to
> all):
>
> disabled
> auto
> enabled
>
> where the default is auto, and auto means "enabled if resolver is
> 127.0.0.1, ::1 or localhost, else disabled".

No. Local resolver could be configured to forward everything to Google. Or
all servers could have one central nameserver in the local network.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
Henrik K <hege@hege.li> writes:

> On Thu, May 13, 2021 at 01:34:37PM -0400, Greg Troxel wrote:
>>
>> I wonder if it would be sensible for spamassassin to have a
>> configuration option for all default-on dnsrbls (one option, applying to
>> all):
>>
>> disabled
>> auto
>> enabled
>>
>> where the default is auto, and auto means "enabled if resolver is
>> 127.0.0.1, ::1 or localhost, else disabled".
>
> No. Local resolver could be configured to forward everything to Google. Or
> all servers could have one central nameserver in the local network.

Why does the existence of that possibility mean "no'?

As it is, we have

it's on by default

which leads to

if the resolver SA is using is just for that instance of SA and
somehow local, things are ok

if the resolver chains to something big, it's not ok and you have to
disable dnsbl queries

What I proposed merely moves the default for non-local resolver
addresses, which means relatibe to the above:

people with non-local resolver addresses that can be used have to
enable dnsbls

people with non-local resolver addresses that shouldn't be used, used
to have a duty to disable and now it will be taken care of

It doesn't change anything for anybody else.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Thu, 13 May 2021, Henrik K wrote:

> On Thu, May 13, 2021 at 01:34:37PM -0400, Greg Troxel wrote:
>>
>> I wonder if it would be sensible for spamassassin to have a
>> configuration option for all default-on dnsrbls (one option, applying to
>> all):
>>
>> disabled
>> auto
>> enabled
>>
>> where the default is auto, and auto means "enabled if resolver is
>> 127.0.0.1, ::1 or localhost, else disabled".
>
> No. Local resolver could be configured to forward everything to Google.

True, but that would be a conscious configuration.

> Or all servers could have one central nameserver in the local network.

So add "on local network".

--
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
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Thu, May 13, 2021 at 02:52:38PM -0700, John Hardin wrote:
> On Thu, 13 May 2021, Henrik K wrote:
>
> > On Thu, May 13, 2021 at 01:34:37PM -0400, Greg Troxel wrote:
> > >
> > > I wonder if it would be sensible for spamassassin to have a
> > > configuration option for all default-on dnsrbls (one option, applying to
> > > all):
> > >
> > > disabled
> > > auto
> > > enabled
> > >
> > > where the default is auto, and auto means "enabled if resolver is
> > > 127.0.0.1, ::1 or localhost, else disabled".
> >
> > No. Local resolver could be configured to forward everything to Google.
>
> True, but that would be a conscious configuration.
>
> > Or all servers could have one central nameserver in the local network.
>
> So add "on local network".

Please describe to me how randomly looking at "/etc/resolv.conf" or
"dns_server" has any relevance on what route the queries will take in the
_end_, and why only very specific values found would imply some "conscious
configuration"?

Might as well create a SpamAssassin Training Academy website and not allow
SA to start without --i_have_read_manuals_and_tutorials_and_best_practises.
Well the first part could help since our wiki (and offcial docs) are pretty
scattered and outdated.
Re: RCVD_IN_DNSWL_HI false positives [ In reply to ]
On Thu, May 13, 2021 at 05:04:47PM +0200, Matus UHLAR - fantomas wrote:
> > > Maybe they could just be blocked in the firewall.
>
> On 13.05.21 16:44, Matthias Leisi wrote:
> > This would multiply the traffic due to retries.
>
> I agree. URIBL provides special result URIBL_BLOCKED, maybe that would be a
> way (with high TTL)

We already have RCVD_IN_DNSWL_BLOCKED.

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

1 2  View All