http://blog.gmane.org/gmane.mail.imap.cyrus hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.mail.imap.cyrus/36590 <pre>We're having issues building zephyr with the new automake stuff, and before we spend too much time fixing it - there's a question worth asking... Does anyone actually use zephyr? If not, I'd prefer to remove it and integrate worldline's notification bus work rather than having multiple competing notification systems. Bron. </pre> Bron Gondwana 2012-05-22T07:40:05 http://comments.gmane.org/gmane.mail.imap.cyrus/36566 <pre>I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had an issue with a folder in a mailbox that would not show any subfolders. I created a new folder 'folder2' and moved all of the subfolders to it and then performed a reconstruct on the new set of folders and everything worked. Now I deleted the old folder 'folder' from the file system and then (after it wouldn't go away from the cyradm listing) used cyr_dbtool to manually remove it (and the subfolders) from the mailboxes.db file. The old folders and subfolders are now gone, however, I can't (using the IMAP client) rename 'folder2' back to 'folder' as when I do, the subfolders are not visible. I've dumped the mailboxes.db file to a flat file to look and see if there is anything in there that wasn't visible in cyradm or using cyr_dbtool show. Everything is as expected except there are some DELETED.user.xxx.folder entries at the top. Are you not allowed the create folders with the same name you've just deleted? Where are these DELETED folders actually stored and how long does it take them to go away? (I'm not using delayed expunge.) If that's not the issue, then is there some other file besides mailboxes.db that might contain bad information or is this a bug in the system? Steve ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> Stephen Ingram 2012-05-19T16:51:38 http://comments.gmane.org/gmane.mail.imap.cyrus/36564 <pre>One account on the server includes a folder called CLIENTS which contains server sub-folders. Today, all of these sub-folders are no longer visible in the imap client (Thunderbird). Checking the server itself, the sub-folders are still there along with all of the mail. cyradm reports: user.jmaxwell.CLIENTS (\Has no children) when issuing lm user.jmaxwell.* although when issuing lm user.jmaxwell.CLIENTS.*, all of the sub-folders are visible. I've tried a reconstruct on both the full user mailbox: reconstruct -r -f user.jmaxwell, and the folder itself reconstruct -r -f user.jmaxwell.CLIENTS. When the reconstruct is performed on user.jmaxwell, the CLIENTS subfolders don't appear in the results. However, when the reconstruct is performed on the user.jmaxwell.CLIENTS folder, all of the sub-folders appear in the results. I'm guessing this means that the index inside of the CLIENTS folder is corrupted. Is there a way to fix this alone? I'm running the invoca 2.4.13 rpms on CentOS 5.3. Steve ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> Stephen Ingram 2012-05-18T19:34:45 http://comments.gmane.org/gmane.mail.imap.cyrus/36563 <pre>Hello, I'm not sure this is the list to post my issue but thought I'd give it a shot. We're running Cyrus IMAPD 3.3.16 on a CentOS 6 server for about 50 users. All users have Thunderbird 11-12 as their email client. A couple of the users rely on "tagging" email in Tbird heavily. Periodically, they lose the tags they have placed for no apparent reason. They are there for a few days/weeks, then gone. Is this something that could be happening in Cyrus, or is it strictly a Thunderbird issue? Any input is appreciated! Thanks! </pre> Tom Plancon 2012-05-18T14:23:53 http://comments.gmane.org/gmane.mail.imap.cyrus/36559 <pre>OS CentOS-6.2 HW i86_64 KVM guest We are migrating from cyrus-imapd-2.2.13 running on CentOS-4.9 to v2.3.16 running on CentOS-6.2; being is the most recent version distributed by the packager. To the best of my ability to determine I have followed the upgrade instructions at http://cyrusimap.web.cmu.edu/docs/cyrus-imapd/2.3.16/install-upgrade.php. The data transfer and SELinux considerations completed successfully as did the mailbox reconstruction and quota updates. The new service is running and I can administer user mailboxes. However, the quota usage reported for user accounts under 2.3.16 differs dramatically from that reported under 2.2.13. It appears on the surface that the usage reported is for each individual mailbox and not for the accumulated usage under the user's INBOX. For example, I have the situation under 2.3.16 where a user with 500mb quota and 375mb usage is reported at the highest level as 3% usage because there is very little mail in their INBOX but a great deal of archived mail in subordinate folders. On the 2.2.13 server this identical user mailbox is reported as 75% utilization. I see in the change logs that there were numerous changes to quotas. But it seems odd to me that usage would no longer report cumulative totals. Can somebody give me the short form explanation of how quota is assigned to folders and usage is reported under 2.3.16? </pre> James B. Byrne 2012-05-15T20:41:45 http://comments.gmane.org/gmane.mail.imap.cyrus/36558 <pre> We are looking at upgrading from Cyrus IMAP 2.3 to 2.4. We run a Murder with one front end server and one back end server. We plan to XFER mailboxes from the old back end to a new back end server with more storage. From the mailing list I understand we should upgrade the front end server first before transferring mailboxes. My planned changes for the front end server are to add the suppress_capabilities directive to imapd.conf, ensure the lock directory is created on tmpfs and touch a blank user_deny.db. My expectation is that I can stop the front end server, upgrade the software and restart it with the updated imapd.conf. As far as the front end upgrade is concerned, is there really any difference between the behaviour of 2.3 vs 2.4? Most of the changes appear to be focused on the mailbox handling code. Does anyone running a Murder have experience of the upgrade from 2.3 to 2.4 they could share? Will users notice any difference at this stage? Thanks, Dave. David Mayo Networks/Systems Administrator University of Bath Computing Services, UK ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> David Mayo 2012-05-11T10:14:50 http://comments.gmane.org/gmane.mail.imap.cyrus/36550 <pre>Folks, Proceeding with my (sometimes steep) learning curve on Cyrus Murder (and preparing a Wiki guide to same) I have recently experienced a case of missing mailboxes. Let me explain... I started out by splitting a long-running non-murder 2.4.10 host into a single frontend and backend, with a separate mupdate master. I then added a second frontend -- no problem. I then added a second backend (several problems, but a lot of learning!) and ultimately moved an account onto it. The next day, I tweaked some settings in the config files and restarted the Cyrus server. Went to look at my mailboxes and they're gone! Uh-oh!! Long story short, the original backend is configured with 'servername: mailbox.example.com' and the new backend is 'servername: mailbox.wi.example.com'. I had moved the account with this command (in cyradm): mail.example.com&gt; xfermailbox user.onlight mailbox.wi Problem is that ctl_mboxlist.c:do_dump() compares the mailboxes.db entry for the mailbox with config_servername, and deletes any mailboxes on the local host which don't match. The mailboxes.db entry contains whatever string the user types in to cyradm's XFER command, regardless of what the target server thinks its name is. Now I can understand this, to some extent, but seeing as in several other places Cyrus cavalierly discards portions of hostnames (i.e. all the host_* settings in imapd.conf) it seems odd that here it behaves like this. The user might enter quite a few different names into cyradm and successfully transfer the mailbox, only to have it disappear upon reboot/restart. They may use a short name (as I did) or an IP address, or any other host name which resolves to the destination server, and the command will succeed. It seems to me that since servername is so important, this behavior should at least be mentioned in the imapd.conf(5) manpage. But really, I would expect that once the source server is connected to the target server via IMAP protocol, if the target lists a servername in its greeting or capability string (as it will unless 'serverinfo: off' is set) then THAT name is what should be entered into the mailboxes.db file, and not whatever shorthand the user may have used. Is this doable? Cheers, -nic </pre> Nic Bernstein 2012-05-10T14:56:41 http://comments.gmane.org/gmane.mail.imap.cyrus/36548 <pre>We are running Cyrus 2.2.13, and I recently noticed that we have many imapd processes on the server, dating back to the day that the server was last booted, which was over 3 months ago. The entries for many of them in /var/imap/proc look like this: &gt; 249.sub-174-253-10.myvzw.com [174.253.10.249] Note there's no user name with them. I have googled myself silly, and can't find any evidence that others have seen this problem. I know they need to be killed; short of rebooting the server, is there anything I could/should do? I inherited this installation, btw, and don't really have anyone to talk to about it. Thanks. b. ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> Brian Capouch 2012-05-09T23:42:34 http://comments.gmane.org/gmane.mail.imap.cyrus/36540 <pre>In trying to bring up a murder with 2.4.10, I am encountering a problem I just cannot seem to get past. I've got a Mupdate master, 2 backends and 2 frontends. Everyone seems to be exchanging mailboxes.db info just fine, but I cannot move a mailbox (user inbox) from the original backend (used to be single, standalone system) to the second backend. Here is sample cyradm session, first to a frontend: # cyradm -user cyradmin mail Password: mail&gt; xfer user.nic mailbox.wi xfermailbox: bad parameters to function mail&gt; rename user.nic user.nic mailbox.wi renamemailbox: The remote Server(s) denied the operation and to the backend holding the mailbox to be moved: # cyradm -user cyradmin mailbox Password: mailbox&gt; xfer user.nic mailbox.wi xfermailbox: The remote Server(s) denied the operation mailbox&gt; rename user.nic user.nic mailbox.wi renamemailbox: The remote Server(s) denied the operation Here are protocol traces from the hosts involved: From the first session: On host&lt;mail&gt; ---------- cyradmin Fri May 4 07:01:01 2012 &lt;1336132861&lt;4 RLIST "" "" &gt;1336132861&gt;* LIST (\Noselect) "." "" 4 OK Completed (0.000 secs) &lt;1336132870&lt;5 XFER user.nic mailbox.wi &gt;1336132871&gt;5 NO bad parameters to function &lt;1336132898&lt;6 RENAME user.nic user.nic mailbox.wi &gt;1336132898&gt;6 NO The remote Server(s) denied the operation On host&lt;mailbox.wi&gt; ---------- murder Fri May 4 07:01:10 2012 &lt;1336132871&lt;Q01 LOGOUT &gt;1336132871&gt;* BYE LOGOUT received Q01 OK Completed On host&lt;postman&gt; (with clock drift) ---------- postman Fri May 4 07:03:26 2012 &lt;1336133006&lt;X0 ACTIVATE {8+} user.nic {26+} mailbox.occinc.com!default {63+} niclrswipcdaadmindcyruslrswipkxteacyradminlrswipkxtecda &gt;1336133006&gt;X0 OK "done" &lt;1336133006&lt;Q01 LOGOUT &gt;1336133006&gt;Q01 OK "bye-bye" And from the second: On host&lt;mailbox.wi&gt; ---------- murder Fri May 4 07:14:51 2012 &lt;1336133691&lt;Q01 SETQUOTA {9+} +user.nic (STORAGE 3500000) &gt;1336133691&gt;Q01 NO Permission denied &lt;1336133691&lt;Q01 LOGOUT &gt;1336133691&gt;* BYE LOGOUT received Q01 OK Completed ---------- murder Fri May 4 07:15:00 2012 &lt;1336133700&lt;Q01 SETQUOTA {9+} +user.nic (STORAGE 3500000) &gt;1336133700&gt;Q01 NO Permission denied &lt;1336133700&lt;Q01 LOGOUT &gt;1336133700&gt;* BYE LOGOUT received Q01 OK Completed On host&lt;postman&gt; (again with clock drift) ---------- postman Fri May 4 07:16:38 2012 &lt;1336133798&lt;X0 ACTIVATE {8+} user.nic {26+} mailbox.occinc.com!default {63+} niclrswipcdaadmindcyruslrswipkxteacyradminlrswipkxtecda &gt;1336133798&gt;X0 OK "done" &lt;1336133798&lt;Q01 LOGOUT &gt;1336133798&gt;Q01 OK "bye-bye" So it looks to me like the ACL is not being transferred, and the entire operation is buggered from there on. Right? What's the fix to this? Is there some overarching ACL which I'm missing? Here are the pertinent (sanitized) portions of the configurations from both backends: # mailbox - main backend admins: cyrus cyradmin allowplaintext: yes sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN sasl_minimum_layer: 0 sasl_auto_transition: no servername: mailbox.example.com proxyservers: cyradmin murder allowusermoves: true idlemethod: idled allowallsubscribe: true altnamespace: true defaultacl: anyone lrsip mupdate_server: postman.example.com mupdate_username: postman mupdate_authname: postman mupdate_password: password1 proxy_authname: murder proxy_password: password2 force_sasl_client_mech: PLAIN postman_mechs: PLAIN mailbox_mechs: PLAIN serverlist: mailbox mailbox.wi ---------------------- # mailbox.wi - new backend admins: cyrus cyradmin allowplaintext: yes sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN LOGIN sasl_minimum_layer: 0 sasl_auto_transition: no servername: mailbox.wi.example.com allowallsubscribe: true duplicatesuppression: true expunge_mode: delayed proxyservers: cyradmin murder allowusermoves: true mupdate_server: postman.example.com mupdate_username: postman mupdate_authname: postman mupdate_password: password1 proxy_authname: murder proxy_password: password2 force_sasl_client_mech: PLAIN postman_mechs: PLAIN mailbox_mechs: PLAIN serverlist: mailbox mailbox.wi For what it's worth, all authentication is via saslauthd with LDAP. I am able to create new mailboxes on the new backend, and access them via all frontends, etc. I am just not able to transfer mailboxes, which is kind of the critical part of this whole effort (distribute mail from centralized location to remote sites). Any assistance would be greatly appreciated. Best regards, -nic </pre> Nic Bernstein 2012-05-04T12:32:13 http://comments.gmane.org/gmane.mail.imap.cyrus/36539 <pre>Hello list How can I disable a user from getting emails? I dont want to delete it, just to stop pop his account. Thank you in advance! </pre> Nikos Gatsis - Qbit 2012-05-04T11:45:21 http://comments.gmane.org/gmane.mail.imap.cyrus/36537 <pre>Hello there, With many thanks to Дилян Палаузов &lt;dilyan.palauzov&lt; at &gt;aegee.org&gt;, we would like to let you know about one particular feature now definitely included for a pending Cyrus IMAP 2.5 release. As a feature for the upcoming 2.5 release of Cyrus IMAP, though the exact schedule is yet unknown, we have merged into master the grand overhaul to using autoconf / automake. This marks a first significant milestone closing in on actually producing a 2.5 series release, but, and this is very important: NOT without your help. We would like those of you that have a need to or experience with building Cyrus IMAP from source to let us know whether the autoconf and automake (or, as I like to call it, "autofu") Works For You(TM). To this end, we encourage you to clone the GIT repository master branch and attempt a build, or, alternatively, download the following snapshot release: http://git.cyrusimap.org/cyrus-imapd/snapshot/cyrus-imapd-2.5-snapshot- autoconf-and-automake.tar.gz The canonical build process we think applies, generally speaking, is: $ autoreconf -v $ ./configure [your-options] $ make This process currently requires autoconf &gt;= 2.67. We would appreciate you let us know whether or not such process works for you, preferrably though Bugzilla (please use product 'Cyrus IMAP' and component 'Distribution'). Thank you, in advance, On behalf of the Cyrus team, Kind regards, Jeroen van Meeuwen </pre> Jeroen van Meeuwen (Kolab Systems 2012-04-28T16:15:22 http://comments.gmane.org/gmane.mail.imap.cyrus/36536 <pre>Folks, Finally getting around to bringing up my first production Murder environment and I have the feeling that I have more than I need in my frontend configs. Here is what I currently have configured: Frontend imapd.conf: admins: cyrus cyradmin configdirectory: /var/lib/imap partition-default: /var/spool/imap sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail mboxname_lockpath: /var/run/cyrus/lock proc_path: /var/run/cyrus/proc duplicate_db_path: /var/run/cyrus/deliver.db statuscache_db_path: /var/run/cyrus/statuscache.db tlscache_db_path: /var/run/cyrus/tls_sessions.db allowplaintext: yes sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN sasl_minimum_layer: 0 sasl_auto_transition: no servername: mail.example.com lmtp_downcase_rcpt: true username_tolower: true lmtpsocket: /var/run/cyrus/socket/lmtp idlesocket: /var/run/cyrus/socket/idle notifysocket: /var/run/cyrus/socket/notify syslog_prefix: cyrus proxyservers: cyradmin allowusermoves: true idlemethod: idled allowallsubscribe: true altnamespace: true defaultacl: anyone lrsip createonpost: true proxyd_disable_mailbox_referrals: true mupdate_server: postman.example.com mupdate_username: postman mupdate_authname: postman mupdate_password: ******** proxy_authname: murder proxy_password: ******** force_sasl_client_mech: PLAIN postman_mechs: PLAIN mailbox_mechs: PLAIN Backend imapd.conf: admins: cyrus cyradmin configdirectory: /var/lib/imap partition-default: /var/spool/imap sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail mboxname_lockpath: /var/run/cyrus/lock proc_path: /var/run/cyrus/proc duplicate_db_path: /var/run/cyrus/deliver.db statuscache_db_path: /var/run/cyrus/statuscache.db tlscache_db_path: /var/run/cyrus/tls_sessions.db allowplaintext: yes sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN sasl_minimum_layer: 0 sasl_auto_transition: no servername: mailbox.example.com singleinstancestore: true duplicatesuppression: true expunge_mode: delayed lmtp_downcase_rcpt: true username_tolower: true lmtpsocket: /var/run/cyrus/socket/lmtp idlesocket: /var/run/cyrus/socket/idle notifysocket: /var/run/cyrus/socket/notify syslog_prefix: cyrus proxyservers: cyradmin murder allowusermoves: true idlemethod: idled allowallsubscribe: true altnamespace: true defaultacl: anyone lrsip mupdate_server: postman.example.com mupdate_username: postman mupdate_authname: postman mupdate_password: ********* force_sasl_client_mech: PLAIN postman_mechs: PLAIN Mupdate master imapd.conf: admins: cyrus cyradmin postman configdirectory: /var/lib/cyrus defaultpartition: default partition-default: /tmp allowplaintext: yes sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN sasl_minimum_layer: 0 sasl_auto_transition: no servername: postman.example.com allowallsubscribe: true altnamespace: true defaultacl: anyone lrsip umask: 077 syslog_prefix: cyrus I think it would be most useful if we had some sort of guide as to which directives are *required* versus *optional* or *useless* for each given mode of operation. I do appreciate that some of the settings listed in imapd.conf.5 now list " - Cyrus Murder" after them (such as hostname_password) indicating they only apply in a murder, but knowing which are necessary or not for each mode would sure be handy. If someone can provide quick notes, I'd be glad to make a Wiki entry. Cheers, -nic </pre> Nic Bernstein 2012-04-27T17:53:10 http://comments.gmane.org/gmane.mail.imap.cyrus/36522 <pre>Hi. I hoped that cyrus would be managable through ldap but that doesn't seem to be the case. Is the cyrus ldap support strictly for authentication? It's just that sasl can do that as well. I'd like to know if there are other options to managing mailboxes besides calling perl scripts. I need to come up with some kind of a graphical interface to manage mailboxes and I'm looking for the available options to interface with cyrus. thanks Martin ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> Martin Kraus 2012-04-24T09:00:05 http://comments.gmane.org/gmane.mail.imap.cyrus/36514 <pre>Hi there, I'm forwarding this message posted to the announcement mailing list originally, to let you know any upgrades should target 2.4.16 as opposed to 2.4.15. We are pleased to announce the release of Cyrus IMAPd 2.4.16. This is a stable release in the 2.4.x series. It contains exactly one bugfix in tools/rehash, which was rewritten after 2.4.14 introduced a critical fault for deployments that have the fulldirhash option enabled. Release 2.4.15 was released to resolve this issue, among others, but the tool as released with 2.4.15 contained Perl syntax errors. We recommend ALL sites that deploy Cyrus IMAP with the fulldirhash option enabled to update to 2.4.16. Please see bug #3651[1] for a full history of this bug. A special thanks goes out to Carlos Velasco for catching and reporting this issue first. We apologize for any inconvenience caused. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.16.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.16.tar.gz On behalf of the Cyrus team, Kind regards, Jeroen van Meeuwen [1] https://bugzilla.cyrusimap.org/show_bug.cgi?id=3651 </pre> Jeroen van Meeuwen 2012-04-19T10:00:01 http://comments.gmane.org/gmane.mail.imap.cyrus/36512 <pre>Hello. I have two nodes - first is master and second is replica. cyrus-imapd version on master is 2.4.13 and on replica 2.4.14. I have configured rolling replication from first master node to replica. When I try to synchronize all user mailboxes in parallel to running rolling replication - it seems that syncserv process deletes mailboxes (in log file there are a log of messages like: Apr 17 13:24:45 backend2 syncserverin[1647]: Deleted mailbox domain!shared.box Apr 17 13:24:45 backend2 syncserverin[1647]: Deleted mailbox domain!shared.box2 Apr 17 13:24:45 backend2 syncserverin[1647]: Deleted mailbox domain2!shared.box3 Apr 17 13:24:45 backend2 syncserverin[1647]: Deleted mailbox domain!user.user Apr 17 13:24:45 backend2 syncserverin[1647]: Deleted mailbox domain3!user.box4 ) Syncserv process with PID 1647 serves rolling replication (I see it from log file - another syncserv process serves synchronization of one user mailbox - which I explicitly have asked via sync_client -l -u user&lt; at &gt;domain). Why syncserve deletes these mailboxes and what is the proper way to initially synchronize all user mailboxes from master node to replica? </pre> Dmitry Banschikov 2012-04-17T14:20:17 http://comments.gmane.org/gmane.mail.imap.cyrus/36503 <pre> Hi experts, we have a mupdate server (Solaris 10, Cyrus 2.3.16) and frontnend and backend servers (Redhat Linux due to migration from Solaris environment). The RHEL frontend connects to the (Solaris) mupdate server, authentication work. But after Apr 17 07:27:21 eg-mailfrontend cyrus/mupdate[7395]: successful mupdate connection to mupdate-febe.intern.tu-berlin.de Apr 17 07:27:21 eg-mailfrontend cyrus/mupdate[7395]: scarfing mailbox list from master mupdate server nothing happens, the mailbox list lacks update. Lets look what mupdate does: [root&lt; at &gt;eg-mailfrontend elsnccpa]# ps -ef | grep mupdate | grep -v grep cyrus 7393 7388 0 07:27 ? 00:00:00 mupdate cyrus 7395 7388 0 07:27 ? 00:00:00 mupdate [root&lt; at &gt;eg-mailfrontend elsnccpa]# strace -p 7396 Process 7396 attached - interrupt to quit accept(4, ^C &lt;unfinished ...&gt; Process 7396 detached [root&lt; at &gt;eg-mailfrontend elsnccpa]# man tcpdump [root&lt; at &gt;eg-mailfrontend elsnccpa]# man imapd.conf [root&lt; at &gt;eg-mailfrontend elsnccpa]# man imapd.conf [root&lt; at &gt;eg-mailfrontend elsnccpa]# strace -p 7395 Process 7395 attached - interrupt to quit futex(0x7f8af2249e84, FUTEX_WAIT_PRIVATE, 1, NULL^C &lt;unfinished ...&gt; The frontends running the same cyrus version under Solaris work perfect. Any clue? --Frank Elsner ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> Frank Elsner 2012-04-17T06:43:03 http://comments.gmane.org/gmane.mail.imap.cyrus/36499 <pre>Dear guys, I have a 5GB mailbox which I moved using imapsync. But somehow I messed up with --delete option and end up with almost all the messages having \Deleted flag set. I do not have delayed expunge enabled, so I can not use unexpunge utility. I am using cyrus-imapd v2.3.7. Is there any way I can unset \Deleted flag for all the mails in the mailbox? Thank you. -- Regards, Sachin Divekar ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/</pre> Sachin Divekar 2012-04-09T02:02:19 http://comments.gmane.org/gmane.mail.imap.cyrus/36494 <pre>Good morning, I'm running an ISP environment with Cyrus 2.3.18. I have seen, we have some problems when sync_client tries to do a SEEN from some mailboxes. First of all, say that we had to patch Cyrus IMAP with this proposed patch http://www.irbs.net/internet/info-cyrus/0602/0330.html because else... our customers who used Outlook (with any version!!!, even 2010!!!) and pop3 mail retrieval protocol and the option of left message copy on the server, where constantly downloading the same messages one time and another (and always they checked for new mail in this MUA... and obviously you know... our customer's annoyance). After applying this patch, although the first problem has been corrected, (the Outlook and UIDL one...) I have observed (and reproduced) that sync_client's forked proccess gets stuck with some mailboxes when SEEN actions that had to move big strings like this one : cyr_dbtool /expert/correo/imap/domain/e/egoitz.com/user/e/egoitz.seen skiplist show 04409b4d4f77894d1 1333240179 13393 1333240678 11,25,57,63,88,96:97,104,120,130,147,152,158:160,198,204,218,256,263,273,333,335,355,382:383,420,441,458,467,509,514,530,545,548,594,601,616,641,661,665:666,681,703,743,812,819,824,838,847,859,865,878,889,891,894,899,934,953,984,997,1002,1009,1024,1033,1068,1070,1123,1126,1165,1170,1175:1176,1179,1195,1197,1211,1221,1230,1261,1263,1275,1282,1299,1314,1334,1345,1364,1377,1417,1419,1421,1439,1443,1451,1454,1462,1476,1478,1515,1526,1529,1540,1564:1566,1573,1593,1608,1626,1628,1674,1697,1702,1713,1719,1736,1738,1748,1769,1775,1781,1830,1834,1842,1865,1870,1888,1910,1923,1930,1932,1935,1940,1973:1974,2005,2009,2011,2027,2044,2069,2079,2095,2101:2102,2119,2122,2134,2137,2141,2143,2154,2209,2223,2247,2267,2271,2287,2313,2331,2333:2334,2336,2338,2356,2370,2387,2431,2451,2478,2493,2517,2520,2550,25 56,2572,2575,2594,2596,2600,2607,2658:2659,2708,2715,2732,2744,2766,2778,2817,2830,2885,2889,2904,2911,2917,2920,2930,2940,2955,2962,2970:2971,2985,3011,3031,3039:3040,3061,3091,3096,3147,31 54,3164, 3171,3180,3183,3191:3192,3199,3219,3221,3225,3227,3230,3235,3254,3264,3273,3280,3304,3343,3361,3371,3375,3406,3414,3419,3425,3445,3463,3489,3492,3499,3525,3556,3564,3604,3636,3643,3665,3667,3670,3691:3692,3747,3797,3801,3803,3811,3852,3872,3883,3886,3907,3930,3993,4020,4036,4043,4105,4113,4142,4149,4159,4172,4187,4218,4220,4257,4309,4363,4365,4369,4371,4393:4394,4400,4434,4463,4481,4515,4551,4554,4581,4585,4591,4600,4641,4663,4710,4713,4721,4767,4792,4818,4872,4898,4928,4961,4977,4979:4981,4983,5009,5014,5037,5064,5076,5105,5156,5165,5177,5193,5208,5241,5261,5275,5281,5296,5298,5311,5313,5321,5328,5334,5343,5363,5392,5395,5401,5404,5408,5427,5440,5453,5466,5483,5520,5527,5537,5549,5597,5603,5608,5613,5652,5683,5688,5692,5719,5730,5747,5753,5764,5804,5845,5848,5860,5880,5883,5887,5910,5919: 5920,5937,5950,5963,5974,5980,6014,6017,6032,6043,6052,6054,6070,6143,6180,6194,6273,6307,6342,6378,6384,6389,6407,6418,6421,6435,6443,6452,6480,6488,6534,6544,6556,6566,6576,6588,6603,6616, 6691,673 3,6736,6749,6772,6820,6844,6860,6864,6878,6907,6913,6921,6932,6977,6988,6990,6996,7014,7030,7034,7042,7052,7084,7087,7095,7142,7151,7157,7162,7176:7177,7187,7194,7199,7215,7247,7275,7282,7331,7340:7341,7346,7349,7376,7383:7384,7403,7425,7479,7566,7571,7603,7611,7623,7648,7688:7689,7728,7758,7766,7795,7806,7815,7819,7851,7854,7863,7887,7915,7919,7929:7930,7932,7941,7981,7985,8147,8200,8257,8282,8287,8304,8309,8317,8321,8324,8326,8328,8330,8335,8359,8366:8367,8372,8432,8455,8460,8476,8499,8504,8513,8519,8531,8542,8567,8569,8575,8647,8660:8661,8669,8687:8688,8724,8750,8754,8773,8778,8792,8816,8834,8838,8876,8912,8927,8934,8937:8938,8969,8980:8981,9005,9008,9018,9029,9035:9036,9040,9044,9052,9066,9069,9076:9077,9084,9087:9088,9110,9131,9143,9152,9181,9191,9200,9207,9233,9255,9317,9340,9350,935 9,9375,9402,9405,9412,9416:9417,9420:9421,9427,9433,9441,9445,9448,9451,9466,9473,9478,9505,9532,9569,9572,9598,9600,9609,9636,9645,9657,9671,9690,9702,9709,9711:9712,9714,9717,9729,9735,973 7,9740:9 741,9750,9752,9755,9776,9782,9787,9799:9800,9817,9825,9833,9836,9889,9894:9895,9901,9903,9907:9908,9916,9919:9920,9923,9932,9938,9957,9972,10000,10027,10062,10065,10095,10109,10147,10159,10183,10186,10193,10239,10307,10347,10374,10423,10426,10434,10437,10479:10480,10495,10502,10513,10515,10523:10524,10538,10552,10566,10574,10595,10611,10615,10620,10624,10647:10648,10650,10660,10672,10674,10683:10684,10704,10715,10757:10758,10780,10784,10786,10788,10826,10830,10841,10863,10865,10868,10873,10884,10892,10905,10915,10927,10953:10954,10962,10975,11027,11042,11044,11053,11056,11061,11076,11103,11169,11196,11205,11218,11285,11295,11315,11317,11331,11333:11334,11338,11351,11354,11361,11377:11378,11381,11405,11407,11412,11414,11440,11452,11484,11486,11489,11493,11498,11541,11552,11562,11579,11601,1 1608,11610,11618,11657,11684,11688:11689,11697,11713,11717,11730,11739,11750,11754,11775,11788,11794,11840,11862,11864,11869,11871:11872,11901:11902,11922,11926,11954,11957,11967,11979,11991 ,11994,1 1996,12007:12008,12014:12015,12019,12022,12030,12039,12046,12048:12049 17ee87c64f778f641 1333240441 20 1333240546 1:15,20 60fce00e4f778f591 1333240443 36 1333240403 1:31,33:35 6dd5e44d4f778f491 1333240233 71 1333240678 1:71 After doing some tests, and as said before, reproduced the problem... have noticed that sync_client is not being able to handle this big string with the function prot_printf as left in the proposed patch in the previous written URL (http://www.irbs.net/internet/info-cyrus/0602/0330.html). With other smaller strings has no problem with SEEN, but with this one, as said gets stuck there. So... like Outlook is a very used MUA (very known in fact....) and replication is essential IMHO to work smoothly.... I wanted to propose you this modified version of the patch I have attached to this mail. If you were so kind, I would be very thanked if you told me if you see some problem applying this to Cyrus-IMAPd 2.3.18 (you know... you would have to apply them with -p0 because have not take care with file locations.... sorry :) ). I have checked that when applying my modified version of the patch, the problem of SEEN mailboxes gets fixed and although have not tested directly the Outlook problem has to be corrected too... because of the own naure of the changes. If you see it ok?, wouldn't it be fine if you commit it to the official cvs of this nice server project?. I mean this is a very common problem that could happen, and the replication IMHO makes Cyrus (apart from other features of course) to be the better software of this kind. So to summarize... do you see any problem with this patch?... and to be applied to now patched servers (with previous version of the patch of the proposed patch of the URL) ?. Could it be committed to cvs? Thanks a lot for you're time, Best regards---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/</pre> egoitz< at >ramattack.net 2012-04-01T09:25:57 http://comments.gmane.org/gmane.mail.imap.cyrus/36489 <pre>I has the next question, how cyrus calculated the quota occupied by user? This is very important but my server don't calculated correctly but error in many accounts and his folder. Un saludo. </pre> Manuel Vazquez 2012-03-30T15:33:36 http://comments.gmane.org/gmane.mail.imap.cyrus/36483 <pre>Hello, I would ask another little help. When I set this sieve script: if true { addflag "\\Flagged"; keep; } I receive mails unflagged. Other sieve rules work as expected. If I want a working filter I have to set: if true { addflag "\\Flagged"; fileinto "INBOX"; } Could you help me? Many sieve clients make the first rule... it could be a bug? This is my sieve: "IMPLEMENTATION" "Cyrus timsieved v2.4.14-Invoca-RPM-2.4.14-1" "SASL" "PLAIN" "SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify envelope relational regex subaddress copy" "UNAUTHENTICATE" This problem occurs also with 2.4.13 version. This is my imapd.conf: === configdirectory: /var/lib/imap #partition-default: /dev/null partition-maildata1: /maildata/comune.prova.it/maildata1 partition-maildata2: /maildata/uc.test.it/maildata1 partition-maildata3: /maildata/regione.piemonte.it/maildata1 partition-maildata4: /maildata/uc.csi.it/maildata1 partition-maildata5: /maildata/csi.it/maildata1 partition-maildatadm: /maildata/admin.invalid/maildatadm #defaultpartition: default metapartition_files: header index cache expunge squat metapartition-maildata1: /metamaildata1 metapartition-maildata2: /metamaildata2 metapartition-maildata3: /metamaildata3 metapartition-maildata4: /metamaildata4 metapartition-maildata5: /metamaildata5 metapartition-maildatadm: /metamaildatadm altnamespace: 0 serverinfo: on admins: oxcyrus annotation_definitions: /etc/annoIMAP.conf sievedir: /var/lib/imap/sieve postmaster: postmaster&lt; at &gt;regione.piemonte.it sendmail: /usr/sbin/sendmail fulldirhash: 1 hashimapspool: true #sasl_auxprop_plugin: sasldb sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN allowapop: 0 quotawarn: 80 normalizeuid: 1 syslog_prefix: cyrus unixhierarchysep: 1 autocreatequota: 0 implicit_owner_rights: l createonpost: 0 autosubscribe_all_sharedfolders: yes expunge_days: 30 singleinstancestore: 1 defaultdomain: admin.invalid improved_mboxlist_sort: 1 virtdomains: userid quotadb: skiplist allowusermoves: 1 ==== I thank you very very much for every hints and helps! Best Regards Marco ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> Marco 2012-03-30T08:41:21 http://comments.gmane.org/gmane.mail.imap.cyrus/36481 <pre>Hello, I'm in panic upgrading Cyrus from 2.4.13 to 2.4.14. After upgrade cyrus stop to work with these errors: IOERROR: opening index uc.csi.it!user.marco^favero: System I/O error Before upgrade, if I ask a mbpath I see: mbpath user/marco.favero&lt; at &gt;uc.csi.it /metamaildata4/domain/C/uc.csi.it/V/user/marco^favero After upgrade I see: mbpath user/marco.favero&lt; at &gt;uc.csi.it /maildata/uc.csi.it/maildata1/domain/C/uc.csi.it/P/user/marco^favero ...so it seems Cyrus change paths after upgrade and it loose all mailboxes! The righ path is '/maildata/uc.csi.it/maildata1/domain/C/uc.csi.it/V/user/marco^favero/' according to mbpath before upgrade. This is my cyrus banner: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=PLAIN SASL-IR] tst-msg01.csi.it Cyrus IMAP v2.4.14-Invoca-RPM-2.4.14-1 server ready a01 CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY X-NETSCAPE AUTH=PLAIN SASL-IR COMPRESS=DEFLATE IDLE My host is: Linux host.csi.it 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST 2010 x86_64 x86_64 x86_64 GNU/Linux Could you help me to understand what it happens? This is my imapd.conf: === configdirectory: /var/lib/imap #partition-default: /dev/null partition-maildata1: /maildata/comune.prova.it/maildata1 partition-maildata2: /maildata/uc.test.it/maildata1 partition-maildata3: /maildata/regione.piemonte.it/maildata1 partition-maildata4: /maildata/uc.csi.it/maildata1 partition-maildata5: /maildata/csi.it/maildata1 partition-maildatadm: /maildata/admin.invalid/maildatadm #defaultpartition: default metapartition_files: header index cache expunge squat metapartition-maildata1: /metamaildata1 metapartition-maildata2: /metamaildata2 metapartition-maildata3: /metamaildata3 metapartition-maildata4: /metamaildata4 metapartition-maildata5: /metamaildata5 metapartition-maildatadm: /metamaildatadm altnamespace: 0 serverinfo: on admins: oxcyrus annotation_definitions: /etc/annoIMAP.conf sievedir: /var/lib/imap/sieve postmaster: postmaster&lt; at &gt;regione.piemonte.it sendmail: /usr/sbin/sendmail fulldirhash: 1 hashimapspool: true #sasl_auxprop_plugin: sasldb sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN allowapop: 0 quotawarn: 80 normalizeuid: 1 syslog_prefix: cyrus unixhierarchysep: 1 autocreatequota: 0 implicit_owner_rights: l createonpost: 0 autosubscribe_all_sharedfolders: yes expunge_days: 30 singleinstancestore: 1 defaultdomain: admin.invalid improved_mboxlist_sort: 1 virtdomains: userid quotadb: skiplist allowusermoves: 1 ==== I thank you very very much! Regards Marco ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ </pre> Marco 2012-03-30T08:28:43 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.mail.imap.cyrus