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).
> 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).
> 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.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
