[prev in list] [next in list] [prev in thread] [next in thread] 

List:       info-cyrus
Subject:    Re: The problem of implement virtual domain
From:       Michael Fair <michael () daclubhouse ! net>
Date:       2002-06-28 21:09:23
[Download RAW message or body]

> Michael Fair wrote:
> > 
> > Here's the virtual domain supported IMAP
> > namespace as I see it.
> > 
> > /sharedfoldernames
> > /user/usernames
> 
> How is this accessed?  Is this for some "default" domain in which people
> don't append the domain to their login?  I thought about this, but it
> makes getting LIST output correct, unless you give different meanings to
> "userX" and "userX@domain" for userid in ACLs.

The /user/ folder would be accessed for all users that
do not have '@' in the autorization id.  This is simply
put "the way it works now" and the way it would continue
to work for simple unified namespace mailstores.

I can see what you mean about it making "LIST" more
difficult since it would have to know that "/domain.tld/"
and all of its subfolders should not be presented to
the client.  Since the "loginrealms" parameter needs
to be provided in imapd.conf to enable cross realm
logins, perhaps this same field could be used to also
filter the "LIST" command when operating in the "/"
namespace where userids don't have '@' in them.

> > /domain.tld/sharedfoldernames
> > /domin.tld/user/usernames
> 
> Forgive my ignorance, but what does "tld" stand for

oh no problem at all sorry it wasn't more obvious.  
tld = top level domain

Similar to the dom.ain convention others have used.

> > I don't see that anything special needs to be done
> > for ACLs, quotas, partitions,or anything else.
> > They will continue to function in exactly the same
> > way they always have.  So unless there is some other
> > special processing for the /user heirarchy that
> > I am unaware of, to cyrus for all intents and
> > purposes that I can forsee, cyrus only needs to
> > see the /domain.tld folders as special shared folders
> > that can have a meaningful "user" subtree to them.
> 
> Depending on whether people want inter-domain folder sharing and/or
> intra-domain folder sharing, this effects how ACLs need to be handled.

Yes, I can see how inter-domain could be a problem.

My intention for initial implementation was really rudimentary.
Each domain would try to be it's own mailstore.  For all 
mailbox operations the session would be chrooted to that 
domain's subfolder.  This allowed for intra, but not inter 
sharing.  There would also be no global folder share.  Each 
domain would be completely isolated from all other domains.  
This is not a problem for ISPs because in general, it is safe 
to treat each domain as an completely independent customer
that wants to see itself independent of everything else.  
They don't expect and most times don't even understand the 
concept of a shared folder between two domains.  Typically 
the most they want is the ability to alias domains so that 
one domain acts just the same as the other but this can
be handled long before cyrus ever has to deal with it.

For ACLs, I intended all userids in the virtual domain 
namespace would be fully qualified email addresses and 
must be typed out as such.  userids in the root namespace
would not have '@'.  So as far as the ACLs were concerned
there would simply be one unified user namespace.

While technically one would be able to give any user
permissions on any folder inter-domain or otherwise,
it would be fruitless because once they logged in via
imapd they wouldn't be able to access any folders outside
their own domain's subfolder because they are chrooted
(this is chrooted in the IMAP LIST sense, not the OS
filesystem and process sense).

I suppose cyradm could also chroot itself if a realm was 
specified when it was started up, and automatically 
append the '@domain.tld' string to the end of any userids 
provided but I did not plan on adding that functionality.


IP" know that these features would handle most virtual
domain needs.  Not having, per domain certificates is 
something us "single I folks will just have to live 
with until IPv6 or SRV records become the norm.  Either
that or the implemented IMAP draft changes to make it
possible for us to determine destination server before 
TLS negotation.


I hope that helps with at least what one medium sized
ISP would consider acceptable/sufficient for their needs.
(note: I no longer work there, but this would have worked)

-- Michael --

[prev in list] [next in list] [prev in thread] [next in thread]