auto create / subscribe folder patches

[mailing list subscriber]

On Thu, Oct 4, 2012 at 1:00 AM, Bron Gondwana <brong at fastmail.fm> wrote:
> 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 at fastmail.fm> 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.

There was this patch in 2006, is it close to requirements?
http://www.irbs.net/internet/info-cyrus/0612/0181.html

Two months later Ken asked the author to upload the patch in a bug,
but no bug I can find in bugzilla:
http://www.irbs.net/internet/info-cyrus/0702/0057.html

If is not compatible with current version, what can we ask the author
to modify about it?

I have bcc'ed this email to original patch author, Florian G Pflug

>
> 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 at fastmail.fm
>