Man thanks to those who responded. I was mainly wondering how the inability to do blacklist checks would impact the overall ability of SpamAssassin to detect spam. Given the responses, I'll go in a different direction. I'll move the site to a VPS, where I can have more control over SpamAssassin and DNS configuration.
Thanks! Tom On 5/2/20 3:25 AM, Jari Fredriksson wrote: > I have too had a problem of this in my masscheck box. It is a cloud VM > in Google Cloud and they do like to provide a /etc/resolv.conf for > their own DNS which has been next to impossible to overcome. I do > replace it in the beginning of my masscheck process with my own but to > no avail. > > I now figured out I can add this to auto-mass-check.cf and going to > see how it works. > > spam@gauntlet ~ $ grep dns gcloud/auto-mass-check.sh > echo "dns_server 127.0.0.1" >> spamassassin/user_prefs > > br. jarif > > On 30.4.2020 22.28, Richard Doyle wrote: >> First result on Google: >> http://cweiske.de/tagebuch/uribl_blocked.htm >> >> Short version: URIBL will block you if you use any of the big DNS >> providers, such as 8.8.8.8. >> >> >> On 4/30/20 11:59 AM, Tom Williams wrote: >>> Hi! I'm new to this mailing list, but not new to SpamAssassin. I've >>> used it on and off for a number years. :) Recently, (within the past >>> 6 months or so) I enabled it for email in a shared web hosting >>> environment (we host with InMotionHosting). Anyway, due to the >>> volume of >>> email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED' >>> entries in the SpamAssassin header injected in the headers of incoming >>> mail. If our server can't use URIBL to check mail, will that have an >>> adverse or negative impact on SpamAssassin's ability to detect/identify >>> spam? Our host is running SpamAssassin 3.0 (shudders, I know it's >>> ancient). >>> >>> Thanks in advance! >>> >>> Tom >>>
