james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [jira] Commented: (JAMES-562) Aliasmanagment should not depend on a user
Date Tue, 05 Sep 2006 16:20:39 GMT
Vincenzo Gianferrari Pini wrote:

> Wait a moment, I may be the only one, but I'm using the "old Alias and
> Forward support" entirely for more than 60% of my end users, and the
> table entries are managed by an application that synchronizes every 10
> minutes our HR database and James database. So removing such support
> would immediately hurt my James production system.

Well, as you know, I'm not a fan of immediately removing anything, since
even if you weren't, I suspect that many if not most JAMES users who use
some forwarding use the current account-based approach.  Furthermore, with
LDAP-based repositories, it is be quite natural to have a forwarding address
(see the InetOrgPerson schema) defined in the account.

But I certainly wouldn't invest in a THIRD approach to aliases!  Please
notice that the issue "complains" that a user account is required for
aliasing.  That's not so, and we should not develop yet another alternative.

My real point when talking about the old scheme is to emphasize that virtual
user tables should be the preferred approach for user mapping into which
education and effort is invested.

Also, to speak directly to your concern, please consider that we already
have JDBC and XML based VUT implementations.  Doesn't it seem reasonable to
unify the mapping code by writing a VUT that is populated from user
repositories?  For one thing, as I noted, the account-based alias/forwarding
code happens only during local delivery, whereas virtual user table behavior
can happen anywhere in the pipeline, from in-protocol to delivery.

> I know that if I had to build my synchronization application *now* I
> would use virtual user table, but it wasn't like that 3.5 years ago.

And I am sure that there are others in the same boat.  :-)

	--- Noel

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message