Looking at the virtualusertable query I see that if I only add the rule
It will never alias any recipient: neither bago@someremotedomain nor bago@somelocaldomain.
If I instead add another generic mapping referring to the domain like:
(yes, this does not change anything, but I need to add it to make the previous work)
Then a message to bago@somedomain will be rewritten to firstname.lastname@example.org
This is the query:
FROM VirtualUserTable, VirtualUserTable as VUTDomains
(VirtualUserTable.user like ? OR VirtualUserTable.user like '%')
(VirtualUserTable.domain like ? OR
(VirtualUserTable.domain like '%' AND VUTDomains.domain like ?))
And the key/guilty part is the self-join and the "AND VUTDomains.domain like ?"
This mean that domain=% will match any domain already used in another rule. This is not documented anywhere and I also think this is not an intended behaviour.
Was this hack used to try to alias only local domains?
Should we change it to consider % valid for any local domain (specified in servernames) even if not used in other mapping rules and document it this way?
Do we need to introduce a new wildcard to specify ANY domain (even the non local)?
On the other side the XMLVirtualUserTable seems to have not such behaviour and to always rewrite any domain, even remote one or domains not used in other mapping rules.
So what is the intended behaviour? I think that is really bad that XML and JDBC behave differently wrt this issue.
My preference is:
1) use the XML behaviour by default when using %
2) optionally introduce later a new wildcart to match only local domains (this can be already achieved by using HostIsLocal matcher for the virtual users table.
This means: remove the self join and the where condition on VUTDomains from JDBCVirtualUserTable.