Woo hoo! I'm happy we're back on a forward track. :) :) :)

>I would like to be able to add a domain to James without having to hard
>code it in the config.xml and without having to restart.


This should be a feature goal for James v3.  Do you know the Wiki?  :-)

No, I've heard it mentioned on the list though. Is it a Jakarta project? I'll look on the site.

As for the v3 goal.. I'd like to suggest that we add to a 2.x. A lot of stuff has been talked about being added to James and we keep talking about a 3.x version it, but I'd really like to get to the "Release Often" paradigm. It's been talked about a lot on the list, but I think now that we are moving forward again we're all excited to work on big changes.

>1) Write code to replace the  entries in the config.xml with
>   JDBC calls.


We need to discuss, generically, how we want to handle dynamic
configuration.
Agreed. I like to throw my ideas out to see how they work with others. In my current situation, something that would make my life a lot easier is a set of objects that represent the standard user, alias, repository tables.

My desire: I want to write a web app to manage pop accounts and aliases, etc. What this requires is that I write my own object that fiddles with the user and alias tables. I'd love a James object I could instantiate, make changes to, and then commit, outside of an Avalon structure. I realize this might not be a doable thing, but I just want to put it out there to see what you think.

One method, as a strawman, might be to view the current config.xml as a bootstrap, and to have configuration handlers that can go out to other data sources, and call methods on James to affect configuration. So you might have a configuration handler that would lookup server names from JNDI or from a database, and it would call a method on James to add a new server name.
I think I follow you... it's a little big for me to picture.

>2) Stop using SMTP-AUTH (the thing requiring the hard coded domains), and write code to dynamically allow and disallow mail relay.

>add a mailet to record the IP address and timestamp of a user
>when they make a successfully authenticated POP connection.

This ties in with Serge's comment about DRAC
(http://mail.cc.umanitoba.ca/drac/).
Yes, I use otto_relayd which is a system very similiar to DRAC and what I was basing the concept of my request on. I'd be interested in a way to plug functionality into the POP server (like we plug mailets into the transport processor), so that I could do special stuff during POP sessions. *shrug* :)

Kenny


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to