Nime wrote: ↑
I'm not from China.
My DNS is 127.0.0.1 / WAN IP: 126.96.36.199
Is dbl.spamhaus.org alternative to multi.surbl.org?
You don't have to be IN China to have your DNS routed TRHOUGH China. Anyway, the point was not that anyone having this issue is in China, but just to point out that your DNS is obviously messed up and it could be for many reasons.
Open cmd window and type "nslookup microsoft.com.multi.surble.org". The response should be " can't find microsoft.com.multi.surble.org: Non-existent domain".
If you get ANY OTHER answer that will trigger hmailserver to see the lookup as a positive result. A positive result from multi.surbl.org will be a dns response code like: 127.0.0.64
If you get a regular IP address, which is perhaps the IP of the domain you're checking - that means something is WRONG. The response from multi.surbl.org should ONLY BE a 127.0.0.x response code or NOTHING (NXDOMAIN). Anything else is a problem with your DNS.
From their FAQ:
I'm using an anti-spam or anti-phishing DNS proxy, and I'm seeing legitimate sites marked as unsolicited.
There are some DNS proxy or modification services that change the responses from certain DNS queries in order to prevent users from visiting sites advertised in phishing, unsolicited messages, etc. This can cause errors when using SURBLs if the proxies return an IP address of an alternative (safe) web site. The modified IP address can have an incorrect effect on SURBL list identification depending on where the bit patterns happen to be in the modified response. The result is that legitimate sites may be misidentified, but the effect appears to be somewhat random or arbitrary.
A solution is to disable such site correction or modification features on servers or clients doing SURBL queries. Alternatively, consider using regular (non-modifying) nameservers for those systems. Often the best solution is to set up a local caching nameserver.
Note also that SURBL applications may be incompatible with DNS modification or proxy services that change the DNS query results of non-matches (NXDOMAIN results) for non-existent sites.
Note that as of 1/25/07, OpenDNS no longer modifies results for SURBL lists. It should now be safe to use OpenDNS with SURBL applications. If you find you are behind a firewall or proxy that is modifying SURBL DNS queries incorrectly, one solution is to set up a local caching nameserver. A local caching server can significantly improve performance also.
I'm using my provider's nameservers, and I'm seeing legitimate sites marked as unsolicited.
Some ISPs such as Verizon and Charter are reportedly modifying some DNS NXDOMAIN responses in a way that causes what look like false positives on domains that are not blacklisted. Unfortunately this breaks DNS responses for SURBLs and other blacklists. Please check with your ISP if you are seeing DNS responses modified in this way. Verizon has an opt-out procedure with instructions on switching to DNS servers that do not change NXDOMAIN responses. Others such as Charter have opt-out nameservers that reportedly do not support NXDOMAIN, in which case none of their nameservers may be compatible with DNS blacklists. One solution is to not use your provider's nameservers, for example by setting up your own local caching nameserver instead. Most operating systems have built-in support for running your own nameservers, and a local nameserver can significantly improve performance.
Based on the above, your problem could be your ISP's DNS is faulty, or the router is misconfigured or hijacked. Either way, the solution is to get DNS back onto your server (bypass your router and ISP for DNS).
On your server, open networking > your NIC properties > Internet Protocol Version 4 properties > manually set DNS option to either opendns (188.8.131.52, 184.108.40.206) or google dns (220.127.116.11, 18.104.22.168). I don't remember if a restart is required.
THEN open cmd prompt > "nslookup microsoft.com.multi.surble.org" and see if you get the correct response (NOTHING).