[POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)

[Kendrick Vargas]

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 wanna be lazy, set the defaultdomain option" errors instead of
disallowing the behavior alltogether? Having the ability to have a global
admin should be tied to the "virtdomains: yes" option, not the
defaultdomain option. It just makes more sense.

As for determining the IP address by reversing, I really think that should
be an option, because I really think it'll create more headaches than it's
worth.

Don't get me wrong. I love cyrus :-) It makes my life alot easier and I
especially love sieve and all the other things cyrus-imapd and cyrus-sasl
let me do. I've used cyrus in high user situations (50k+ users) since
about version 1.5.17 or so... I've also got a hacked version of 2.1
running on my personal server that lets me have usernames with the domain
part mixed in. Sorta my own virtdomains version of 2.1. Thanx again :-)
			-peace

-- 
Let he who is without clue kiss my ass