Re: How to add virtual domain support
I also had envisioned matching that scheme at the top of the mailstore as well. /ip.address1.of.host/user/bob /ip.address2.of.host/user/bob Since the IP address is something known at connection time, that could be used to authenticate out of a different database allowing us to support bob@domain1 and bob@domain2. From it sounds like from you earlier conversation, this will not help us with SSL certificates. -- Michael -- - Original Message - From: Todd Nemanich [EMAIL PROTECTED] To: Joe Rhett [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 5:03 PM Subject: Re: How to add virtual domain support Joe Rhett wrote: The main point of this is to actually get some virtual hosting within a single mailstore. The use_ip_as_realm patch will provide most of the changes needed to do either named or ip vhosts, primarily how information (mailboxes, acls, message flags, etc) is seperated across realms so you can have bob@realm1 and bob@realm2 who are different users. Changing the realm won't resolve name conflicts within the message store. Currently, I'm thinking of creating multiple trees under /var/spool/imap for the multiple virtual hosts. i.e. /var/spool/imap/ and /var/spool/imap/.realm2/ will be parallel mailstores for the different realms (This seems the least intrusive way to do it). Sorry I didn't explicitly mention that earlier. -- Todd Nemanich [EMAIL PROTECTED] Protecting the opulent and staging moral standard, They expect redemption of character and self growth Bad Religion - Inner Logic
Re: How to add virtual domain support
I have a suggestion on this subject. What about the possibility of binding a realm to a local address for cyrus (IP based vhost)? Yes, authentication and named vhosts via username and realm is ideal, but given that that information is usually not explicitly send by the client, if the imap server could assign the realm based on some implicit information such as the IP address, then there is an answer that should work while we all wait for more widespread support of SASL realms. If there was a patch to do this, would it be accepted into CVS? It does mean that you must get an SSL certificate per IP address, if using SSL. This would make other approaches seem better. -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: How to add virtual domain support
Joe Rhett wrote: I have a suggestion on this subject. What about the possibility of binding a realm to a local address for cyrus (IP based vhost)? Yes, authentication and named vhosts via username and realm is ideal, but given that that information is usually not explicitly send by the client, if the imap server could assign the realm based on some implicit information such as the IP address, then there is an answer that should work while we all wait for more widespread support of SASL realms. If there was a patch to do this, would it be accepted into CVS? It does mean that you must get an SSL certificate per IP address, if using SSL. This would make other approaches seem better. Well, this is a little quirky. The client would have to pass their authentication information or something to indicate their realm prior to TLS negotiation. As I understand it, there is no real way to do this in a named virtual host architecture. The problem here is that the certificate contains the common name of the mail host. To give an example of this, take a box who's default ip realm domain1 and a secondary realm vhost is domain2. When a client connects and does STARTTLS, the server does not know which realm they are trying to use yet (since no authentication information has been passed yet). So it passes the default certificate containing the common name host.domain1. When the client recieves this certificate, it should reject the certificate, or at least inform the user that the certificate is for host.domain1, not host.domain2. If you have an alternative answer to using IP vhosts for doing SSL, I would love to hear any thoughts on how. -- Todd Nemanich [EMAIL PROTECTED] Protecting the opulent and staging moral standard, They expect redemption of character and self growth Bad Religion - Inner Logic
Re: How to add virtual domain support
On Fri, 4 May 2001, Joe Rhett wrote: I have a suggestion on this subject. What about the possibility of binding a realm to a local address for cyrus (IP based vhost)? Yes, authentication and named vhosts via username and realm is ideal, but given that that information is usually not explicitly send by the client, if the imap server could assign the realm based on some implicit information such as the IP address, then there is an answer that should work while we all wait for more widespread support of SASL realms. If there was a patch to do this, would it be accepted into CVS? It does mean that you must get an SSL certificate per IP address, if using SSL. This would make other approaches seem better. Joe, SASL is not SSL. *plonk* -alex
Re: How to add virtual domain support
I have a suggestion on this subject. What about the possibility of binding a realm to a local address for cyrus (IP based vhost)? Yes, authentication and named vhosts via username and realm is ideal, but given that that information is usually not explicitly send by the client, if the imap server could assign the realm based on some implicit information such as the IP address, then there is an answer that should work while we all wait for more widespread support of SASL realms. If there was a patch to do this, would it be accepted into CVS? It does mean that you must get an SSL certificate per IP address, if using SSL. This would make other approaches seem better. Joe, SASL is not SSL. *plonk* If you have a different DNS name IP address for each virtual domain, you'll need a different SSL certificate for each one or the browser will complain upon establishing a connection -- long before SASL issues are relevant. Note that I did specify if using SSL. So I'll deny your *plonk*, and raise you one kiddo. Pay attention! -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: How to add virtual domain support
This is a great additional feature, and good thinking! I will say that if all you are going to do is IP based virtual hosting then the server as it stands now is sufficient to the task. With the addition of being able to specify the config file on the command line you can get separate authentication domains and separate mail stores via the separate configuration files. However, I personally prefer the single server approach rather than running multiple servers. I'm we should even implement this first as it could be used as a stepping stone to the next phase of email parsed realm info. It also doesn't seem like it would be to intrusive, and could be an easily accepted patch. Since we can also implement it as a config file switch like use_ip_as_realm: true only those people who were interested in the new behavior would have to use it. -- Michael -- - Original Message - From: Todd Nemanich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 27, 2001 9:11 AM Subject: Re: How to add virtual domain support Michael Fair wrote: Yes, the Cyrus server supports realms though it is largely unused. Currently SASL just fills the realm info in with the hostname of the machine. You can see this when you do sasldblistusers. In regards to all clients supportnig SASL. Perhaps it's only a matter of time, but will they implement it according to the standards (specifically Microsoft). I have a suggestion on this subject. What about the possibility of binding a realm to a local address for cyrus (IP based vhost)? Yes, authentication and named vhosts via username and realm is ideal, but given that that information is usually not explicitly send by the client, if the imap server could assign the realm based on some implicit information such as the IP address, then there is an answer that should work while we all wait for more widespread support of SASL realms. If there was a patch to do this, would it be accepted into CVS? -- Todd Nemanich [EMAIL PROTECTED]
Re: How to add virtual domain support
Michael Fair wrote: Yes, the Cyrus server supports realms though it is largely unused. Currently SASL just fills the realm info in with the hostname of the machine. You can see this when you do sasldblistusers. In regards to all clients supportnig SASL. Perhaps it's only a matter of time, but will they implement it according to the standards (specifically Microsoft). I have a suggestion on this subject. What about the possibility of binding a realm to a local address for cyrus (IP based vhost)? Yes, authentication and named vhosts via username and realm is ideal, but given that that information is usually not explicitly send by the client, if the imap server could assign the realm based on some implicit information such as the IP address, then there is an answer that should work while we all wait for more widespread support of SASL realms. If there was a patch to do this, would it be accepted into CVS? -- Todd Nemanich [EMAIL PROTECTED] Protecting the opulent and staging moral standard, They expect redemption of character and self growth Bad Religion - Inner Logic
Re: How to add virtual domain support
I then planned that the users log in with their email address (or a slightly modified version of it to support older versions of Netscape and a couple other MUA's that didn't like email addresses as log in name) and rewrote the mailbox lookup routines to return the new mailbox instead of the original user.username mailbox. I've previously worked as a support techie. In my experience, users find it more logical to use their mail address when they log on to services. If this brakes older clients, make the user/domain separator configurable. What I did before was made a couple possibilities. You could use '@' or ':' ':' could also be used in place of periods in the domain name. I wasn't trying to pick a good character I was just trying to make something that would work. What would be a good alternative? [EMAIL PROTECTED] is obvious, but if that is not usable can we come up with something better than: username:domain:dom The first is to use Kerberos and just snag the domain information from there. This of course forces anyone who wants to use virtual domains to also use Kerberos which is completely impractical at this time. My intent is that this would be a supported feature, but not a requirement. What about SASL? SASL has different 'Login realms' - use the domain as realm. The problem is that email clients don't supply the realm information when they authenticate. If they log in as their email address then this isn't a problem because the login name contains the domain info but the holy grail in my mind's eye would be to allow [EMAIL PROTECTED] and [EMAIL PROTECTED] to both be able to authenticate as bob. In this case the domain information needs to be drawn from somewhere else. I'm mostly convinced at this point that until we are able to do name based virtual domains as in HTTP/1.1 or can do DNS queries on mail.foo.com:imap and get back both ip address and port information from the DNS server, the best answer is to use a FQEA as the login id. -- Michael --
Re: How to add virtual domain support
[...] What about SASL? SASL has different 'Login realms' - use the domain as realm. The problem is that email clients don't supply the realm information when they authenticate. If they log in as their email address then this isn't a problem because the login name contains the domain info but the holy grail in my mind's eye would be to allow [EMAIL PROTECTED] and [EMAIL PROTECTED] to both be able to authenticate as bob. IMHO SASL is the right way to do it. In time, clients probably will support SASL realms (just a matter of time before Microsoft realize the power of ADS/LDAP). OBTW: I'm not sure how Cyrus Imapd pass a login realm to SASL (does the imap server support this?) -- Ørnulf Nielsen
Re: How to add virtual domain support
The problem is that email clients don't supply the realm information when they authenticate. If they log in as their email address then this isn't a problem because the login name contains the domain info but the holy grail in my mind's eye would be to allow [EMAIL PROTECTED] and [EMAIL PROTECTED] to both be able to authenticate as bob. In this case the domain information needs to be drawn from somewhere else. I'm mostly convinced at this point that until we are able to do name based virtual domains as in HTTP/1.1 or can do DNS queries on mail.foo.com:imap and get back both ip address and port information from the DNS server, the best answer is to use a FQEA as the login id. This probably the best way to go. I remeber a email client once ( eudora???) that used [EMAIL PROTECTED] as the username to mean connect to popserver.com use username person. If it supported [EMAIL PROTECTED]@popserver.com I dont know. Until someone writes the RFC it wont exist . ( how do you get to write RFC I know in the past you just did one but now ?) -- Simon
Re: How to add virtual domain support
[...] What about SASL? SASL has different 'Login realms' - use the domain as realm. The problem is that email clients don't supply the realm information when they authenticate. If they log in as their email address then this isn't a problem because the login name contains the domain info but the holy grail in my mind's eye would be to allow [EMAIL PROTECTED] and [EMAIL PROTECTED] to both be able to authenticate as bob. IMHO SASL is the right way to do it. In time, clients probably will support SASL realms (just a matter of time before Microsoft realize the power of ADS/LDAP). OBTW: I'm not sure how Cyrus Imapd pass a login realm to SASL (does the imap server support this?) Yes, the Cyrus server supports realms though it is largely unused. Currently SASL just fills the realm info in with the hostname of the machine. You can see this when you do sasldblistusers. In regards to all clients supportnig SASL. Perhaps it's only a matter of time, but will they implement it according to the standards (specifically Microsoft). Microsoft supports CRAM-MD5 logins, but not according to the Spec so you only use the encrypted logins with Exchange server if you are using a Microsoft mail client. Outlook also isn't the only client out there either. If SASL catches on as an authentincation protocol and clients start implementing it directly then I completely concur that SASL is a great way to satisfy the need. So in the meantime we need to cook something up that people here on the list would be at least willing, and preferably excited about being able to implement in their environments. So far the best practice seems to be using the FQEA as the login name and supporting some kind of alias for those mail clients that weren't savvy enough to forsee us doing that. If that's the case then it's a fairly straightforward patch to add a domain property to the user structure which gets prepended to all folder names. If we combine this with the earlier separator or than dot patch we would get a folder heirarchy something like: domain.dom/user/persona domain.dom/publicfoldera The patch would include some code at login time to extract the domain info, keep the username, and throw the @ or the # away and reconstruct the mailbox name. This is gettting exciting! I can finally see an elegant way to add the virtual domain support to cyrus! -- Michael --
Re: How to add virtual domain support
The problem is that email clients don't supply the realm information when they authenticate. If they log in as their email address then this isn't a problem because the login name contains the domain info but the holy grail in my mind's eye would be to allow [EMAIL PROTECTED] and [EMAIL PROTECTED] to both be able to authenticate as bob. In this case the domain information needs to be drawn from somewhere else. I'm mostly convinced at this point that until we are able to do name based virtual domains as in HTTP/1.1 or can do DNS queries on mail.foo.com:imap and get back both ip address and port information from the DNS server, the best answer is to use a FQEA as the login id. This probably the best way to go. I remeber a email client once ( eudora???) that used [EMAIL PROTECTED] as the username to mean connect to popserver.com use username person. If it supported [EMAIL PROTECTED]@popserver.com I dont know. That's why we support an alternate login id. A not-so-pretty version would be: person:personaldomain:[EMAIL PROTECTED] I was tying to find something better than :, perhaps # person#personaldomain#[EMAIL PROTECTED] Of course: person#[EMAIL PROTECTED] might work as well. -- Michael --
Re: How to add virtual domain support
[...] I then planned that the users log in with their email address (or a slightly modified version of it to support older versions of Netscape and a couple other MUA's that didn't like email addresses as log in name) and rewrote the mailbox lookup routines to return the new mailbox instead of the original user.username mailbox. I've previously worked as a support techie. In my experience, users find it more logical to use their mail address when they log on to services. If this brakes older clients, make the user/domain separator configurable. [...] The first is to use Kerberos and just snag the domain information from there. This of course forces anyone who wants to use virtual domains to also use Kerberos which is completely impractical at this time. My intent is that this would be a supported feature, but not a requirement. What about SASL? SASL has different 'Login realms' - use the domain as realm. -- Ørnulf Nielsen
Re: How to add virtual domain support
Ørnulf Nielsen wrote: [...] I then planned that the users log in with their email address (or a slightly modified version of it to support older versions of Netscape and a couple other MUA's that didn't like email addresses as log in name) and rewrote the mailbox lookup routines to return the new mailbox instead of the original user.username mailbox. I've previously worked as a support techie. In my experience, users find it more logical to use their mail address when they log on to services. I agree with you. The users freak out when I tell them that their username is amartinez_domain4u_org for email and ftp, but are quiet ok to use [EMAIL PROTECTED] as login name for ftp/email/web etc
How to add virtual domain support
Hey all, We know there are a number of us that would love to support virtual domains directly in Cyrus and with the recent patch to make the separator character configurable I think we have a good base to make the virtual domains more of a native feature. The way I've always envisioned the addition of virtual domain support in cyrus was by adding the domain (or some alias) as part of the namespace. This email presents several approaches that we could take to add virtual domains to the cyrus codebase and I hope to elicit comments on how others think we want to go about doing this as well. I would like to especially get input from the CMU team and the other active developers in the hopes of creating patches that we all understand. For a while I thought we might even want to make a separate code branch to do the virtual domain support on, and then add in whatever patches apply to the main codebase as we go along until the virtual domain support has stabilized. I don't know if this will be absolutely necessary or not, I think it mostly depends on how intrusive we get with our virtual domain design. While I have done my best to keep in mind the different installations needs, my bias is towards many domains with small numbers of mailboxes (small being less than 100). The needs of this system are very different than one domain with 15,000 user maliboxes/public folders. I had already hacked in virtual domain suport in the 1.6.24 server by using the following scheme for the Cyrus namespace: domain_dom.user.usernames I found that this namespace schema was the best way to implement it as it models the current scheme the closest. The only thing that changes is that now the server has the concept of a root folder which is not necessarily the top of the tree. The easiest way to think about this is having the server doing a chroot on the IMAP namespace. I then planned that the users log in with their email address (or a slightly modified version of it to support older versions of Netscape and a couple other MUA's that didn't like email addresses as log in name) and rewrote the mailbox lookup routines to return the new mailbox instead of the original user.username mailbox. I am looking at reimplementing this for 2.0 but I wanted to get people's feddback on how we should go about doing it before we wrote the code and people couldn't use it. I'm fairly convinced that the IMAP namespace should resemble something like: domain.dom/user/username or domain.dom/publicfoldername where the domain name (or some alias) is the top level. As I mentioned earlier this closely resmbles what the server does now and seems to require the least amount of modification. Not using, and not being familiar with Kerberos at all I don't know how the domain feature there would translate to virtual domain support. Though I suppose that the support we added for virtual domains in general could easily be extended, modified, patched, or otherwise tweaked to make it compatible with the Kerberos domain feature. Ideally I would like to see something added to the IMAP hello messages where the client tells the server what server name it was trying to reach like in HTTP 1.1. Name based virtual domains have proven to be very useful and this would require a change to the IMAP spec. I've never participated in RFC modification before, but this is one feature that I'd love to see added to the spec because then we could really support native virtual domains by having separate namespaces for each domain. For the record I do not consider IP based virtual domains a scalable solution. We have over three hundred domains and to be forced to allocate over a full Class C for mail servers is not going to work for us. Especially given the fact that when we move into a distributed environment where we have multiple servers in geographicly separate locations serving the same namespace the problem of IP allocation begins to compound itself (this is different than a cluster at the same geographic location). Allow me to apologize if I sound vehement about this, but I've spent days trying to make IP based virtual domains work for us but with the number of domains we are supporting it just isn't scalable to the infrastructure we want to build. For the time being, we have just accepted the fact that all our users will just have to have unique log in names. Below I have presented my ideas on how to support virtual domains within the cyrus system and where each account would derive the domain info from. Please supply feedback both positive and negative to help us hash out the system. The first is to use Kerberos and just snag the domain information from there. This of course forces anyone who wants to use virtual domains to also use Kerberos which is completely impractical at this time. My intent is that this would be a supported feature, but not a requirement. The second is to make people use ther FQEN as their
