Fritz, I think you miss the point of my usage. The URI in the URIBL cache is obviously a list of URI. They are obviously tagged as good or bad at the time they were inspected.
Which of the "good" URI should actually be "bad" and should be added to a URIBL? How do I prove that? Remember, I run my own DNSBL and URIBL. So, because the URIBL cache includes "good" URI, "for my usage", I have the URIBL cache disabled and consider the URIBL cache to be broken. Any length of time that makes the URIBL cache useful, causes "good" URI to be "good" until they are aged out of the cache. Consider this sequence of events: 1. Spam message delivery is attempted 1a. Message contains URI, but URI are not listed in any URIBL 1b. Message origin IP is not listed in any DNSBL 2. Message passes through ASSP 2a. Message URI added to cache as "good" 2b. Message IP added to cache as "good" 3. Message is inspected manually and found to be spam 3a. One or more URI added to local URIBL 3b. IP address added to DNSBL 4. Over several hours, 100 more spam like #1 arrive for delivery 4a. Maybe origin IP is same as #1. If so, it is "good" in cache. Never checks DNSBL, where it is bad. 4b. URI is good in cache. Never checks URIBL, where it is bad. 5. I have not checked if expiration is updated by appearance in a message or if expiration is set on entry into cache and never updated. Worst case for "good" message is that the cache expiration is updated by appearance in a message. So, if one uses only public DNSBL and URIBL, having "good" URI and IP in cache might be "okay". But "good" items in cache still defeat new listings. If you run your own DNSBL and/or URIBL, having "good" in cache is a hindrance to being responsive. Also, I run three ASSP servers for redundancy, so manually removing items from cache is not fun. What might be useful, is using cache, but having a "Preferred DNSBL" and a "Preferred URIBL", which are checked before the cache, where "bad" result would override a "good" in the cache. Michael Thomas Mathbox 978-687-3300 Toll Free: 1-877-MATHBOX (1-877-628-4269) > -----Original Message----- > From: Fritz Borgstedt [mailto:[email protected]] > Sent: Sunday, January 02, 2011 12:54 PM > To: ASSP development mailing list > Subject: Re: [Assp-test] Enhancement Suggestion > > > ASSP development mailing list <[email protected]> > schreibt: > >By adding the code I added, my goal was too get a clean list of the > >URI in > >the message, so that they could be added to a URIBL. So, I would > >certainly > >want the "good" and "bad" URI listed. > > > The URIBL Cache of ASSP is already collecting good and bad URIs. > Set URIBLCacheInterval to 14 days to get a long list. > Set URIBLCacheIntervalMiss even longer. > The cache contains two different records: > > Status 1: Hit > 112.213.88.2121292016835 1 multi.surbl.org<-127.0.0.36 > Status 2: Miss > 100automobile.de1293958887 2 > > -------------------------------------------------------------- > ---------------- > Learn how Oracle Real Application Clusters (RAC) One Node > allows customers > to consolidate database storage, standardize their database > environment, and, > should the need arise, upgrade to a full multi-node Oracle > RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Assp-test mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-test > > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
