Uribl.com Website Review

We are currently investigating connectivity issues in Virginia which are causing intermittant packet loss and preventing our website from loading. If you exerpience this issue, try to load the page again and it should work. We hope to have a resolution in the next 24 hours. For those that cannot update spamas*as*in versions, please see old news below APRIL 6, 2015: NEW TLD SPAM for details on how to update becoming a new norm to try to avoid RBLs and URIBLs alike. Because real-time blacklist services are mostly reactive in nature, these short high volume campaigns can sneak by 10-30% of the spam run before blacklistings kick in. A nice tactic to counter these efforts, is to use SMTP delays. By introducing a delay, you allow real-time blacklists a small window for identification and publication of the new information. It will also drop quite a few spam bots which dont want to hang around that long Note, this will effectively delay all your incoming mail by 60 seconds, and may increase your SMTP concurrencies, so please monitor after rcpt to: (ie SpamAs*as*in at queue level). To give delay to connection time RBL lookups prior to EHLO, you will want to move to postfix 2.8+ and use postscreen (greet pause) to accomplish this. If you have implemented SMTP delays on other MTAs and would like to share them with us, please contact us and let us know. campaigns in order to capitalize on the reactive nature of blacklist services. In the past, it could take up to 4 minutes for us to identify, list, rebuild, and syncronize the update. Recent campaigns we have investigated have sent 80-90% of their payload within 3 Because of this, we have made a handful of enhancements to improve our identification speed and reduce the list time latency. As a result, we have reduced identification times by up to 100 seconds for new spam campaigns, by improving the speed at which we deliver live query data into our system. All users should see immediate results from these changes.