>>>>> On Sun, 10 Dec 2000 22:48:33 -0800,
>>>>> Michael Fair <[EMAIL PROTECTED]> (mf) writes:
mf> I have thought a lot about this. I even patched
mf> 1.6.24 to use email addresses as IDs, and had
mf> different domains residing in different namespaces
mf> (implemented as different top-level folders).
Would the folks login using their email address as the login name?
mf> This allowed each domain to have its own set of
mf> users and shared folders without name collisions
mf> in other domains.
As I think it should be. Though, I suppose they share
configuration settings, correct?
mf> I authenticated out of a database using the domain
mf> name as the table name to get the data out of and
mf> didn't do any "per domain" configuration other
mf> than creating a separate partition for each.
Ah, I see.
mf> It worked, but was by no means a generic solution.
mf> It was merely a proof of concept to see how much
mf> work was really involved. "A lot, but doable"
mf> was my conclusion. It's certainly no small task,
mf> however the Cyrus system is far from being a lost
mf> cause about it. In fact, during the "upgrade"
mf> several other features can easily be integrated
mf> with minimal extra effort. Such as a (compile time)
mf> configurable separator character for those who
mf> want something other than "." and the ability to
mf> create folders at the same level as "inbox" (like
mf> Drafts, Trash, Sent Items, etc..)
Hmm... this is getting pretty involved....
My concern with this approach, as you later point out, is that it
deviates enormously from the original code base. It seems to also
introduce considerable complexity, but perhaps that's just from a
first reading of this. Also, I don't think that having folks login
using their fully qualified email address is desirable. It
certainly doesn't convey that they are using their own little
service, which ideally is the perception most desirable when
providing a service to totally disjoint domains.
Perhaps not ultimately the most desirable in the long run, but seems
to me that simply providing a `-c configfile' option to master,
which then propagated that setting to all the auxiliary services, is
the tidiest code-wise. Even if more elaborate schemes were to
subsequently follow, it's not like the availability of this `-c'
option would preclude that. Seems like this might be useful for
other things, like testing or something.
The next thing, and even this doesn't seem like it would be too
complicated, would be to allow binding the services to particular
addresses. Perhaps a syntax along these lines:
imap cmd="imapd" listen="imap" prefork=0
imap cmd="imapd" listen="mailhost.example.org:imap" prefork=0
imap cmd="imapd" listen="[255.255.255.255]:imap" prefork=0
Perhaps I'm taking too many liberties with over simplification, but
it seems like this would rather expediently provide the capability
to support multiple domains without radically diverging from the
current source code.
As for the jail approach suggested, I'm afraid that one of the
potential deployments is using Solaris 8, on an E250 to be exact.
--
Amos
