You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jeff Koch <je...@intersessions.com> on 2022/05/13 21:42:04 UTC

RCVD_IN_DNSWL

Hi:

We're getting numerous false positives on 'RCVD_IN_DNSWL_HI RBL'. When I 
check these IP's (193.106.175.39, for example) at https://www.dnswl.org 
they are NOT listed.

                * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at 
https://www.dnswl.org/, high
                *      trust
                *      [193.106.175.39 listed in list.dnswl.org]

How can I fix this?  I've run sa-update and it does not help.

TIA - Jeff

Re: RCVD_IN_DNSWL

Posted by Henrik K <he...@hege.li>.
On Wed, May 18, 2022 at 08:16:15AM +0300, Henrik K wrote:
> On Fri, May 13, 2022 at 05:42:04PM -0400, Jeff Koch wrote:
> > 
> > Hi:
> > 
> > We're getting numerous false positives on 'RCVD_IN_DNSWL_HI RBL'. When I check
> > these IP's (193.106.175.39, for example) at [1]https://www.dnswl.org they are
> > NOT listed.
> > 
> >                * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at [2]https://
> > www.dnswl.org/, high
> >                *      trust
> >                *      [193.106.175.39 listed in list.dnswl.org]
> 
> The test_log() function in 3.4, which produces the "listed in" line you see
> is quite broken.  I suspect you are simply seeing results for wrong test,
> 193.106.175.39 is listed in SORBS.
> 
> To see what is queried, check the debug log for some message:
> spamassassin -t -D async < message 2>&1 | grep dnswl.org
> 
> Don't forget that it's reversed:
> 
> 4.3.2.1.list.dnswl.org = 1.2.3.4

Never mind, I think the log text itself should always be correct, the IP and
listname should not get mixed up..

Doesn't hurt to always check the debug output, use "-D all" to find
everything.


Re: RCVD_IN_DNSWL

Posted by Henrik K <he...@hege.li>.
On Fri, May 13, 2022 at 05:42:04PM -0400, Jeff Koch wrote:
> 
> Hi:
> 
> We're getting numerous false positives on 'RCVD_IN_DNSWL_HI RBL'. When I check
> these IP's (193.106.175.39, for example) at [1]https://www.dnswl.org they are
> NOT listed.
> 
>                * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at [2]https://
> www.dnswl.org/, high
>                *      trust
>                *      [193.106.175.39 listed in list.dnswl.org]

The test_log() function in 3.4, which produces the "listed in" line you see
is quite broken.  I suspect you are simply seeing results for wrong test,
193.106.175.39 is listed in SORBS.

To see what is queried, check the debug log for some message:
spamassassin -t -D async < message 2>&1 | grep dnswl.org

Don't forget that it's reversed:

4.3.2.1.list.dnswl.org = 1.2.3.4


Re: RCVD_IN_DNSWL

Posted by Łukasz Michalski <lm...@zork.pl>.
On 5/13/22 23:42, Jeff Koch wrote:
>
> Hi:
>
> We're getting numerous false positives on 'RCVD_IN_DNSWL_HI RBL'. When 
> I check these IP's (193.106.175.39, for example) at 
> https://www.dnswl.org they are NOT listed.
>
>                * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at 
> https://www.dnswl.org/, high
>                *      trust
>                *      [193.106.175.39 listed in list.dnswl.org]
>
> How can I fix this?  I've run sa-update and it does not help.
>
> TIA - Jeff

My case:
https://www.mail-archive.com/users@spamassassin.apache.org/msg108935.html

Yours may or may not be the same.

Regards,
Łukasz


Re: RCVD_IN_DNSWL

Posted by Arne Jensen <da...@darkdevil.dk>.
If this issue is actually directly related to 
intersessions.com/avspamfilter.com, it looks like you may need to obtain 
a paid subscription at dnswl.org (as well as other DNSxL/URIxL lists you 
want to have access to):

>
>         Terms and Conditions
>
> *Users, Data Access and Subscriptions*
>
> Every user of dnswl.org must read and understand the terms and 
> conditions for the use of dnswl.org data.
>
> A “user” is an organisation or an individual who operates hardware 
> and/or software for filtering spam, for aggregating e-mail reputation 
> data or for reselling such services to end-users, using dnswl.org 
> data. Typically, e-mail service providers, anti-spam appliance vendors 
> and similar organisations are considered to be “users”. A 
> “subscription” is a paid access for a single user to dnswl.org data.
>
> Every user with more than 100’000 queries per day on the public 
> nameserver infrastructure and every commercial vendor of dnswl.org 
> data must register with dnswl.org and purchase a subscription. [...]. 
> It is the responsibility of the user to ensure that he is properly 
> registered and has a valid subscription, even if access to the public 
> nameservers is not explicitly blocked for that particular user.

