You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2006/12/17 19:35:54 UTC
JDBCVirtualUserTable weird behaviour (BUG!)
Looking at the virtualusertable query I see that if I only add the rule
user=bago
domain=%
target=bago@catchalldomain.com
It will never alias any recipient: neither bago@someremotedomain nor
bago@somelocaldomain.
If I instead add another generic mapping referring to the domain like:
user=nonexistinguser
domain=somedomain
target=nonexistinguser@somedomain
(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
bago@catchalldomain.com
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JDBCVirtualUserTable weird behaviour (BUG!)
Posted by Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> Looking at the virtualusertable query I see that if I only add the rule
> user=bago
> domain=%
> target=bago@catchalldomain.com
>
> It will never alias any recipient: neither bago@someremotedomain nor
> bago@somelocaldomain.
>
> If I instead add another generic mapping referring to the domain like:
> user=nonexistinguser
> domain=somedomain
> target=nonexistinguser@somedomain
> (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
> bago@catchalldomain.com
>
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JDBCVirtualUserTable weird behaviour (BUG!)
Posted by Norman Maurer <nm...@byteaction.de>.
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=%
>> target=bago@catchalldomain.com
>>
>> It will never alias any recipient: neither bago@someremotedomain nor
>> bago@somelocaldomain.
>>
>> If I instead add another generic mapping referring to the domain like:
>> user=nonexistinguser
>> domain=somedomain
>> target=nonexistinguser@somedomain
>> (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
>> bago@catchalldomain.com
>>
>> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,4586342944679416518385!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JDBCVirtualUserTable weird behaviour (BUG!)
Posted by Norman Maurer <nm...@byteaction.de>.
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=%
>>> target=bago@catchalldomain.com
>>>
>>> It will never alias any recipient: neither bago@someremotedomain nor
>>> bago@somelocaldomain.
>>>
>>> If I instead add another generic mapping referring to the domain like:
>>> user=nonexistinguser
>>> domain=somedomain
>>> target=nonexistinguser@somedomain
>>> (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
>>> bago@catchalldomain.com
>>>
>>> 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: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>> !EXCUBATOR:1,4586342944679416518385!
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,4586408844673489620044!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org