John Fawcett:
> 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).
Actually, there is no legitimate character set for non-ASCII SMTP
commands. There is an RFC for UTF8 SMTP, but is not implemented
on any significant scale at this time. It creates major headaches
for envelope and content inspection, with non-identity MIME encoding
and with alternate email addresses.
Wietse
> 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
>
>
