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

Reply via email to