Arnt Gulbrandsen:
> On Wednesday, June 4, 2014 11:16:51 PM CEST, Wietse Venema wrote:
> > * Postfix table queries are case-insensitive. I don't see any attempt
> > to implement that for UTF8 addresses. This leaves an ambiguity.
>
> I looked at this now.
>
> As I read the code, tables mostly map to lower case and then do a binary
> comparison. The mysql and pgsql tables may additionally use the database
> server's ilike operation. Finally, lowercase() maps U to u, but leaves 0xC0
> as 0xC0, even if the Postfix server runs in a locale where the lowercase
> form of that is 0xE0.
>
> Is that correct?
That question is not applicable. Postfix locale is "C", and
lowercase() only translates ASCII characters.
> I can provide a supplementary patch that provides case insensitivity for
> unicode. It's easy, but there are several ways to do it, and I don't know
> which you prefer.
>
> 1. Toupper/tolower in Postfix, with the usual table. This adds the bulk of
> a table and is language-independent but imperfect. The well-known problem
> is i/?. (The lowercase("I") equvalent is "?" in Turkish and a handful of
> other locales.)
>
> 2a. Toupper/tolower that call out to ICU if EAI is enabled and there's any
> non-ASCII is in the argument. This slows down toupper()/tolower() but
> Postfix escapes having the table and ICU devotes considerable effort to
> correctness. It's easy to compose the string, too (composition means to use
> ? instead of "a"+"ring above").
>
> 2b. Ditto, but calling a language-sensitive function in ICU, so that i is
> equal to ? if the Postfix server runs in one of those locales. I'm unhappy
> about this alternative ? a Swiss service provider may well service both
> Kazakh and Korean users and how should the service providers's Postfix be
> configured?
>
> 3. Switching to titlecase. A bigger change. Titlecase is a form in which in
> which case differences are erased and in principle it's neither equal to
> uppercase nor to lowercase. It's only usable for implementing
> case-insensitive comparison/lookup using fast binary comparison.
>
> In my opinion the change to titlecase isn't worth it. There aren't enough
> problems with lowercase() to justify such a sweeping change. Also keeping
> lower case allows compiled tables to survive upgrades/downgrades.
>
> I'm neutral regarding 1 and 2a. If you'll tell me what you prefer I'll
> write a patch and test that it matches another implementation.
This will require further research. If case canonicalization is as
complex as you describe then the "correct" result is likely to
differ from what real people expect. That is a security hole.
Wietse
