3 Replies Latest reply on Jan 3, 2011 9:38 PM by dmitri

    About cache update of TrustedSource in HIP8.0

      Happy New Year!

      I use the TrustedSource function in HIP8.0. Several days ago, I found that it blocked ip address which is Google Public DNS. I submit a review application and yesterday it was changed from 'High Risk' to 'Mimimal Risk'. But now HIP8.0 still blocks it. I know from the product guide that HIP8.0 adopts a cache architecture to reduce the latency. I wonder how often the cache updates and when will not be blocked by HIP8.0.

      Thank you.

        • 1. Re: About cache update of TrustedSource in HIP8.0

          Hi Alex,


          Each IP address has a potentially different reputation for each  direction (inbound/outbound), protocol (TCP, UDP, ICMP) and port number  it has been seen on. In your case, the IP address had a High Risk email reputation (inbound TCP port 25), which did get corrected but should not have triggered an alert since that IP is not involved in any email sending behavior. Can you post some details, if you still have them, for that alert so that we can track down what happened there?




          Dmitri Alperovitch

          • 2. Re: About cache update of TrustedSource in HIP8.0


            Thanks for your reply. Since this issue occurred, I have disabled the TrustedSource. When I just enable it again, everything works now, and HIP doesn't block any more. Therefore I can't provide any evidence now. Previously, when I visited any website, I can see in the log that HIP8.0 blocks and then my OS use the alternative to solve the domain names. When I ping, HIP allows it. But when I ping, HIP blocks it, and the log says TrustedSource - Get Ratings. In the command line window it says 'General Failure'. Given that things are working now, I wonder generally how long it will take for HIP to update its TrustedSource cache, and whether it is possible for users to update/clear the cache mannually.


            • 3. Re: About cache update of TrustedSource in HIP8.0

              Ok. I see what happened here. The cache was not the issue - typically an entry will not stay in the cache for long (I believe it's typically a few mins). The issue here was that when the email reputation of that IP was adjusted per your original requests, its DNS and ICMP reputations were not - that was fixed this morning. Sorry for the problem

              1 of 1 people found this helpful