I haven't needed virtual domain support, and so I haven't thought about
it much, but my first reaction is that simply changing the 'user.'
prefix to 'domain.' is either going to be insufficient or will become a
hack.
First off, I applaud the effort. I know that many people would like to
see this happen, so I'll try to help wherever I can. But the
implementation needs to be clean and backwards compatible for it to have
a chance of getting rolled into the main distribution.
Off the top of my head, here are questions that I think would need to be
answered:
1. Are all domains isolated from others, or do they get to see other
domains folders?
2. Public folders: do all domains share the same public area, or do they
each have their own?
3. If you simply change 'user.' to 'domain.', then what is the prefix
for the Other User's namespace?
4. How does this affect quotas, ACLs and seen state?
My gut tells me that each domain (both personal folders and shared
folders) should be isolated from each other. This means that there
should be one more level of hierarchy above the current one, ie:
domain.com/user/username
domain.com/shared
domain.net/user/username
domain.net/shared
I think creating this new structure might be a lot of work, and I can
guarantee that the bulk of it will be getting LIST/LSUB correct.
On the flip side, I _think_ that the HIERSEP code will support usernames
like '[EMAIL PROTECTED]' without any changes, so that folders like
'[EMAIL PROTECTED]/Trash' would be allowed. This would mean that all
domains would reside under the same umbrella and that the public folders
would be shared amongst the domains. However, the personal folders for
each domain could be kept in a separate Cyrus partition.
Just my $.02
Ken
Devdas Bhagat wrote:
>
> On Thu, 19 Jul 2001, Kevin J. Menard, Jr. spewed into the ether:
> <snip>
> > Pretty cool. I presume you're building this on top of the HIERSEP codebase
> > so that [EMAIL PROTECTED] and [EMAIL PROTECTED] have different prefixes?
> Not yet.
>
> > DB> However, at many places, the "user." string is hardcoded. Can someone
> > DB> please tell me in which files a change *must* be made for this to work?
> > DB> (Minimally pop and imap).
> > DB> What I'm trying to say is: I have a split function ready, now where do
> > DB> I put it for it to be available to everyone?
> > DB> Can we move *all* header files to an include directory, please?
> >
> > I don't know what you have in mind, but probably the easiest thing to do,
> > that I can think of, is to replace the "user" part with a string, which is
> > configurable via imapd.conf, with the default value being user. I don't
> No, what I am doing is
> #define MAILBOX_TOP user
> char *domain=MAILBOX_TOP
> char *domainname=NULL;
> split(&username,&domainname)
> domain = domainname
>
> So if the user logs in without the domain, I get domain = user, else I
> get that domain.
>
> > quite know how the HIERSEP code works though, and i wonder if a uid
> > of [EMAIL PROTECTED] would get translated to domain.com^user rather
> > than domain.com.user. Hmm. . . this may very well cause problems
> > with the on disk structure. But then again, I don't know all what
> > I'm talking about.
> It doesn't. Thats the point. Currently the disk structure enforces a
> structure like user.username. I am changing this to domain.username
> (Not a TLD, just the first part. So andrew.cmu.edu will require
> user@andrew to login.)
>
> > Best to consult Ken since he wrote that code ;)
> I do plan to integrate this in later, but right now, I would like to
> see all possible changes.
> BTW, grep *is* is very good tool for this. I should have something up
> in about an hour (all my changes commented out, but marked with a DVB).
> Hopefully my code is commented well enough.
>
> Devdas Bhagat
> --
> He has shown you, o man, what is good. And what does the Lord ask of you,
> but to do justice, and to love kindness, and to walk humbly before your God?
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
