> Two Questions:
>
> 1) What recommendations does anyone have to appropriately partition the
Cyrus Server to handle this
> architecture and what configuration is necessary to ensure that when
LinuxServer1 receives a message for
> [EMAIL PROTECTED], the mail is delivered to user.smith on the
partition reserved for Depatment1,
> and when a message is delivered for [EMAIL PROTECTED], the correct
delivery is also made?
>
> 2) Assuming 1 is possible, how will 2 users with the same username, but
different contexts, login to the
> same Cyrus Imap server and enter the appropriate mailbox...
> username = <username.users.department.organization> (NDS Context
Model)
> or
> username = <user@domain> (Domain Model)
>
> Any comments/suggestions/help would be greatly appreciated.
I'm not an expert at enterprise class solutions, and don't know many of t
he
details
or benefits that NDS can offer, but I can try and help somewhat by sheddi
ng
light
on a few details.
Essentially what you are asking is for virtual domain support which cyrus
does not have
at the moment. That said, there are ways around the lack of such support
but they all
have significant drawbacks.
The main problem is that unlike http 1.1, there is no easy way to discern
where
the end user was trying to go within the IMAP protocol. At best you can
create
a unique IP address per department and then modify the server code to
implement
separate mail stores based on the unique IP information. When a user tri
es
to
log in you only two useful pieces of information to try and determine wha
t
department they are trying to reach: the username, the destination IP
Address.
If you are not willing to create unique usernames across your entire
installation
then you must somehow create different cyrus servers for people to log in
to.
There
is no way to have the same server, on the same machine, running the same
configuration
file to have more than one user.smith. Each cyrus installation is one bi
g
mailstore.
Each person with the name smith will have to have their own unique mailbo
x
identifier
if you want them to exist within the same mailstore.
When I had my 1.6.24 installation I hacked up a version of cyrus that
supported
virtual domains. It allowed the user to log in as [EMAIL PROTECTED] and th
en
calculated the appropriate locally unique mailbox name to go with it. I
never released the code because 2.X came out within 2 weeks after I finis
hed
and it wasn't all the clean of a job either.
While I am guilty of using partitions as a neat way to implement separate
domains
(or in your case departments), this is not what they were designed for.
They were
designed purely as a way to spread the same mail store across separate
physical
devices to aid in storage and backup purposes. As a result, they only
physically
separate the different mailboxes on the file system. They do not create a
ny
logical
separation that the server can use. It's still just one big mailstore.
There have been many discussions about this in the past and the mailing l
ist
archives will go into a lot of the details about it, but you do have a fe
w
options I can immediately think of (and I'm sure you have others as well)
.
This assumes you are running 2.X code:
1) Redesign your NDS, or implement an administrative policy
that mandates the creation of unique user identifiers for
each person regardless of department. If you really want to
save yourself a lot of trouble, this is probably your best
bet given the current state of cyrus.
2) Use physically separate machines for each department. Do
not have them share any data, each one authenticates out of
its own subtree of NDS.
3) Alias many IP Addresses onto one interface and then launch several
instances of the cyrus server (one per department) each using a seperate
configuration file (possibly even chroot'd into a seperate file space)
bound to a unique IP. Add DNS entries imap.department1.edu,
imap.department2.edu which map to the corresponding IPs on the server.
This one is currently the most popular approach and in many people's
opinion is the lesser of all the evils.
4) It might be possible to modify the master process to examine the
source address and then launch imapd using the separate config model.
This of course blows away any hopes of doing remote logins from home
or the road. (I don't recommend this one)
5) Configure all the IMAP programs in your entire site to use
username-departmentname as the login ID for IMAP. Create all
mailboxes on the Cyrus server as username-departmentname.
Modify the server authentication mechanims to separate everything
before authenticating against the NDS tree.
6) Abstract the unique name away from the IMAP clients by creating
a new IMAP server for them to connect to. Essentially this new
server does two things. First, it is able to authenticate against
the NDS because somehow it knows about the context it exists in.
Second, it then logs into the cyrus server using a unique ID which
it either looked up or constructed, or perhaps it connects to a
non-standard port which is dedicated to that deparment. It then
just acts as relay between the two computers passing data from
the client to the sever, and vice versa.
7) Use a server other than Cyrus that supports virtual hosting.
I don't like this one very much, but when a server doesn't support
the required features you need, no matter how many nice and other
useful features it has, it just can't do the job.
==============================================================
None of these are very appealing to me. I wish DNS included a
service name (like mail.department.edu:imap) and responded with
both IP and port information, or that all network protocols
included the servername they were trying to reach as part of
the standard intitial messages. This way all servers could
make virtual hosting so much easier by either binding a domain
to a specific port, or being told by the client what domain
they are a part of.
Regardless, good luck and I hope this was at least educational
even if it wasn't very useful to solve the problem.
If any out there sees any glaring misconceptions or has some
more elegant solutions, I'd love to be corrected here.
-- Michael --
