Re: [exim] dnsdb question

Top Page
Delete this message
Reply to this message
Author: Marc Perkel
Date:  
To: Graeme Fowler
CC: exim-users
Subject: Re: [exim] dnsdb question
Thanks - that worked.

set acl_c_rdns = ${lookup
dnsdb{defer_never,ptr=$sender_host_address}{$value}}

Graeme Fowler wrote:
> On Wed, 2007-12-05 at 13:57 -0800, Marc Perkel wrote:
>
>> Having a small issue.
>>
>> set acl_c_rdns = ${lookup dnsdb{ptr=$sender_host_address}{$value}{}}
>>
>> Works except that if the lookup fails I get DEFER. What I want is if the
>> lookup fails to get an empty string. What am I doing wrong?
>>
>
> Well...
>
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch09.html#SECTdnsdb
>
> states:
>
> "If the lookup does not succeed, the fail keyword causes a forced
> expansion failure – see section 11.4 for an explanation of what this
> means."
>
> ...and in turn,
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch11.html#SECTforexpfai states:
>
> "If, instead of a “false” substring, the word “fail” is used (not in
> braces), the entire string expansion fails in a way that can be detected
> by the code that requested the expansion."
>
> This is handled differently according to the expansion in use. In your
> case, it's a dnsdb lookup, so the following applies:
>
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch09.html#SECID67
>
> "The dnsdb lookup fails only if all the DNS lookups fail. If there is a
> temporary DNS error for any of them, the behaviour is controlled by an
> optional keyword followed by a comma that may appear before the record
> type. The possible keywords are “defer_strict”, “defer_never”, and
> “defer_lax”. With “strict” behaviour, any temporary DNS error causes the
> whole lookup to defer. With “never” behaviour, a temporary DNS error is
> ignored, and the behaviour is as if the DNS lookup failed to find
> anything. With “lax” behaviour, all the queries are attempted, but a
> temporary DNS error causes the whole lookup to defer only if none of the
> other lookups succeed."
>
> I believe the answer lies therein :)
>
> Graeme
>
>
>