James Server
  1. James Server
  2. JAMES-745

XMLVirtualUserTable and JDBCVirtualUserTable not work symetric

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0, 2.3.0
    • Fix Version/s: 3.0-M1
    • Component/s: None
    • Labels:
      None

      Description

      from ml:

      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

        Activity

        Hide
        Eric Charles added a comment -

        Fixed in http://svn.apache.org/viewvc?rev=992557&view=rev
        Wildcard usage will be document on website 3.0.
        Can be closed.

        Show
        Eric Charles added a comment - Fixed in http://svn.apache.org/viewvc?rev=992557&view=rev Wildcard usage will be document on website 3.0. Can be closed.
        Hide
        Stefano Bagnara added a comment -

        I'm with Eric. Swithing to "*" and making all of the implementations to work the same way, documenting the backward incompatibility. When we break compatibility it's better to break a lot instead of introduce small and unexpected changes in behaviours (so I prefer to change the wildcard while we change the wildcard behaviour).

        Show
        Stefano Bagnara added a comment - I'm with Eric. Swithing to "*" and making all of the implementations to work the same way, documenting the backward incompatibility. When we break compatibility it's better to break a lot instead of introduce small and unexpected changes in behaviours (so I prefer to change the wildcard while we change the wildcard behaviour).
        Hide
        Eric Charles added a comment -

        for 3.0-M1, we could align JDBCVirtualUserTable to existing XMLVirtualUserTable, with a * as wildcard.
        This means that previous 2.3 deployments should upgrade and replace % with * (of well in xml, of well in database).
        This would be an additional action to be documented in the migration path.
        If ok, JDBCVirtualUserTable.mapAddressInternal could be adapted to reflect XMLVirtualUserTable.mapAddressInternal.

        Show
        Eric Charles added a comment - for 3.0-M1, we could align JDBCVirtualUserTable to existing XMLVirtualUserTable, with a * as wildcard. This means that previous 2.3 deployments should upgrade and replace % with * (of well in xml, of well in database). This would be an additional action to be documented in the migration path. If ok, JDBCVirtualUserTable.mapAddressInternal could be adapted to reflect XMLVirtualUserTable.mapAddressInternal.
        Hide
        Norman Maurer added a comment -

        Any news one this ? I whould like to fix this issue ... I whould use 1)

        Show
        Norman Maurer added a comment - Any news one this ? I whould like to fix this issue ... I whould use 1)

          People

          • Assignee:
            Eric Charles
            Reporter:
            Norman Maurer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development