Hi Terry, I thought of another thing to look at. The uribl lookups are done in a script that is included in the Exim4U installation here: /etc/exim/exim.pl/exim_surbl.pl This script checks three URL blacklists: SURBL, URIBL and DBL. The exim log entries that you sent in your first email were all only URIBL lookups. So, you may consider re-enabling the lookups in /etc/exim/exim.conf and disabling only the URIBL blacklist directly in /etc/exim/exim.pl/exim_surbl.pl to determine if the problem is only with the URIBL blacklist or with all three blacklists. Look at lines 61 through 65 in exim_surbl.pl: # The following ariables enable or disable the SURBL, URIBL and DBL # lookups. Set to 1 to enable and 0 to disable. my $surbl_enable = 1; my $uribl_enable = 1; my $dbl_enable = 1; Here, you can disable/enable each blacklist individually. If, for some reason, you find that the problem only exists with the URIBL blacklist then you can keep the script running and benefit from the other two blacklists. This script was written by Erik Mugele and you can read more about it here: http://www.teuton.org/~ejm/exim_surbl/ If you find that all three lists generate false positives, then I would suggest that the problem probably is directly related to this installation's DNS lookups. Whereas, if the problem only occurs with the URIBL then I'm not sure what to say. In any event, Erik Mugele's script is well known and popular within the exim community and this is the first time that I have ever heard of this type of problem that was not caused by the use of a public or large ISP's DNS servers. So, if you make any progress diagnosing this problem please let me know what you find. Thanks, Gordon On 06/24/2014 09:12 AM, Terry wrote:
Hi by there own address I meant a gmail one so they noticed the block. They do have there own caching dns server and every thing seems in order. I have disabled the check for them so things are fine now. But it was a bit puzzling