Wakko Warner wrote:
*selectively snipped*
>> Second, I *think* you will need to split that into two separate SQL
>> calls. ELSE simplify. See below.
>
> That was 2 seperate SQL statements.
>
ACK - what I meant was each on their own 'condition = ' call.
(which a router may not be happy with anyway ...)
*snip*
>>> The entire ${lookup is not supposed to return anything.
>>>
One begs to ask why use it, then ..
;-)
*snip*
> Would be nice if there was a "null" router available. I plan on adding
> another "null" router to gather data for several others (and yes, I know
> that exim caches queries)
In the practical sense, any router that does not call a 'viable'
transport IS a 'null' router, though blackholing or specifically
transporting to /dev/null OR using an 'unseen' (that works) to reach a
router that is not 'null' may be considerably kinder to your queue AND
NOT generate DFB's
One might may or may not want suhc a router to verify. Or might want to
use the DB to verify instead of a router-walk at all.
BTW - speaking of DFB's - if you want your sender_verify probes to be
'handled' correctly, it may help to make their calls in such a manner as
to not appear to be originating on a zombified WinBox whose rDNS doesn't
match anything you have published in *your* DNS.
Check your logs for my attempt to honor your request to be 'CC'ed...
;-)
Bill
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