The web/mail packages offered by your organisation appears to be what I 
would call commercial products, and considering the issues to be with  
intersessions.com/avspamfilter.com, I would personally go as far as to 
say that I don't believe you would be fitting any criteria to avoid a 
subscription.

You would literally be in the very same (or similar) situation with the 
majority of all other major DNSxL/URIxL list out there, when we're 
talking commercial use.


Den 14-05-2022 kl. 04:35 skrev Jeff Koch:
> o-o.myaddr.l.google.com. 60     IN      TXT     "3.228.172.202"
>
> whoami-ecs.v4.powerdns.org. 60  IN      TXT     "ip: 3.239.157.44, 
> netmask: no ECS"
>
None of those two IP addresses seem to point (directly) back to you in 
any way, ... do you actually operate them?

Amazon (AWS, EC2, SES, ... whatever) that seems to be the only possible 
contact for those IP addresses have so far shown literally no interest 
in mitigating issues originating from their network.

As we've been unable to see any signs of remorse, or even remediation, 
in regards to limiting the (potential) abuse of our public 
infrastructure, there are a handful of origins within their network, 
which are unfortunately blocked with the "returnhi" flag.

Even if we assumed it was solely legitimate attempts to use the public 
infrastructure, taking alone the *few* top most of all "abusive" Amazon 
entries on the ACL, those addresses are producing very well over 100 
times the quota, considering the 100'000 queries/day limit.

The alternative (and very limited) use of the "returnhi" flag as seen in 
this situation, only happens as a last resort, like e.g. after months 
with no signs of remorse/remediation.

-- 
Med venlig hilsen / Kind regards,
Arne Jensen

Re: RCVD_IN_DNSWL

Posted by Jeff Koch <je...@intersessions.com>.
See below:

On 5/13/2022 8:41 PM, Arne Jensen wrote:
> Den 13-05-2022 kl. 23:42 skrev Jeff Koch:
>> We're getting numerous false positives on 'RCVD_IN_DNSWL_HI RBL'. 
>> When I check these IP's (193.106.175.39, for example) at 
>> https://www.dnswl.org they are NOT listed.
>>
>>                * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at 
>> https://www.dnswl.org/, high
>>                *      trust
>>                *      [193.106.175.39 listed in list.dnswl.org]
>>
>> How can I fix this?  I've run sa-update and it does not help.
>
> From the machine running your SpamAssassin, please run the following 
> commands:
>
> 1. dig TXT o-o.myaddr.l.google.com
>
o-o.myaddr.l.google.com. 60     IN      TXT     "3.228.172.202"
>
> 2. dig TXT whoami-ecs.v6.powerdns.org
>
NA
>
> 3. dig TXT whoami-ecs.v4.powerdns.org
>
whoami-ecs.v4.powerdns.org. 60  IN      TXT     "ip: 3.239.157.44, 
netmask: no ECS"

Jeff
>
> And provide a response with their outputs.
>
> -- 
> Med venlig hilsen / Kind regards,
> Arne Jensen

Re: RCVD_IN_DNSWL

Posted by Arne Jensen <da...@darkdevil.dk>.
Den 13-05-2022 kl. 23:42 skrev Jeff Koch:
> We're getting numerous false positives on 'RCVD_IN_DNSWL_HI RBL'. When 
> I check these IP's (193.106.175.39, for example) at 
> https://www.dnswl.org they are NOT listed.
>
>                * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at 
> https://www.dnswl.org/, high
>                *      trust
>                *      [193.106.175.39 listed in list.dnswl.org]
>
> How can I fix this?  I've run sa-update and it does not help.

 From the machine running your SpamAssassin, please run the following 
commands:

1. dig TXT o-o.myaddr.l.google.com
2. dig TXT whoami-ecs.v6.powerdns.org
3. dig TXT whoami-ecs.v4.powerdns.org

And provide a response with their outputs.

-- 
Med venlig hilsen / Kind regards,
Arne Jensen