I opened a bug report: http://issues.apache.org/jira/browse/JAMES-745
bye Norman Norman Maurer schrieb: > I just reread my message and notice that my answer is a bit confusing :-( > > Here is what i tried to say: > > I agree that we should follow the way how the XMLVirtualUserTable work. > If we really want to add a check in the mailet for local domain then we > should use the mailetContext.isLocalServer(String) method. IMHO it makes > more sense to use the matcher HostIsLocal . > > bye > Norman > > Norman Maurer schrieb: > >> Stefano Bagnara schrieb: >> >> >>> Looking at the virtualusertable query I see that if I only add the rule >>> user=bago >>> domain=% >>> [EMAIL PROTECTED] >>> >>> It will never alias any recipient: neither [EMAIL PROTECTED] nor >>> [EMAIL PROTECTED] >>> >>> If I instead add another generic mapping referring to the domain like: >>> user=nonexistinguser >>> domain=somedomain >>> [EMAIL PROTECTED] >>> (yes, this does not change anything, but I need to add it to make the >>> previous work) >>> >>> Then a message to [EMAIL PROTECTED] will be rewritten to >>> [EMAIL PROTECTED] >>> >>> This is the query: >>> -- >>> SELECT VirtualUserTable.target_address >>> FROM VirtualUserTable, VirtualUserTable as VUTDomains >>> WHERE >>> (VirtualUserTable.user like ? OR VirtualUserTable.user like '\%') >>> AND >>> (VirtualUserTable.domain like ? OR >>> (VirtualUserTable.domain like '\%' AND VUTDomains.domain like ?)) >>> ORDER BY >>> concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc >>> LIMIT 1 >>> --- >>> 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. >>> >>> WDYT? >>> >>> Stefano >>> >>> >>> >>> >> This make sense to me. Optional we could also check in >> mailetContext.isLocalServer(domain) for local domains. >> >> +1 >> >> bye >> Norman >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> !EXCUBATOR:1,4586342944679416518385! >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > !EXCUBATOR:1,4586408844673489620044! > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
