Re: [exim] Default enabling of dnsdb

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] Default enabling of dnsdb
W B Hacker wrote:
> Dean Brooks wrote:
>> On Sun, May 10, 2009 at 02:37:20AM +0800, W B Hacker wrote:
>>> Brian Blood wrote:
>>> I get the impression those participating in the thread are not aware
>>> that the Exim reverse_host_lookup has sufficiently thorough logic to
>>> discriminate between 'good enough' and 'NFW' returns.
>> Neither reverse_host_lookup or the $host_lookup_failed variables are
>> acceptable for testing explicitly for the existance of PTR records.
>> Both will fail if the forward lookup fails.
>>
>> Also, those mechanisms do not give enough granularity over DNS
>> timeouts on *just* the PTR lookup itself. The $host_lookup_deferred
>> will be set if either the PTR or the forward lookup times out, which
>> compounds the problem further.
>>
>> I am unaware of any other way to do this without using dnsdb.
>>
>> --
>> Dean Brooks
>> dean@???
>>
>
> I believe your last statement.
>
> That doesn't flag it immutable.
>
>
> What do you suppose this does?
>
>
>    # C_1 PTR RR Test
>    #
>    warn
>     condition    = ${if eq{$sender_host_name}{}{yes}{no}}
>     log_message  = C_1 Null return for PTR RR search. KMELHEA

>
> The real 'experts' here can probably do that in 1/10 the byte-count...
>
> Bill
>


.. or at least fix it 'coz it was the wrong one..

;-)

THIS is what works:

   # CONNECT_3A BFBI test for outright absence of a PTR RR
   #
   deny
     logwrite    = C3A Checking for basic presence of PTR RR
     condition   = ${if eq{$interface_port}{25}}
     !hosts      = : +relay_from_hosts
     condition   = ${if and{{def:sender_host_address} \
                    {!def:sender_host_name}}{yes}{no}}
     log_message  = C3A No PTR RR found for $sender_host_address



NB: key conditional shamelessly stolen from a post by Marc Sherman 3+
years ago:

http://www.mail-archive.com/exim-users@exim.org/msg08258.html

Exemptions for our non-MTA boxen's cron reports and port 587 submission
inferred.

TESTED today to NOT trigger on 'generic' PTR RR, NOR on 'stale'
(once-valid, but now 'orphaned') PTR RR's.

The 'full' reverse_host_lookup test series has actually been invoked to
derive the above, (see ~/src/hosts.c)..

.. but full results are not tested until a subsequent acl clause to
determine if the PTR RR found is of any actual *use* in an smtp environment.

A more all-around useful test, of course.

That said, no 'extra' code is needed, there is a modest saving in
session time and log verbosity by bailing-out earlier.

Risk of falsing due to DNS response delays has yet To Be Determined
(here, anyway).

Bill