On Wed, Oct 3, 2012, at 11:50 PM, mailing list subscriber wrote:
> On Wed, Oct 3, 2012 at 8:53 AM, Bron Gondwana <brong@xxxxxxxxxxx> wrote:
> > On Wed, Oct 3, 2012, at 07:22 AM, Simon Walter wrote:
> >> On 10/03/2012 01:32 PM, Andrew Morgan wrote:
> >> > If I remember right, the autocreate patches don't work in a Cyrus
> >> > Murder (cluster). Until the autocreate patches work with all the
> >> > supported ways of running Cyrus IMAP, I don't think they will be
> >> > included.
> >> >
> >> > I can understand your issue though. The bigger Cyrus sites already
> >> > use scripts to create new mailboxes when new users are created. The
> >> > really small sites probably don't mind creating mailboxes by hand.
> >> > The sites with more than 10 but fewer than 100 users probably are not
> >> > satisfied by either solution.
> >> >
> >>
> >> Understood. Hopefully something like that will be implemented that works
> >> with Murder. Perhaps the same code that cyradm uses to create mailboxes?
> >>
> >> We do have quite a few users. I'm pretty sure anyone managing users via
> >> LDAP would prefer to have mailboxes automatically created. I may look
> >> into an OpenLDAP overlay. Failing that, Dovecot.
> >>
> >> Anyway, thanks for explaining this.
> >
> > They're in the git repository now, and will be in Cyrus 2.5 when it's
> > ready for release. They still don't work with murder, but I'm looking
> > into that. Of course, it would need some form of "autocreatebackend"
> > option with murder...
>
> I noticed that everytime auto- patches have been brought into issue,
> murder was argued as a sensible impacted part. i'm curious how many
> admins out of total setups are actually using it. I myself just abuse
> cyrus as a single server for a soho office, so murder it's always
> ignored. I understand it's powerful and there are other setups with
> massive number of servers and users, but I'm just curious if maybe at
> some point would be better to give those with a couple of mailboxes a
> murder-free cyrus fork where you can easily patch things ("global
> sieve rules" dead thread?) without worrying about breaking murder?
Who wants to maintain that? Not me. It's bad enough keeping 2.4 and
master (soon to be 2.5) following a similar path.
That said, I'm happy to merge a patch that does global sieve rules in
a sane way, even if they don't work with murder (presumably - each
backend would have its own global rules and it's the admin's problem
to keep them in sync. That's cool - sieve doesn't really interact with
murder much anyway.
I even don't mind if they don't replicate.
But it had better bloody work with the different alt_namespace and
unixheirarchy settings, and not introduce and security problems. And
someone who actually cares had better write it if they want it.
I don't see how to make it work. I would much prefer to have an
@include syntax for sieve which made it easy for users to import the
rule from a central account or something, so it's manageable and
visible to the user controlling the sieve account.
Or you can do what we do at FastMail which is provide a rule builder
interface and spit our boilerplate into everyone's sieve scripts before
uploading them to the server. That works fine too - and the user can
always see the raw script if they want to understand what's going on,
or override it completely if they'd rather do it themselves and forgo
the automated stuff.
The automated stuff is peppered throughout the script, around their
various rules - doing everything from adjustible spam filtering to
automatically filing messages matching different "personalities" they
have created into separate folders. You can't have that much power
with a dumb global prepend.
But hey - feel free to fork if there's something you feel strongly
enough about and are willing to support.
Bron.
--
Bron Gondwana
brong@xxxxxxxxxxx
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
