Re: How to add virtual domain support
On Sat, May 05, 2001 at 10:38:55AM -0700, Michael Fair wrote: > 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 Please do not use IP addresses in directoty names, use the domain names instead. IP addresses can change while the domain names remain the same. Also, think about the future; IPv6 addresses as directory names would be very ugly... The DNS was designed to map IP addresses to meaningful names, use it. Gabor -- Gabor Gombas Eotvos Lorand University E-mail: [EMAIL PROTECTED]Hungary
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
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
On Fri, 4 May 2001, Joe Rhett wrote: > 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 Doh. I realized my mistake a minute after sending it. Not enough coffee and its 5pm on Friday... > So I'll deny your *plonk*, and raise you one kiddo. Pay attention! gratefully accepted. :)
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
> > The best way is to have the client log into a single hostname with a single > > IP (and single matching certificate) but provide domain information during > > the login. > > This is indeed a better idea, which already has been discussed. My > opinion is that the server should have the option to implicitly set it's > realm information, since you don't always have the information you need > from the client to set the realm. If you don't like it, don't use it. :) > 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. -- 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
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
Joe Rhett wrote: > > It's not possible at that level, which is what I was saying. > > The best way is to have the client log into a single hostname with a single > IP (and single matching certificate) but provide domain information during > the login. This is indeed a better idea, which already has been discussed. My opinion is that the server should have the option to implicitly set it's realm information, since you don't always have the information you need from the client to set the realm. If you don't like it, don't use it. :) 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. -- 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
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
It's not possible at that level, which is what I was saying. The best way is to have the client log into a single hostname with a single IP (and single matching certificate) but provide domain information during the login. The second, non-scaleable approach is a different configuration per IP address which is now supported, but doesn't scale due the cost of IPs, the cost of certificates, etc etc. On Fri, May 04, 2001 at 02:03:30PM -0400, Todd Nemanich wrote: > 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 -- 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
> 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
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
> > 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
>[...] >>> 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. 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?) -- Ørnulf Nielsen
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
Ø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
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
