------- 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 <[email protected]> 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:;"@mailin-ng2.xxx So let's define: addresslist foo = Undisclosed-Recipient:;@mailin-ng2.xxx then: $ exim -C /etc/exim/test.conf -be > ${if match_address{[email protected]}{+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: [email protected]: 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 {[email protected]}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 [email protected] -be > ${if match_address{[email protected]}{+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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
