There's no really easy way, but this patch might help. Basically it parses
the last Received: header to set the internal date.
http://cyrus.brong.fastmail.fm/#cyrus-receivedtime-2.3.8.diff
The problem is if you apply it, you then have to reconstruct all your
mailboxes to rebuild the cyrus.index
You can also use
vm.lower_zone_protection=size_in_mb
to protect portions of low memory. This doesn't help with caching issues but
can help prevent the kernel from getting cornered and resorting to oom-killer.
We haven't tested everything in our enviroment at 64bit so we've used lower
zone prot
On Sep 28, 2007, at 5:29 AM, Nikos Gatsis wrote:
> It's the first time that I've install the cyrus-imap on a fedora 7
> server.
> So, I'm very new with cyrus.
> I'd like to set a vacation message for each user and I don't find a
> way.
> Can you help me?
No, and please nobody do. Vacation mes
On Tue, 09 Oct 2007 15:04:32 -0700, Vincent Fox <[EMAIL PROTECTED]> wrote:
> So I want to do LMTP between an MX pool and Cyrus backends.
>
> The common way I read about doing this, is with a shared LMTP
> account from MX pool to backends. So it becomes a postman sort
> of account with the password
> Yesterday I checked my own Cyrus servers to see if I was running out of
> lowmem, and it sure looked like it. Lowmem had only a couple MB free, and
> I had 2GB of free memory that was not being used for cache.
>
> I checked again today and everything seems to be fine - 150MB of lowmem
> free
On Tue, 9 Oct 2007, Andrew Morgan wrote:
> On Sat, 6 Oct 2007, Rob Mueller wrote:
>
>> As it turns out, the memory leaks weren't critical, because the the pages do
>> seem to be reclaimed when needed, though it was annoying not knowing exactly
>> how much memory was really free/used. The biggest p
On Sat, 6 Oct 2007, Rob Mueller wrote:
> As it turns out, the memory leaks weren't critical, because the the pages do
> seem to be reclaimed when needed, though it was annoying not knowing exactly
> how much memory was really free/used. The biggest problem was that with
> cyrus you have millions o
So I want to do LMTP between an MX pool and Cyrus backends.
The common way I read about doing this, is with a shared LMTP
account from MX pool to backends. So it becomes a postman sort
of account with the password in plaintext in various places and of
course transiting the network that way.
Is t
I'll put in my 10cents as it's not really on topic for this mailing list.
When converting from a qmail+courier IMAP solution to Zimbra *ugh* I had
a similar problem in this case Zimbra had a solution.
imapsync --ssl1 --ssl2 --host1 #HOST1# --host2 #HOST2# \
--authuser1 cyrus --password1 #PASSWORD
On Tue, 9 Oct 2007, Guillaume Postaire wrote:
Hi all,
We just have done a migration from a very old Cyrus stand alone
installation to a new one with murder.
During the migration everything went ok and no user complaint, so we
destroy our old mailbox.
Shortly after that one of our user notice
On Tue, 9 Oct 2007, Guillaume Postaire wrote:
> Hi all,
>
> We just have done a migration from a very old Cyrus stand alone
> installation to a new one with murder.
>
> During the migration everything went ok and no user complaint, so we
> destroy our old mailbox.
>
> Shortly after that one of our
Ian G Batten <[EMAIL PROTECTED]> wrote:
>
> On 09 Oct 07, at 1522, Blake Hudson wrote:
>>>
>> Could database type differences (or contention) be an issue here? What
>> database format are each of you using?
>
> Yes. With skiplist (took me several stabs at it to get the
> conversion to work) it ta
On 09 Oct 07, at 1748, Ian G Batten wrote:
>
> On 09 Oct 07, at 1522, Blake Hudson wrote:
>>>
>> Could database type differences (or contention) be an issue here?
>> What
>> database format are each of you using?
>
> Yes. With skiplist (took me several stabs at it to get the
> conversion to wo
On 09 Oct 07, at 1522, Blake Hudson wrote:
>>
> Could database type differences (or contention) be an issue here? What
> database format are each of you using?
Yes. With skiplist (took me several stabs at it to get the
conversion to work) it takes 0.19s. Versus ~250s with BDB. A slight
dif
On 09 Oct 07, at 1522, Blake Hudson wrote:
>>
>> Sorry this doesn't help solve your problem but it proves it should
>> be a lot faster than that.
>>
>> Joseph Brennan
>> Columbia University Information Technology
>>
>>
> Could database type differences (or contention) be an issue here? What
> data
On 09 Oct 07, at 1550, Wesley Craig wrote:
> What's your authentication & authorization infrastructure look like?
sasl into yellow pages.
> Every mailbox has an associated ACL, which must be canonicalized to
> determine whether the user in question gets to see it.
> ctl_mboxlist just lists
I'm trying to setup a murder with 3 machines for testing.
(mupdated, fe, and be all separate machines)
The mupdate master works fine, the backend can do the initial dump/import to
the master (and mupdatetest works on the backend and frontend)
The front end however doesn't seem to be able to aut
What's your authentication & authorization infrastructure look like?
Every mailbox has an associated ACL, which must be canonicalized to
determine whether the user in question gets to see it. ctl_mboxlist
just lists whatever it finds. I've seen Kerberos cause LIST * to
take a long time -
Joseph Brennan wrote:
> --On Tuesday, October 9, 2007 14:19 +0100 Ian G Batten
> <[EMAIL PROTECTED]> wrote:
>
>
>> We have ~35K mailboxes (as reported by ctl_mboxlist -d | wc -l), and
>> the LIST takes upwards of 5 minutes. The imapd spins as much CPU as
>> it can get hold of, too.
>>
>
--On Tuesday, October 9, 2007 14:19 +0100 Ian G Batten
<[EMAIL PROTECTED]> wrote:
> We have ~35K mailboxes (as reported by ctl_mboxlist -d | wc -l), and
> the LIST takes upwards of 5 minutes. The imapd spins as much CPU as
> it can get hold of, too.
We have 1,117,961 mailboxes in a murder.
We have clients which issue LIST "" * when they start up. We think
we need them to do this, because we are making quite heavy use of
shared mailboxes so a mailbox may arrive in a hierarchy other than
INBOX.* to which the user should subscribe.
We have ~35K mailboxes (as reported by ctl_mbo
Looking at the migration script, it's essentially find . -name
cyrus.* -exec mv {} /meta/part/{} \;. That's quite slow, because it
has to stat() all the messages to find the files which are metadata.
I've written an alternative for the migration we're planning for
later this week, which
Hi all,
We just have done a migration from a very old Cyrus stand alone
installation to a new one with murder.
During the migration everything went ok and no user complaint, so we
destroy our old mailbox.
Shortly after that one of our user notice a huge problem with outlook
that we don't repr
23 matches
Mail list logo
