> I don't aggre. What seems to happen is that the people that actually > develop James are interested in a personal mail server and not in a > multidomain server. There is only two messages in September 2001 > what can be > called a discussion about multidomain in the last year. I implement > multidomain some time ago and send it to the list but after that > there is no > answer. > > I understand that this is a change difficult to do because it affects > several classes in the code, but without it James is only usable > as a single > domain server, what is enough for some people but not for all.
In some respects you are right, it is indeed enough for many people that James serve a single userbase. However it is not true that "the people that actually develop James are interested in a personal mail server and not in a multidomain server". In fact adding virtual host support to James has been discussed a number of times since september, and is understood to be a key goal. The fact that it is suffering from lack of progress is largely due to the fact that most of the developers of James are unable to make significant commitments of their time at the moment. The two Simple schemes for multiple domains which have been proposed do not fully implement the functionality true virtual hosts would have (completely seperate mailet processes, binding to different IP addresses for instance) and both fall foul of the naming convention problem. Personally I believe that naming conventions in any application are the last resort. A true solution shouldn't restrict the variety of names that can be used, and that a better solution is possible in this case. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
