At 21:14 29.04.2003 +0200, Carlos wrote:
Could be. Do you have a local dns server? If you don't, perhaps you could set one as cache, and perhaps the "not found" answer would be inmediate. I'm unsure of this, but you could try.
I use a local dns server - but I think, since the the inactive RBL is like a dead dns server, you cannot avoid the timeout.
Mmm :-? Yes, probably. But... that would be once you find the correct rbl server, and I think you said the default one was wrong. Once you configure the right one, then speeding it up would be a different matter, I guess. Could be documented somewhere :-?
I believe that it should be possible with the following options (found them in /usr/share/sendmail/m4/proto.m4): _OPTION(Timeout.resolver.retrans, `confTO_RESOLVER_RETRANS', `5s') _OPTION(Timeout.resolver.retrans.first, `confTO_RESOLVER_RETRANS_FIRST', `5s') _OPTION(Timeout.resolver.retrans.normal, `confTO_RESOLVER_RETRANS_NORMAL', `5s') _OPTION(Timeout.resolver.retry, `confTO_RESOLVER_RETRY', `4') _OPTION(Timeout.resolver.retry.first, `confTO_RESOLVER_RETRY_FIRST', `4') _OPTION(Timeout.resolver.retry.normal, `confTO_RESOLVER_RETRY_NORMAL', `4') Lower the values for RETRANS and RETRY could lower the overall-time for dns lookups (that's my assumption...). I tried it with RETRANS of 3s and RETRY of 1, but I realized more "IP name lookup failure" messages in /var/log/mail (I 'realized', that doesn't mean that there were really more). Now I'm going with a RETRANS of 2s and a RETRY of 2 - this should be high enough for a good RBL and low enough for some other servers only waiting 30sec for an answer after the initial connect. Bad is only, that I don't know how to proof, that this config-changes really do what I want them to do. Perhaps starting sendmail in debug-mode could reveal some informations, but in _which_ debug-mode (there seem to be a lot!)? Patrick