On 31 Oct 2007, at 22:42, Rich Wales wrote:
> Can you (or anyone else) suggest anything I can do in the meantime
> (while I'm still running 2.3.9) to ensure that a sync_client stays
> running on my master server, or to start a new one as needed if it
> dies?
It usually dies for a reason, i.e., som
On 03 Nov 2007, at 23:20, Rich Wales wrote:
> Wesley Craig wrote:
>> It usually dies for a reason, i.e., some discrepancy that either
>> sync_client or sync_server couldn't handle. The typical way to
>> handle it is to contact someone.
>
> What sort of debugg
On 04 Nov 2007, at 13:11, Rich Wales wrote:
> Where would I find this log info? As I said earlier, the only info
> I've
> found so far are the "Error in do_sync(): bailing out!" notices in the
> /var/log/messages file. Are there some other log files saved
> somewhere
> else? I do have "-l" a
On 04 Nov 2007, at 14:27, Rich Wales wrote:
> No, sorry, as best I can tell, there isn't anything non-routine in any
> of the log files on my replica server.
> Do I need to specify any command-line flags to sync_server?
No, sync_server doesn't take much in the way of command line
options. If th
If you're running with -r -l (-v is for interactive use -- it causes
printf output), you should be getting messages like:
APPEND user.marie
in syslog at level INFO. If you're not seeing those, then you have
syslog configured to filter them. See the man page for syslog.conf.
:wes
O
The log files are pretty obvious in what they say, e.g., they just
list mailboxes or users to check. So I suspect they would reveal to
you which mailboxes are problematic. I sort of assume that you're
running sync_client with -l, otherwise it doesn't log much. If it's
run with -l, it sho
On 04 Nov 2007, at 22:57, Rich Wales wrote:
> Should I be looking for similar syslog messages on my replica server
> too (and checking syslog.conf on that system if necessary)?
No, not similar. But most sync_server errors that will cause
sync_client to bail out ought to cause sync_server to giv
On 14 Nov 2007, at 23:15, Vincent Fox wrote:
> We have all Cyrus lumped in one ZFS pool, with separate filesystems
> for
> imap, mail, sieve, etc. However, I do have an unused disk in each
> array
> such that I could setup a simple ZFS mirror pair for /var/cyrus/
> imap so
> that the database
On 15 Nov 2007, at 18:25, Rob Mueller wrote:
>> About 30% of all I/O is to mailboxes.db, most of which is read. I
>> haven't personally deployed a split-meta configuration, but I
>> understand the meta files are similarly heavy I/O concentrators.
>
> That sounds odd.
Yeah, it's not right. I was
On 16 Nov 2007, at 15:53, Dan White wrote:
> Nov 16 13:44:57 neo cyrus/imap[6171]: decoding error: generic
> failure; SASL(-1): generic failure: , closing connection
A fuller version of this error is probably recorded in your auth log.
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyru
If I recall correctly, this is a bad interaction/bug between Cyrus
IMAPd and Cyrus SASL. I see you're running IMAP 2.3.10. What
version of SASL?
:wes
On 17 Nov 2007, at 10:27, Dan White wrote:
> Nov 17 09:25:02 neo cyrus/imap[11281]: encoded packet size too big
> (4156 > 4096)
Cyrus
On 19 Nov 2007, at 12:57, Dan White wrote:
> Regarding the call to kick_mupdate and the attempt to open the file
> socket, could I be missing an entry in my cyrus.conf file?
When I saw your note included:
> Nov 17 09:25:02 neo cyrus/imap[11281]: decoding error: generic
> failure; SASL(-1): ge
On 19 Nov 2007, at 16:15, Dan White wrote:
> kaled (mupdate master and frontend):
> none, other than an mupdate_admins entry
If it's an mupdate master & frontend, you probably want the
mupdate_server configured, and mupdate_config: standard.
> Is xfermailbox valid in a standard murder?
Yes, yo
On 22 Nov 2007, at 21:01, Diego Woitasen wrote:
> I tried with that, but doesn't work. I delivered a message in both
> serves and nothing. Again, the mailbox was replicated when I restart
> Cyrus.
I haven't run "mupdate_config: replicated" myself, but I assume you
need to run mupdate on the back
On 23 Nov 2007, at 07:15, Diego Woitasen wrote:
> I have running mupdate in all servers. In my setup, there is no
> backends. Only two servers, master and slave.
The "master" cyrus.conf doesn't have these lines:
mupdate_server: rh-cluster1
mupdate_username: cyrus
mupdate_a
On 24 Nov 2007, at 11:05, Diego Woitasen wrote:
> I didn't put these lines because rh-cluster1 is the master server. I
> have only two machines, rh-cluster1 (master) and rh-cluster2 (slave).
> Is really necessary that rh-cluster1 mupdate_server parameter point to
> itself?
>
> I'll try that on Mon
On 26 Nov 2007, at 05:49, Lauro Costa G. Borges wrote:
> the cyrus admin dn bind succeeds but saslauthd complains about
> having two DN's matching the UID attribute (remember I have copies of
> the user entries for the moodle service, since each moodle
> installation has/can see -only- the users
On 26 Nov 2007, at 20:31, Diego Woitasen wrote:
> It's working now. I will publish the results of my testing in a few
> days. I can't find to much information about this setup.
Yours is the first site that I've encountered with that particular
setup. I like it :) Especially for a small site.
The internal Cyrus "mailbox ID" ought to be unique, but it's not. On
the sub folder, remove the cyrus.header file and reconstruct. This
will assign a new, unique mailbox ID. Any ideal how they ended up
with the same IDs?
:wes
On 04 Dec 2007, at 20:09, Gabor Gombas wrote:
> I'm having pro
UMich continues to run 2.2.x frontends & mupdate master with 2.3.x
backends. We did successfully xfer all of our user data from 2.2.x
backends to 2.3.x backends, after some small adjustments to the code
(contributed).
:wes
On 10 Dec 2007, at 20:55, Andrew Morgan wrote:
> Has anyone else do
The stock unexpunge prints the searchable data available in the
cache. The attached patch (to 2.3.8, I haven't checked to see if it
ports forward cleanly to 2.3.11) adds a -H flag to indicate that the
"human readable" fiends should be read from the cached envelop and
printed. If you open
Which patch are you interested in?
:wes
ps On the face of it, setting the lmtp service to run "proxyd"
doesn't sound right to me.
On 27 Feb 2008, at 02:51, Khalid Mehmood wrote:
> I have been trying to setup lmtp.conf on a frontend to
> deliver mail via lmtp proxyd without any success. I
> hav
On 17 Mar 2008, at 11:25, J.J. Day wrote:
> #allowplaintext: yes
This is likely to be your problem.
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
First failure:
On 17 Mar 2008, at 17:18, J.J. Day wrote:
> C: A01 AUTHENTICATE PLAIN
> S: A01 NO no mechanism available
> Mar 17 14:34:11 dc-mail imaps[5423]: badlogin: dc-mail.training.int
> [192.168.251.3] PLAIN [SASL(-4): no mechanism available: Couldn't
> find mech PLAIN]
PLAIN authN was
On 18 Mar 2008, at 16:11, Jorey Bump wrote:
> Everything
> seems to be working fine, with the exception of STARTTLS
> connections to
> port 143 from *remote* machines.
>
> C: S01 STARTTLS
> S: S01 OK Begin TLS negotiation now
> verify error:num=19:self signed certificate in certificate chain
Who
On 18 Mar 2008, at 17:55, Jorey Bump wrote:
> http://lists.andrew.cmu.edu/pipermail/info-cyrus/2008-January/
> 028210.html
Do you use client certificates? Because the message you're quoting
is about someone who does:
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2008-January/
0281
You know, this *almost* sounds like you've configure Thunderbird to
do TLS on the imaps port.
:wes
On 19 Mar 2008, at 01:09, Jorey Bump wrote:
> Jorey Bump wrote, at 03/18/2008 09:18 PM:
>
>> I'm focusing now on the open_ssl error "wrong version number" and
>> just
>> realized the current sys
On 20 Mar 2008, at 13:07, Jorey Bump wrote:
> Andrew Morgan wrote, at 03/20/2008 12:20 PM:
>> Maybe the format of your CA bundle file is not what openssl
>> expects? Do
>> you get valid output when you run:
>>
>> openssl x509 -in /etc/ssl/certs/ -text
> I'm not sure. There are no errors, but
On 31 Mar 2008, at 11:52, Ken Murchison wrote:
> How can
> lmtpd be intelligent enough to know that the forwarded address will
> cause the message to come back?
There's no way to do that, but one could insert a header, e.g, "X-
Sieve-Redirect". Maybe the value would be a random string which was
On 02 Apr 2008, at 09:00, Joseph Brennan wrote:
> The crucial difference is that if one writes a bad procmail recipe,
> the message loops round and round until one of the MTAs considers
> the hop count exceeded and bounces it to sender, but if one writes
> a bad sieve rule, the message _is silently
What's the ticket number/URL?
:wes
On 12 Apr 2008, at 09:11, Goetz Babin-Ebell wrote:
> Looking in the last source I have here (2.3.8), I'm definitively not
> happy about the code that generates that message:
> * If you don't do SSL client authentication, this message
> ~ is only confusing noise
From the article:
> I’ve *finally* discovered why my IMAP server no longer likes my
> self-signed certificates. The certificates are just fine. Cyrus is
> just fine. It’s OpenSSL that’s the problem - Bug 1513 to be exact.
> Cyrus calls SSL_CTX_use_certificate_chain_file() to read in the
>
On 13 Apr 2008, at 17:19, Goetz Babin-Ebell wrote:
> Cyrus barfing on no CA data set with no client authentication is a
> bug.
Hard not to agree. :) Submit a patch, please.
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archive
Is this an iPhone? Might look at this:
http://www.dannyfoo.com/blog/apple-iphone/malaysia-iphone-x-apop-
authentication-support-and-secure-connection-failed/
Also, the way the APOP challenge is written out has changed, so I
might look there.
:wes
On 30 Apr 2008, at 11:34, Jorey Bump
On 06 May 2008, at 08:35, Klaus Steinberger wrote:
> ldap_group_base: ou=Gruppen,o=physik
> ldap_group_filter: (member=%D)
The above is fine.
> ldap_member_method: attribute
> ldap_member_attribute: groupMemberShip
> ldap_member_base: ou=Gruppen,o=physik
The above should be:
ldap_member_method:
On 06 May 2008, at 15:51, Klaus Steinberger wrote:
> I'm using cyrus-imapd-2.3.7-1.1.el5 (Scientific Linux).
That's pretty old, there have been a lot of fixes to the pt & ldap
code in the intervening 5 or so releases.
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: htt
Given that he's got two machines, I might suggest mupdate_config:
replicated and definitely have mailboxes.db on local disk.
:wes
On 14 May 2008, at 06:30, Bron Gondwana wrote:
> Depending on your requirements, it may make sense to place your
> mailboxes.db on local
> disk (it's pretty small)
--On Donnerstag, 29. Mai 2008 11:28 +0200 Martin Ziegler
<[EMAIL PROTECTED]> wrote:
> When i try to log in to IMSPd saslauthd returns a successfull
> authentication but IMSPd says, that there is no such user on this
> server.
I presume you're also getting a syslog from imspd like this:
On 01 Jun 2008, at 14:08, Martin Ziegler wrote:
> There is no other syslog message than the ones i posted in my
> initial email (SASLAUTHd which says that the authentication was
> successfull and IMSP which says "user does not have an account on
> this server).
Perhaps your syslog isn't conf
b, you have to either
use /var/imsp or edit the PREFIX definition in syncdb.c.
:wes
> --On Sonntag, 1. Juni 2008 14:38 -0400 Wesley Craig <[EMAIL PROTECTED]>
> wrote:
>> So you modified PREFIX in syncdb.c?
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ:
On 04 Jun 2008, at 06:49, [EMAIL PROTECTED] wrote:
> /usr/sbin/ctl_mboxlist -u < /tmp/mailboxes.dump
Before you reconstruct, does ctl_mboxlist -d on the new server list
all of the mailboxes that were on the old server?
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: htt
On 04 Jun 2008, at 16:43, Keith Edmunds wrote:
> On Wed, 4 Jun 2008 13:56:59 -0400, [EMAIL PROTECTED] said:
>> Before you reconstruct, does ctl_mboxlist -d on the new server list
>> all of the mailboxes that were on the old server?
>
> Yes, it does.
Are they there after you reconstruct?
> (Not su
On 05 Jun 2008, at 03:07, Keith Edmunds wrote:
> On Wed, 4 Jun 2008 20:56:50 -0400, [EMAIL PROTECTED] said:
>> The question is which tool (if any) is removing them.
>
> I don't think any tool is removing them. Even before reconstructing, a
> "lm" doesn't list all the mailboxes.
So the data is stil
On 09 Jun 2008, at 13:06, Stephen Liu wrote:
> S: L01 NO Login failed: generic failure
These generic login failures typically produce a log message in your
security logs.
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/In
On 13 Jun 2008, at 06:58, Simon Matter wrote:
> Did anybody look at this in the mean time?
We're discussing option in on the devel list. Please feel free to
chime in!
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info:
On 16 Jun 2008, at 19:07, Andrew Morgan wrote:
> Does the mupdate process in a Cyrus murder actually use TLS?
Almost certainly. mupdate_connect devolves to backend_connect, the
same routine that cyrus routinely uses throughout for proxy
connections. Also, the mupdate server pays attention to
On 07 Jul 2008, at 09:31, Gary Mills wrote:
> I'm seeing errors like this regularly in our messages log:
>
> Jul 4 11:43:37 castor imap[16398]: [ID 514311 local6.error]
> DBERROR: skiplist recovery: 058C should be INORDER
> Jul 4 11:43:37 castor imap[16398]: [ID 729713 local6.error]
> DBE
On 14 Jul 2008, at 07:54, Marten Lehmann wrote:
> I don't want to mark old messages as deleted and expunge them, because
> then maybe I'm expunging messages, that haven't been flagged as
> deleted
> by me but the owner of the mailbox and aren't ment to be expunged at
> this moment.
ipurge is the
On 15 Jul 2008, at 08:16, ram wrote:
> I use ipurge now , but ipurge seems to have some bug. If I dont use
> "-f"
> the mailbox under sub domains using realm is not matched
ipurge just uses findall. The -f flag allows ipurge to examine user
mailboxes. Bug fixes are (of course) welcome.
:wes
On 23 Jul 2008, at 13:44, Paul Engle wrote:
> You do have to do the ctl_mboxlist -d to get the specific timecode,
> though.
You can also use, e.g.:
cyradm> lm DELETED.user.wc2263.*
DELETED.user.wc2263.EG.487BF83F (\HasNoChildren)
DELETED.user.wc2263.XXX.487BF841 (\HasNoC
On 24 Jul 2008, at 04:00, Sebastian Hagedorn wrote:
> I'm note really a dc fiend, so I'm not 100% sure what you are doing
> there, but doesn't this work just as well?
>
> % perl -e 'print scalar localtime(hex "487BF841")."\n"'
> Tue Jul 15 03:07:13 2008
Absolutely it does. My only concern is th
If you're getting a message like this:
expiring messages in ... older than ... days
that's the result of the /vendor/cmu/cyrus-imapd/expire annotation
being set. It's controlled with the -E flag. A spam dump is a
pretty typical place to find an annotation like that.
:wes
On 27 Jul
On 27 Jul 2008, at 16:17, Per olof Ljungmark wrote:
> Wesley Craig wrote:
>> If you're getting a message like this:
>> expiring messages in ... older than ... days
>> that's the result of the /vendor/cmu/cyrus-imapd/expire annotation
>> being set. It&#
On 27 Jul 2008, at 17:36, Per olof Ljungmark wrote:
> Here's the entire log output from one of the events.
The message:
expiring messages in ... older than ... days
is only given on stderr and when verbose is given.
> cyr_expire[6935]: Expunged 64610 messages from
> user.spamdump.arch
On 28 Jul 2008, at 08:14, UnlimitedMail.net - Carles Xavier Munyoz
Baldó wrote:
> Note that Cyrus Murder is still relatively young in the grand
> scheme of
> things, and if you choose to deploy you are doing so at your
> own risk.
That text is from 2002. Yes, Cyrus Murder is younger
On 29 Jul 2008, at 11:09, Per olof Ljungmark wrote:
> Thanks for the info. I can't help wonder if this was a firm design
> decision? From a user perspective it should be easier if this followed
> the synchronization I believe.
No, I don't think it's firm. There's been some discussion of how
del
You can add it to the bugzilla here:
https://bugzilla.andrew.cmu.edu/
Thanks!
:wes
On 30 Jul 2008, at 05:57, Dmitriy Kirhlarov wrote:
> We find a problem -- when ptloader build with ldap support by gcc4 on
> amd64 platform it's doesn't work.
>
> After investigation ptloader core with gd
The user's subscription DB, on either the master or the replica.
:wes
On 10 Aug 2008, at 10:56, Per olof Ljungmark wrote:
> Where does sync_client fetch the mailbox info from?
>
> DELSUB username INBOX^INBOX^Drafts
> DELSUB username INBOX^INBOX^Sent
> DELSUB username INBOX^INBOX^Trash
> DELSUB us
On 11 Aug 2008, at 08:57, Mathieu Kretchner wrote:
>> what is in use now ?
> Cyrus
>
> Why should I choose Cyrus instead of dovecot ?
Are you having a problem with Cyrus? Migrating from any server to
any other is likely to be challenging (to say the least), so you
ought to have a pretty compe
On 12 Aug 2008, at 06:53, Mathieu Kretchner wrote:
> At present, we have a lot of I/O, we wonder if the last version of
> cyrus is improved for this point ?
Recent versions have several features designed to allow very large
scaling of I/O. In addition to optimization to the old architecture,
On 13 Aug 2008, at 10:31, kbajwa wrote:
> I think you are missing a point which is most important, i.e., what
> type of
> support Cyrus vs Dovecot offers. In my experience:
>
> Cyrus = 0
> Dovecot= 100
As someone who answers many help requests for cyrus (and I'm very far
from the on
cyr_expire -D and -X deal with delayed delete & expunge,
respectively. Neither will address message that the MUA hasn't
already deleted (in the case of folders) or expunged (in the case of
messages).
The tool that is closest to the desired functionality is ipurge. In
order for ipurge to
I've seen this before with Thunderbird. As I recall, Thunderbird
requests a lengthy operation but times out (or fills a buffer?)
before getting a result back. It then tries the operation again,
until the mailbox is woefully full.
To clean up, we typically calculate checksums on the files a
On 29 Aug 2008, at 10:13, Kenneth Marshall wrote:
> We tried many IDLE options here, but so many clients had poor IDLE
> support that we ended up turning it off. The number of help desk
> calls such as the one above dropped essentially to zero after the
> change.
I wonder if you have some practica
On 01 Sep 2008, at 14:50, Denis BUCHER wrote:
> What should I do next to solve my problem ?
There are actually a couple of places cyrus might give the fatal
error "word too long". The prot routines should be recording the
interactions before passing the data up to the imap layer where the
p
I haven't tried it, but it's certainly meant to. The name of the
user should be in the CN attribute of the subject certificate.
:wes
On 09 Sep 2008, at 08:58, Johannes Rußek wrote:
> so cyrus does support ssl client certificates (otherwise there
> wouldn't
> be errors such as "TLS server eng
Yes, the code lacks at least the ability to specify aspects of the
schema. I also noticed that it's using obsolete APIs, tho I'm not
sure that's actually a problem. I'd be happy to work with you to get
an acceptable patch committed for this code path.
:wes
On 10 Sep 2008, at 07:48, Johann
I'd suggest waiting for 2.3.13, which is likely to appear soon. It
will have numerous significant bug fixes. In fact, if you're
planning to do any testing, contributing to the testing of 2.3.13
release candidates would be very helpful.
:wes
On 16 Sep 2008, at 08:17, Ciprian Marius Vizitiu
On 17 Sep 2008, at 11:40, Jens Hoffrichter wrote:
> Why does cyrus need it's own
> structure for the mailboxes, which is similar, but not wholly
> compatible, to maildir. Maildir and cyrus both suffer from the same
> disadvantages (huge needs in terms of inodes etc.), yet I see no
> distinctive adv
On 06 Apr 2008, at 11:28, Alain Spineux wrote:
> I opened a new bug on bugzilla.
>
> https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2987
I think you mean:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3053
I've reviewed the patch. Please address my comments to get it
committed. Th
On 05 Aug 2008, at 14:24, James M McNutt wrote:
> not sure why we get "Unknown code imap 54"
Your compile is referring to com_err from some other package, which
is apparently not compatible with cyrus-imapd. Probably better if
you just used the one that comes with cyrus-imapd.
:wes
Cyru
On 13 Aug 2008, at 06:22, UnlimitedMail.net - Carles Xavier Munyoz
Baldó wrote:
> (1) One of the problems I have is that the mupdate master process
> generates
> too many logs lines like these:
> [...]
> Worker thread finished, for a total of 5 (5 spare)
> New worker thread started, for a total
On 19 Sep 2008, at 08:55, James M McNutt wrote:
> how do you tell it to only use the com_err from cyrus-imapd?
Try: ./configure --whatever-else-you-might-say --with-com_err=yes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info
On 25 Sep 2008, at 10:04, Per olof Ljungmark wrote:
> No idea why, comments anyone? A limitation of some sort when
> expunging a
> lot of messages?
>
> cyr_expire [96599]: Expunged 3005 messages from user.myuser.Trash
> cyr_expire[96599]: expunged 4907 out of 109443 messages from 143
> mailboxe
I'd probably use imtest to connect, get the PID of the server process
that I'm connected to, and then attach to that process with ktrace
(or whatever) with timestamps enabled. Then I'd select the mailbox
-- this is assuming that mutt is only issuing a select when it says
"Selecting INBOX".
On 30 Sep 2008, at 09:31, Nic Bernstein wrote:
> I have seen much discussion of the "no mechanism available" issue, but
> the answer typically is "install certificates," or "Use START_TLS" or
> the like. Well, I have certificates, I have START_TLS, and I still
> have
> this problem. How do I ge
On 30 Sep 2008, at 15:36, Nic Bernstein wrote:
> So please forgive me if I am missing something, but I don't seem to
> be any closer.
Did you stop & restart the front- and backends? The only other
suggestion I have is strace imapd. Since the process breaks before
authentication, you won't
On 30 Sep 2008, at 16:12, Nic Bernstein wrote:
> Strace on which system, frontend or backend? I'm guessing
> frontend, but...
It will be a lot easier on the front, yes. Use imtest, authenticate,
and then start strace before you SELECT INBOX.
:wes
Cyrus Home Page: http://cyrusimap.web.c
On 03 Oct 2008, at 04:31, Simon Matter wrote:
> Any update on this issue? I'm wondering whether the patch will go into
> 2.3.13?
Nic and I are still talking. This patch will likely be applied after
2.3.13 is released. We've already made "last call" for 2.3.13. I
did find a bug in the versio
On 05 Oct 2008, at 18:14, Michael Menge wrote:
> the config.guess and config.sub included in cyrus are very old,
> replace them with a newer version.You may already have a newer version
> on your system.
Also, the latest config.guess and .sub have been committed to HEAD
for inclusion in the upco
Try --without-gssapi.
:wes
On 13 Oct 2008, at 15:45, Larry Rosenbaum wrote:
> I can't get it to build. I get the following:
>
> gcc -c -I.. -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/
> include
> -I../com_err/et -I/usr/local/include -DHAVE_CONFIG_H -g -O2 \
> auth_krb5.c
> auth_krb
On 13 Oct 2008, at 16:42, Rosenbaum, Larry M. wrote:
> That fixed it. Thanks.
Sure, please respond to the list so someone finding your original
question can get the correct answer as well. Thanks!
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cm
Thanks, I've opened this bugzilla:
http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3071
as a blocker for 2.3.13. A reminder: it's much, much better to
report bugs in the bugzilla than on the lists. The lists are for
discussion.
:wes
On 14 Oct 2008, at 13:09, Stephen Grier wrote:
>
You're thinking of modifying ipurge to do this? Sounds like a nice
idea. Messages are moved to Trash with COPY, and COPY retains the
original INTERNALDATE. However, the last_updated is set to NOW on
COPY, so that's probably what you want. ipurge currently supports
SENTDATE and INTERNALD
INTERNALDATE is stored in the cyrus meta files. So if you were to
delete the meta files and reconstruct, INTERNALDATE is set to the
mtime of the message file.
Your assertion that copy updates INTERNALDATE doesn't sound right to
me. What version of cyrus are you talking about?
:wes
On 23
Perhaps you're running a really old version?
Changes to the Cyrus IMAP Server since 2.1.4
* Sieve is no longer dependent on duplicate delivery suppression
(it still uses the duplicate delivery database however).
You can cheerfully disable duplicatesuppression, and sieve will
continue to
On 24 Oct 2008, at 13:09, Andrew Morgan wrote:
> Use the following option, which was added in 2.3.13:
>
> proxyd_disable_mailbox_referrals: 0
> Set to true to disable the use of mailbox-referrals on
> the proxy
> servers.
>
> This fixes the exact problem you desc
It appears to me that sync'd messages get an mtime of the
INTERNALDATE in 2.3.9 (and then improved in 2.3.10). Prior to that
release, mtime is probably when the message was sync'd, at a guess.
In your case, the subsequent message dates are probably just
reflecting the speed of replication
On 29 Oct 2008, at 09:18, Ian Eiloart wrote:
> Is there a way that I can prevent the proxies on the front end of
> my Murder
> cluster from advertising MAILBOX-REFERRALS in the CAPABILITY
> string? Or
> from issuing referrals?
There doesn't appear to be a way to disable advertising MAILBOX-
R
You can run two saslauthd's, with separate configurations and
separate sockets. The one for pop would use the special ldap filter,
presumably looking for an attribute or something that only users
authorized to use POP would have.
:wes
On 29 Oct 2008, at 09:36, Ian Eiloart wrote:
> I offer
I think the actual syntax would be:
sasl_pop_pwcheck_method: auxprop
sasl_pop_auxprop_plugin: sasldb
The documentation (which needs improvement, and since you're getting
free help on the cyrus list I hope you'll open a bugzilla with some
suggested improvements) is mostly in th
On 30 Oct 2008, at 12:34, Andrew Morgan wrote:
> I always thought the service name for options was whatever service
> name you put in cyrus.conf. It would be the first column in the
> SERVICES section, such as:
>
> imap cmd="/usr/local/cyrus/bin/imapd" listen="imap"
> prefork=10 maxchi
On 30 Oct 2008, at 12:54, Andreas Winkelmann wrote:
> Service-Name itself is the given name of the Daemon from
> cyrus.conf. It is not
> the service Name from Cyrus-SASL. Separating Options between the
> Daemons is
> not a Cyrus-SASL Feature it is a Cyrus-IMAP Feature. You can use it
> for ot
I can see why you describe it as "well hidden". Thanks for the
enlightenment. I'll endeavor to get all of these points adequately
included in the documentation. Thanks!
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3114
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3115
On 04 Nov 2008, at 07:39, Rob McMahon wrote:
> I suspect the underlying cause is this chunk from
> lib/cyrusdb_quotalegacy.c(foreach):
>
> /* strip off the qr specific path and replace with pattern */
> sprintf(strstr(quota_path, FNAME_QUOTADIR) + strlen
> (FNAME_QUOTADIR),
> "
The seen list is indexed by the mailbox ID which is stored in the
cyrus.header file. If you don't copy the cyrus.header file, your
seen data is useless. Reconstruct will retain the mailbox ID if the
cyrus.header file is intact. Hope that helps.
:wes
On 04 Nov 2008, at 13:43, Ciprian Mari
On 05 Nov 2008, at 10:31, Ken Murchison wrote:
> I'm not aware of any CONDSTORE clients other than Polymer, written by
> Dave Cridland. He may have written a similar client for a cell
> phone m
> manufacturer.
As I understand it, the IMP people are working on CONDSTORE support,
tho I think th
On 17 Nov 2008, at 14:14, Joshua Kordani wrote:
> An imap process keeps kicking out when a particular user tries to
> access
> his mail.
>
> mail log reports this:
> master[8762]: process 26353 exited, signaled to death by 7
>
> The process in question is the imap process that is handling the
> p
On 18 Nov 2008, at 05:28, Antonio Talarico wrote:
> Where i can found a list with allowed character for a folder name?
./imap/mboxname.c:#define GOODCHARS " #$'+,-.
0123456789:[EMAIL PROTECTED]"
:wes
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu
On 18 Nov 2008, at 06:28, ? wrote:
> I have a problem with cyrus-imapd 2.3.13 building from ports on
> FreeBSD 7.0
> When I recieve notify from IMAPd about "Over quota" or any other in my
> mailbox, I see "Unknown code IMAP 46(45)" or any other "Unknown imap
> code" instead o
1 - 100 of 353 matches
Mail list logo
