the autocreate feature (Cyrus IMAPd 2.3.7 Released)

[Greg A. Woods]

At Tue, 18 Jul 2006 09:34:55 -0400,
Ken Murchison wrote:
> 
> Timo Veith wrote:
> > do I recall correctly that there was a mail in the archive where the 
> > possibility of add the autocreate patch to a newer cyrus version? 
> > Something was about to be changing in the murder code or so and thatfore 
> > it could be possible or so.
> > 
> > How far has this issue come?
> 
> I haven't looked at it.  I've been working on stuff that CMU needs 
> (autocreate isn't one of them).  If a version of the autocreate patch is 
> posted that works in all modes (altnamespace, unixhierarchysep, 
> virtdomains, Murder), then we will most likely accept.

I can certainly appreciate your need and desire to work on what CMU needs.

I'd just like to point out that while authentication and authorisation
needs obviously vary widely, I think the complexity of setting up Cyrus
with its very own separate A&A services is exactly what makes it
difficult for smaller sites to adopt.  Such smaller sites typically (at
least in my experience) have to create OS-level accounts for their users
anyway, whether it be for personal web pages at an ISP, or for file
server access in a corporate environment.  Indeed larger sites which use
something like Kerberos will also already have existing A&A services
which will be considered authoritative for determining mailbox existence
too.  Also note that typical default Unix MTA configurations will by
default treat the OS-level A&A information as authoritative for what
mailboxes should exist on the server as well.  I.e. traditional Unix
philosophy is that all accounts get to use mail and traditional MTAs
expect the MDA to be able to deliver messages to a mailbox for every
account regardless of whether that account was just added moments ago or
not.  The Cyrus philosophy of effectively separating the authorisation
for mail delivery (and retrieval) from the authorisation for every other
system function is rather alien to many.  Unix types typically don't
expect to have to create a mailbox for a new user any more than they
would have to do something special give that user printing, HTTP, FTP,
or any other kind of service their systems provide.

So, the autocreate feature, combined with "saslauthd -a getpwent" (and
kerberos, and maybe pam, for those who think it's an answer to any real
problem, or shadow for those stuck with such hacks), actually eliminates
all of the separate A&A services complexity completely and reduces Cyrus
back to nearly being as simple to set up as any other true Unix-based
mailbox server.  (Perhaps a slightly more robust and automated install
procedure built into the "make install" phase would help too.)

I.e. while CMU and many other existing sites might not need autocreate,
I think it's a feature that would endear Cyrus to a far wider audience
than it currently enjoys.

What bothers me most in the water under the bridge department is that
there have been various forms of the autocreate feature floating around,
which have been well tested in many production environments, long before
any of the Cyrus features which are incompatible with autocreate with
were first introduced and I dare say that had the patch been
incorporated earlier then such compatibility with the other new features
may just have come along for the ride, so to speak, as those other newer
features were implemented.

Also it seems to me that hinging the inclusion of the autocreate feature
on its full and total compatibility with some other features is somewhat
unnecessary.  While such compatibility would be nice, I think it should
be obvious from the history of those who do use the existing
implementation(s) that such compatibility is totally unnecessary (at
least for our current uses).  I'd say let's get it in there now and just
document what it doesn't work well with yet.  Then those who use it will
be able to spend more of their maintenance time and effort on eventually
working on new compatibility for other features as they come across the
need rather than continually having to manage private changes for their
production environments -- something which is even more of a big
headache for exactly those smaller sites which autocreate benefits most.

The only real feature I'd find useful to go along with autocreate as it
stands today would be some tool to regularly (and automatically, kind of
like an "idle" job) go through the mailboxes list and report those which
no longer correspond to valid accounts and at the same time move their
associated message and data files off into some archive partition for
eventual manual offline archiving, deletion, or even retrieval if an
account is re-created for the same human user.

(BTW, the autocreate patch I use now with 2.2.x does seem to work well
with unixhierarchysep, as do I believe the relevant patches did with all
older releases as well.  I've never tried it with altnamespace as that
feature seems to bugger up clients like pine too much to ever use
anyway.)

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>       Secrets of the Weird <woods at weird.com>