Maybe french would be easier ...not big deal. Let's say FE= frontend,
BE= backend
When you login as admin through cyradm to a FE , you don't use the
proxyd process so you have to log again . You can also from FE, log as
cyrus user like cyradm -u cyrus myBE directly to the chosen one.
How t
Do you really mean to get [EMAIL PROTECTED] to user.test.linux?
Try [EMAIL PROTECTED]
Is the final mail address still with the + sign?
Anyway, main folder test does not need 'anyone p' ACL, only subfolder.
Nothing to do with duplicate delivery in my mind.
Laurent
Michael Loftis a écrit :
Duplic
Hello,
using Debian Sarge with CyrusIMAP MURDER 2.2.8 and MTA Postfix, LMTP
appears slow.
Here are my conf parameters regarding mail delivery :
POSTFIX
--> main.cf
initial_destination_concurrency = 50
mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
lmtp_destination_concurrency_l
On a Debian Sarge with CyrusIMAP MURDER 2.2.8 and MTA Postfix, the
following strange phenomenon appears :
LMTP dialog between frontend and backend slow down, with an increasing
mailq. What happends : few frontend lmtpproxy processes fall in a
CLOSE_WAIT state on the backend(s) lmtp port. Unti
Hello,
Running CyrusIMAP 2.2.8 on Debian Sarge, with a 2 frontends & 3
backends murder, in operational situation. (5000 dayly users, will
climb up to 7 at the end of the year, with an average of 4 mails of
50ko per user/days)
The problem : mupdate chokes in a strange way when frontends
Hi Arnaud
Just think about the "allowusermoves" parameter in imapd.conf
Hope it will help.
Laurent
Mathieu Arnold a écrit :
>+-le 26/05/2005 17:22 +0200, Mathieu Arnold a dit :
>| I don't really understand what or why it's doing that, but it's doing it. If
>| anyone has any idea of why, I'd be
In fact, 100 000 users represent more or less 600 000 folders &
subfolders. The choice of murder is high availability, even if one
backend falls down, only 25% of the users will loose the mail service.
Each server has 2 CPU & 5 GB RAM.
Any idea on optimizing Berkeley DB cache?
Laurent.
Joh
Hello,
running CyrusIMAP 2.2.8 on Debian Sarge, with a murder of 2 frontends &
3 backends, (4 & 4) at the end.
I have to deal with increasing charge of by now 500 users that will grow
up to 100 000.
All mailboxes exist, for a 65Mb mailboxes.db on mupdate
1- Mupdate slows down informing Frontend
Paul Dekkers a écrit :
Hello Laurent,
LaurentG wrote:
In order to manage common users status changes (indicated by the
update of the LDAP directory) I'd need to enumerate all the granted
ACLs my common user owns.
As an admin, I don't have his password, so can't connect as hi
Hello,
In order to manage common users status changes (indicated by the update
of the LDAP directory) I'd need to enumerate all the granted ACLs my
common user owns.
As an admin, I don't have his password, so can't connect as his identity
but need to list all ACLs he owns (except his own mailbo
Thanks for your help, I had the 'p' right on the mailbox but only for a
specific user, not for anyone. By the way, are there any other types of
extentions available? Any doc available about it?
This one is very useful for us anyway.
Thanks again.
Laurent
Ken Murchison a écrit :
Laur
Hi,
On a Cyrus Murder (2.2.8) with Postfix MTA, I'd like to use address
extensions in order to deliver mail directly to an INBOX subfolder with
an address like [EMAIL PROTECTED]
The mail is deliverred to the INBOX, but not to the subfolder.
Does LMTP recognize that kind of addresses?
How to have
Thank you for answering.
*Sieve*
Any preconized client for sieve? Websieve? Any other? (until
Horde3.0/Ingo become stable).
We have used ingo. There were no problems with that.
What version of Horde do you use for Ingo? It seems that there's no
version of Ingo running on top of Horde 2.x.
Am-I w
Hello,
after testing Cyrus Aggregator 2.2.8. I'm about to to deploy it for a
potential 10 users population.
The architecture I plan is the following :
2 LVS with heartbeat in front
3 frontends with 5Gb of RAM (authenticating against LDAP)
3 backends with 500 Gb each for mailboxes storage and
14 matches
Mail list logo