URIBL Blocked - SpamAssasin
-
What's present in the resolv.conf
?0 -
3 IP's related to the company who host my server/data centre and options rotate options timeout:1 0 -
options rotate options timeout:1
Interesting, I've not seen that in the resolv.conf before. The reason I asked is due to the "Free for some" method URIBL utilizes - Most RBL servers use a "Free for some" method, whereas long as a given DNS server isn't performing too many requests, it's allowed. But for a DNS server that is too busy, (eg: 8.8.8.8 is very busy), it will be blocked from doing RBL queries, since it no longer qualifies as the "Free for some" method, and would then fall under the category where payment is required to perform that volume of RBL queries. So when this occurs, the assumption is the dns servers you're using are performing too many queries to the RBL - like a form of rate-limiting. The solution would be to use nameservers that haven't hit that limit with the URIBL. You might try using CloudFlare's to see, but I couldn't guarantee they hadn't reached that limit since they're public.0 -
My current data centre is UKFast, I'd imagine that thier DNS servers have probably hit the limit. Even though I don't host my own name servers, my server still has DNS tables, as these are created with a new account etc. Is it possible for me to add my own IP in resolve.cnf ? 0 -
As my server isn't fully populated yet, I've taken a risk, I'm not sure what implications this will have. ?? I now manually add my DNS at registra level and use thier name servers. I found the IP of thier NS2 name server, and added this as the top entry in resolve.cnf. I no longer see the URIBL error, and my sites still appear to be working. 0 -
Your own name servers are not recommended as resolvers. We use Google's name servers, i.e: Nameserver 8.8.8.8 Nameserver 8.8.4.4 + one IP provided by the datacenter. From resolv.conf man page: rotate sets RES_ROTATE in _res.options, which causes round robin selection of nameservers from among those listed. This has the effect of spreading the query load among all listed servers, rather than having all clients try the first listed server first every time.
without "roate" the 1st nameserver IP is always used 1st, and if it fails then 2nd, etc.0 -
Actually Google's will hit the limit for the pretty frequently, which is why I went out on a limb and suggested CloudFlare's, which are substantially faster than Googles due to the caching they utilize and are more secure using DNS over TLS and DNS over HTTPS. 0 -
Any reason why I shouldn't use my own name server as a resolver Although when I say mine, it's not physically mine, it's that of the registra 123-reg.co.uk Incidentally, I don't see any errors. 0 -
I'm not using my own nameserver. In fact, I don't even have bind installed. In resolve.cnf I have 4 IP's The IP address of the NS2 server of my registra (123-reg) and 3 which belong to the data centre who I rent my server through (UKFast) Since adding the 123-reg IP, I no longer see the URIBL errors, and don't yet see any problems (that i'm aware of) on the my server. 0 -
Technically, that's not your name server :) That's your registrar's, since your host DNS remotely. 0 -
I'm sort of back to square one now. Updates failed last night due to unreliable resolvers. I ran /scripts/check_unreliable_resolvers, Which came back with a large list of IP's some of which had red stops signs against them, some have geen ticks. I removed the registra NS server entry from resolve.cnf, and the resolver check exited successfully. 0 -
It may be that your registrar doesn't have their NS set up to be resolvers. There's a decent list of Public DNS resolvers here: Public recursive name server - Wikipedia If you want to check it out. 0 -
Thanks Lauren I'll have a play with these over the weekend. I owe you one :) 0 -
I tried about 5 of those public resolvers, and i'm afraid they all suffer the same fate. Maybe something that I have to live with. It's not overly important, as I can clearly see in exin regect log that my other RBL's are perfoming well. It would just be nice not to see the URIBL failure. 0 -
Rather than modifying resolv.cfg, I modified /etc/mail/spamassassin/local.cf and added dns_server xxx.xx.xx.xx xxx.xx.xx.xx being the IP address of 123-reg NS servers. lets see what this brings 0 -
I have the same thing - no longer see the error "ADMINISTRATOR NOTICE: The query to URIBL was blocked", but also no reference to URIBL in any message headers, so no messages has been rejected by URIBL, so URIBL seems not working. 0 -
Just to confirm, are you expecting this to show up in the mail headers? @serg499 @keat63 ? 0 -
Yes, like all other SA content details: Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_REMOTE_IMAGE Message contains an external image
We shouldn't?0 -
Interesting - can you let me know the exact modifications you're making to the system so I can do some testing on my end? Since the original content of the thread is more than a year old, I'd just like to confirm those details. It may also be a good idea to submit a ticket to our team so we can check this directly on the server for you. 0
Please sign in to leave a comment.
Comments
21 comments