Hi Ellie,
On 2019-10-16 13:53, ellie timoney wrote:
> On Mon, Oct 14, 2019, at 10:29 AM, ellie timoney wrote:
>
> I think this is fixed now, on both master and 3.0 branches. Testing
> and feedback appreciated, of course!
This is looking a lot better.
$ imtest -a cyrus localhost
[...]
BBB xback
On Mon, Oct 14, 2019, at 10:29 AM, ellie timoney wrote:
> I've created a github issue
> (https://github.com/cyrusimap/cyrus-imapd/issues/2893), and am about to make
> a test case to reproduce the problem, so I can get on with fixing it. :)
I think this is fixed now, on both master and 3.0 branch
Am 14.10.19 um 03:00 schrieb Deborah Pickett:
> So how are people currently backing up shared folders, if they’re not
> using Cyrus backupd?
FWIW, we just take snapshots of the file systems and backup those. Mail
files aren't databases, so I don't think you have to worry about
corrupted files as m
ralian owned and operated for over 30 years
From: ellie timoney
Sent: Monday, 14 October 2019 10:29
To: Deborah Pickett ; info-cyrus@lists.andrew.cmu.edu
Subject: Re: XBACKUP and backupd not backing up public folders (3.0.8)
Hi Deborah,
Thanks, that's all useful! Looks like in
Hi Deborah,
Thanks, that's all useful! Looks like in both places it's struggling with lack
of a userid, which makes some sense because it's a shared mailbox, and shared
mailboxes don't have userids.
I guess this means that in its current state, the backup system can't handle
shared mailboxes.
Hi Ellie,
Thanks for helping me look at this.
On 2019-10-09 16:17, ellie timoney wrote:
> Does the same problem occur if you use sync_client (on the master server, as
> the cyrus user) to replicate the shared mailbox to the backup server (rather
> than using XBACKUP over IMAP)? Something like
;m deploying Cyrus 3.0.8 (Debian buster 3.0.8-6) at $dayjob to replace
> an Exchange server. That part is going well, but I'm hitting a hurdle
> pulling backups of public folders (shared mailboxes, calendars and
> address books, anything outside the user/ hierarchy) using XBACKUP and
&
Hi everyone,
I'm deploying Cyrus 3.0.8 (Debian buster 3.0.8-6) at $dayjob to replace
an Exchange server. That part is going well, but I'm hitting a hurdle
pulling backups of public folders (shared mailboxes, calendars and
address books, anything outside the user/ hierarchy) using X
ation held for the shared (public)
folders? It doesn't seem to be under /var/imap/user.
2) Once I find it, how can I migrate it across from the 2.2 server to
the 2.4 server?
Many thanks,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc
Hi,
I'm looking for a way to post info using the cyradmin utility for only the
public folders.
For example to show annotations of all user accounts:
> info user/*
What I want to do now is to query for all none users ( i.e. all public
folders), for example:
> info !user/*
Is
It does help, it was all I needed.
Thanks.
D.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Hannessen
Sent: Friday, December 10, 2004 3:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Public folders
what you are looking for seems to be shared folders
e running cyrus v2.1.7, Postfix v2.1.5, SA
> and gld.
>
> The system is up and running for 6 months without any problems.
>
> I was now asked to create several public folders on this system, usable
> by all users.
>
> Is there a good how-to on how to get this done?
>
> TIA
&
Hello list,
I have a Debian Sarge machine running cyrus v2.1.7, Postfix v2.1.5, SA
and gld.
The system is up and running for 6 months without any problems.
I was now asked to create several public folders on this system, usable
by all users.
Is there a good how-to on how to get this done?
TIA
> Quoting Simon Matter <[EMAIL PROTECTED]>:
>
>> > Anyways, I've got the group added to LDAP, and 'id user' is showing
>> that
>> > getgrent(3) sees the 'straycats' group. However, setting the
>> > 'group:straycats'
>>
>> How is your saslauthd configured?
>
> I'm using Fedora Raw Hide, so in /etc/
Quoting Simon Matter <[EMAIL PROTECTED]>:
> > Anyways, I've got the group added to LDAP, and 'id user' is showing that
> > getgrent(3) sees the 'straycats' group. However, setting the
> > 'group:straycats'
>
> How is your saslauthd configured?
I'm using Fedora Raw Hide, so in /etc/sysconfig/sas
> Howdy, again,
>
> Another problem, another email. This problem I've yet to solve.
>
> I've got series of mailboxes (straycat.*) and I want to use the group:
> mechanism
> to set the ACLs for these mailboxes, as this seems the most elegant
> solution.
> I thought to myself, "I'll just add all the
Howdy, again,
Another problem, another email. This problem I've yet to solve.
I've got series of mailboxes (straycat.*) and I want to use the group: mechanism
to set the ACLs for these mailboxes, as this seems the most elegant solution.
I thought to myself, "I'll just add all the users to a POS
Here is the 21.K patch.
Apologies if this makes for an unacceptably large email.
- It adds a new command "folder" which takes a folder as a parameter to
"timsieved" which allows a script to be associated with any folder or
heirarchy of folders in the imap store.
- It alters lmtpd to pick the ap
On Sat, 2001-11-10 at 00:36, Nick Sayer wrote:
>
> > The big problem is that you can only have one script for the entire set
> > of public folders.
> >
>
> Unless you create multiple such users.
>
>
>
I'm sure that will work... but I think a mor
I think trying to patch in little solutions to how sieve currently works
are going to meet with problems that the current model wasn't designed with
this kind of broad functionality in mind. Going to a slightly different
model would not only solve this problem, but others as well.
Here's what
I *was* referring to the action "redirect" in sieve... for some reason I
thought it was an extension that hadn't been implemented in cyrus
But sure enough it exists in CVS and 2.0.16. Strange. I must have made a
mistake somewhere in one of my scripts...
This is what I got after trying to use
That was how my inital implementation worked. In this case the pseudo
user was "anyone".
It is working quite nicely for me.
The big problem is that you can only have one script for the entire set
of public folders.
On Fri, 2001-11-09 at 17:35, Nick Sayer wrote:
> It seems to
ill
ns> be run. That sieve script can have nothing but fileinto directives to
ns> populate the public folders. This pseudo-user does not even have to have an
ns> INBOX, I don't think. Or if it does, then it will be perpetually empty if
ns> your sieve script is written correctly. :
It seems to me that this could be far more easily done by creating a pseudo-
user. Have this user be the target of the alias and his sieve script will
be run. That sieve script can have nothing but fileinto directives to
populate the public folders. This pseudo-user does not even have to have an
> On 09 Nov 2001 16:48:43 +,
> Ian Castle <[EMAIL PROTECTED]> (ic) writes:
ic> ... An alternative approach might be to implement the "redirect" feature
ic> in sieve. So that 'fileinto "some.folder"' wouldn't do any extra
It's already there. See RFC3028:
4.3. Action redirect
Ian Castle wrote:
>
> On Fri, 2001-11-09 at 14:52, Dave McCracken wrote:
> >
> > I have a question, though. If a sieve script does a 'fileinto' to redirect
> > mail to another folder, does the sieve script for that folder get run?
> > Intuitively I think it should, but what are the implication
On Fri, 2001-11-09 at 14:52, Dave McCracken wrote:
>
> I have a question, though. If a sieve script does a 'fileinto' to redirect
> mail to another folder, does the sieve script for that folder get run?
> Intuitively I think it should, but what are the implications?
Interesting. That would prob
ted in this approach - or some modification of it
(basically something which delivers filtering on public folders) I would
far rather use the common code base rather than my own private patch, so
would be willing to go a bit further...
So... here it is (lots of cvs diff -u )...
[hang on! is it OK to
> On Fri, 9 Nov 2001 08:59:34 -0500,
> Lawrence Greenfield <[EMAIL PROTECTED]> (lg) writes:
lg> If we're going to worry about Sieve performance, we really should look
lg> into compiling scripts to a byte-code. Currently we run lex/yacc on a
lg> script on _every delivery_. This is pretty
> On Fri, 9 Nov 2001 08:10:35 -,
> Ian Castle <[EMAIL PROTECTED]> (ic) writes:
ic> Well, the mechanism/interface is there. Allow "activate" to apply to more
ic> than one script.
ic> One way would be to have a subdirectory called "default" with symlinks to
ic> all the active scripts i
--On Friday, November 09, 2001 08:10:35 + Ian Castle
<[EMAIL PROTECTED]> wrote:
> So rather than thinking that "this script applies to this user" I am
> suggesting that we think "this script applies to this folder". Obviously,
> if the folder is "user.fred" then the statements are synonymous
From: Amos Gouaux <[EMAIL PROTECTED]>
Date: Fri, 09 Nov 2001 00:15:07 -0600
[...]
What about all the stats looking for the script? Could that be a
problem? If so, could a db be used as a Sieve script index, like
the mailboxes.db?
If we're going to worry about Sieve performance,
On Fri, 2001-11-09 at 06:15, Amos Gouaux wrote:
> What about all the stats looking for the script? Could that be a
> problem? If so, could a db be used as a Sieve script index, like
> the mailboxes.db?
>
That would be a possible optimisation. Currently, the is one fopen call
for every deliver
> From: Lawrence Greenfield [mailto:[EMAIL PROTECTED]]
>
> I think that you addressed my concerns in your second proposal. I'm
> not sure I love the idea of the "folder" command in timsieved, but
> I'll have to contemplate.
>
> I think there's also a question about whether at most one sieve scri
Backwards compatibility is preserved
ic> - You get some nice cool features - sieving on public folders, having
ic> different scripts for different folders - including your own sub
ic> folders, different people can maintain different folders
ic> - Shouldn't have any particular perfor
From: Ian Castle <[EMAIL PROTECTED]>
Date: 08 Nov 2001 06:44:20 +
On Wed, 2001-11-07 at 22:22, Lawrence Greenfield wrote:
> The other thing to consider is how to keep the Cyrus black-box
> approach. Non-administrators should be able to modify these Sieve
> scripts and name
This follows on from my previous email, where I presented a method of
enabling sieving on mail delivered directly to shared/public folders.
While that does all the I need it to do, my implementation only allowed
a single active script for all public folders. This is a serious
limitation if you
On Thu, 2001-11-08 at 06:44, Ian Castle wrote:
>
> And I have a question - why is the existing name space magic cluttered
> up with the hash on the user name? Not saying it is unneeded - but if it
> is needed, then why isn't a similar hash needed in the folder directory?
>
Sorry, I was being ig
a particular
folder"? At the moment I am under the impression that public folders are
created by someone using "cyradm" who creates the folder and then grants
rights on that folder to other users.
At the moment I am thinking that only the user of cyradm (i.e."admins:"
in
> On Wed, 7 Nov 2001 17:22:08 -0500,
> Lawrence Greenfield <[EMAIL PROTECTED]> (lg) writes:
lg> The other thing to consider is how to keep the Cyrus black-box
lg> approach. Non-administrators should be able to modify these Sieve
lg> scripts and name them appropriately.
lg> Magic directo
The other thing to consider is how to keep the Cyrus black-box
approach. Non-administrators should be able to modify these Sieve
scripts and name them appropriately.
Magic directories just don't cut it.
Larry
> On Wed, 7 Nov 2001 21:12:48 -,
> Ian Castle <[EMAIL PROTECTED]> (ic) writes:
ic> Oh dear. I can see a whole new imap function coming on - ". SIEVE folder
ic> script"...
Actually, in one of my more perverse moments I actually wondered
about storing the sieve scripts in the same dire
> So maybe for a post to "[EMAIL PROTECTED]",
> the script would be in /var/lib/sieve/system/public/interestingmessages/ ?
> Or would this be tooo bizarre?
>
> I'd love to have the ability of running Sieve for some of our shared
> folders, but must admit to being a tad concerned about running *al
temscripts" should be set to a directory accessible by the
deliver process - but not accessible by ordinary users! Deliver will
then look for a sieve script in this directory. If one exists then it
will be used to filter the email sent to the public folders. The script
should be sent up in the
Hurray! I've now got sieving on my public folders... It was a little bit
trickier than I thought - but not too bad. I want to test things a bit
more thoroughly and think about the issues a bit first...
Basically, I using a 'security context' of "anyone" for the filteri
Date: Mon, 05 Nov 2001 11:02:59 -0500
From: Ken Murchison <[EMAIL PROTECTED]>
I don't really remember where we left off. I *think* that Ian's idea is
what we were talking about -- checking sieveusehomedir==false and if
postuser!="" using postuser as the owner of the script.
I thi
On Mon, 2001-11-05 at 16:02, Ken Murchison wrote:
>
>
>
> I don't really remember where we left off. I *think* that Ian's idea is
> what we were talking about -- checking sieveusehomedir==false and if
> postuser!="" using postuser as the owner of the script.
>
Or maybe having a "sievesharedf
talking about -- checking sieveusehomedir==false and if
> km> postuser!="" using postuser as the owner of the script.
>
> When again is postuser==""?
It's the default value unless specified otherwise in imapd.conf(5).
It's whatever the admin decides to use
> On Mon, 05 Nov 2001 11:02:59 -0500,
> Ken Murchison <[EMAIL PROTECTED]> (km) writes:
km> I don't really remember where we left off. I *think* that Ian's idea is
km> what we were talking about -- checking sieveusehomedir==false and if
km> postuser!="" using postuser as the owner of the
Amos Gouaux wrote:
>
> >>>>> On 05 Nov 2001 14:39:44 +,
> >>>>> Ian Castle <[EMAIL PROTECTED]> (ic) writes:
>
> ic> I have quite a large number of shared/public folders to which mail is
> ic> sent/posted directly using the [EMA
>>>>> On 05 Nov 2001 14:39:44 +,
>>>>> Ian Castle <[EMAIL PROTECTED]> (ic) writes:
ic> I have quite a large number of shared/public folders to which mail is
ic> sent/posted directly using the [EMAIL PROTECTED] convention.
ic> I want to sieve m
I have quite a large number of shared/public folders to which mail is
sent/posted directly using the [EMAIL PROTECTED] convention.
I want to sieve mail sent to these folders (to remove spam and other
nasties).
Currently (2.0.16 and CVS HEAD) only mail sent to a user's folders is
sieved.
52 matches
Mail list logo
