------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1153
--- Comment #9 from Phil Pennock <pdp@???> 2011-09-24 11:45:09 ---
You keep censoring the samples you provide, which makes it hard to examine
what's happening. You also have something weird happening, because:
To: Undisclosed-Recipient:;
is valid and should not have been treated as a left-hand-side and then
qualified. How did that address come to exist?
Question 1: did you built Exim yourself? If so, why are you using dynamically
loaded lookups? They slow things down and add complexity to the upgrade
process. They're intended for vendors who distribute packages to others, who
might not have all of the dependencies installed. Those packages should take
care of ensuring that a lookup module is never out of sync with the main Exim
binary, to avoid weird failure modes.
The error message comes from search_findtype(), perhaps called via
search_findtype_partial(). It means that the internal table of searches did
not contain the entry and the string being looked up was literally the empty
string.
As previously noted, one way to get that is with quote_<type> without
specifying a type, so:
$ exim -be
> ${quote_:foobar}
Failed: unknown lookup type ""
Normal lookups without a type specified return "missing lookup type" if an
alphabetic character isn't found where the lookup type should be. Which leads
to method 2 for getting this error message:
> ${lookup {foo}partial-{bar}}
Failed: unknown lookup type ""
> ${lookup {foo}partial-*{bar}}
Failed: unknown lookup type ""
The third place it can come from is for string matching, for lookups of the
form:
cdb;/path/to/cdbfile
On a hunch, I added to "domainlist local_domains" the item: ;fred
$ exim -C /etc/exim/test.conf -bt foobar
LOG: MAIN PANIC DIE
unknown lookup type ""
$ exim -C /etc/exim/test.conf -be
> ${if match_domain{example.com}{+local_domains}}
2011-09-24 10:11:08 [81089] unknown lookup type ""
Hrm. You had:
"Undisclosed-Recipient:;"@???
So let's define:
addresslist foo = Undisclosed-Recipient:;@mailin-ng2.xxx
then:
$ exim -C /etc/exim/test.conf -be
> ${if match_address{snert@???}{+foo}}
2011-09-24 10:16:34 [81162] unknown lookup type ""
(Keeping the quotes in that addresslist definition leads to a syntax error)
So let's create "/tmp/datasource" containing one line:
foo@???: Undisclosed-Recipient:;@mailin-ng2.xxx
because this lets us have a lookup return data like that, much as your MySQL
might be doing:
$ exim -be
> ${lookup {foo@???}lsearch{/tmp/datasource}}
Undisclosed-Recipient:;@mailin-ng2.xxx
I suspect that somewhere, "Undisclosed-Recipient:;" is being included as an
item in an addresslist/... as a result of one of your queries.
addresslist snert = ${lookup {$sender_address}lsearch{/tmp/datasource}}
$ exim -C /etc/exim/test.conf -f foo@??? -be
> ${if match_address{wibble@???}{+snert}}
2011-09-24 10:20:19 [81410] unknown lookup type ""
So at this point I think you're constructing a list somewhere, based on a
${lookup} to insert text into the list as list items, as a string expansion,
rather than using a lookup as member _of_ the list.
String expansion happens first. Results are parsed for list separators.
Result is then iterated over, and a leading semi-colon can be bad. You're
effectively eval'ing your data
You want your lookup to happen as a defined lookup, not as a string expansion
item, so that the results aren't subject to being examined as anything other
than raw data.
Thus for my example above:
addresslist snert = lsearch;/tmp/datasource
and for you, I suggest auditing the data in your MySQL database as returned by
the VIRTUAL_DOMAINS lookup, and look at rewriting the lookup to be of the form:
mysql;SELECT something FROM somewhere WHERE col1 = '${quote_mysql:$domain}'
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
