Re: [exim] Trapping string expansion failures

On 2010-09-22 at 16:27 +0100, Ben wrote:
> Thanks for the reply. Unfortunately that still doesn't work. I still get a 451
> when the ldap lookup fails. It simply stops the verify at that point, and
> doesn't decline and move onto the next router.

This means that instead of "{no}" or "fail" (for a forced expansion
failure) you have an unforced failure. Which suggests that the problem
is not that the data is absent but that there's a problem talking to
LDAP. (So the condition got you closer but not all the way).

Exim does not provide a mechanism to have unforced expansion failures be
handled as anything other than a "defer". That quickly leads to
non-deterministic routing which leads to debugging hell.

Your choices are:
* provision redundant LDAP servers, to provide service reliability in
the face of component unreliability
* batch-dump LDAP to files which can be distributed, verified,
canaried, deployed, etc and automate that to happen every 10 minutes
if there has been an update in LDAP (or anyway).
* hack on the Exim sources, provide a new knob to have unforced
expansion failures be a "decline" instead of a "defer"
* pay/convince someone else to do so for you
* use a different MTA

Myself, I would use one of the first two. I'm not convinced of a
use-case that doesn't create more problems than it solves for having
arbitrary failures turn into decline -- sure, Exim will provide knobs to
shoot yourself in the foot, but I don't fancy the support burden of
explaining how people have done so, thus coding this option does not
appeal to me personally. That doesn't mean that patches won't be
accepted.

> I still can't figure out a way to get around this, bar changing the source
> code to alter behaviour wrt to lookup failures. But that'd break too many
> existing configurations to be realistic. I can't believe I'm the first person
> to have wanted this, but I'm stumped as to how to proceed.

If the LDAP server which has been configured simply doesn't exist,
that's a configuration error which is a temporary local problem, thus
the defer. The way around this is multiple servers.

> One thing I have turned up is that a lookup against a flat file (e.g. ${lookup
> lsearch{/etc/exim/mailaliases}{$value}fail} ) will fail (IMHO) properly if the
> file doesn't exist. The router declines and moves on. The documentation also
> mentions that dnsdb failures behave in a similar fashion. Is it expected
> (and/or desired) behaviour for other database lookups to work differently?
> MySQL lookups fail/defer in the same way as LDAP does (I just checked).

I agree that this inconsistency is awkward. With a do-over, it might be
done differently, but changing this would break existing setups. Thus a
new option.

Conceptually though, there's a difference between "file absolutely is
not there" and "could not connect to the server".