Re: Compile 2.2.12 in RHEL4

2007-09-11 Thread Paul Dekkers
Hi, Simon Matter wrote: I have a config.sub and a config.guess that works with 64 architectures. There is some way to put these files in the rpm that I downloaded from invoca.ch ??? Maybe with these files I can use the rpm. Did you try the 2.3.x rpms? They should work fine. I don't

Re: Murder works wonderfully but alarms users

2007-09-11 Thread Dale Ghent
On Sep 10, 2007, at 11:59 AM, Gary Mills wrote: We have a Cyrus murder configuration with one proxy front-end and one storage back-end. I'm very pleased with it. However, users who happen to look at the full headers of their e-mail are often alarmed by the word `murder' that appears in the

Re: Shared folder filtering (probably a thousand times asked)

2007-09-11 Thread Johannes Rußek
Am Montag, den 10.09.2007, 22:11 +0200 schrieb Ulrich Spoerlein: On Mon, 10.09.2007 at 16:01:12 +0200, Johannes Rußek wrote: beloved list, i'm so free to ask this question probably for the 1000st time: how can i manage sieve script for shared folders? i have a few shared folders where

RE: struct_et_list warnings with 2.3.9

2007-09-11 Thread Larry Rosenbaum
See also https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2805 -Original Message- From: [EMAIL PROTECTED] [mailto:info-cyrus- [EMAIL PROTECTED] On Behalf Of Wesley Craig Sent: Friday, September 07, 2007 10:12 PM To: David Newman Cc: info-cyrus@lists.andrew.cmu.edu Subject: Re:

Cyrus replication problems

2007-09-11 Thread Sergey N. Romanov
Hello all, I have 2 servers and try to make replication between them. I have FreeBSD 6.2 and Cyrus IMAPd 2.3.9 compiled from sources. Configuration of master server. imapd.conf : ... sync_machineid: 1 sync_host: xx.xx.xx.xx sync_authname: x sync_password: x sync_log: 1 cyrus.conf:

Re: GSSAPI Murder authentication and The context has expired on long proxyd sessions

2007-09-11 Thread Paul M Fleming
I had the same problems. if you google for this you'll find a discussion regarding how SASL context expires should be handled. Heimdal allows expired contexts to be used after expiration. MIT does not. 1) indefinitely long means the default lifetime of your KDC or the individual keys involved.

Cyrus lagging accepting IMAP connections

2007-09-11 Thread Rick Kunkel
Hello all, I'm new to Cyrus. Historically, I've used Qpopper, Sendmail, and UW IMAP. We recently switched to Cyrus for IMAP. It came highly recommended... We've got this on a darned burly machine, running some very recent version of Debian, with a fast CPU, 4GB RAM, and fast SAS drives.

Re: Cyrus lagging accepting IMAP connections

2007-09-11 Thread Andy Fiddaman
On Tue, 11 Sep 2007, Rick Kunkel wrote: ; # telnet mail 143 ; Trying xxx.xxx.xxx.xxx... ; Connected to mail. ; Escape character is '^]'. ; ; And then it just kinda sits. Sometimes, after 30 seconds or so ; ; * OK mail Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready Generally this kind of

Re: Cyrus lagging accepting IMAP connections

2007-09-11 Thread Scott M. Likens
Rick, This problem is related to Debian using /dev/random instead of /dev/urandom. Short term solution would be to rm /dev/random mknod /dev/random c 1 9 The other solution for you would be to recompile the sources and change the configure to use urandom instead of random... You can search the

Re: Cyrus lagging accepting IMAP connections

2007-09-11 Thread Blake Hudson
Cyrus could lag at this stage if there is a problem reversing its own IP. With the 'listen' argument specified as is, I would think it would be reversing 127.0.0.1 (or possibly the main IP on the box?). Make sure that you have both of these IPs specified in the hosts file. Also make sure that your

Re: Cyrus lagging accepting IMAP connections

2007-09-11 Thread Rick Kunkel
Hm! I did some additional reading after receiving this, and it seems that pursuing the random number generator path is the way to go... A coupla quick questions (that I think are likely going to be answered with it depends answers): 1. Is nuking /dev/random in the way described going to have

Re: Cyrus lagging accepting IMAP connections

2007-09-11 Thread Scott M. Likens
1. Not likely, but not impossible... To Quote a source The /dev/random device hands out high-quality random bits, up to the limit of the random information it has been seeded with. The /dev/urandom device does not have this limitation. It continues to hand out bits of decreasing quality as long