Mailing List Archive

On 4/9/2021 10:34 AM, Benny Pedersen wrote:
> above ip is not listed yet, with inho is sign of no maintain at all
> anymore


So I noticed that this IP you mentioned is a heavily-listed IP that is
currently listed on many DNSBLs, including many of the best and most
reliable and accurate ones. (I think that was part of your point.) So
you're complaining that SORBS isn't listed this one. Maybe you were
providing this as a representative example, correct? So I guess you're
saying that there are more like this?

But for the sake of clarity, let me just say that no DNSBLs should ever
be judged too harshly for "false negatives" - no DNSBL has the exact
same view of the worldwide email data - and each DNSBL's false positive
prevention filters will always make SOME mistakes that cause "false
negatives" - that's a very acceptable price to pay considering that no
system can ever be perfect.

Low false positives AND overall catch-rates AND overall UNIQUE
catch-rates (blocking stuff everyone else is still missing) - are all
far more important metrics.

(you might be disappointed with SORBS in those areas too? - that's fine
- I'm just trying to clarify that overly judging a DNSBL based on
/*particular*/ false negatives can be overly harsh and might miss the
good things that a DNSBL has to offer)

-- Rob McEwen, invaluement +1 (478) 475-9032

On 09/04/2021 15:57, Rob McEwen wrote:

On 4/9/2021 10:34 AM, Benny Pedersen wrote:

above ip is not listed yet, with inho is sign of no maintain at all anymore

So I noticed that this IP you mentioned is a heavily-listed IP that is currently listed on many DNSBLs, including many of the best and most reliable and accurate ones. (I think that was part of your point.) So you're complaining that SORBS isn't listed this one. Maybe you were providing this as a representative example, correct? So I guess you're saying that there are more like this?


But for the sake of clarity, let me just say that no DNSBLs should ever be judged too harshly for "false negatives" - no DNSBL has the exact same view of the worldwide email data - and each DNSBL's false positive prevention filters will always make SOME mistakes that cause "false negatives" - that's a very acceptable price to pay considering that no system can ever be perfect.

Low false positives AND overall catch-rates AND overall UNIQUE catch-rates (blocking stuff everyone else is still missing) - are all far more important metrics.

(you might be disappointed with SORBS in those areas too? - that's fine - I'm just trying to clarify that overly judging a DNSBL based on particular false negatives can be overly harsh and might miss the good things that a DNSBL has to offer)

That sounds reasonable. But my experience is that spamhaus RBLs (zen, zrd, dbl) have a zero false positive rate (or so low that I have never found one). IMHO if an email is matched by spamhaus it is the sender's big problem, not the recipient's. (And I have no connection to spamhaus...)

(you might be disappointed with SORBS in those areas too? - that's fine
- I'm just trying to clarify that overly judging a DNSBL based on
/*particular*/ false negatives can be overly harsh and might miss the
good things that a DNSBL has to offer)

Probably not that.  It is just SORBS.  Like when a friend gets you
kicked out of a bar for trouble you didn't cause:

"I GOT SORBED."

Rob, I gotta say that I am impressed with the whole Spamhaus-dqs program
and their use of customer keyed DNS zone queries.  Seems to be the way
around the client DNS forwarder issues.  How are you guys at Invaluement
tracking in that area?  I saw some esp stuff on Github.

-- Jared Hall

On 4/10/2021 6:55 AM, Jared Hall wrote:
> Rob, I gotta say that I am impressed with the whole Spamhaus-dqs
> program and their use of customer keyed DNS zone queries.  Seems to be
> the way around the client DNS forwarder issues.  How are you guys at
> Invaluement tracking in that area?

I'm not sure I'm understanding what you're saying? Are you referring to
the fact that their paid customers doing direct queries (NOT the free
stuff!) - use zone names that have a unique key embedded into the actual
zone - so that the queries can then be distinguished by this unique key?
- thus eliminating the need to use the client's local DNS servers'
public IP as the method of allowing/denying direct queries? Is that what
you're referring to?

> Seems to be the way around the client DNS forwarder issues

