[Exim] exim-4.33 strange configuration problem

Hello.

I'm trying to implement webmail system using Exim + Postgres. All data
should be stored in the database. I've found a problem with Exim 4.33
configuration in case of two or more virtual domains. Note that each
domain can contains the same user names and they are different users.

For example:

I have a local domain called 'domain.com' and also second virtual
domain 'special.domain.com'. I've configured Exim to accept mail for
both domains. All works fine if I send a mail to one user from one of
my domains.

For example the query for determining system aliases looks like:

begin routers

system_aliases:
 driver = redirect
 allow_fail
 allow_defer
 data = ${lookup pgsql{SELECT Recipients FROM SystemAliases \
                       INNER JOIN Domains ON (SystemAliases.DomainID =
Domains.DomainID) \
                  WHERE LocalPart='${local_part}' AND DomainName='${domain}'}}

and it executes as

SELECT Recipients FROM SystemAliases INNER JOIN Domains ON
(SystemAliases.DomainID = Domains.DomainID) WHERE LocalPart='user1'
AND DomainName='domain.com'

when e-mail is sent to user1@???

But if I try to send e-mail to user1@??? in TO field and
user2@??? in CC field the exim executes two sets of
queries but in both sets the ${domain} variable is the same and equals
to first domain 'domain.com'

e.g. First query is:

SELECT Recipients FROM SystemAliases INNER JOIN Domains ON
(SystemAliases.DomainID = Domains.DomainID) WHERE LocalPart='user1'
AND DomainName='domain.com'

and second is:

SELECT Recipients FROM SystemAliases INNER JOIN Domains ON
(SystemAliases.DomainID = Domains.DomainID) WHERE LocalPart='user2'
AND DomainName='domain.com'

Of course it is not correct.

I've read the Exim documentation several times and it seems that
${domain} variable must be different in both sets of queries executed
by Exim.

Please help me to understand it is a bug or just incorrect Exim configuration.

If you need some parts of exim configuration file please ask me and
I'll send it.

Thanks,

Vladimir Mischenko