On 26/01/11 12:05, Claudio Prono wrote: > Uhm, i have another information about that case: the mail are sended to > postfix from an antispam appliance (Symantec). Can be a problem of > config of that antispam results illegal characters are sended to postfix? > > Anyway, here is my conf > > user = postfix > password = xxxxxxxxxxxx > hosts = 127.0.0.1 > dbname = postfix > table = domain > select_field = transport > where_field = domain > > Can i add something to solve that problem? > > Cordially, > > Claudio Prono. > Claudio the problem is happening because your column definition for "domain" column has character set latin1 (which by default has collation latin_swedish_ci) and the data being passed from postfix is in utf8 (which by default has collation utf8_general_ci).
Unless postfix is setting utf8 explicity via "set" commands, which I believe it is not, then the character set used by postfix is coming from mysql defaults (which you can see by listing "mysqladmin variables"), see character_set_client and character_set_connection" The character set mismatch between database column and postfix lookup key is not creating problems for ascii data. For non-ascii utf8 characters, mysql is unable to make the comparison between the database column and lookup key because mysql cannot chose the right comparison method (collation). as mentioned by others the best solution is probably to adjust your column definition. If that is not an immediate solution, then the simplest thing may just be to redefine your query to pass data using the same character set as your database column. That can be done inside the "query" parameter instead of using "table", "select_field" and "where_field". user = postfix password = xxxxxxxxxxxx hosts = 127.0.0.1 dbname = postfix query = select transport from domain where domain= _latin1 '%s' That won't make the query necessarily return results, but it should avoid the "illegal mix of collations" errors. John