Serge Knystautas wrote:
>
> Ye Tao wrote:
> > two questions:
> >
> > 1. how to replace the existing UserManager with my own
> > implementation, for example,if i want to use LDAP. so
> > far the only way i can think of is to write my own
> > UserManager with the same package path, and put it
> > before the James implementation in the classpath. is
> > it possible to enhance the current James
> > implementation to allow a more pluggable framework?
>
> This is where I think JAMES needs to head next. A few other people have
> already noted their interest to allow swappable mail stores (generally
> to an RDBMS instead of the file system), and then there's of course the
> user manager. Federico has built much of the architecture, and I've
> been waiting for him to get back from vacation before diving too far
> into this. We use LDAP internally (and of course RDBMS's), so I'm very
> much interested in this, and I think this will involve defining an API
> and building a few implementations for the usermanager and mail stores.
> The hard part with user manager is getting combining authentication with
> mail store. The UserManager authenticates the user and then knows how
> to grab their inbox... I don't think this will be easy to capture (at
> least nothing jumps right out at me).
>
Ok here I am!
About this issue my picture is of one UserManager and one MailRepository
with pluggable backend.
Right now all you need to do to switch to a LDAP is to write an
ObjectRepository LDAP based and configure the RemoteManager to use it:
form
<usersManager>
<repository> file://../var/users/ </repository>
</usersManager>
to
<usersManager>
<repository> ldap://[host]/[..] </repository>
</usersManager>
To register the new repository type (wich can be in any package you
wish) just add this line to the Store configuration:
<repository type="OBJECT" model="SYNCHRONOUS,
ASYNCHRONOUS"
destination="ldap://"
class="com.mycompany.whatever.MyLDAPImplementation"/>
The same apply to the MailRepository (actually I think I need to clean a
couple of lines of code) as soon as you provide a StreamRepository
implementation too.
> > 2. the current mail servlet is pretty nice and allows
> > a more programmtic way to handle emails. can we add
> > one more field(or maybe two) into Mail.java:
> > RemoteAddress/RemoteIP. This is important to make
> > James a more suitable mail server solution for
> > enterprise. for example, one must-have feature is to
> > deny relaying. a spammer could use James to relay
> > emails. It would be nice to expose the
> > remoteIP/remoteAddress in the Mail.java (or some
> > better way, but currently Mail.java is the only unit
> > used in servlet control) so filters can be written to
> > prevent from spamming.
>
> I've already added these to CVS (as well as simple matchers that work
> off of these) and completely agree denying relaying (and other spam
> guards) are very important. In fact, this was the last hurdle to clear
> before making a final 1.0 release (which should be soon now that I'm
> back from vacation as well).
Good.
>
> > btw, why do we need a root path for the servlets, this
> > sometimes leads to awkard package names. Not all
> > servlets will be under org.apache.
>
> I believe you can specify multiple packages (kind of a search order),
> although I'm not sure if we pushed this back to a later release. You
> might want to try this out using various delimiters. If not, you should
> always use the complete class name whenever referencing a mailet or
> matcher.
>
yes you can place your mailet wherever you want...
<mailetpackages>
<mailetpackage>org.apache.james.transport.mailets.</mailetpackage>
</mailetpackages>
so when you refere to a servlet name like in
<mailet match="RecipientIs=administrator@localhost" class="Forward">
james will try to load the "class" name from each mailetpackage
includind (by default) the empty package like
<processor name="root"
class="org.apache.james.transport.LinearProcessor">
Federico
[EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