If I'm correct about what you meant - then yes - this eliminates
problems that used to happen when trying to track customers, and
permission, by IP - because when tracking by an embedded code - then it
doesn't matter from WHERE the queries come - and queries that come from
public DNS servers (8.8.8.8 or 1.1.1.1) - can be distinguished one from
the other - whereas when not doing this - it's impossible to tell
distinguish the queries from each other and know who is doing them. This
became especially important because so often the default caching DNS
server gets auto-flipped to 8.8.8.8, sometimes without the IT person's
knowledge! And many IT people think that pointing to 8.8.8.8 is the
textbook way to setup DNS - and have never even heard of things like BIND.

Is THAT what you're talking about?

If so, at invaluement, we've been doing this for 3 years now - but we
still have a lot of work to do in migrating many long-time customers
over to our new system. And it was developed before I even knew that
Spamhaus was doing it this way, and  this involved some extremely
complex custom modifications of rbldnsd (I couldn't afford to hire an
expensive high-quality C++ programmer at the time - so it took me about
100 hours of very intense programming to do that! It didn't help that
I'm not very good at C++!). I'm not even sure when Spamhaus started this.

Our new system for doing this now involves 86 servers in 43 cities
around the world - which enables our clients to get their queries
answered much faster due to accessing an invaluement DNS server with an
extremely close geolocation. Queries then tend to get answered in a very
low number of milliseconds - often <10ms.

-- Rob McEwen https://www.invaluement.com +1 (478) 475-9032

On Sat, 10 Apr 2021 08:56:19 -0400
Rob McEwen wrote:

> On 4/10/2021 6:55 AM, Jared Hall wrote:
> > Rob, I gotta say that I am impressed with the whole Spamhaus-dqs
> > program and their use of customer keyed DNS zone queries.  Seems to
> > be the way around the client DNS forwarder issues.  How are you
> > guys at Invaluement tracking in that area?
>
> I'm not sure I'm understanding what you're saying? Are you referring
> to the fact that their paid customers doing direct queries (NOT the
> free stuff!) - use zone names that have a unique key embedded into
> the actual zone - so that the queries can then be distinguished by
> this unique key?

It's not just paid customers, anyone can register.

On 2021-04-10 15:28, RW wrote:
> On Sat, 10 Apr 2021 08:56:19 -0400
> Rob McEwen wrote:
>
>> On 4/10/2021 6:55 AM, Jared Hall wrote:
>> > Rob, I gotta say that I am impressed with the whole Spamhaus-dqs
>> > program and their use of customer keyed DNS zone queries.  Seems to
>> > be the way around the client DNS forwarder issues.  How are you
>> > guys at Invaluement tracking in that area?
>>
>> I'm not sure I'm understanding what you're saying? Are you referring
>> to the fact that their paid customers doing direct queries (NOT the
>> free stuff!) - use zone names that have a unique key embedded into
>> the actual zone - so that the queries can then be distinguished by
>> this unique key?
>
> It's not just paid customers, anyone can register.

and use there own key with public dns servers, hillerious

spamassassin shows the dqs key with default rules, so workaround is meta
rule

dont use public dns servers ever, free or not

after all its not free

can i get a ansver on sorbs ?, is it time to not use sorbs in
spamassassin or is there a way to contakt sorbs ?, i have giving up
trying :(

hopefully dnsbl owners is professionel people until it shown thay are
not

On Sat, 10 Apr 2021 15:44:54 +0200
Benny Pedersen wrote:


> dont use public dns servers ever, free or not
>

It's not about using public caches. They are going to block look-ups
from generic rDNS as well. I think they are already blocking some VPS
address blocks.

On 2021-04-10 15:59, RW wrote:
> On Sat, 10 Apr 2021 15:44:54 +0200
> Benny Pedersen wrote:
>
>
>> dont use public dns servers ever, free or not
>>
>
> It's not about using public caches. They are going to block look-ups
> from generic rDNS as well. I think they are already blocking some VPS
> address blocks.

and if users of dqs do try that dqs key is shared

the first dqs rule set had that problem in _REPORT_

hope rules in 4.x.x will handle this in generic without using meta rules

On 4/9/2021 8:26 AM, Dominic Raferd wrote:
>>
> That sounds reasonable. But my experience is that spamhaus RBLs (zen,
> zrd, dbl) have a zero false positive rate (or so low that I have never
> found one). IMHO if an email is matched by spamhaus it is the sender's
> big problem, not the recipient's. (And I have no connection to spamhaus...)

I agree. I have found most other BL's in particular Google's internal
BL to be horrible at false positives as a matter of fact.

Ted