Hi Jeremy,
Yes, a new LDAPRecipientRewriteTable will allow to add 'secondary address' to existing ones.

You will have to put your hands in JAVA. The code resides in https://svn.apache.org/repos/asf/james/server/trunk/ - data-api and data-library have the code common to all impl (deprecated jdbc, jpa), see the rrt package - your implementation will come in data-ldap with a brand new package org.apache.james.rrt.ldap. This project has the implementation for the users, so you can see how the ldap connections are made. You will have to implement LDAPRecipientRewriteTable which extends AbstractRecipientRewriteTable

We use maven:
http://james.apache.org/server/3/dev-build.html

Other areas of contributions are:
- Small tutorial to setup up James with Apache DS (steps taken, LDAP Schema, LDIF extract of example users...) - A few users have previously asked for this.
- Unit tests with embedded ApacheDS for users (and rrt)

Thx again, Eric

On 27/08/2012 06:22, Jeremy T. Bouse wrote:
        I've stumbled through getting JAMES up and running and talking with
ApacheDS so far. The gotcha I found in getting JAMES to acknowledge my
users in ApacheDS was to change my usersrepository from:

<usersrepository name="LocalUsers"
     class="org.apache.james.user.ldap.ReadOnlyUsersLDAPRepository"
     ldapHost="ldap://localhost:389";
     principal="uid=ldapUser,ou=system" credentials="topsecret"
     userBase="ou=users,dc=example,dc=com" userIdAttribute="uid"/>

        that I had found referenced to in several locations to be:

<usersrepository name="LocalUsers"
     class="org.apache.james.user.ldap.ReadOnlyUsersLDAPRepository"
     ldapHost="ldap://localhost:389";
     principal="uid=ldapUser,ou=system" credentials="topsecret"
     userObjectClass="inetOrgPerson"
     userBase="ou=users,dc=example,dc=com" userIdAttribute="uid"/>

        I'm not using any custom LDAP schema for my users but instead relying
on the standard inetOrgPerson as I feel it provides all that is
necessary. A standard user would be described as:

dn: uid=Administrator,ou=users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: System Administrator
sn: Administrator
mail: [email protected]
uid: Administrator
userPassword:: topsecret_hash

        This works and if I run the james-cli for 'listusers' I do in fact now
get all of the users listed under the userBase DN and I can log into the
services (POP3, IMAP & SMTP) authenticating as the users from ApacheDS/LDAP.

        Where my path strays and I haven't been able to find any clear course
correction guidance is if I add an additional email address to a user by
adding a second 'mail' attribute entry for say '[email protected]' and
then try to send email to that address JAMES will respond back that the
address does not exist. It would appear that there is no way, unless I'm
missing something, for JAMES to realize that the login 'Administrator'
in fact then has 2 valid email addresses that should be accepted for.

        It would seem this would be a perfect fit for a
LDAPRecipientRewriteTable class and I'm not finding any mention of one
though I see there is a JDBCRecipientRewriteTable (deprecated of course)
and a JPARecipientRewriteTable so figure it wouldn't be too hard to
flesh out I'd imagine. I'm not a big JAVA developer, mostly DevOps and
Administration but I'm certain if I could get some assistance and
guidance I could flesh out and test this theory.

        To me the logic would seem to be treat the 'uid' Username @ domain as
the primary email address (as it does already) and then have a LDAP RRT
class map 'mail' attribute values to the primary address. Of course
making the attribute name configurable as someone using pilotPerson
schema class might want to use 'otherMailbox' or use 'email' or
'emailAddress' from the extensibleObject schema class or some other
custom schema variation.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to