Re: [Exim] Two Bugs 4.34 - match_domains and dnsdb

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Nico Erfurth
Date:  
À: Silmar A. Marca
CC: exim-users
Sujet: Re: [Exim] Two Bugs 4.34 - match_domains and dnsdb
Silmar A. Marca wrote:

> Exim 4.34 have two Bugs:
>
> 1) match_domains don't search if "+domain_list" is a Mysql Query. If
> "+domain_list" is a mysql query, the condition is aways true.
> example:
> MYSQL_HELO_DOMAINS = SELECT domain.domain_name FROM domain


This query is bogus, it always returns data, as long as you have
something in your table. You need to use a where-clause, to make that
work, like

MYSQL_HELO_DOMAINS = SELECT 1 from domain where \
domain_name='${quote_mysql:$sender_helo_name}'

Exim does NOT check the value of the lookup, it only checks for
SOMETHING to be returned. Please read the docs on this.

http://www.exim.org/exim-html-4.30/doc/html/spec_10.html#IX726

> #------------------------------------------------------------------------
> 2) DNSDB return DEFER on ACL
> example in helo_acl (try using helo=rionb43.dc.glb.com):
>   drop   log_message    = "DENY - Helo - $sender_helo_name forged heloname
> detected"
>          message        = No you are not ME or OURS (HELO was $sender_helo_name)
>         condition      = ${if match {${lookup
> dnsdb{a=$sender_helo_name}{$value}{}}} \
>                               {$interface_address} \
>                               {true}{false}}
> The error: temporarily rejected EHLO or HELO xxx.xx.xx: failed to expand ACL
> string "${if match {${lookup dnsdb{a=$sender_helo_name} {$value}}}
> {true}{false}}": lookup of "a=rionb43.dc.glb.com" gave DEFER:


# host rionb43.dc.glb.com
Host rionb43.dc.glb.com not found: 2(SERVFAIL)

It's ok for exim to give a DEFER here, that's by design. The underlying
resolvers returns a temporary error, so exim can't tell whatever the
name exists or not. As a workaround you could use the
dns_again_means_nonexist option(Again, check the docs). IIRC there is
already an wishlist-item, to make exim react more predictable in such a
case. But currently it works as all the other lookups work.

Nico