Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Quoting Rob Siemborski [EMAIL PROTECTED]: On Fri, 2 Jan 2004, Christos Soulios wrote: Rob Siemborski wrote: On Fri, 2 Jan 2004, Paul Boven wrote: The only argument I currently completely understand for an IP-only based setup is that of sites that need to distinguish ANONYMOUS users between domains (and prehaps that is good enough). What about being able to determine the virtual domain based on the ip address and presenting different ssl certificate for each domain? Even presenting different host name, one that is in accordance to the ssl certificate. All this happens long before authentication. Right? This would be really nice to implement. You can do that in a model that still allows users to add an @ sign and a domain to their userid. I cannot figure out how this can be achieved. And to make it clear, I will give an example. I have two domains domain1.com and domain2.com which are hosted by the hosts imap.domain1.com and imap.domain2.com respectively. These two servers must have two different certificates with cn=imap.domain1.com and cn=imap.domain2.com When the user connects to the imap.domain1.com and long before the user authentication takes place, the cyrus must be able to present the correct certificate. Because most mail clients will not accept to connect to the imap host imap.domain1.com and be presented a certificate with cn=imap.otherdomain.com But how can cyrus be able to know which is the correct certificate to present? Of course, not by retrieving the domain by the userid suffix. Then it is too late. The authentication has already taken place. In my opinion this must have taken place by the time the user connects. And then the only way for cyrus to determine the correct virtual domain is _only_ using the ip address of the server interface. Am I right or am I missing something here? Christos The only way to get a win out of a model that disallows that feature is to come up with something where it actively causes problems. And the SASL ANONYMOUS mechanism is about all I can currently see. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Sat, 3 Jan 2004, Christos Soulios wrote: You can do that in a model that still allows users to add an @ sign and a domain to their userid. I cannot figure out how this can be achieved. And to make it clear, I will give an example. I have two domains domain1.com and domain2.com which are hosted by the hosts imap.domain1.com and imap.domain2.com respectively. These two servers must have two different certificates with cn=imap.domain1.com and cn=imap.domain2.com When the user connects to the imap.domain1.com and long before the user authentication takes place, the cyrus must be able to present the correct certificate. Because most mail clients will not accept to connect to the imap host imap.domain1.com and be presented a certificate with cn=imap.otherdomain.com Sure. But if they are looking for a certificate for imap.otherdomain.com, why are they connecting to imap.domain1.com? This has nothing to do with what userid is presented. But how can cyrus be able to know which is the correct certificate to present? Of course, not by retrieving the domain by the userid suffix. Then it is too late. The authentication has already taken place. In my opinion this must have taken place by the time the user connects. And then the only way for cyrus to determine the correct virtual domain is _only_ using the ip address of the server interface. I don't understand why this requires denying users access via the [EMAIL PROTECTED] login names. Yes, they get the wrong certificate. But then, why are they connecting to the wrong interface in the first place? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Christos Soulios wrote: Quoting Rob Siemborski [EMAIL PROTECTED]: On Fri, 2 Jan 2004, Christos Soulios wrote: Rob Siemborski wrote: On Fri, 2 Jan 2004, Paul Boven wrote: The only argument I currently completely understand for an IP-only based setup is that of sites that need to distinguish ANONYMOUS users between domains (and prehaps that is good enough). What about being able to determine the virtual domain based on the ip address and presenting different ssl certificate for each domain? Even presenting different host name, one that is in accordance to the ssl certificate. All this happens long before authentication. Right? This would be really nice to implement. You can do that in a model that still allows users to add an @ sign and a domain to their userid. I cannot figure out how this can be achieved. And to make it clear, I will give an example. I have two domains domain1.com and domain2.com which are hosted by the hosts imap.domain1.com and imap.domain2.com respectively. These two servers must have two different certificates with cn=imap.domain1.com and cn=imap.domain2.com When the user connects to the imap.domain1.com and long before the user authentication takes place, the cyrus must be able to present the correct certificate. Because most mail clients will not accept to connect to the imap host imap.domain1.com and be presented a certificate with cn=imap.otherdomain.com But how can cyrus be able to know which is the correct certificate to present? Of course, not by retrieving the domain by the userid suffix. Then it is too late. The authentication has already taken place. In my opinion this must have taken place by the time the user connects. And then the only way for cyrus to determine the correct virtual domain is _only_ using the ip address of the server interface. Am I right or am I missing something here? IMO this should be handled by TLS. There is an extension (RFC 3546) to handle this, but I don't think its had wide deployment yet. -- 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
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Ken Murchison wrote: Christos Soulios wrote: If the domain passed in the fully qualified userid matches the domain selected from the ipaddress, then cyrus, proceeds to authenticate user using sasl. If it is different, then authentication fails without even making a query to the authentication mechanism. Can you explain why this matters. Are you limited certain domains to a particular interface for security reasons? I assumed that byaddr is just a convenience for the users. Security is one thing. More than this, my opinion is that in order cyrus to be deployed in a true multi domain environment, and thus actually be used by ISPs, admins must be able to distribute the virtual domains according to the name of the server, users are connecting to. In such a multi domain environment, users have no abillity to choose their domain by appending a @domain to their userid. However, now they can. Of course, one may argue that the same thing may be done using the correct authentication policy through sasl. This is true, but this sollution leaves part of the domain determination procedure to sasl. My opinion is that for the shake of complicity cyrus should handle this. Besides nobody needs the overhead of a sasl call, when cyrus can do the same thing. Moreover, being able to determine the virtual domain solely by the ip address the user was connected to, gives you - the cyrus developers - the option to know the domain before the user passes an authentication command to cyrus. I will give a short example which shows how useful this is. If my imap server hosts two virtual domains. And I happen to permit anonymous logins to only one of them. Having determined the domain before the user passes an authentication command, gives me the option to allow or deny an anonymous login. Of course, this is not something it can be implemented now. But I would like to see that too in some future release of cyrus. Trying to see a little bit further, dictates me that byaddr is not merely a convenience for users. It is a key feature to implement full virtual domains support in cyrus. How do you propose to handle admins, especially the global admin? Jure's proposal seems to make the most sense to me at this point (admins use fully qualified userids) Jure's proposal sounds fine to me too. With a small change. Which is that domain admins do not need to pass a @domain when they authenticate. In stead of this, the domain is determined upon connection - using the interface they connected to - and if the user is an admin of the virtual domain, is determined in same good old way it was determined in cyrus-2.1.x In the config file, of course the notation may be in the form of : admins: cyrus [EMAIL PROTECTED] [EMAIL PROTECTED] A different, cleaner (IMHO) implementation would be to have two config options. Something like: globaladmins: cyrus domainadmins: [EMAIL PROTECTED] [EMAIL PROTECTED] Regards, Christos -- Christos Soulios (soulbros_at_noc.uoa.gr) Microsoft is not the answer. Microsoft is the question. No is the answer.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Hi Christos, everyone, Christos Soulios wrote: Security is one thing. More than this, my opinion is that in order cyrus to be deployed in a true multi domain environment, and thus actually be used by ISPs, admins must be able to distribute the virtual domains according to the name of the server, users are connecting to. In such a multi domain environment, users have no abillity to choose their domain by appending a @domain to their userid. Security is a very important thing. And security to me means encryption, not only of the authentication phase but of the whole session. Now with HTTPS I know you loose the ability to support virtual domains, because the TLS session must be setup before the requested URL is transferred. This means you can only have one hostname per IP-adres as soon as you use SSL. Wouldn't you run into the same problem when enabling virtual domain support on cyrus? I've deployed several single domain cyrus servers, but am working on my first multidomain one, with Squirrelmail via SSL on top. So the way things look now is that the machine will have only one hostname, imap.example.com, and that everyone logs in with their complete email-address as the fully qualified username, either with imaps or via https and squirrelmail. In short: I think we should keep the ability to allow users to provide fully qualified usernames. Regards, Paul Boven.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Paul Boven wrote: Hi Christos, everyone, Security is a very important thing. And security to me means encryption, not only of the authentication phase but of the whole session. Now with HTTPS I know you loose the ability to support virtual domains, because the TLS session must be setup before the requested URL is transferred. This means you can only have one hostname per IP-adres as soon as you use SSL. Wouldn't you run into the same problem when enabling virtual domain support on cyrus? Well, I do not want to have a flame on this matter. Besides, it is beyond this thread what security is. To me your proposal is not about security, it is about content encryption. Encryption is just one aspect of security. I've deployed several single domain cyrus servers, but am working on my first multidomain one, with Squirrelmail via SSL on top. So the way things look now is that the machine will have only one hostname, imap.example.com, and that everyone logs in with their complete email-address as the fully qualified username, either with imaps or via https and squirrelmail. In short: I think we should keep the ability to allow users to provide fully qualified usernames. I totally agree with you. The ability to append the domain to the user id is already implemented. What I suggest is just another option, which suits my needs and I think that there will be others which will find it useful in the future. Regards, Paul Boven. -- Christos Soulios (soulbros_at_noc.uoa.gr) Microsoft is not the answer. Microsoft is the question. No is the answer.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Fri, 2 Jan 2004, Paul Boven wrote: Security is a very important thing. And security to me means encryption, not only of the authentication phase but of the whole session. Now with HTTPS I know you loose the ability to support virtual domains, because the TLS session must be setup before the requested URL is transferred. While this is definately true in HTTP (as sensitive information travesrses the network otherwise unencrypted), it is no where near as important in IMAP, unless you are concerned about people knowing what mailboxes you select (or if you use a mailbox that only gets APPENDed to). In almost every case, all of the information available in Cyrus has already crossed the network unencrypted, be it via SMTP between sites or via NNTP from a feeder peer. So, the contents of the messages have already been exposed, so the *content* isn't secure anyway. The only argument I currently completely understand for an IP-only based setup is that of sites that need to distinguish ANONYMOUS users between domains (and prehaps that is good enough). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Rob Siemborski wrote: On Fri, 2 Jan 2004, Paul Boven wrote: The only argument I currently completely understand for an IP-only based setup is that of sites that need to distinguish ANONYMOUS users between domains (and prehaps that is good enough). What about being able to determine the virtual domain based on the ip address and presenting different ssl certificate for each domain? Even presenting different host name, one that is in accordance to the ssl certificate. All this happens long before authentication. Right? This would be really nice to implement. Christos -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Christos Soulios (soulbros_at_noc.uoa.gr) Microsoft is not the answer. Microsoft is the question. No is the answer.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Fri, 2 Jan 2004, Christos Soulios wrote: Rob Siemborski wrote: On Fri, 2 Jan 2004, Paul Boven wrote: The only argument I currently completely understand for an IP-only based setup is that of sites that need to distinguish ANONYMOUS users between domains (and prehaps that is good enough). What about being able to determine the virtual domain based on the ip address and presenting different ssl certificate for each domain? Even presenting different host name, one that is in accordance to the ssl certificate. All this happens long before authentication. Right? This would be really nice to implement. You can do that in a model that still allows users to add an @ sign and a domain to their userid. The only way to get a win out of a model that disallows that feature is to come up with something where it actively causes problems. And the SASL ANONYMOUS mechanism is about all I can currently see. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Wed, 31 Dec 2003 16:09:47 +0100 Christian Schulte [EMAIL PROTECTED] wrote: How are loginrealms handled if virtdomain-support gets enabled when it was in use before without virtdomains ? I forgot a bit about loginrealms ... they make sense to me in a setup where mail system is set up for a single domain but you have users in other domains that would like to auth to your imap server ... Now what to do in multi domain setup? Apply loginrealms to all domains hosted by server? My guess would be no ... I'd even suggest ignoring this option in multidomain setup as it would only bring on additional confusion in configuring things :) The middle way would be something like per domain loginrealms ... if anyone *really* need this ... but i'd suggest him first to clean up his system design. -- Jure Pear
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Fri, 2 Jan 2004 13:09:43 -0500 (EST) Rob Siemborski [EMAIL PROTECTED] wrote: The only way to get a win out of a model that disallows that feature is to come up with something where it actively causes problems. Yes, and this requires active knowledge of cyrus sasl code. I think you guys know most about it :) And the SASL ANONYMOUS mechanism is about all I can currently see. Hrm yes. RFC 2245 does not mention this situation ... I see two ways out of it: * extend rfc to allow somethign like [EMAIL PROTECTED] * allow only one anonymous user per IP (domain) ... In case of many domains on one IP, defaultdomain would be a good way to specify how to treat anonymous user. -- Jure Pear
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Fri, 2 Jan 2004, Paul Boven wrote: Christos Soulios wrote: Security is one thing. More than this, my opinion is that in order cyrus to be deployed in a true multi domain environment, and thus actually be used by ISPs, admins must be able to distribute the virtual domains according to the name of the server, users are connecting to. In such a multi domain environment, users have no abillity to choose their domain by appending a @domain to their userid. Security is a very important thing. And security to me means encryption, not only of the authentication phase but of the whole session. Now with HTTPS I know you loose the ability to support virtual domains, because the TLS session must be setup before the requested URL is transferred. This means you can only have one hostname per IP-adres as soon as you use SSL. Wouldn't you run into the same problem when enabling virtual domain support on cyrus? I think you are confusing virtual domain support with apache virtual hosts style support. Virtual domain support (as I understand it) is just supposed to be the ability to maintain mailboxes seperated for each of a bunch of domains. In this case, the SSL negotiations are handled between the client and the server before any authentication happens. The only time this would matter to you is if you want your imap server to have different names, which has absolutely no bearing on the actual functionality of the virtual domain support. In that case, you could probably (through command line options specified in the cyrus.conf) specify different instances of imapd on each interface with different imapd.confs with seperate ssl configs. The only reason this matters is if you want each client to connect to imap.theirdomain.com (or some such) for imap/pop access, and additionally setup SSL for each one individually. Why anyone would do this over just having one imap access point is beyond me. In my reluctant experience, it just raises maintenance and support overhead. -peace -- Let he who is without clue kiss my ass
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Quoting Ken Murchison [EMAIL PROTECTED]: But authentication should fail in this case, unless the user's in two different domains have the same userid and password. Actually, I think that it is more efficient if cyrus-imap did all the virtual domains handling, without the assistance of any authentication mechanism. Don't know. Rob and I wondered what would be the reasonable thing to do if byipaddess was configured and a user used a fully qualified userid to log in. If the domain passed in the fully qualified userid matches the domain selected from the ipaddress, then cyrus, proceeds to authenticate user using sasl. If it is different, then authentication fails without even making a query to the authentication mechanism. Its not a problem to implement it. I'd like to get some more discussion on how the two methods can/should interact. These methods are totally different and there is no reason/need for interacting. One method uses _only_ the userid to find out the user's virtual domain, the other one uses _only_ the host's ip address. Christos
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Jure Pear wrote: virtdomains=ipaddr (or something) here we need to teach server the ip-domain mapping. reverse dns? most likely. server accepts authenticates usernames without @domain on appropriate interfaces (ip adresses) and it searches for username only in the domain the ip adress the user is coming from belongs. [EMAIL PROTECTED] usernames should be rejected IMHO. global admin should be specified without the @domain and authenticated on any ip address. per domain admin users should be specified with @domain and should only authenticate when coming to the right ip address. So, you're suggesting that admins always use fully qualified userids? This would work, but it requires that an unqualified userid be checked to see if its an admin before appending the domain from the ip address. This is probably the easiest way to handle the global admin without enforcing a default domain and also allows something like: admins: cyrus [EMAIL PROTECTED] [EMAIL PROTECTED] Is there a problem if *any* user is allowed to use a fully qualified userid in an ipaddr config? -- 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
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Christos Soulios wrote: If the domain passed in the fully qualified userid matches the domain selected from the ipaddress, then cyrus, proceeds to authenticate user using sasl. If it is different, then authentication fails without even making a query to the authentication mechanism. Can you explain why this matters. Are you limited certain domains to a particular interface for security reasons? I assumed that byaddr is just a convenience for the users. How do you propose to handle admins, especially the global admin? Jure's proposal seems to make the most sense to me at this point (admins use fully qualified userids) -- 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
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Am Mittwoch, 31. Dezember 2003 02:47 schrieb Jure Pear: On Tue, 30 Dec 2003 13:33:37 -0500 Ken Murchison [EMAIL PROTECTED] wrote: Its not a problem to implement it. I'd like to get some more discussion on how the two methods can/should interact. Let me share my point of view: virtdomains=off: server accepts authenticates usernames without @domain on any interface it is configured to listen on. this is basically the 2.1 behaviour, so let say the handling of [EMAIL PROTECTED] kind of usernames is undefined (because there were some early 3rd party patches to handle them). admin is only one, so no need for global admins. Handling of [EMAIL PROTECTED] kind of usernames is defined by: loginrealms: empty string The list of remote realms whose users may log in using cross-realm authentications. Seperate each realm name by a space. (A cross-realm identity is considered any identity returned by SASL with an @ in it.) So every fully-qualified username gets its @domain part stripped no matter what it contains if its mentioned in loginrealms otherwise the username is rejected. This makes @domain logins possible without the need for virtdomains so that someone planning to migrate to virtdomains already has fully qualified usernames in use which will make things easier during the update. virtomains=userid server server accepts authenticates usernames without @domain on any interface it is configured to listen on only if the defaultdomain is set... All unqualified usernames are treated as @defaultdomain. Usernames @loginrealms are also treated as @defaultdomain (@loginrealms part gets also stripped to un-qualify the userid) ? without defaultdomain server accepts authenticates only usernames in the form [EMAIL PROTECTED], where domain specifies the hirearchy tree the user belongs to. global admin should be specified without the @domain and admin users with @domain should only have rights over their domain tree. Here the only existing un-qualified usernames are global admins ? loginrealms has no effect ? virtdomains=ipaddr (or something) here we need to teach server the ip-domain mapping. reverse dns? most likely. server accepts authenticates usernames without @domain on appropriate interfaces (ip adresses) and it searches for username only in the domain the ip adress the user is coming from belongs. [EMAIL PROTECTED] usernames should be rejected IMHO. global admin should be specified without the @domain and authenticated on any ip address. per domain admin users should be specified with @domain and should only authenticate when coming to the right ip address... ...where they will login with an un-qualified username. Completely no @domain usernames nowhere but in the admins line. loginrealms also has no effect ? How are loginrealms handled if virtdomain-support gets enabled when it was in use before without virtdomains ? -- Christian
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
I just committed some code to CVS which changes the virtdomains option from a SWITCH to an ENUM having 3 options: off/no/0/false/f (disabled) userid(fully qualified userids only) on/yes/1/true/t (current behavior) What this means (hopefully) is that existing installations of 2.2 code (whether virtdomains is enabled or not) should be unaffected. Those that don't want the reverse IP address lookup can use the userid option. Great answer! Perfect for us. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
This means that there is no choice for an administrator who might want to distribute users to the domains _only_ according to the IP address of the server that users connect to? I would not like my users to have the ability to choose a domain only by appending a @domain to their userid. Are there any negatives consequences for implementing a byipaddress only option too? I would like to see it implemented in cyrus, if this is not a problem. Regards, Christos Ken Murchison wrote: I just committed some code to CVS which changes the virtdomains option from a SWITCH to an ENUM having 3 options: off/no/0/false/f(disabled) userid(fully qualified userids only) on/yes/1/true/t(current behavior) What this means (hopefully) is that existing installations of 2.2 code (whether virtdomains is enabled or not) should be unaffected. Those that don't want the reverse IP address lookup can use the userid option. -- Christos Soulios (soulbros_at_noc.uoa.gr) Microsoft is not the answer. Microsoft is the question. No is the answer.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Tue, 30 Dec 2003, Christos Soulios wrote: This means that there is no choice for an administrator who might want to distribute users to the domains _only_ according to the IP address of the server that users connect to? I would not like my users to have the ability to choose a domain only by appending a @domain to their userid. Are there any negatives consequences for implementing a byipaddress only option too? I would like to see it implemented in cyrus, if this is not a problem. It is not, but the default setup will do what you want... -Igor Regards, Christos Ken Murchison wrote: I just committed some code to CVS which changes the virtdomains option from a SWITCH to an ENUM having 3 options: off/no/0/false/f(disabled) userid(fully qualified userids only) on/yes/1/true/t(current behavior) What this means (hopefully) is that existing installations of 2.2 code (whether virtdomains is enabled or not) should be unaffected. Those that don't want the reverse IP address lookup can use the userid option. -- Igor
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Tue, 30 Dec 2003 13:33:37 -0500 Ken Murchison [EMAIL PROTECTED] wrote: Its not a problem to implement it. I'd like to get some more discussion on how the two methods can/should interact. Let me share my point of view: virtdomains=off: server accepts authenticates usernames without @domain on any interface it is configured to listen on. this is basically the 2.1 behaviour, so let say the handling of [EMAIL PROTECTED] kind of usernames is undefined (because there were some early 3rd party patches to handle them). admin is only one, so no need for global admins. virtomains=userid server server accepts authenticates usernames without @domain on any interface it is configured to listen on only if the defaultdomain is set. without defaultdomain server accepts authenticates only usernames in the form [EMAIL PROTECTED], where domain specifies the hirearchy tree the user belongs to. global admin should be specified without the @domain and admin users with @domain should only have rights over their domain tree. virtdomains=ipaddr (or something) here we need to teach server the ip-domain mapping. reverse dns? most likely. server accepts authenticates usernames without @domain on appropriate interfaces (ip adresses) and it searches for username only in the domain the ip adress the user is coming from belongs. [EMAIL PROTECTED] usernames should be rejected IMHO. global admin should be specified without the @domain and authenticated on any ip address. per domain admin users should be specified with @domain and should only authenticate when coming to the right ip address. virtdomains=on server first looks for [EMAIL PROTECTED], then in case of user the ip address and then the defaultdomain setting. reject if none are available. global admin should be specified without the @domain and admin users with @domain should only have rights over their domain tree. This is how i would lay out things ... dont know if it matches current status accurately. Are here any obvious shortcomings and problems i'm not seeing? -- Jure Pear
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Ken Murchison wrote: Kendrick Vargas wrote: Hi folks, I asked earlier how I could get users within the primary (default) domain hashed into the domain/ subdirectories of the imap spool instead of being right at the toplevel without any real domain association. I was told that the defaultdomain option was meant to ease the passage from version 2.1 to 2.2, so if I simply didn't set it, I'd get the hashing all nice and pretty. Now I have a slightly different issue. I've finally gone back and set things up in this manner. No defaultdomain setting. Users are hashed in the domains as they should be, however I'd like to have a global admin. The documents say I need the defaultdomain to have a global admin. Why? Is there anyway to get around this? I'd like to have a global admin without having the defaultdomain set. I don't really understand why that would be a requirement. Maybe this behavior should be some sort of configurable flag. If someone could point me in the direction to the source I could hack past to disable this behavior, I'd greatly appreciate it. This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. I just committed some code to CVS which changes the virtdomains option from a SWITCH to an ENUM having 3 options: off/no/0/false/f(disabled) userid (fully qualified userids only) on/yes/1/true/t (current behavior) What this means (hopefully) is that existing installations of 2.2 code (whether virtdomains is enabled or not) should be unaffected. Those that don't want the reverse IP address lookup can use the userid option. -- 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
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Sweeet, but I think i'll wait till the next full release to test it, since the target system is sorta production. Thanks :-) -peace On Mon, 29 Dec 2003, Ken Murchison wrote: Ken Murchison wrote: Kendrick Vargas wrote: Hi folks, I asked earlier how I could get users within the primary (default) domain hashed into the domain/ subdirectories of the imap spool instead of being right at the toplevel without any real domain association. I was told that the defaultdomain option was meant to ease the passage from version 2.1 to 2.2, so if I simply didn't set it, I'd get the hashing all nice and pretty. Now I have a slightly different issue. I've finally gone back and set things up in this manner. No defaultdomain setting. Users are hashed in the domains as they should be, however I'd like to have a global admin. The documents say I need the defaultdomain to have a global admin. Why? Is there anyway to get around this? I'd like to have a global admin without having the defaultdomain set. I don't really understand why that would be a requirement. Maybe this behavior should be some sort of configurable flag. If someone could point me in the direction to the source I could hack past to disable this behavior, I'd greatly appreciate it. This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. I just committed some code to CVS which changes the virtdomains option from a SWITCH to an ENUM having 3 options: off/no/0/false/f (disabled) userid(fully qualified userids only) on/yes/1/true/t (current behavior) What this means (hopefully) is that existing installations of 2.2 code (whether virtdomains is enabled or not) should be unaffected. Those that don't want the reverse IP address lookup can use the userid option. -- Let he who is without clue kiss my ass
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Mon, 29 Dec 2003, Ken Murchison wrote: Ken Murchison wrote: Kendrick Vargas wrote: Hi folks, I asked earlier how I could get users within the primary (default) domain hashed into the domain/ subdirectories of the imap spool instead of being right at the toplevel without any real domain association. I was told that the defaultdomain option was meant to ease the passage from version 2.1 to 2.2, so if I simply didn't set it, I'd get the hashing all nice and pretty. Now I have a slightly different issue. I've finally gone back and set things up in this manner. No defaultdomain setting. Users are hashed in the domains as they should be, however I'd like to have a global admin. The documents say I need the defaultdomain to have a global admin. Why? Is there anyway to get around this? I'd like to have a global admin without having the defaultdomain set. I don't really understand why that would be a requirement. Maybe this behavior should be some sort of configurable flag. If someone could point me in the direction to the source I could hack past to disable this behavior, I'd greatly appreciate it. This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. I just committed some code to CVS which changes the virtdomains option from a SWITCH to an ENUM having 3 options: off/no/0/false/f (disabled) userid(fully qualified userids only) on/yes/1/true/t (current behavior) What this means (hopefully) is that existing installations of 2.2 code (whether virtdomains is enabled or not) should be unaffected. Those that don't want the reverse IP address lookup can use the userid option. I have not checked the code, but how does this affect global admins? -- Igor
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Igor Brezac wrote: On Mon, 29 Dec 2003, Ken Murchison wrote: Ken Murchison wrote: Kendrick Vargas wrote: Hi folks, I asked earlier how I could get users within the primary (default) domain hashed into the domain/ subdirectories of the imap spool instead of being right at the toplevel without any real domain association. I was told that the defaultdomain option was meant to ease the passage from version 2.1 to 2.2, so if I simply didn't set it, I'd get the hashing all nice and pretty. Now I have a slightly different issue. I've finally gone back and set things up in this manner. No defaultdomain setting. Users are hashed in the domains as they should be, however I'd like to have a global admin. The documents say I need the defaultdomain to have a global admin. Why? Is there anyway to get around this? I'd like to have a global admin without having the defaultdomain set. I don't really understand why that would be a requirement. Maybe this behavior should be some sort of configurable flag. If someone could point me in the direction to the source I could hack past to disable this behavior, I'd greatly appreciate it. This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. I just committed some code to CVS which changes the virtdomains option from a SWITCH to an ENUM having 3 options: off/no/0/false/f(disabled) userid (fully qualified userids only) on/yes/1/true/t (current behavior) What this means (hopefully) is that existing installations of 2.2 code (whether virtdomains is enabled or not) should be unaffected. Those that don't want the reverse IP address lookup can use the userid option. I have not checked the code, but how does this affect global admins? If you set virtdomains:on it will behave like the current code. If you set virtdomains:userid you can have a global admin without setting defaultdomain. Like I said, you *shouldn't* notice any difference unless you switch from on to userid. -- 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
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Hi list. It would be very helpful if I could choose _only_ one from these options. You see, with current code for virtual domains, I faced the following frustrating situation. Provided that I have set up two domains foo.com and bar.com in my dns server and that I have given 2 IP addresses to my Cyrus. Then a user may connect to the server foo.com and login with the username [EMAIL PROTECTED] Well, this is a pretty uncomfortable situtation, since users may login to different domains from the ones they got connected, which seems a little bit weird to me. My opinion is that cyrus should provide an option on how to find out the domain. Also, I understand that current situation is helpful for some admins. For this reason I would suggest having 4 options, which would be something like : none, byuserid, byipaddress, both. I think this would be a fair sollution for everyone. Christos Ken Murchison wrote: This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. Happy Holidays, Ken -- Christos Soulios (soulbros_at_noc.uoa.gr) Microsoft is not the answer. Microsoft is the question. No is the answer.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
I vote for the config option. I'm always in favour of less hard coded behaviour and more configuration options (with sane defaults). :) Regards On Mon, 2003-12-29 at 00:40, Christos Soulios wrote: Hi list. It would be very helpful if I could choose _only_ one from these options. You see, with current code for virtual domains, I faced the following frustrating situation. Provided that I have set up two domains foo.com and bar.com in my dns server and that I have given 2 IP addresses to my Cyrus. Then a user may connect to the server foo.com and login with the username [EMAIL PROTECTED] Well, this is a pretty uncomfortable situtation, since users may login to different domains from the ones they got connected, which seems a little bit weird to me. My opinion is that cyrus should provide an option on how to find out the domain. Also, I understand that current situation is helpful for some admins. For this reason I would suggest having 4 options, which would be something like : none, byuserid, byipaddress, both. I think this would be a fair sollution for everyone. Christos Ken Murchison wrote: This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. Happy Holidays, Ken -- Oliver Jones Director [EMAIL PROTECTED] +64 (21) 41 2238 Deeper Design Limited +64 (7) 377 3328 www.deeperdesign.com
[POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
Kendrick Vargas wrote: Hi folks, I asked earlier how I could get users within the primary (default) domain hashed into the domain/ subdirectories of the imap spool instead of being right at the toplevel without any real domain association. I was told that the defaultdomain option was meant to ease the passage from version 2.1 to 2.2, so if I simply didn't set it, I'd get the hashing all nice and pretty. Now I have a slightly different issue. I've finally gone back and set things up in this manner. No defaultdomain setting. Users are hashed in the domains as they should be, however I'd like to have a global admin. The documents say I need the defaultdomain to have a global admin. Why? Is there anyway to get around this? I'd like to have a global admin without having the defaultdomain set. I don't really understand why that would be a requirement. Maybe this behavior should be some sort of configurable flag. If someone could point me in the direction to the source I could hack past to disable this behavior, I'd greatly appreciate it. This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. Happy Holidays, Ken -- 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
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Fri, 26 Dec 2003, Ken Murchison wrote: Kendrick Vargas wrote: Hi folks, I asked earlier how I could get users within the primary (default) domain hashed into the domain/ subdirectories of the imap spool instead of being right at the toplevel without any real domain association. I was told that the defaultdomain option was meant to ease the passage from version 2.1 to 2.2, so if I simply didn't set it, I'd get the hashing all nice and pretty. Now I have a slightly different issue. I've finally gone back and set things up in this manner. No defaultdomain setting. Users are hashed in the domains as they should be, however I'd like to have a global admin. The documents say I need the defaultdomain to have a global admin. Why? Is there anyway to get around this? I'd like to have a global admin without having the defaultdomain set. I don't really understand why that would be a requirement. Maybe this behavior should be some sort of configurable flag. If someone could point me in the direction to the source I could hack past to disable this behavior, I'd greatly appreciate it. This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. I depend on the current behavior. My users can login with their full qualified username or just their userid provided they connect to the right interface. I find this very useful when merging email servers. We've written a patch to address this issue, but Rob decided against the patch (performance issue): (http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-develmsg=255) -- Igor
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
On Fri, 26 Dec 2003, Ken Murchison wrote: Kendrick Vargas wrote: Hi folks, I asked earlier how I could get users within the primary (default) domain hashed into the domain/ subdirectories of the imap spool instead of being right at the toplevel without any real domain association. I was told that the defaultdomain option was meant to ease the passage from version 2.1 to 2.2, so if I simply didn't set it, I'd get the hashing all nice and pretty. Now I have a slightly different issue. I've finally gone back and set things up in this manner. No defaultdomain setting. Users are hashed in the domains as they should be, however I'd like to have a global admin. The documents say I need the defaultdomain to have a global admin. Why? Is there anyway to get around this? I'd like to have a global admin without having the defaultdomain set. I don't really understand why that would be a requirement. Maybe this behavior should be some sort of configurable flag. If someone could point me in the direction to the source I could hack past to disable this behavior, I'd greatly appreciate it. This has to do with the fact that the virtdomains code handles domains by login id and ip address simultaneously. If you don't have a fully qualified user id, the code will do a reverse lookup on the ip address of the local NIC and add that domain. The only way to prevent the appending of the domain is by setting a default domain. which then makes the directory structure a bit messy and all attempts to circumvent that end up looking like a hack. I could probably fix this by changing the code to only do virtdomains by one mechanism at a time, NOT both. Since the 2.2 code recently added the ability to have enumerated config options, I could change the virtdomains option to be a tri-state variable, something like [ off, byuserid, byipaddress ]. As long as nobody is depending on the current behavior, I have no problem changing this. Of course, if people do need the current bevavior, I could add a fourth state to handle this. I'd like to get some feedback from those of you that have been using the virtdomains code before I go and make any changes. Well, I'd like you to consider that the people who'd be using the virtual domains code most will likely be ISP's. ISP's typically can't afford to assign an IP address for each mail domain they'd like to receive or send email for. I personally fall into the category of having bandwidth available to me from my work and having a box on which I host my friends' vanity domains. I certainly can't afford to use up IP addresses. In fact, due to the growing lack of IPv4 address availability, and the not-yet ready IPv6 system on the net, I doubt ANYONE will be in a position to throw around IP addresses pretty soon. In larger organizations, assigning IP addresses, and assigning the reverses to a specific domain is an expensive task. The only time I know of it really being done is for SSL hosts (web or otherwise). Furthermore, if you do that, it stands to reason that the web traffic and other traffic for that domain should go that that specific IP, cuz, well, having a specific IP is something of an honor. ISP's tend to have small farms of machines, or specific machines to handle various aspects of the service. A small web farm maybe, a machine to handle mail, another to handle database access. It's why there are MX records, so that mail doesn't necessarily depend on an IP address. I think the behavior of determining the virtualhost by reversing the IP address is just gonna create frustration here and there because many people will be adjusting their configuration with workarounds (which they'll have to teach the junior admins in case the behavior is fixed later). I also think it's going to be catering to a minority and I don't believe it would make a good default. One of the things I love about cyrus is that it helps me control my users and my system in a way that just makes things way easier for me. Combined with mysql and postfix, cyrus lets me let my friends control their vanity domains and give accounts to their friends (assuming the meet the they'd better not abuse this idea I've drilled into their heads) without having to come to me. It's beautiful, simply beautiful. I also tend to replicate the setup on my personal server over to my business clients because it simply works. Postfix + AMaViS-NG + spamassassin + cyrus is a winning combination for a mail server. All the configurations in MySQL, all components checking MySQL for their configurations, it is simply beautiful. The thing of it is, the only thing that really bothered me about the current setup is that a global admin requires a defaultdomain to be set. It just doesn't make sense to me. I realize that you need to be able to infer a domain in case a defaultdomain isn't set, but if there just isn't anything you can infer, then why not just spit back permission denied or if you
