Skip to content
Nigel Metheringham edited this page Nov 30, 2012 · 3 revisions



Am I to understand that the database lookups must only return one value? They can not return a list of values? The documentation seems to indicate that it's possible to return a list.


Lookups can be used in two different situations, and what they return is different in the two cases. (Be thankful Exim 3 is gone; there was yet another case!)

  1. You can use a lookup in any expanded string. The syntax is
${lookup ..... }

In this case, whatever is looked up replaces the expansion item. It may be one value or a list of values. Whether a single value or a list is acceptable or not depends on where you are using the string expansion. If it is for an option that expects just one value, then only one value is allowed (for example).

  1. You can make use of the lookup mechanism to test whether something (typically a host name or IP address) is in a list. For example,
hosts = a : b : c

in an ACL tests whether the calling host's name matches a , or b , or c . Now, suppose you want to keep the list of names in a database, or cdb file, or NIS map, or... By writing

hosts = pgsql;select ....

you are saying to Exim: Run this lookup; if it succeeds, behave as if the host is in the list; if it fails, the host is not in the list. > You are using the indexing mechanism of the database as a fast way of

checking a list. A simpler example is

hosts = lsearch;/some/file

where the file contains the list of hosts to be searched. The complication happens when a list is first expanded before being interpreted as a list. This happens in a lot of cases. You can therefore write either of these:

hosts = cdb;/some/file
hosts = ${lookup{something}cdb{/some/file}}

but they have different meanings. The first means see if the host name is in the list in this file . The second means run this lookup and use the result of the lookup as a list of host items to check . In the second case, the list could contain multiple values (colon separated), and one of those values could even be cdb;/some/file . Flexibility does lead to complexity, I'm afraid.