On Tue, 23 Jan 2001 12:02:43 -0500, Serge Knystautas wrote:
>----- Original Message -----
>From: "Michael Wyraz" <[EMAIL PROTECTED]>
>
>
>> > > * mail for every domain sould be stored in a different repository
>> >
>> > Very doable (but see below)
>> how?
>
>Mail repositories (whether stored in the file system, a database, or
>wherever) are already designed to support nesting folders. Mail would then
>get delivered to the appropriate subfolder.
great. so we don't have to make changes here.
>
>> I think the "qmail-soltuion" for that problem could help:
>> there are repositories for each domain (for mails and users) with the
>> domain-name as dir-name.
>> a login consits of the username, the @ and the domain. for compatibility
>> reasons you can use % instead of @. the pop-module (in this case vpopper)
>> decides which repository is used depending on the domain name specified in
>> the login.
>
>That's an interesting twist. I might still suggest an alias so if I have
>longer domain names, the usernames don't become unreasonably long. Maybe
>set some default and then allow you to override that in the conf file.
maybe there should be a possibility to make both. aliases and long names. if you have
(like we do)
some hundred domains, it's almost impossible to mak an alias for each user :-/
>
>> it wold better if you can make a user "milo" in the repository for
>> microsoft.com. the popper decides then do use this repository to check the
>> login/pwd.
>>
>> but so it must be possible to change the maillet which matches usernames
>to
>> access a specified user repository.
>
>So basically then we also have multiple user repositories (for each virtual
>domain), which makes sense. We'd have to think how the telnet tool supports
>administering this.
i thougth the whole day about that problem. my conclusion is, that we don't need to
make a
user rep. for each domain if the domain could be part of the username. more for that
written below...
>
>> i hope, we can solve all that problems. i think it's a needed feature for
>> many domain hosters.
>
>Agreed. I think I'm getting a good understanding of how you envision this
>working. I usually start by figuring how the conf file would look and
>figure out what gets changed. I'm still working on the site conversion and
>some documentation, so if you want to start on this, that'd be great. I can
>help with what sections of the code will need to get changed.
here my thougths for that (and some questions for implementing):
1. UsersRepository
a username consists of "[EMAIL PROTECTED]". there are special VHost User
Repositories (how can be set which UserRepository classes are known by
james? i found no config option for that?). or the existing UserRep's are changed
(can UserRepositories, Mailets and Matchers access the configuration?).
I Think it's better to modify the existing for file rep. and make a new for database
rep.
This change includes:
* a new Configuration Parameter "EnableVirtualHosting"
* a parameter for specifying valid seperator chars/strings between the username and
the host part
* the new ep. implements a new column containing the domain part of the username.
*if virtual hosting is enabled the method "public boolean test(String name, Object
attributes)" of the UsersRepository
matches all variants of username+valid seperator+host
2. MailServer.getUserInbox
should now return for user "[EMAIL PROTECTED]" (if EnableVirtualHosting is true):
[path to inbox]/domain.com/user/ (i think you know what i mean ;-)
3. Mather: UserIs
if EnableVirtualHosting is true it should have the same behavior as ReceipientIs.
Alternatively one who uses Virtual Hosting has to use Reciepient is instead of UserIs.
----
i think that's all we have to do to implement virtual hosting ;-)
but there's another thing that would be usefull in this case:
Domains (aka ServerNames) are currently configured in the xml config.
for virtual domains it would be much better if there were a (maybe aditional)
DomainsRepository
which could be implemented with town. So there's no need to restart for adding a
domain and it's users.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
