Subject: [Asrg] Comments/Mods (2.2.1)

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 11:24:32 +1100

This is going to be difficult - pasting on the first part of the section 
even though the whole section needs to be reviewed.

Currently:

2.2.1.  Listings SHOULD Be Temporary

   In many cases, listings can exist for long periods of time past the
   conditions leading to the listing's creation, and/or the listed
   entity has changed ownership.

   Generally speaking, listings SHOULD be considered temporary, and
   should expire on their own at some point in the future unless reasons
   for listing still exist.

Comments:

In the (currently fictional) prime number DNSBl all listings are permanent.

In the SORBS DNSbl we have an attitude if a listing is a problem someone 
will query it, if not (in most cases) it is not a problem to stay listed.

_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 22:39:41 -0400

> 2.2.1.  Listings SHOULD Be Temporary

...

> In the (currently fictional) prime number DNSBl all listings are permanent.

Note the paragraph I kept in above.

Seth could set up a "every week check to see if this IP is still prime, 
and if not, delist" process.  But I'm sure he could come up with a proof 
that if the IP is currently prime, it'll _stay_ prime, and optimize out 
the "every week..." bit ;-)

Fully in compliance either way.

> will query it, if not (in most cases) it is not a problem to stay listed.

It's been our experience that with effective detection, the occasional 
email that gets through before the thing relists is a smaller price to 
pay than the initial bafflement/damage incurred by someone being 
allocated the listed IP 6 months later who may have a devil of a time 
figuring out how to get out from under it.  At least with certain kinds 
of lists.

As I've mentioned elsewhere, both we (and Spamhaus) synthetically expire 
NJABL proxy entries before use (here, in the XBL respectively), because 
we could _see_ that older NJABL entries had appreciably higher FPs, and 
in my experience seemed to be borne out with SORBS proxy/socks (by 
inference and knowledge of SORBS expiration policies and sufficiently 
higher overall FPs to be of concern)

The CBL expiration interval seems extremely short compared to just about 
everything short of Spamcop, but it sure doesn't seem to suffer for it. 
  Neither does Spamcop.

Many people have used the argument over the years that DNSBLs are a 
better solution than local manual blacklists _because_ they're centrally 
managed by someone who (presumably) knows what they're doing and at 
least occasionally re-evaluates/re-assesses their listings in some form. 
  I'm sure that the people acquiring AEGIS netspace will agree, or those 
being given newly released ARIN space when faced with manually 
implemented BOGON lists.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 14:05:42 +1100

> higher overall FPs to be of concern)

SORBS Proxies do expire (1 year), so do the trojans (28 days, then 30 
days for DB removal).  The open-relay entries do not (they are trivially 
retested and are significantly fewer).  The spam entries do not expire 
from the database, they are just exported as part of the 
'spam.dnsbl.sorbs.net' zone - which is the 'day dot spamming hosts' list 
- not included by default in any of the aggregate zones.

The new SORBS bot spam list (not public yet) has an expiry of hours.
> least occasionally re-evaluates/re-assesses their listings in some form.

I have never said 'because the entries are re-evaluated/re-assessed', I 
always say because it's centrally managed.  One place to get removed.  
The prime number entries do not need to be reassessed or reevaluated 
because it's a constant, it will never change, there is no point in 
spending CPU cycles checking to see if something has changed.
> being given newly released ARIN space when faced with manually 

I have messages from ARIN indicating 24.100.0.0/14 was returned to ARIN 
at least 6 months ago and they are now starting to assign new netblocks 
from there.  I will be expiring the entire range from all SORBS DBs 
shortly (if anything exists).  Some entries in that range could have 
been perm entries, only the return to ARIN makes the listing change (ie 
something out of our control requires entry changes, there are certainly 
no "Temporary Entries"). 

I'm having trouble explaining myself ... hope you got the gist.

Regards,

Mat

---

From: Seth <[email-masked]>
Date: Tue, 1 Apr 2008 23:35:53 -0400 (EDT)

> the "every week..." bit ;-)

Temporal logic is fun.

But I actually implement by checking each time (trial division by all
the primes under 65536, there aren't that many).  Does that make the
entries permanent or extremely ephemeral?

Seth