Chris Lewis wrote:
Matthew Sullivan wrote:
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.
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)
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.
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 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.
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.
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg