Re: [Exim] DNSBL Question/Alert

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: James P. Roberts
Data:  
Para: Exim Users Mailing List
Asunto: Re: [Exim] DNSBL Question/Alert
> [ On Wednesday, January 8, 2003 at 10:07:47 (-0000), Mark Douglas
wrote: ]
> > Subject: Re: [Exim] DNSBL Question/Alert
> >
> > > the (Osirusoft) DNS blocking list check began timing out
> >
> > Yesterday morning I was caught by this. Most SMTP connections were
> > timing out and we eventually traced it to the Osirusoft lookup
> > hanging. I removed that lookup and things seem normal.
>
> If most of your SMTP client connections were timing out when a DNSBL

was
> unavailable then either your SMTP client are _very_ poor quality and
> non-standard implementations, or your DNS resolver is waiting far too
> long for responses.


I would disagree with your above assessment. It wasn't the SMTP client
connections that were timing out.

The connections were being deferred due to the "+defer_unknowns" option
on the DNSBL lookups. Without that option, Exim just treats a DNSBL
lookup timeout as passing the test. With that option set, Exim defers
any message from any source which suffers a timeout during any of the
DNSBL lookups; thus, when the DNSBL server went down, EVERY message
suffered a timeout during that test, and EVERY message was deferred (Ok,
at least, every message that had the DNSBL test applied).

>
> Clients are supposed to wait at least FIVE minutes for the intitial

220
> message, and also 5 minutes for the response to the MAIL and each RCPT
> command too.
>
> If your Exim was delaying the initial 220 response, or its response to
> MAIL and RCPT commands for over five minutes, then your DNS resolver

is
> seriously broken.


As noted above, this was not the problem.

>
> FYI none of the systems I manage had any problem handling the
> osirusoft.com outage, though they did exhibit more than the average
> number of simultaneous connections for the duration of the outage

(which
> is only to be expected when each connection lasts at least a full

minute
> or two).


Because you were not using "+defer_unknowns" in your DNSBL list.

Jim Roberts
Punster Productions, Inc.