Re: Restore message date from "Date:" field
Gionatan, I believe the tool you're looking for is 'mbtool' From the man page: DESCRIPTION mbtool is a tool for performing various actions on the indexes of a list of mailboxes. The only actions currently supported are -t, which will normalize the internaldate time stamp of each record in the index to GMT, and -r which will create a new unique ID for each mailbox. ... -t Normalize internaldate on all index records of all listed mail‐ boxes to match the Date: header if theyâre off by more than a day, which can be used to fix up a mailbox which has been re‐ stored from backup and lost its internaldate information. ... EXAMPLES*mbtool -t* user.jsmith Normalize |internaldate| on all index records in /user.jsmith/. Working on user.jsmith... 0001: Tue, 08 Jul 2014 16:45:18 -0500 => Mon, 07 Jul 2014 20:44:18 + 0002: Tue Jul 08 16:45:13 CDT 2013 => Fri, 30 Aug 2013 19:46:03 + <...> http://www.cyrusimap.org/imap/reference/manpages/systemcommands/mbtool.html?highlight=mbtool Cheers, -nic On 7/31/20 6:39 AM, Gionatan Danti wrote: Hi all, I just noticed the dates of some old emails are wrongly displayed on roundcube webmail. In short, the list view shows the filesystem date of the affected messages (ie: mtime of u.1 file), rather than what is found in the "Date:" header field These were emails migrated from an old system, but I vaguely remember I had some issue at the time which I solved with some combination of rsync+imapsync. Can "reconstruct" be used to repopulate the index file with the correct date from "Date:" field? If not, what I can do to solve the issue? I already tried "reconstruct -u user@domain -x -f -r -G", but with no avail. Thanks. -- Nic Bernstein n...@nicbernstein.com https://www.nicbernstein.com https://www.linkedin.com/in/nic-b-26577a178/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus Murder Environment Upgrade
Miguel, That's perfectly normal, and I think it's even covered in the release notes... Nope, I'm wrong, the release notes mention the larger Memory footprint, due to more data and metadata being cached in memory. But the on-disk size increases, too, as there is more information being held in indexes, etc. The same is true, again, when going from 2.5 to 3.X Cheers, -nic On 6/10/20 1:47 PM, Miguel Mucio Santos Moreira wrote: Wolfgang, If you don't mind, I'd like to know if when you upgraded backend servers from 2.4 version to 2.5 version you have an increase, in metadata size.Here we had 30% around of increase Thanks one more time Greetings -- *Miguel Moreira* DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Terça, Junho 09, 2020 10:39 -03, Wolfgang Breyha escreveu: Hi! On 09/06/2020 14:56, Miguel Mucio Santos Moreira wrote: > Dear Wolfgang, > > Firstly thanks for your answer, secondly I have one more doubt, during this > time where the new Mupdate Master is receiving mailboxes information from > backend servers, is necessary stopping comunications between frontend > servers and mupdate master or none action is necessary besides that one > you've mentioned before? > We're concerned if frontend servers will connect to Mupdate Master and > receive from it an information which there's no mailboxes anymore until the > backend push entirely mailboxes information and this situation to cause any > trouble. I recommend the follow steps: *) check that your currently running setup has no conflicts in mailboxes.db by running "ctl_mboxlist -mw". It is possible that you see output if somebody changes his mailboxes while you run the command, but it should not appear again if you run the command a second time. If everything is fine... *) shut down all running cyrus frontends first, then backends and mupdate last *) backup your mailboxes.db on mupdate server *) replace/update mupdate and start it with empty/removed mailboxes.db. *) backup your mailboxes.db on the backends *) do the ctl_mboxlist -m by hand on the backends (only one at the same time) you can check if everything went ok with "-mw" at any time afterwards. *) start cyrus on backends In our setup the frontends have mupdate running as well. I can't currently remember if this is mandatory. If this is true in your setup then: *) remove or rename the mailboxes.db database on the frontends and start them. They will fetch the database immediately from the mupdate server. This is visible in syslog as well and takes about 30 seconds in our setup (~250MB mailboxes.db). otherwise *) start the frontends At this point everything should be up and running again. Watching syslog output all the time usually helps. IIRC we updated the mupdate server to 2.5 first. Then we had a mix of 2.4 and 2.5 backends for some time. The 2.5 backends had some capabilities suppressed. Frontends had 2.4 until all backends had 2.5. Last but not least we upgraded to 2.5 on the frontends. If you need more info/details feel free to ask. Greetings, Wolfgang -- Wolfgang Breyha | https://www.blafasel.at/ Vienna University Computer Center | Austria Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@nicbernstein.com https://www.nicbernstein.com https://www.linkedin.com/in/nic-b-26577a178/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: imap clients say i have 4K messages but spool has 12894 files
On 5/26/20 9:00 AM, Brian J. Murrell wrote: On Tue, 2020-05-26 at 08:47 -0500, Nic Bernstein wrote: |expunge_mode:| delayed The mode in which messages (and their corresponding cache entries) are expunged. “semidelayed” mode is the old behavior in which the message files are purged at the time of the EXPUNGE, but index and cache records are retained to facilitate QRESYNC. In “delayed” mode, which is the default since Cyrus 2.5.0, So this doesn't apply to my 2.4.17 then does it? Brian, My sincere apologies! I should have read your original post more completely. My bad. -nic As shown in this excerpt from the manpage < http://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html> ;, the default is now "delayed," since v2.5.0. Again, I am running 2.4.17, so does this apply? Those files on disk are expunged messages which have not yet been deleted. They may be recovered via the 'unexpunge' command, as described on its manpage, here < http://www.cyrusimap.org/imap/reference/manpages/systemcommands/unexpunge.html?highlight=unexpunge> ;. To see a list of such messages, try 'sudo -u cyrus -c "unexpunge -l user/usern...@domain.tld' # sudo -u cyrus bash -c "/usr/lib/cyrus-imapd/unexpunge -l user.brian" [nothing returned] b. -- Nic Bernstein n...@nicbernstein.com https://www.nicbernstein.com https://www.linkedin.com/in/nic-b-26577a178/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: imap clients say i have 4K messages but spool has 12894 files
On 5/26/20 8:33 AM, Brian J. Murrell wrote: Hi. Every IMAP client I query my cyrus imapd 2.4.17 server with says I have ~4K messages in my INBOX. However when I do a listing of /var/spool/imap/b/user/brian/ it shows almost 13K files. None of these include messages which have been deleted but not expunged. I manually expunge my mailbox many times per day. If I'm understanding mbexamine's output correctly, I have files on disk that are not being displayed by mbexmine. My understanding of mbexamine's output is that on a line formatted as such: 01> UID:00089183 INT_DATE:[redacted] SENTDATE:[redacted] SIZE:1537 that the 00089183 is the reference to the file on the spool in /var/spool/imap/b/user/brian/89183. Is that correct? If so, I definitely have files on the disk which are not found in any "01> UID" line from mbexamine. ~9600 of them. That seems to make up the difference between what an IMAP client sees and how many files are on disk. I also have multiple occurrences of the same "01> UID:" and where there are no matching files on the disk. Should that be possible? So how come the huge discrepancies and how do I reconcile them? Cheers, b. Brian, In a nutshell, RTFM. Or, read this mailing list, since the answer to this is literally exactly the same as to the very last question in this list. It's all about the setting of 'expunge_mode' in imapd.conf: |expunge_mode:| delayed The mode in which messages (and their corresponding cache entries) are expunged. “semidelayed” mode is the old behavior in which the message files are purged at the time of the EXPUNGE, but index and cache records are retained to facilitate QRESYNC. In “delayed” mode, which is the default since Cyrus 2.5.0, the message files are also retained, allowing unexpunge to rescue them. In “immediate” mode, both the message files and the index records are removed as soon as possible. In all cases, nothing will be finally purged until all other processes have closed the mailbox to ensure they never see data disappear under them. In “semidelayed” or “delayed” mode, a later run of “cyr_expire” will clean out the retained records (and possibly message files). This reduces the amount of I/O that takes place at the time of EXPUNGE and should result in greater responsiveness for the client, especially when expunging a large number of messages. Allowed values: /immediate/, /semidelayed/, /delayed/ As shown in this excerpt from the manpage <http://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html>, the default is now "delayed," since v2.5.0. Those files on disk are expunged messages which have not yet been deleted. They may be recovered via the 'unexpunge' command, as described on its manpage, here <http://www.cyrusimap.org/imap/reference/manpages/systemcommands/unexpunge.html?highlight=unexpunge>. To see a list of such messages, try 'sudo -u cyrus -c "unexpunge -l user/usern...@domain.tld' Cheers, -nic -- Nic Bernstein n...@nicbernstein.com https://www.nicbernstein.com https://www.linkedin.com/in/nic-b-26577a178/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Migrating calendars to Cyrus
On 2/21/20 5:09 AM, Andrea Venturoli wrote: Hello. I've been using CyrusIMAP for a long time, since before it supported CalDAV/CardDAV. At a site, I had installed DAVical, but I'd like to get rid of it, now that Cyrus can do what it does. I've migrated most calendars and I'm left with only one user, who, unfortunately, has more than 2k items in his calendar. Doing it via a client is a pain. Is there something like imapsync I can use? Andrea, Yes, there is something very much like imapsync that you can use, it's called sync-remote-caldav.php and it's in the 'scripts' directory of the Davical distribution. I used this to migrate from Davical to Cyrus, and it works like a charm. If you no longer have your Davical distribution directory, just download again. One thing about using this is that it uses relative paths to load parts of the davical library, so you need to run it from within the operational davical location. Good luck! -nic -- Nic Bernstein n...@nicbernstein.com https://www.nicbernstein.com https://www.linkedin.com/in/nic-b-26577a178/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Fwd: Help putting cyrus on Docker
ipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page:http://www.cyrusimap.org/ List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@nicbernstein.com mobile: +1 414 807 1734 snail: N Astor St Apt A5, Milwaukee, WI 53202-3319 https://www.nicbernstein.com https://www.linkedin.com/in/nic-b-26577a178/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Question for upgrading
On 12/13/18 9:52 AM, Egoitz Aurrekoetxea wrote:
I was trying to upgrade part of our Cyrus imap installation,
concretely that one consisting in still 2.3. I was planning to set up
Cyrus 3.0. I have seen all works properly except for the unexpunge
command because as someone stated here, a reconstruct -V max was
needed.The problem is that this reconstruct command, takes ages and
I'm not able to keep the service offline so many time. So I have been
thinking in the following scenario :
Egoitz,
As long as you've followed all of the various steps needed to account
for version changes, as outlined in the Release Notes for /all/
intermediary releases, then the last step should be the updating of the
indexes. Rather than running "reconstruct -V max" on all mailboxes at
once, simply run it on subsets. We've done this on large installations
without ill effect. You can have the service on line during the
reconstruct, and, as you note, have most all functionality present.
We build a list of users (mboxlist.txt), and then run a cron job, during
off-peak hours, using the 'parallel' command like so (from 'crontab -e
-u cyrus'):
### ## Start a batch of recursive reconstruct jobs at 7PM and
discontinue ## at 6:53AM. 0 19 * * * parallel -j 5 --resume --joblog
/var/lib/imap/reconstruct.log cyrus reconstruct -G -V max -r -u {} <
/var/lib/imap/mboxlist.txt 53 06 * * * kill -TERM `ps ax | grep
[p]arallel | awk '{print $1}'`
Cheers,
-nic
--
Nic Bernstein n...@onlight.com
Onlight Inc. www.onlight.com
6525 W Bluemound Rd., Ste 24 v. 414.272.4477
Milwaukee, Wisconsin 53213-4073 f. 414.290.0335
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Simple replication question
On 11/15/18 2:16 AM, Zorg wrote: I ve one cyrus imap server I want to create a replicated one I have read the documentation but nothing explain how two start the first replication If my slave master is empty how can i synchronise them the first time Once you've got replication configured, simply follow the instructions in the Standard Operating Procedures for "Manual Replication" here: https://cyrusimap.org/imap/reference/admin/sop/replication.html?highlight=replication#manual-replication To be clear, the "sync_client" command is run on the replica master, The "sync_server" on the replica will be automatically started up by the 'cyr_master' process (may be called 'cyrmaster' or simply 'master', depending on version and distro). The arguments and options in the sample command will sync a given user, but you may use any of the various options to sync the entire mail store, or parts of it. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Sieve scripts execution for connected folders
Your use of the phrase "connected to all users" and, earlier, "connected
and subscribed", is confusing. Am I correct to assume you mean the
folder is "subscribed" by all users? There is no such thing asa
mailbox/folder being "connected" as a state. It may be subscribed or
not, it may be connected to, by a client, but "connected" is not a
static condition.
Cyrus can support shared seen state, but it's also not clear, from your
messages, if you want shared seen state, or don't want it? Just what are
you trying to achieve?
Also, which version of Cyrus are you using? Current is 3.0.8, historic
is 2.5.12, development is 3.1.X.
The rule with user sieve scripts is that they may only act on that
user's mailboxes, not on shared mailboxes which one is subscribed to.
If you want to have new messages in a shared mailbox show as new for
each user, separately, then you need to disable shared seen. This may
be done on the mailbox level, using the cyradm(8) command, with the
mboxcfg subcommand:
localhost>*info office*
{office}:
private:
check: NIL
checkperiod: NIL
comment: NIL
sort: NIL
specialuse: NIL
thread: NIL
expire: NIL
news2mail: NIL
sieve: NIL
squat: NIL
shared:
check: NIL
checkperiod: NIL
comment: NIL
sort: NIL
specialuse: NIL
thread: NIL
annotsize: 0
duplicatedeliver: false
expire: NIL
lastpop: NIL
lastupdate: 31-Jul-2018 09:59:20 -0500
news2mail: NIL
partition: default
pop3newuidl: true
pop3showafter: NIL
*sharedseen: false*
sieve: NIL
size: 4101
squat: NIL
synccrcs: 1118531081 0
uniqueid: 4c8f66f0-9f6a-4fa1-b8bf-547afa1ec5e8
localhost> mboxcfg office sharedseen true
localhost>*info office*
{office}:
private:
check: NIL
checkperiod: NIL
comment: NIL
sort: NIL
specialuse: NIL
thread: NIL
expire: NIL
news2mail: NIL
sieve: NIL
squat: NIL
shared:
check: NIL
checkperiod: NIL
comment: NIL
sort: NIL
specialuse: NIL
thread: NIL
annotsize: 0
duplicatedeliver: false
expire: NIL
lastpop: NIL
lastupdate: 9-Oct-2018 10:09:19 -0500
news2mail: NIL
partition: default
pop3newuidl: true
pop3showafter: NIL
*sharedseen: true*
sieve: NIL
size: 4101
squat: NIL
synccrcs: 1118531081 0
uniqueid: 4c8f66f0-9f6a-4fa1-b8bf-547afa1ec5e8
Is that what you're trying to achieve, changing the setting of Shared \Seen?
Cheers,
-nic
On 10/09/2018 12:16 PM, kvaps wrote:
Hi, thanks for quick answer,
Yes, I know about shared folder sieves, but I have aniother case:
Eg I have some users:
user/us...@example.org
user/us...@example.org
user/us...@example.org
and shared folder
shared/t...@example.org
This folder connected to all users and have no shared seen state.
I need to set seen flag automatically for user1, and keep second as unseen.
- kvaps
On Tue, Oct 9, 2018 at 1:08 PM Nic Bernstein wrote:
Kvaps,
It is unclear from your message just where this "shared folder" is
rooted and where your sieve scripts are. Do you mean a folder which is
outside of the "user" name space? If so, you cannot manage message
delivery to this folder via user sieve scripts, but must use global
sieve scripts instead.
Please see the documentation here:
https://www.cyrusimap.org/imap/reference/admin/sieve.html#sieve-scripts-in-shared-folders
I hope this is helpful information,
-nic
On 10/09/2018 11:57 AM, kvaps wrote:
Hello,
I have shared folder which connected and subscribed in my mailbox, it
is looks like normal subfolder., but my sieve scripts not handle mail
inside it.
I want to set seen flag for new messages inside this folder
automatically by sieve script.
Is it possible for configure sieve-script working for connected folders too?
- kvaps
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Nic Bernstein n...@onlight.com
Onlight Inc. www.onlight.com
6525 W Bluemound Rd., Ste 24 v. 414.272.4477
Milwaukee, Wisconsin 53213-4073 f. 414.290.0335
--
Nic Bernstein n...@onlight.com
Onlight Inc. www.onlight.com
6525 W Bluemound Rd., Ste 24 v. 414.272.4477
Milwaukee, Wisconsin 53213-4073 f. 414.290.0335
Cyrus Home Page: http://www.cyrusimap.org/
List
Re: Sieve scripts execution for connected folders
Kvaps, It is unclear from your message just where this "shared folder" is rooted and where your sieve scripts are. Do you mean a folder which is outside of the "user" name space? If so, you cannot manage message delivery to this folder via user sieve scripts, but must use global sieve scripts instead. Please see the documentation here: https://www.cyrusimap.org/imap/reference/admin/sieve.html#sieve-scripts-in-shared-folders I hope this is helpful information, -nic On 10/09/2018 11:57 AM, kvaps wrote: Hello, I have shared folder which connected and subscribed in my mailbox, it is looks like normal subfolder., but my sieve scripts not handle mail inside it. I want to set seen flag for new messages inside this folder automatically by sieve script. Is it possible for configure sieve-script working for connected folders too? - kvaps Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Is "reconstruct -V max..." needed when upgrading from 2.5.10 to 3.0.7?
;user.onlight", prefixlen=0, goodp=0x7fcbc16162c0 , cb=0x7fcbc1616390 , rock=0x7ffd75ae6820, tidptr=) at lib/cyrusdb_skiplist.c:1177 #6 0x7fcbc16141cd in mboxlist_find_category (rock=rock@entry=0x7ffd75ae6820, prefix=prefix@entry=0x7ffd75ae5fb0 "user.onlight", len=len@entry=0) at imap/mboxlist.c:2685 #7 0x7fcbc1614b2c in mboxlist_do_find (rock=rock@entry=0x7ffd75ae6820, patterns=patterns@entry=0x55c0894b26f0) at imap/mboxlist.c:2877 #8 0x7fcbc1619fe6 in mboxlist_findallmulti (namespace=, patterns=0x55c0894b26f0, isadmin=, userid=0x0, auth_state=, proc=, rock=0x7ffd75ae68e0) at imap/mboxlist.c:2942 #9 0x55c087d5a4bd in main (argc=2, argv=) at imap/cyrdump.c:119 I'll note, too, that the behavior of reconstruct, with regards to those low numbered UIDs, is totally inconsistent. Here's a re-run on the same mailbox, after re-rsyncing (with --delete option) from the original server: root@newmail:~# su cyrus -c "/usr/lib/cyrus/bin/reconstruct -V max user/onlight" user.onlight: update uniqueid from header (null) => 710a47ca47ebc676 user.onlight updating quota_mailbox_used: 10715 => 3910 user.onlight: updating exists 8 => 3 user.onlight: updating sync_crc 2250269913 => 1705867986 user/onlight Repacked user/onlight to version 13 root@newmail:~# ls -l /var/spool/cyrus/mail/I/user/onlight/ total 76 -rw--- 1 cyrus mail 2924 Mar 27 2008 1. -rw--- 1 cyrus mail 748 Mar 27 2008 2. -rw--- 1 cyrus mail 804 Jul 15 2008 3. -rw--- 1 cyrus mail 1137 Oct 2 2009 4. -rw--- 1 cyrus mail 1192 Apr 22 2012 5. -rw--- 1 cyrus mail 1423 Sep 19 2016 6. -rw--- 1 cyrus mail 1743 Dec 22 2016 7. -rw--- 2 cyrus mail 1357 Jun 1 2017 8. -rw--- 1 cyrus mail 744 Jun 1 2017 9. -rw--- 1 cyrus mail 336 Mar 1 2017 cyrus.annotations -rw--- 1 cyrus mail 10276 Jul 31 15:54 cyrus.cache -rw--- 1 cyrus mail 165 Feb 28 2017 cyrus.header -rw--- 1 cyrus mail 1064 Jul 31 16:16 cyrus.index drwx-- 2 cyrus mail 4096 Nov 30 2017 Drafts drwx-- 2 cyrus mail 4096 Nov 30 2017 Sent drwx-- 2 cyrus mail 4096 Nov 30 2017 Spam drwx-- 2 cyrus mail 4096 Nov 30 2017 Trash So now it's just ignoring UIDs 1-6, and claiming the mailbox has just 3 messages. Color me confused. Honestly, I am not sure how anyone is managing large upgrades from 2.5 to 3.0? Not being able to reliably bring the existing message store up to the necessary level is quite unsettling. Cheers, -nic Hope this helps, Regards, Savvas Karagiannidis On Tue, Jul 31, 2018 at 6:43 PM Nic Bernstein <mailto:n...@onlight.com>> wrote: Friends, I'm preparing for a couple of belated 2.5.X to 3.0.X upgrades, and have a question about how necessary it is to run "reconstruct -V max" on the mailstore. Both systems are currently running 2.5.10, and are already at index version 13. However, when performing "reconstruct -V max" on one, on a new 3.0.7 (with patches) system, I see this: root@newmail:~# /usr/lib/cyrus/bin/reconstruct -V max user/onlight user.onlight uid 1 rediscovered - appending user.onlight uid 2 rediscovered - appending user.onlight uid 3 rediscovered - appending user.onlight uid 4 rediscovered - appending user.onlight uid 5 rediscovered - appending user/onlight Repacked user/onlight to version 13 The last line can be ignored, as it's really a noop. The "rediscovered - appending" stuff is what catches my eye. However, once the reconstruct is complete, here's what the mailbox looks like: root@newmail:/var/spool/cyrus/mail/I/user/onlight# /usr/lib/cyrus/bin/cyrdump user/onlight Content-Type: multipart/related; boundary="dump-27466-1533049817-351841533" --dump-27466-1533049817-351841533 Content-Type: text/xml IMAP-Dump-Version: 0 imap://newmail.example.com/user.onlight <http://newmail.example.com/user.onlight> 0 15 *6 7 9 10 11 12 13 14 * ... Note that the doesn't list those low number UIDs which were listed in the reconstruct sequence. In other words, I think this all is harmless, but I'm not sure how much overhead it brings to the whole process. One of the servers has a total of 70GB of mail, so a complete reconstruct run only takes a short while. The other, however, has over 8TB scattered over >30 partitions. If I could avoid running reconstruct across that whole wad, it'd be great. Thoughts please? -nic -- Nic bernstein...@onlight.com <mailto:n...@onlight.com> Onlight, Inc.www.onlight.com <http://www.onlight.com> 6525 W Blue
Is "reconstruct -V max..." needed when upgrading from 2.5.10 to 3.0.7?
Friends, I'm preparing for a couple of belated 2.5.X to 3.0.X upgrades, and have a question about how necessary it is to run "reconstruct -V max" on the mailstore. Both systems are currently running 2.5.10, and are already at index version 13. However, when performing "reconstruct -V max" on one, on a new 3.0.7 (with patches) system, I see this: root@newmail:~# /usr/lib/cyrus/bin/reconstruct -V max user/onlight user.onlight uid 1 rediscovered - appending user.onlight uid 2 rediscovered - appending user.onlight uid 3 rediscovered - appending user.onlight uid 4 rediscovered - appending user.onlight uid 5 rediscovered - appending user/onlight Repacked user/onlight to version 13 The last line can be ignored, as it's really a noop. The "rediscovered - appending" stuff is what catches my eye. However, once the reconstruct is complete, here's what the mailbox looks like: root@newmail:/var/spool/cyrus/mail/I/user/onlight# /usr/lib/cyrus/bin/cyrdump user/onlight Content-Type: multipart/related; boundary="dump-27466-1533049817-351841533" --dump-27466-1533049817-351841533 Content-Type: text/xml IMAP-Dump-Version: 0 imap://newmail.example.com/user.onlight 0 15 *6 7 9 10 11 12 13 14 * ... Note that the doesn't list those low number UIDs which were listed in the reconstruct sequence. In other words, I think this all is harmless, but I'm not sure how much overhead it brings to the whole process. One of the servers has a total of 70GB of mail, so a complete reconstruct run only takes a short while. The other, however, has over 8TB scattered over >30 partitions. If I could avoid running reconstruct across that whole wad, it'd be great. Thoughts please? -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Monitoring cyrusimapd
On 06/19/2018 10:23 AM, Albert Shih wrote: Hi everyone, I would like to know what kind of monitoring you perform on a cyrus-imapd. Beside classic (check_imap, check_disk, check_cpu etc...) do you have any special thing to monitor about cyrus-imapd. For example do you launch any check on each database ? How can I check if the replication work fine ? We use the attached PHP plugin in Icinga to monitor the SNMP OIDs provided by Cyrus. I haven't tried this with the newer Prometheus-based system, but it works just fine on 2.5.X systems built with SNMP enabled: Usage: $argv[0] -H -C -s -p -c -w -h -t -d Required: -H [STRING|IP] Hostname or IP address -s Which service name to check: This may be any service defined in cyrus.conf on host being checked. For example: imap, imaps, pop3 lmtp. This is also used as a label for the results. * Note: To receive a list of services supported by host, use the special keyword 'list'. * Note: Services with special characters in their name, such as lmtp[v6], must be quoted; i.e. 'lmtp[v6]'. Options: -C STRING SNMP community string (defaults to `public'). -p Which property to report (and alarm) on (defaults to 'active'): * forks * active * connections ... Warning & critical thresholds are allowed (scalar or range) for all checks. This is primarily a process oriented check script. It's useful to keep an eye on how many of each service's processes are running versus the configured quantity. You may want to take a look at issue 1827 on GitHub in regards to SNMP on Cyrus: https://github.com/cyrusimap/cyrus-imapd/issues/1827 Please note that this plugin relies upon utils.php by Marcel Kühn & Doug Warner: http://doug.warner.fm/nagios-utilsphp-script-for-php-plugins.html Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Moving from cIMAP-2.3.16 to 3.0.5
James, Patrick is entirely correct. As explained in the man page for ctl_mboxlist(8) the "-f" flag is to specify an alternative input file (mailbox database) not an output file. Output is via standard out, and can redirected into the file of your choice, or piped to the new host, like so: $ sudo -u cyrus /usr/lib/cyrus-imapd/ctl_mboxlist -d | ssh -tt newhost.example.com sudo ctl_mboxlist -u Assuming you have the configuration directory specified in imapd.conf(5) on both systems, the right DB files should be used. Cheers, -nic On 05/12/2018 06:20 PM, Patrick Boutilier wrote: On 05/12/2018 06:03 PM, James B. Byrne via Info-cyrus wrote: I have used rsync to move our entire maill store from the old server to the new. I now I wish to move the contents of mailboxes.db from the old to the new. I have tried: sudo -u cyrus /usr/lib/cyrus-imapd/ctl_mboxlist -d -f /var/spool/imap/mailboxes.db.txt on the old followed by a transfer of /var/spool/imap/mailboxes.db.txt to the new followed by: sudo -u cyrus /usr/local/cyrus/sbin/ctl_mboxlist -u -f /var/spool/imap/mailboxes.db.txt on the new and all I get is a blank line and no indication in ps that the task is consuming any cpu. If I press I see this: line 1: no partition found line 2: no partition found line 3: no partition found . . . There is only one partition on both systems and it is '/var/spool/imap' on both. I have also tried the method suggested on the 3.0.6 documentation respecting upgrading and use rsync to move over mailboxes.db. In each case I cannot get reconstruct to run and upgrade or rebuild the mail store on the new service. # sudo -u cyrus /usr/local/cyrus/sbin/reconstruct -r -f -V * # I get an immediate empty return. I know that there exist physical mailboxes on the server that cyradm does not report. I know that these mailboxes exist on the old server and therefore I infer are present in mailboxess.db. How do I get the contents of the old mailboxes.db file into the new so that reconstruct will run? Pretty sure you are using -f incorrectly. Try this: sudo -u cyrus /usr/lib/cyrus-imapd/ctl_mboxlist -d > /var/spool/imap/mailboxes.db.txt on the old followed by a transfer of /var/spool/imap/mailboxes.db.txt to the new followed by: sudo -u cyrus /usr/local/cyrus/sbin/ctl_mboxlist -u < /var/spool/imap/mailboxes.db.txt on the new Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Un-Murdering Cyrus?
Friends, I've got a Cyrus installation, at a client with roughly a dozen locations around the UA, which started life about 20 years ago and was split into a murder -- 2 frontends, 1 backend, 1 mupdate master -- several years back. At the time of the split, there were plans to geographically distribute portions of the mailstore, via the murder. However, before that project got very far, the client decided to make the leap to higher bandwidth Internet feeds, and then to an MPLS network, so the impetus for the murder has really gone away. At this point, with an upgrade from 2.5.11 to 3.0.X imminent, it makes sense to un-murder (resurrect?) the systems. Is this possible? I'm assuming it would simply involve dumping the mailboxes.db, stripping out the murder-specific bits, and then reloading it. Is that correct? Or, given that there's only a single backend, is this even necessary; can I just use the mailboxes.db from the single backend? Here's what a typical user's mailboxes.db entries look like on the murder's mupdate master: user.onlight1 mailbox.example.com!default onlightlrswipkxtecda cyradmin lrswipkxtecda cyradminlrswipkxtecda user.onlight.Drafts 1 mailbox.example.com!default onlight lrswipkxtecda cyradminlrswipkxtecda user.onlight.Junk 1 mailbox.example.com!default onlight lrswipkxtecda cyradminlrswipkxtecda anyone p cyradmin lrswipkxtecda user.onlight.Sent 1 mailbox.example.com!default onlight lrswipkxtecda cyradminlrswipkxtecda user.onlight.Trash 1 mailbox.example.com!default onlight lrswipkxtecda cyradminlrswipkxtecda Here is the same excerpt from the backend's mailboxes.db: user.onlight0 default onlight lrswipkxtecda cyradmin lrswipkxtecda cyradminlrswipkxtecda user.onlight.Drafts 0 default onlight lrswipkxtecda cyradmin lrswipkxtecda user.onlight.Junk 0 default onlight lrswipkxtecda cyradmin lrswipkxtecda anyone p cyradminlrswipkxtecda user.onlight.Sent 0 default onlight lrswipkxtecda cyradmin lrswipkxtecda user.onlight.Trash 0 default onlight lrswipkxtecda cyradmin lrswipkxtecda And here's a similarly typical user's mailboxes.db entries from a non-murder setup of the same vintage: user.onlight0 default onlightlrswipcda cyradmin lrswipcda anyone p user.onlight.Drafts 0 default onlightlrswipcda cyradmin lrswipcda anyone p user.onlight.Sent 0 default onlightlrswipcda cyradmin lrswipcda anyone p user.onlight.Spam 0 default onlightlrswipcda cyradmin lrswipcda anyone p user.onlight.Trash 0 default onlightlrswipcda cyradmin lrswipcda anyone p So, ignoring the obvious differences in some of the ACLs, it looks to me like the backend's mailboxes.db is just fine, and is all I would need. Is this correct? In other words, all I really need to do is update the backend's cyrus.conf to reënable the various normal services, turn off the mupdatepush service, and Bob's your uncle, right? Please advise, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: IMAP-3.0.4
Please re-read the upgrade documentation: https://www.cyrusimap.org/imap/download/upgrade.html In particular, please consult section 5, which includes this warning: To check your entire system’s configuration you can use the conf-all action. This command takes all the system defaults, along with anything you have provided overrides for in your config files: cyr_info conf-all -C -M *Important config* options: |unixhierarchysep:| and |altnamespace:| defaults have changed in imapd.conf(5) <https://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html#std:cyrusman-imapd.conf%285%29>. Implications are outlined in the Note in User Namespace Mode <https://www.cyrusimap.org/imap/concepts/features/namespaces.html#imap-admin-namespaces-mode> and Switching the Alternative Namespace <https://www.cyrusimap.org/imap/reference/admin/sop/altnamespace.html#imap-switching-alt-namespace-mode>. Please also see “Sieve Scripts,” below. * unixhierarchysep: on * altnamespace: on Cheers, -nic On 03/08/2018 10:59 AM, James B. Byrne via Info-cyrus wrote: Using imapsync we are attempting to move our mail store from an Cyrus-IMAPd-2.3.16 running under CentOS-6.9 to a Cyrus-IMAPD-3.0.4 running under FreeBSD-11.1p6. In all instances we are using software as packaged by the respective distribution. On our existing system our user mailboxes are referenced using user.mailbox. On the new system we can create mailboxes with the same nomenclature (user.mailbox). However, when we try to transfer an existing mailbox to the new server via imapsync it does not use the existing mailbox given by user.mailbox. Instead, it seems to create on the target host a new mailbox called user/mailbox distinct from user.mailbox. My question is: What configuration issue is causing this discrepancy between expected (user.mailbox --> user.mailbox) and observed behaviour (user.mailbox --> user/mailbox)? The the non-default settings in imapd.conf on the target system are: syslog_prefix: CYRUS syslog_facility:MAIL admins: cyrus admin configdirectory:/var/imap partition-default: /var/spool/imap sieveusehomedir:false sievedir: /var/imap/sieve allowplaintext: true anyoneuseracl: true autocreate_inbox_folders: delivery|\ delivery.forwarding|\ delivery.imports|\ delivery.private|\ Drafts|\ Intray|\ Sent|\ Spamyes|\ Spamno|\ Trash autocreate_quota: 102400 autocreatequota_units: 1048576 autocreate_subscribe_folders: delivery|\ delivery.forwarding|\ delivery.imports|\ delivery.private|\ Drafts|\ Intray|\ Sent|\ Spamyes|\ Spamno|\ Trash client_timeout: 10 hashimapspool: 1 lmtp_downcase_rcpt: true lmtp_fuzzy_mailbox_match: true quotawarn: 5 sasl_mech_list: PLAIN sasl_pwcheck_method:saslauthd sendmail: /usr/sbin/sendmail tls_client_ca_file: /usr/local/etc/pki/tls/certs/ca-bundle.crt tls_server_cert: /usr/local/etc/pki/imapd/20160039.pem tls_server_key: /usr/local/etc/pki/imapd/20160039.key -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Impact of changing back "altnamespace"
On 03/02/2018 12:15 PM, Tom Plancon wrote: Hello, A week or so back I posted here about issues I was having with cyrus-imapd 2.3 after changing the "altnamespace" variable in imapd.conf to "yes" in order to set up shared mailboxes. It threw a monkey wrench into my server and caused a lot of problems for a couple of days Things have settled down but still some residual problems for users in their email clients, e.g. Inbox contents disappears or does not show recent mail. Also deleting hangs for a long time. I'm considering changing "altnamespace" back to "no" hoping it will clear up those issues. Any thoughts as to what I can expect if I do this? All input is appreciated! Thanks! If you do this, you'll need to revert your sieve scripts, if any, to be compatible with the old setting. After updating the settings in /etc/imapd.conf, you should to run the 'translatesieve' Perl script (in the /tools directory) like so: $ //translatesieve -u -a As explained in the man page, you should first use "Dry Run" mode, via the "-n" flag, to see what would be changed. Prior to use, you may wish to save backups of your sieve scripts. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Initial use of Xapian
On 02/14/2018 11:04 AM, Per olof Ljungmark wrote: Quoting Nic Bernstein <n...@onlight.com>: On 02/14/2018 10:35 AM, Lists Nethead wrote: Quoting Nic Bernstein <n...@onlight.com>: The advice to move it to START is actually based on a recently discovered bug, referred to in that issue report (#2234). It /should/ be in DAEMON, but for that bug, which has been fixed. The fix will be in the next release. In general, the mailing is a grand place to start, and IRC is also your friend (#cyrus on freenode). Cheers, -nic On 02/14/2018 04:58 AM, Lists Nethead wrote: Quoting Sebastian Hagedorn <haged...@uni-koeln.de>: --On 14. Februar 2018 um 11:13:15 +0100 Lists Nethead <li...@nethead.se> wrote: I am testing Xapian in a 3.0.5 setup on FreeBSD using most default setting. If I start imapd with "squatter cmd="squatter -R", more and more "squatter" processes are created and eventually grabs all resources. Where did you put that statement? You can't put it in the DAEMON section with 3.0.5. Put it in START instead. See this issue for more information: <https://github.com/cyrusimap/cyrus-imapd/issues/2234> A-ha. So it is better to look at Github instead of the mailing list apparently. https://www.cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html still advises DAEMON, that is why it ended up there. Thanks to the advise above and I believe I got it working now. One more thing though, if replication is involved, it appears one needs one log for squatter and another for replication, am I correct? I got replication to work only after I added another log, like, sync_log_channels: squatter replog and syncclient cmd="/usr/local/cyrus/sbin/sync_client -r -n replog" Not sure if this is mentioned in the docs somewhere. Cheers, //per In general, for each consumer of a sync_log, a new log should be defined in `sync_log_channels:`. I use the word "consumer" there intentionally, as the processes which use these logs actually consume them, and leave nothing behind (assuming it all works as expected). So if more than one process tries to eat up the same log, you'll have problems. The overloading of the sync_log framework for purposes beyond replication is new in 3.0, so we're still getting the documentation up to snuff in that regard. However, the documentation already makes this concept clear in that when using more than one replica you need to specify more than one sync_log via the `sync_log_channels:` directive (see https://www.cyrusimap.org/imap/reference/admin/sop/replication.html#channels for details). We obviously do need to produce more generalized documentation for this whole scheme, and I'll be using this discussion as a guide in that regard. sync_log, as the name implies, started life as a way for the "master" server to provide a list of "units" -- either users or mailboxes -- it has touched, so that a replica knows what to request in updates. This is such a useful concept, however, that it is spreading to other subsystems which need to know what might have changed in a potentially large data set (the typical mail store) and so we need to explain this not just in the Replication documentation, but in a more general way. Note also that there is a `sync_log_unsuppressable_channels:` directive, which defaults to "squatter". This is defined as: If specified, the named channels are exempt from the effect of setting sync_log_chain:off, i.e. they are always logged to by the sync_server process. This is only really useful to allow rolling search indexing on a replica. If you are going to use a name other than "squatter" for your rolling indexing sync_log channel, then you need to update this as well. Nic, thank you for the clarification, it makes real sense. I do understand that managing a project like this is quite a task and v.3 is still young. Apart from the log issue and xapian I also stumbled over other undocumented changes related to FreeBSD only I think(?) in that binaries that before existed in bin/ are now separated into sbin/ and libexec/, meaning that your scripts will of course fail after the upgrade. I should produce a short writeup for the FreeBSD camp. Cheers, //per Per, I've created an issue #2248 for this on GitHub, and have just created PR #2249 which addresses it. Thanks for your feedback. As for the FreeBSD path changing issues, that's up to the package creator. Please let them know. Cheers, -nic 1: https://github.com/cyrusimap/cyrus-imapd/issues/2248 2: https://github.com/cyrusimap/cyrus-imapd/pull/2249 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Initial use of Xapian
On 02/14/2018 10:35 AM, Lists Nethead wrote: Quoting Nic Bernstein <n...@onlight.com>: The advice to move it to START is actually based on a recently discovered bug, referred to in that issue report (#2234). It /should/ be in DAEMON, but for that bug, which has been fixed. The fix will be in the next release. In general, the mailing is a grand place to start, and IRC is also your friend (#cyrus on freenode). Cheers, -nic On 02/14/2018 04:58 AM, Lists Nethead wrote: Quoting Sebastian Hagedorn <haged...@uni-koeln.de>: --On 14. Februar 2018 um 11:13:15 +0100 Lists Nethead <li...@nethead.se> wrote: I am testing Xapian in a 3.0.5 setup on FreeBSD using most default setting. If I start imapd with "squatter cmd="squatter -R", more and more "squatter" processes are created and eventually grabs all resources. Where did you put that statement? You can't put it in the DAEMON section with 3.0.5. Put it in START instead. See this issue for more information: <https://github.com/cyrusimap/cyrus-imapd/issues/2234> A-ha. So it is better to look at Github instead of the mailing list apparently. https://www.cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html still advises DAEMON, that is why it ended up there. Thanks to the advise above and I believe I got it working now. One more thing though, if replication is involved, it appears one needs one log for squatter and another for replication, am I correct? I got replication to work only after I added another log, like, sync_log_channels: squatter replog and syncclient cmd="/usr/local/cyrus/sbin/sync_client -r -n replog" Not sure if this is mentioned in the docs somewhere. Cheers, //per In general, for each consumer of a sync_log, a new log should be defined in `sync_log_channels:`. I use the word "consumer" there intentionally, as the processes which use these logs actually consume them, and leave nothing behind (assuming it all works as expected). So if more than one process tries to eat up the same log, you'll have problems. The overloading of the sync_log framework for purposes beyond replication is new in 3.0, so we're still getting the documentation up to snuff in that regard. However, the documentation already makes this concept clear in that when using more than one replica you need to specify more than one sync_log via the `sync_log_channels:` directive (see https://www.cyrusimap.org/imap/reference/admin/sop/replication.html#channels for details). We obviously do need to produce more generalized documentation for this whole scheme, and I'll be using this discussion as a guide in that regard. sync_log, as the name implies, started life as a way for the "master" server to provide a list of "units" -- either users or mailboxes -- it has touched, so that a replica knows what to request in updates. This is such a useful concept, however, that it is spreading to other subsystems which need to know what might have changed in a potentially large data set (the typical mail store) and so we need to explain this not just in the Replication documentation, but in a more general way. Note also that there is a `sync_log_unsuppressable_channels:` directive, which defaults to "squatter". This is defined as: If specified, the named channels are exempt from the effect of setting sync_log_chain:off, i.e. they are always logged to by the sync_server process. This is only really useful to allow rolling search indexing on a replica. If you are going to use a name other than "squatter" for your rolling indexing sync_log channel, then you need to update this as well. Cheers, -nic <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Initial use of Xapian
The advice to move it to START is actually based on a recently discovered bug, referred to in that issue report (#2234). It /should/ be in DAEMON, but for that bug, which has been fixed. The fix will be in the next release. In general, the mailing is a grand place to start, and IRC is also your friend (#cyrus on freenode). Cheers, -nic On 02/14/2018 04:58 AM, Lists Nethead wrote: Quoting Sebastian Hagedorn <haged...@uni-koeln.de>: --On 14. Februar 2018 um 11:13:15 +0100 Lists Nethead <li...@nethead.se> wrote: I am testing Xapian in a 3.0.5 setup on FreeBSD using most default setting. If I start imapd with "squatter cmd="squatter -R", more and more "squatter" processes are created and eventually grabs all resources. Where did you put that statement? You can't put it in the DAEMON section with 3.0.5. Put it in START instead. See this issue for more information: <https://github.com/cyrusimap/cyrus-imapd/issues/2234> A-ha. So it is better to look at Github instead of the mailing list apparently. https://www.cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html still advises DAEMON, that is why it ended up there. Thanks, Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Why Cyrus?
On 01/19/2018 05:29 AM, Patrick Goetz wrote: The biggest ongoing problem with Cyrus is the documentation, not that it's harder to install. Cyrus is, if anything, easier to install than Dovecot (modulo distro packaging, which is the main difference here). The Dovecot guy writes very good documentation, and until recently trying to get information about how to set up Cyrus was like pulling teeth. I'm always having to appeal to this list whenever an issue comes up. Recently I set up a vacation notification system. Super easy AFTER A MONTH SPENT researching how to do it. I'm still not completely clear on how to set up multiple virtual mailhosts, either; my next onerous email research project. FastMail of course has no incentive or reason to write documentation making it easier to set up your own Cyrus system(s); that's going to be up to the community. I'm sorry, and don't wish to start a flame war here, but can't just let this comment pass. Fastmail are dedicated to improving the documentation of Cyrus, and have on staff a person, Nicola Nye <nico...@fastmailteam.com>, for that specific reason. They've spent a bundle of money to improve the documentation, as have other organizations like Kolab <https://kolabsystems.com/> and Onlight <https://www.onlight.com/> (my firm). Last year Onlight flew me to Melbourne for two weeks, to set up camp in the Fastmail offices and write documentation. While I will agree that improvement is still needed, a remarkable amount has been done in the past few years. It's the nature of almost all Open Source packages that documentation often lags behind features, unless the docs and code are being written by the same people. Another issue common to many FOSS software is that people write documentation which addresses needs they perceive, just like people write software which addresses needs they perceive. For example, I recently needed to migrate older Cyrus installations from 2.5.11 to 3.0.5, and to add Xapian indexing. I couldn't make sense of the existing docs, so I interrogated Bron and others, and rewrote those docs, along with touching up other sections which dealt with the various supported partitioning types. Cyrus is a very capable and scalable email platform, provides a lot of flexibility and supports a lot of options. This necessarily makes it more complex to configure, and more complex to document. My advice to anyone who is having trouble understanding or deploying a feature is to come here or to the cyrus-dev list, and ask questions: https://cyrusimap.org/imap/support/feedback-mailing-lists.html If you need to know how to do something and feel it isn't well documented, ask in the lists, on IRC, or log a ticket at Github. Seriously on that last one. If you log an issue on Github, it will get seen to, by myself or others. https://github.com/cyrusimap/cyrus-imapd/issues As for your next challenge, the term "virtual mailhosts" is a bit vague, so I'm not sure which way to steer you. Do you mean Virtual Domains; one server receiving and hosting mail for multiple email domains? If so, start here: https://cyrusimap.org/imap/concepts/features/virtual-domains.html?highlight=virtual If you mean something else, please follow up with a separate message on this list or IRC (https://cyrusimap.org/imap/support/feedback-irc.html). Lastly, I would remiss not to mention that we will always welcome user contributions to the documentation. If you feel you solved an undocumented, or poorly documented problem, please let us know what you did, what you learnt, how you solved the issue. If you can even just write up an email description of the problem and solution, we can shape it into documentation. Often the best documentation evolves out of a user solving a problem and then sharing their new knowledge. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyrus + roundcube + managesieve for vacation notification
On 12/15/2017 07:38 AM, Vladislav Kurz wrote: On 12/15/17 12:57, Patrick Goetz wrote: Many thanks to Vladislav and Merlin for setting me in the right direction for setting up user-activated vacation notifications. A couple of follow up questions: On 12/14/2017 03:31 AM, Vladislav Kurz wrote: Also, is there anything special I need to do with my cyrus configuration to allow for roundcube to notify imapd about sieve rules being activated/deactivated? Just uncomment the sieve line in cyrus.conf Following the documentation here: https://www.cyrusimap.org/imap/reference/admin/sieve.html it looks like I also need to add a managesieve line to /etc/cyrus/cyrus.conf? sieve cmd="timsieved" listen="servername:sieve" prefork=0 managesieve cmd="timsieved" listen="servername:4190" prefork=0 Is this correct, or am I doing some superfluous? I enabled managesieve and roundcube is talking to the sieve server, but didn't test without. Hello Patrick, these lines look like the same. Sieve port is 4190, and the first item is IMHO just a name. Just keep the first one. Actually, these may not be the same, depending on the contents of /etc/services for the "sieve" service. This used to be 2000, prior to standardization in RFC5804. So, if your /etc/services lists 4190, then get rid of the duplicate line. The fact that Cyrus starts with both lines defined makes me think that either sieve isn't listed in /etc/services (which should have resulted in an error) or that it isn't 4190, since one cannot have two services defined for the same listen port. Since this is our first time using sieve, I haven't worried about this too much until now, but roundcube+managesieve seems to be concerned about the location of global sieve scripts: // default contents of filters script (eg. default spam filter) // $config['managesieve_default'] = '/etc/dovecot/sieve/global'; $config['managesieve_default'] = '/var/imap/sieve'; There is nothing like global sieve script in cyrus (at least I did not find a way how to do it.) There is. Please see the documentation here: https://www.cyrusimap.org/imap/reference/admin/sieve.html#sieve-scripts-in-shared-folders Quoting: Cyrus has two types of repositories where Sieve scripts can live: 1. *Personal* is per user and 2. *Global* is for every user. Global scripts aren’t applied on incoming messages by default: users must include them in their scripts. * Note that there are two types of Global scripts: *global* and *global per domain*. Cheers, -nic The option above is path to a default script (file, not folder) that will be applied to the user upon first login to roundcube. I use it as a template for users with some recommended settings or disabled examples. I usually put it into /etc/roundcube/roundcube.script, but you can put it almost anywhere. (perhaps somewhere in document_root for roundcube is also fine). Do not rely on it as default. It is applied only if the user does not have a sieve script yet. After that users are free to modify it. If someone does not use roundcube at all, he will not get that script applied. -- Nic bernstein...@onlight.com Onlight Inc.www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Adding archiving to an existing Cyrus installation
Bron,
Thanks for the response. Your solution has pointed us towards the
proper approach. We are using ZFS, so would be performing ZFS
send/receive replication rather than "mv", to move the filesystems. Our
typical approach for this sort of thing, then, would be:
* Create a filesystem snapshot
o zfs snapshot $ropt ${SOURCE_FS}@$newsnap
* Perform ZFS send/receive, something like this:
o zfs send -p $SENDVERBOSE $cloneorigin@$sourcestartsnap | zfs
recv -u $RECVVERBOSE -F "$destfs"
* Then, once we've completed a replication, we need to quiesce the
filesystem and do the same, again, to catch-up to current state
* Finally, replace the existing filesystem with the new replica, and
discard the original
To quiesce the filesystem, we would normally like to tell whatever
applications are using it to temporarily freeze operations, so the
underlying filesystem is in a consistent state. When I was in
Melbourne, back in April, we (you, Ellie & I) discussed what would be
needed to introduce such a feature to Cyrus. I'm curious if there's
been any further discussion or work on this? Should I open a feature
request?
It would be nice to be able to complete consistent snapshots for
filesystem operations like replication or backup, and this is a feature
of many large applications, such as mail and DB servers.
Thanks again for shining a welcome light on how to achieve the goal of
adding archive to an existing system.
Cheers,
-nic
On 11/04/2017 10:59 PM, Bron Gondwana wrote:
Hi Nic,
Sorry I didn't get back to answering you on this the other day!
So... this one is kinda tricky, because everything is going to be on
"spool", but here's how I would do it.
Before:
/mnt/smalldisk/conf -> meta files only
/mnt/bigdisk/spool -> all email right now
Stage 1: splitting:
/mnt/smalldisk/conf
/mnt/bigdisk/spool
/mnt/bigdisk/spool-archive -> empty
And set archivepartition-default to /mnt/bigdisk/spoolarchive
Now you need to run an initial cyr_expire. This will take a long
time, but it should be able to use hardlinks to move the files - it's
using cyrus_copyfile.
Once cyr_expire has finished an most of your email is moved into
spool-archive, shut down cyrus.
mv /mnt/bigdisk/spool /mnt/smalldisk/spool
And set partition-default to /mnt/smalldisk/spool
That way your downtime is only while the small remaining spool gets
moved to the other disk.
Bron.
On Sun, 5 Nov 2017, at 02:58, Nic Bernstein wrote:
Thanks much to you both for your comments and suggestions. We had
already considered creating a temporary "staging" partition and
shuffling mailboxes around, as Michael discussed, but have the same
reservations about it. Since we're dealing with nearly 6TB of data,
most of it old, this scheme would introduce considerable disruption to a
very active mail system. We have a hard time getting a two hour
maintenance window, and this would take days!
Bron, other Fastmailers, any thoughts??
-nic
On 11/03/2017 11:20 AM, Michael Menge wrote:
Hi,
Quoting Reinaldo Gil Lima de Carvalho <reinal...@gmail.com
<mailto:reinal...@gmail.com>>:
I think that singleinstancestore (message hard links) will not
survive when
moving from one partition to the other and storage total size
will
increase
significantly.
thanks for the hint. This was not a problem while migration to the
meta-data partition,
as the mails stayed on the same partition (as in file-system and not
cyrus-partition)
and only hardlinks where change at all.
So one more reason for an other migration path.
2017-11-03 12:22 GMT-03:00 Michael Menge
<michael.me...@zdv.uni-tuebingen.de
<mailto:michael.me...@zdv.uni-tuebingen.de>
:
Hi Nic,
Quoting Nic Bernstein <n...@onlight.com
<mailto:n...@onlight.com>>:
Friends,
I have a client with Cyrus 2.5.10 installed. Last
year we migrated
their
old 2.3.18 system to 2.5.10, with an eye towards an
eventual move to
3.0.x. Based on Bron's most excellent email of last
year,
([Subject: Cyrus
database and file usage data] from Cyrus Devel of 8
January 2016)
we used a
tiered layout for the storage:
The main categories are:
* Config directory (ssd) [/var/lib/imap]
o sieve
o seen
o sub
o quota
o mailboxes.db
o annotations.db
* Ephemeral [/var/run/cyrus -- in tmpfs]
o tls_sessions.db
o deliver.db
Re: Adding archiving to an existing Cyrus installation
Thanks much to you both for your comments and suggestions. We had already considered creating a temporary "staging" partition and shuffling mailboxes around, as Michael discussed, but have the same reservations about it. Since we're dealing with nearly 6TB of data, most of it old, this scheme would introduce considerable disruption to a very active mail system. We have a hard time getting a two hour maintenance window, and this would take days! Bron, other Fastmailers, any thoughts?? -nic On 11/03/2017 11:20 AM, Michael Menge wrote: Hi, Quoting Reinaldo Gil Lima de Carvalho <reinal...@gmail.com>: I think that singleinstancestore (message hard links) will not survive when moving from one partition to the other and storage total size will increase significantly. thanks for the hint. This was not a problem while migration to the meta-data partition, as the mails stayed on the same partition (as in file-system and not cyrus-partition) and only hardlinks where change at all. So one more reason for an other migration path. 2017-11-03 12:22 GMT-03:00 Michael Menge <michael.me...@zdv.uni-tuebingen.de : Hi Nic, Quoting Nic Bernstein <n...@onlight.com>: Friends, I have a client with Cyrus 2.5.10 installed. Last year we migrated their old 2.3.18 system to 2.5.10, with an eye towards an eventual move to 3.0.x. Based on Bron's most excellent email of last year, ([Subject: Cyrus database and file usage data] from Cyrus Devel of 8 January 2016) we used a tiered layout for the storage: The main categories are: * Config directory (ssd) [/var/lib/imap] o sieve o seen o sub o quota o mailboxes.db o annotations.db * Ephemeral [/var/run/cyrus -- in tmpfs] o tls_sessions.db o deliver.db o statuscache.db o proc (directory) o lock (directory) * Mailbox data [typical 2.5.X usage] o Meta-data (ssd) + header + index + cache + expunge + squat (search index) + annotations o Spool data (disk: raidX) + messages (rfc822 blobs) We sized the Fast SSD pool (this is three-drive mirrors on ZFS) to be extra large, so it could eventually handle "Hot" data, and left about 300GB free there. Data, on spinning media, is currently 5.74TB with 4.8TB free (RAID10). Metadata is 35GB and /var/lib/imap is 8GB, all of which is in the Fast pool. Now the client is ready to take the dive into v3.0, and I'm trying to figure out how to put "archive" operation in effect. I have read the documentation (hell, I wrote most of it) and understand the settings, but what I cannot quite wrap my brain around is this: There is already all of this data sitting in all of these data partitions (we use a total of 34 separate partitions each for data & metadata) so how do I make the transition to separate archive partitions, since all that data is on the "slow" drives? Can I just reassign all of the current data partitions to archivedata partitions, define the new set of "Hot" data partitions on the Fast pool, and let 'er rip, or what? I promise, if you tell me, I'll write it up as real documentation. :-) We are interested in such a migration too. Our fallback plan, if we don't find a better way to do it is, do use the same method as we introduced the ssd meta-data partition. 1. We created a new partition in our cyrus configuration, 2. we moved moved the accounts from one partition to the other one by one. 3. (this will be new for the archive partition) run cyrus expire to move the old mails back to the slow disks. This method will have two downsides. 1. we have to copy all mails to the fast storage, and move the old mails back to the slow storage. So we have to move most of the mails twice. 2. the path of the old mail will change so they will be stored again in our file based backup so a method without these downsides will be appreciated Regards Michael M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/piper
Adding archiving to an existing Cyrus installation
Friends, I have a client with Cyrus 2.5.10 installed. Last year we migrated their old 2.3.18 system to 2.5.10, with an eye towards an eventual move to 3.0.x. Based on Bron's most excellent email of last year, ([Subject: Cyrus database and file usage data] from Cyrus Devel of 8 January 2016) we used a tiered layout for the storage: The main categories are: * Config directory (ssd) [/var/lib/imap] o sieve o seen o sub o quota o mailboxes.db o annotations.db * Ephemeral [/var/run/cyrus -- in tmpfs] o tls_sessions.db o deliver.db o statuscache.db o proc (directory) o lock (directory) * Mailbox data [typical 2.5.X usage] o Meta-data (ssd) + header + index + cache + expunge + squat (search index) + annotations o Spool data (disk: raidX) + messages (rfc822 blobs) We sized the Fast SSD pool (this is three-drive mirrors on ZFS) to be extra large, so it could eventually handle "Hot" data, and left about 300GB free there. Data, on spinning media, is currently 5.74TB with 4.8TB free (RAID10). Metadata is 35GB and /var/lib/imap is 8GB, all of which is in the Fast pool. Now the client is ready to take the dive into v3.0, and I'm trying to figure out how to put "archive" operation in effect. I have read the documentation (hell, I wrote most of it) and understand the settings, but what I cannot quite wrap my brain around is this: There is already all of this data sitting in all of these data partitions (we use a total of 34 separate partitions each for data & metadata) so how do I make the transition to separate archive partitions, since all that data is on the "slow" drives? Can I just reassign all of the current data partitions to archivedata partitions, define the new set of "Hot" data partitions on the Fast pool, and let 'er rip, or what? I promise, if you tell me, I'll write it up as real documentation. :-) Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: About upgrade and building without caldav/carddav server
Egoitz, Some important notes on this upgrade. Firstly, I have followed this path for a client, and it does work. Secondly, you should read not just the Upgrade document to which Nicola has linked (below) but also read the release notes for all intermediary versions. You can find those here: https://www.cyrusimap.org/imap/download/release-notes/index.html It's always best practice to read intermediary release notes, as changes made in one version (i.e. 2.4.0) may not be mentioned in a later version's release notes. For example, the release notes for 2.4.0 contain this note: * All databases are now default skiplist, and ctl_cyrusdb will automatically convert database type on startup. That's a really good thing, but if you previously set your database types to something other than the default, then they will not be converted (maybe you didn't do so, but your packages may have). As the Upgrade document notes, in that case you should convert your DB formats to a default /before/ you copy them to the new server, using cvt_cyrusdb (for example): cvt_cyrusdb //mailboxes.db berkeley /tmp/new-mailboxes.db skiplist Another big note is that with 3.0.X, the Squat full-text indexing engine may be replaced with Xapian. Check your packaging or build for that. If it is, you'll need to rebuild your indexes before people can use them. Similarly, the main Cyrus index scheme has changed between 2.3 and 2.4, and then again with 2.5 and 3.0. You can upgrade from 2.3 to 3.0, and it does so very nicely, but while a 3.0 server can read the older index formats, you won't get the best behavior or performance. Run the command 'reconstruct -V max' either just like that (upgrade all mailbox's indices) or within a script which walks through your user list. Lastly, please get yourself logged in to #cyrus on IRC so you can get support while you're working. Try a dry run with just a couple of users or mailboxes, to see what you might face, and don't be afraid to ask for help. I've been working with Cyrus for twenty years, and I still ask for help all the time (just ask the folks on this list!). :-) Cheers, -nic On 06/27/2017 06:36 PM, Nicola Nye wrote: By the way, when upgrading from a 2.3.1X server... can you directly install a 3.0 in the server and should it work?. Is it recommended to perhaps go thought the 2.5 version, reconvert databases to suit it's needs (the 2.5 needs) and later pass to 3.0?. I have no experience with upgrading from 2.3 to 3.0, so can't help you with that. When writing the Upgrade documentation (https://www.cyrusimap.org/imap/download/upgrade.html) we did discuss whether you had to go through intermediate versions on the way to 3.0, and the answer is a 'no'! You should be able to go from 2.3 to 3.0 in one hit. As always, make sure you have backups of your data before you begin the upgrade. Let us know how it goes! Nicola Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Problems with cyrus 2.5.10 after system update
On 05/17/2017 10:54 AM, Patrick Goetz wrote: Follow up question: The package maintainer for the Arch cyrus-imapd package has fallen behind and my users need to be able to access their mail, so as a temporary work around I'm just going to build/compile cyrus 3.0.1 from source. I asked about some of this before, but will my 2.5.10 configuration files work as is, or have the key values changed again? Also, the new default is skiplist2, and I'm on skiplist. Is this going to be like a previous upgrade where the Berkeley DB files were automatically converted to skiplists? Please consult the Upgrade documentation at: http://cyrusimap.org/imap/download/upgrade.html There are specific mentions therein as to changes in the configuration files. Also, please see the man page for the cyr_info(8) tool, which offers a lint option: http://cyrusimap.org/imap/reference/manpages/systemcommands/cyr_info.html *cyr_info* /conf-lint/ Lint the configuration for unrecognized settings. duplicate_mailbox_mode: uniqueid archivepartition-default: /var/spool/cyrus/spool-archive rudolf_sync_host: 10.202.79.15 prancer_sync_host: 10.206.51.80 user_folder_limit: 5000 An example of changes you'll find are the various autocreate settings. Many of these were only in vendor patches in earlier versions, but are now standardized. See the man page for imapd.conf(5): http://cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html For example: |autocreateinboxfolders:| Deprecated in favor of /autocreate_inbox_folders/. |autocreatequota:| 0 Deprecated in favor of /autocreate_quota/. |autocreatequotamsg:| -1 Deprecated in favor of /autocreate_quota_messages/. |autosievefolders:| Deprecated in favor of /autocreate_sieve_folders/. A search for "Deprecated" in that man page should prove instructive. Cheers, -nic <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: recovery from complete loss of mailboxes.db?
Patrick, I don't have all of your answers here, but I do have some, interspersed in your message.. On 04/29/2017 02:41 PM, Patrick Goetz wrote: Hi - I'm assembling some system documentation for a client and have been pouring over my cyrus notes and looking at the man pages. A couple of questions, starting with the simple one. annotations.db: "This database contains mailbox and server annotations." I still have no idea what this is used for. Can someone give me an example of a mailbox or server annotation. Annotations are basically metadata which can be associated with different objects: Server, Mailbox and Message. There is a list of supported annotations in the old FAQs: http://cyrusimap.org/imap/reference/faqs/o-annotations.html?highlight=annotations This is less than ideal, we know, but as noted on the skeletal Annotation documentation pages, the documentation is a work in progress. To see how to apply annotations, see the manpage for cyradm(8). Next: Suppose I've completely lost /var/imap/mailboxes.db as well as /var/imap/db.backup1 and /var/imap/db.backup2. Is there any way to recover from this? Given that /usr/lib/cyrus/bin/reconstruct -r -f user/userN will add missing mailfolders to mailboxes.db, can I reconstruct mailboxes.db by simply iterating over all mailbox directories? # cd /srv/imap/user # for i in $(ls) # /usr/lib/cyrus/bin/reconstruct -r -f user/$i # done ? While this will work, after a fashion, you may also end up restoring data which was already deleted in the prior state, depending upon Delayed Expunge and Delayed Delete settings. Also, your use of 'ls' in that example may be less than ideal in a server with lots of mailboxes. So, 'find' may be more friendly here. Finally a note on the documentation: On this page: https://cyrusimap.org/imap/reference/faqs/o-reconstruct.html one finds the following comment: "If you do find yourself with a corrupted mailboxes.db, there are a few things you can try. The first is to see if db_recover can recover your database." However, there is no db_recover listed under Tools & Utilities here: https://cyrusimap.org/ /usr/bin/db_recover is installed on my system, so it exists, but there isn't a man page for it, either, leading to wonder how one is supposed to know what the syntax is for this command. The 'db_recover' command is a Berkeley DB command, not a Cyrus command, which is why we don't include a man page for it. If all of your DBs are Skiplist, as you state below, then db_recover is not going to be of any use. For the record, the "o-" prefix on those FAQs is there to indicate "Old." While Cyrus once required Berkeley DB, it now actively discourages it. I guess that wasn't actually the final question. I'm currently running version 2.5.10 and am thinking about upgrading to 3.0.1. The default db format appears to be Twoskip, and I'm pretty sure that all my db files are Skiplists. Is this going to be like the Berkeley DB to Skiplist thing when upgrading from 2.2 to 2.4, where all the Berkeley DB databases were automatically converted to Skiplists, or does a conversion to Twoskip require some manual intervention? Check the Upgrade docs for this. There's a note in there about DB conversions. http://cyrusimap.org/imap/download/upgrade.html Cheers, -nic Thanks in advance. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Sieve RFC5490 checks user quota usage
Paolo, Attached is the script we've been using for ages for this purpose. Our uses LDAP as a source of user ID information, but it could be easily adapted for other AAA databases. Cheers, -nic On 03/21/2017 10:59 AM, Paolo Cravero wrote: And for Nic, yes, I mean the "IMAP STORAGE quota". I would like to warn the user that his quota is about to fill up through an email, triggered on new mail arrival or login. Why? Because not all clients support reading the quota over IMAP or handling an alert (think of some smartphone IMAP client or an (active)sync system). Is there a way to achieve the same result somehow, with stock cyrus? -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 quota-report.sh Description: application/shellscript <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Sieve RFC5490 checks user quota usage
Paolo, Please clarify; when you say "disk quota," do you mean a filesystem level quota, or do you really mean IMAP STORAGE quota, as administered through Cyrus? -nic On 03/17/2017 10:01 AM, Paolo Cravero wrote: Hello. I am trying to figure out if sieve, with RFC5490 support, is able to read user's disk quota (used) and act accordingly. I would like to trigger a mail to "self" if quota is above a given percent. Something like a vacation message (so once a day or so), triggered on arrival AND if quota is above X %. If sieve doesn't support this, is there another way to do it? Thanks and have a nice weekend, Paolo Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: What happened to normalizeuid?
The "normalize" patch included by Debian isn't that far off from what the option "usercase_tolower" already offers: username_tolower (*on*|off) Convert usernames to all lowercase before login/authentication. This is useful with authentication backends which ignore case during username lookups (such as LDAP). Here's what the Debian patch (0013-Normalize-the-authentication-ID.patch) says: By normalize, it is intended that; 1) Authentication IDs all can be lowercased for more accurate comparison without being volatile to, say, user error, and 2) Any leading or trailing blank space can be stripped And then they go on to patch, mostly, lib/auth_unix.c (as well as global.c, imapoptions, etc.). Other than trimming white space, I can't see what the big deal is with this patch. Cheers, -nic On 01/20/2017 04:24 AM, Sebastian Hagedorn via Info-cyrus wrote: --On 20. Januar 2017 um 08:04:25 +1100 Bron Gondwana via Info-cyrus <info-cyrus@lists.andrew.cmu.edu> wrote: On Fri, 20 Jan 2017, at 03:31, Sebastian Hagedorn via Info-cyrus wrote: --On 19. Januar 2017 um 17:18:06 +0100 Simon Matter <simon.mat...@invoca.ch> wrote: > We and others had this as a patch in our RPMs but I think it has never > been part of vanilla cyrus-imapd. Oops. Should I open an issue for a feature request? I'm surprised that's not something many sites want ... OK, I've never heard of this thing. What is it? .. lmgtfy .. Right, so it's something to normalise the userid when you log in. It will definitely have to be rewritten for Cyrus 3+, because all that stuff got moved into mbname_t and friends. Perhaps my assumption that the option is necessary is wrong? But I know for certain that our webmail users use varied case-spellings of their user names, because in earlier versions of our webmail system they would get different user profiles depending on how they had entered their user names ;-) Bron, how does Fastmail deal with that? Do you simply force users to use the canonic spelling? I guess we could do that, but I'd rather not. Cheers Sebastian Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus IMAP 3.0.0-rc1 Config Lint Surprise
Thanks for the heads-up. We'll get this fixed, it is the man page which is correct. -nic On 01/16/2017 10:19 AM, Andy Dorman via Info-cyrus wrote: On 01/13/2017 12:07 AM, ellie timoney via Info-cyrus wrote: The Cyrus team is proud to announce the immediate availability of the first release candidate from the Cyrus IMAP 3.0 series: 3.0.0-rc1. As a release candidate, it is considered near-stable for production usage. Interfaces, APIs, features, etc are not likely to change between now and the full release. If you plan to upgrade to 3.0, we recommend starting to test your upgrade process now. Feedback and bug reports will be greatly appreciated! Hi everyone. We started the process of checking our Cyrus configs in preparation for testing our dev/beta Debian Cyrus install (2.5.10-3) and ran into an issue right away. I believe the instruction line at this URL: http://www.cyrusimap.org/dev/imap/download/upgrade.html#copy-config-files-and-update for lint checking the cyrus & imapd configs have the file types backwards. The instruction shows: cyr_info conf-lint -C -M But according to the man page the command should look like this: cyr_info [ -C alt imapd.conf ] [ -M alt cyrus.conf ] command And indeed, if you run the command as shown on the web page you get an error caused by the first line of the START section. /usr/lib/cyrus/bin/cyr_info conf-lint -C /etc/cyrus.conf -M /etc/imapd.conf fatal error: invalid option name on line 6 of configuration file /etc/cyrus.conf If I run it as the man page suggests, the output looks a little more reasonable. (and I have a little bit of work to do :-) Hope this helps. -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: "Resource temporarily unavailable", systemd and your FAQ Webpage
Stephan, Thank you for this very interesting description of both the problem and the solution. I'm curious which Linux distribution you're using? We're using Ubuntu Xenial (16.04) and find the following default settings: $ grep -i tasks /etc/systemd/system.conf #DefaultTasksAccounting=no #DefaultTasksMax= so this would seem not to be an issue on Ubuntu systems, at least. Cheers, -nic On 12/16/2016 02:54 AM, Stephan Lauffer via Info-cyrus wrote: Hello! While testing 2.5 we struggled over (known) problems like this...: ...ssh can't fork process to run service imaps/ipv4: Resource temporarily unavailable I searchd... and I found your FAQ... https://cyrusimap.org/imap/faqs/o-toomanyprocesses.html ...and this "tcp_keepalive = 1" hint was doing a good job, but not fixing our problem completely. Less processes as without this setting but too many at all. Btw we have a murder with 5 backends and each has about 5k mboxes. With 2.4 we have about 400 imapd processes on the backends (in normal state) and about 800 on the proxy. Peaks raises this values for sure. But we still wasn't able to get over a limit of about 500 imapds on our new system which is running 2.5. Yesterday night I found our problem: SYSTEMD (and not cyrus-imapd-2.5, but 2.5 was running with systemd here...) I guess there may be more people out there which may be interested in a solition (we will add fixes to our systemd scripts of our suse bulds soon, see https://build.opensuse.org/package/show/home:nixda:devel/cyrus-imapd). The first problem there is: Systemd does not care about your /etc/security/limits.conf The second problem is: Systemd comes with a new limit called "TasksMax". You will find this limit f.e. in /etc/systemd/system.conf as "DefaultTasksMax=512". But you will NOT find this limit in "cat /proc/`cat /var/run/cyrus.pid`/limits". The solution is to add a file with a systemd override for this service. F.e. use the systemctl edit command... (like "systemctl edit cyrus-imapd.service") or place a file in /etc/systemd/system/cyrus-imapd.service.d/override.conf with f.e.: [Service] TasksMax=2048 LimitNOFILE=1 The LimitNOFILE is just a guess... maybe you may not need this here. After setting this override you will see a status information about your process count and limit like this: # systemctl status cyrus-imapd.service ● cyrus-imapd.service - The Cyrus IMAP and POP Mail Server Loaded: loaded (/usr/lib/systemd/system/cyrus-imapd.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/cyrus-imapd.service.d └─override.conf Active: active (running) since Thu 2016-12-15 20:51:17 CET; 12h ago Main PID: 12901 (master) Tasks: 326 (limit: 2048) [...] What about adding a short hint to your faq? Yes, it is not a cyrus problem. And yes, a sysadmin should know... but... I guess systemd in depth may not be good known as the old ulimit thing and if you are searching in the web 99% of the hits deal with ulimit. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: fetching spam from users junk folder
Marcus, In my original response I forgot to mention that for this, or any similar approach, to work, you need to use the misnamed "proxyservers" setting in imapd.conf to grant access to an administrative user. proxyservers: A list of users and groups that are allowed to proxy for other users, separated by spaces. Any user listed in this will be allowed to login for any other user: use with caution. For example: proxyservers: adminuser Or, alternately, assign rights to the appropriate mailboxes in cyradm: > sam user.%.Should\ Be\ Spam adminuser all Cheers, -nic On 12/06/2016 10:39 AM, Nic Bernstein wrote: On 12/06/2016 01:34 AM, Marcus Schopen via Info-cyrus wrote: Hi, I'm looking for an easy way to fetch spams, which were moved into a special junk subfolder by users in their accounts. I'd like to move those messages from there to my account, so I can analyse them to adjust anti spam rules. How would you do that? Ciao! We've used the attached script (and configuration file) for years on many different systems. The script scans the IMAP mail spool for mailboxes matching a name (i.e. "user.yadda.Should Be Spam") and runs the sa-learn program for each message. The same loop could be expanded to also search for false positives (i.e. "user.yadda.False Spam") as a corrective. We based this on earlier work by Nick Burch <n...@tirian.magd.ox.ac.uk>. Feel free to adapt to your needs. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Valid annotations and calendar/addressbook "Dispaly Name"
Friends,
Further questions for our effort to abandon our aging DaviCal server.
How does one set the Display Name for a collection in Cyrus? Is this
handled via annotations? We can see from the sources (annotate.h, line
57) that there's a new /vendor/cmu/cyrus-httpd branch defined, but we
haven't been able to find a list of which annotations are available
(besides this one,
http://cyrusimap.org/imap/faqs/o-annotations.html?highlight=annotation,
which is just the /vendor/cmu/cyrus-imapd branch).
We understand that this may all just work just peachy via protocol, but
we have a need to create an empty framework of suitable calendars &
address books before syncing data from our old server. We just can't
see how to do that and ensure that the Display Name will work properly.
Any help greatly appreciated, even if it's just "Go read this source file."
Armed with this info, I would even be happy to go and update that
previously mentioned Wiki page. :-)
Cheers,
-nic
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
6525 W Bluemound Road, Suite 24 v. 414.272.4477
Milwaukee, Wisconsin 53213-4073
<>
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Loading CalDav calendars
Good people, Forgive me for wasting list bandwidth, but we've found a solution in DaviCal's own sync-remote-caldav.php script. We've simply applied this ACL -- sam user.%.#calendars.% all -- and then use that user's credentials to authenticate. scripts/sync-remote-caldav.php -u http://:8008/dav/calendars/user//Default -U -p -c //Default/ -o Thought it best to reply to myself, again, so anyone else looking for this solution will find this. Cheers, -nic On 10/27/2016 04:32 PM, Nic Bernstein via Info-cyrus wrote: Oh, and for completeness, here's the ACLs on the calendars, lest you think we didn't think of that: > lam user.nic.#calendars.% user.nic.#calendars.Default: anyone 9 nic lrswipkxtecdan user.nic.#calendars.Inbox: nic lrswipkxtecdan anyone 789 user.nic.#calendars.Outbox: nic lrswipkxtecdan Also, it's quite clear after looking in the mail store for a #calendars folder that simply dropping ics files in there will do no good whatsoever. -nic On 10/27/2016 04:25 PM, Nic Bernstein via Info-cyrus wrote: Friends, We're finally starting to play seriously with the CalDav implementation in Cyrus 2.5.10. We've flirted with it in the past, having been building our own packages from the 2.4.x+caldav-beta lines for years, but now we're trying to actually move from our old CYrus IMAP/DaviCal combination to just Cyrus IMAP. The CalDav support seems to work fine with our clients -- Thunderbird/Lightning, Android, etc. -- but while we can use Cadaver to pull perfectly good ics extracts from our old DaviCal server via 'get' and 'mget' operations, we are unable to upload those to Cyrus with Cadaver. Here's what we see: [CLIENT] dav:/dav/calendars/user/nic/Default/> putu4q405ehiej47e0b7eiuk1f...@google.com.ics uploadingu4q405ehiej47e0b7eiuk1f...@google.com.ics to `/dav/calendars/user/nic/Default/u4q405ehiej47e0b7eiuk1fiac%40google.com.ics': Progress: [=>] 100.0% of 936 bytes failed: 403 Forbidden [SERVER] Oct 27 16:13:43 newjiji cyrus/http[10166]: login: rrcs-YADDA.central.biz.rr.com [A.B.C.D] nic Basic User logged in SESSIONID= Oct 27 16:13:43 newjiji cyrus/http[10166]: rrcs-YADDA.central.biz.rr.com [A.B.C.D] as "nic" with "cadaver/0.23.3 neon/0.30.1"; "PUT /dav/calendars/user/nic/Default/u4q405ehiej47e0b7eiuk1fiac%40google.com.ics HTTP/1.1" => "403 Forbidden" We really don't want to lose the event histories we have in the calendars, some of which are >1k entries long, but cannot find a good way to get the data into Cyrus. Could we do so by simply dumping the ics files into the mailbox directory, running a reconstruct and restarting? I've tried using Lightning's import function, but it barfs after a few hundred entries, leaving the collection in an unusable state. The only sure-fire way to recover from that is to blow away and recreate the collection. Obviusly a suboptimal solution. We had even worse luck with Evolution, which wouldn't import at all. Any ideas? -nic -- Nic bernstein...@onlight.com Onlight, Inc.www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 Cyrus Home Page:http://www.cyrusimap.org/ List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic bernstein...@onlight.com Onlight, Inc.www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Loading CalDav calendars
Oh, and for completeness, here's the ACLs on the calendars, lest you think we didn't think of that: > lam user.nic.#calendars.% user.nic.#calendars.Default: anyone 9 nic lrswipkxtecdan user.nic.#calendars.Inbox: nic lrswipkxtecdan anyone 789 user.nic.#calendars.Outbox: nic lrswipkxtecdan Also, it's quite clear after looking in the mail store for a #calendars folder that simply dropping ics files in there will do no good whatsoever. -nic On 10/27/2016 04:25 PM, Nic Bernstein via Info-cyrus wrote: Friends, We're finally starting to play seriously with the CalDav implementation in Cyrus 2.5.10. We've flirted with it in the past, having been building our own packages from the 2.4.x+caldav-beta lines for years, but now we're trying to actually move from our old CYrus IMAP/DaviCal combination to just Cyrus IMAP. The CalDav support seems to work fine with our clients -- Thunderbird/Lightning, Android, etc. -- but while we can use Cadaver to pull perfectly good ics extracts from our old DaviCal server via 'get' and 'mget' operations, we are unable to upload those to Cyrus with Cadaver. Here's what we see: [CLIENT] dav:/dav/calendars/user/nic/Default/> putu4q405ehiej47e0b7eiuk1f...@google.com.ics uploadingu4q405ehiej47e0b7eiuk1f...@google.com.ics to `/dav/calendars/user/nic/Default/u4q405ehiej47e0b7eiuk1fiac%40google.com.ics': Progress: [=>] 100.0% of 936 bytes failed: 403 Forbidden [SERVER] Oct 27 16:13:43 newjiji cyrus/http[10166]: login: rrcs-YADDA.central.biz.rr.com [A.B.C.D] nic Basic User logged in SESSIONID= Oct 27 16:13:43 newjiji cyrus/http[10166]: rrcs-YADDA.central.biz.rr.com [A.B.C.D] as "nic" with "cadaver/0.23.3 neon/0.30.1"; "PUT /dav/calendars/user/nic/Default/u4q405ehiej47e0b7eiuk1fiac%40google.com.ics HTTP/1.1" => "403 Forbidden" We really don't want to lose the event histories we have in the calendars, some of which are >1k entries long, but cannot find a good way to get the data into Cyrus. Could we do so by simply dumping the ics files into the mailbox directory, running a reconstruct and restarting? I've tried using Lightning's import function, but it barfs after a few hundred entries, leaving the collection in an unusable state. The only sure-fire way to recover from that is to blow away and recreate the collection. Obviusly a suboptimal solution. We had even worse luck with Evolution, which wouldn't import at all. Any ideas? -nic -- Nic bernstein...@onlight.com Onlight, Inc.www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Loading CalDav calendars
Friends, We're finally starting to play seriously with the CalDav implementation in Cyrus 2.5.10. We've flirted with it in the past, having been building our own packages from the 2.4.x+caldav-beta lines for years, but now we're trying to actually move from our old CYrus IMAP/DaviCal combination to just Cyrus IMAP. The CalDav support seems to work fine with our clients -- Thunderbird/Lightning, Android, etc. -- but while we can use Cadaver to pull perfectly good ics extracts from our old DaviCal server via 'get' and 'mget' operations, we are unable to upload those to Cyrus with Cadaver. Here's what we see: [CLIENT] dav:/dav/calendars/user/nic/Default/> put u4q405ehiej47e0b7eiuk1f...@google.com.ics Uploading u4q405ehiej47e0b7eiuk1f...@google.com.ics to `/dav/calendars/user/nic/Default/u4q405ehiej47e0b7eiuk1fiac%40google.com.ics': Progress: [=>] 100.0% of 936 bytes failed: 403 Forbidden [SERVER] Oct 27 16:13:43 newjiji cyrus/http[10166]: login: rrcs-YADDA.central.biz.rr.com [A.B.C.D] nic Basic User logged in SESSIONID= Oct 27 16:13:43 newjiji cyrus/http[10166]: rrcs-YADDA.central.biz.rr.com [A.B.C.D] as "nic" with "cadaver/0.23.3 neon/0.30.1"; "PUT /dav/calendars/user/nic/Default/u4q405ehiej47e0b7eiuk1fiac%40google.com.ics HTTP/1.1" => "403 Forbidden" We really don't want to lose the event histories we have in the calendars, some of which are >1k entries long, but cannot find a good way to get the data into Cyrus. Could we do so by simply dumping the ics files into the mailbox directory, running a reconstruct and restarting? I've tried using Lightning's import function, but it barfs after a few hundred entries, leaving the collection in an unusable state. The only sure-fire way to recover from that is to blow away and recreate the collection. Obviusly a suboptimal solution. We had even worse luck with Evolution, which wouldn't import at all. Any ideas? -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 <> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: how to deal with mail retention/archival.
Alvin, This is really more of an issue for your MTA, such as Postfix or Exim. The MDA -- Cyrus in this case -- has little or nothing to do with the sort of archiving/retention you need for compliance. Take a look at always_bcc and similar directives in Postfix, or the equivalent in whatever your MTA is. -nic On 08/26/2016 08:09 AM, Alvin Starr via Info-cyrus wrote: A company I am working with is facing issues of regulatorymail retention. Some searching has yielded little useful results other than putting a system in front to store all incoming messages. What are others doing for mail archival? An ideal solution would let the users carry on using current use patterns and not impose extra restrictions. -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 al...@netvel.net || Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Sieve for shared mailboxes
On 03/18/2016 05:48 AM, Merlin Hartley via Info-cyrus wrote:
...
Of course, over-time more complexity is always required and I have
recently implemented a few shared mailboxes (rather than just sharing
user mailboxes).
Inevitably, the users are now asking for an auto-reply to be
configured for some of these shared mailboxes...
We are already using sieve scripts (managed with Roundcubemail talking
through the firewall to timsieved) so it seems natural to use this
technology here too...
I have followed the instructions on this page:
https://cyrusimap.org/imap/admin/sieve.html?highlight=sieve#managing-sieve-scripts
But the last step doesn't seem to do anything...
So I have a few related questions:
1) how can I query a mailbox to read the flags set by mboxconfig?
Use the 'info' command in cyradm, like so:
root@mail:~# /usr/lib/cyrus/bin/cyradm -U cyrus localhost
Password:
localhost> info tech.support
{tech.support}:
duplicatedeliver: false
lastpop:
lastupdate: 6-Apr-2016 04:01:01 -0500
partition: default
pop3newuidl: true
sharedseen: false
* sieve: global*
size: 801640500
localhost> quit
Note the "sieve: global" line.
2) has anyone got sieve working with shared mailboxes?
Yes, happily and consistently, currently with 2.4.10, and up, on various
installations.
3) is it possible to invoke a sieveshell in the context of a shared
mailbox?
"...context of a shared mailbox..." doesn't really mean anything here.
You must do it as a user who has access to the shared mailbox, as the
page on the website explains.
I seem to have successfully created the global scripts (a 'global'
folder has appeared in the sievedir) - just can't seem to attach it to
a shared mailbox.
Take a look at the output of the 'info' command in cyradm, and if it
doesn't make sense, please post again.
In my experience, the most common cause of problems with sieve and
shared mailboxes is bad scripts.
Cheers,
-nic
--
Nic Bernstein n...@onlight.com
Onlight Inc. www.onlight.com
6525 W Bluemound Rd., Ste 24 v. 414.272.4477
Milwaukee, Wisconsin 53213-4073 f. 414.290.0335
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Request: Please sign this list's messages via DKIM or SPF
On 04/05/2016 11:33 AM, Andrew Morgan via Info-cyrus wrote: On Tue, 5 Apr 2016, lst_hoe02--- via Info-cyrus wrote: Zitat von Binarus via Info-cyrus <info-cyrus@lists.andrew.cmu.edu>: Combine SPF / DKIM with domain blacklisting, and then you *have* an efficient spam fighting tool. As stated the spam actually reaching our inboxes after around 90% cutoff is valid DKIM/SPF signed as it is mostly from the big free providers like Outlook.com, Google and Yahoo. Some other big share is from professional spam farms with always alternating IP and Domains ranges from all over the world with also valid DKIM/SPF. Next big share is from educational servers also mostly valid DKIM/SPF. The tiny rest with around 10% is in fact not DKIM/SPF signed. From the valid e-mail around 20% looks like having a valid SPF/DKIM, mostly professional newsletters not personal mail from customers. So No, SPF/DKIM is no useful spam fighting tool at least not in our corner of the world. Another recent standard, DMARC (https://dmarc.org/) allows the domain owner to specify what the recipient should do with messages that fail DKIM or SPF checks. We ran into this recently and discovered that Yahoo's DMARC records tell the recipient to REJECT messages that fail DKIM or SPF. Google is honoring that DMARC record by putting the message into the Spam folder. This seems like a pretty effective method to prevent someone from spoofing email from your domain. Of course, it does not prevent an actual Yahoo account from sending spam, so you still need traditional spam detection tools as well. However, it is nice that a third-party sender cannot harm your domain's reputation through spoofing. Note: I don't care whether this email list uses SPF or DKIM. Andy If you want to see flame wars even more pointless and/or entertaining than this one, check out the mailing lists for DMARC. ;-) They make these recent exchanges seem quaint by comparison. ___ dmarc-discuss mailing list dmarc-disc...@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss FWIW, mailing lists and DMARC make a particularly noxious couple, as almost all mailing lists will break DMARC, and thus lead to all sorts of rejections. That very subject is the topic of the most vitriolic flame wars on the DMARC lists. Tho, to be honest, I had assumed that the recent changes to the From and Reply-To headers of this mailing list were undertaken to appease strict DMARC requirements. Yes, Google, Yahoo and most of the rest of the Big Boys(c) have adopted DMARC with "p=reject" (or whatever that setting is. At the risk of perpetuating this severely off-topic thread, IMHO if "Binarus" is able to eliminate "90% solely by checking for SPF and DKIM" then one must question just what the rest of their anti-Spam measures were doing? Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: PATCH for lmtp was [frontend lmtp connections to mupdate master]
Bron,
We're starting to run into this same issue -- lmtp proxies fail to
deliver mail when mupdate master craps -- and so started to investigate
this thread. However, it doesn't look like Michael Menge's patch made
it in. Your thoughts?
-nic
On 10/07/2014 08:17 AM, Bron Gondwana wrote:
I'm convinced :) I'll probably add it with Ken while we're at CMU in a couple
of weeks when we can test it together. This is precisely the kind of thing we
love to see! Thanks.
Bron.
On Tue, Oct 7, 2014, at 10:23 PM, Michael Menge wrote:
Hi,
as we have had an other crash of mupdate master last week, we used the
patch on our production system.
After the patch was added the load on mupdate master was dropping form
about 10 to about 1.
After one week of using it we have not found any problems.
As I have not received any other feedback, I added it to the
bugtracker.
https://bugzilla.cyrusimap.org/show_bug.cgi?id=3866
Pleas consider adding it to 2.5 and 2.4.next
Regards
Michael
Quoting Michael Menge <michael.me...@zdv.uni-tuebingen.de>:
Hi,
Quoting Michael Menge <michael.me...@zdv.uni-tuebingen.de>:
Quoting Michael Menge <michael.me...@zdv.uni-tuebingen.de>:
By thew way, the reason I was so surprised in the first place was, that
I have been fooled by the documentation:
Quoting https://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-murder.php
Configuring the frontends
[...]
However, because the frontends only talk to the mupdate master
via a slave running on the local machine, you will also need
to set up a slave on the same machine, in the SERVICES section
of cyrus.conf, like so
And an other misleading DOC !
Quoting
http://www.cyrusimap.org/mediawiki/index.php/Cyrus_Murder_Mail_Delivery
UMich patch
Patch Patches are against 2.2 but are being moved to 2.3
Lmtpproxyd will now use the local mailboxes.db
Quoting Wesley Craig <wescr...@gmail.com>:
On 29 Sep 2014, at 10:08, Michael Menge
<michael.me...@zdv.uni-tuebingen.de> wrote:
thanks for your mail. By any chance do you still have the patch?
In fact, I don't. Dusting off my notes, I recall now that instead
of patching this (bogus) code, we instead decided to configure the
frontends as "unified", while leaving the backends "standard". The
only downside of this approach was that a naive admin could
potentially create a user's mailbox on a frontend.
Sorry I said that we ported that code forward: in fact we simply
got the effect of consulting mailboxes.db without porting forward.
:wes
I have patched my lmtpd to use the local mailbox.db in all cases,
unified Murder, and standalone cyrus already did this.
I tested it with a few testmails on my test system,
but as i don't have a unified setup or a standalone test system
at the moment i didn't test these setups.
I would appreciate a review.
Regards,
Michael Menge
M.MengeTel.: (49) 7071/29-70316
Universität Tübingen Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung mail:
michael.me...@zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
M.MengeTel.: (49) 7071/29-70316
Universität Tübingen Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung mail:
michael.me...@zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Email had 1 attachment:
+ smime.p7s
7k (application/pkcs7-signature)
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
6525 W Bluemound Road, Suite 24 v. 414.272.4477
Milwaukee, Wisconsin 53213-4073
--- cyrus-imapd-2.4.17/imap/lmtpd.c 2012-12-01 20:57:54.0 +0100
+++ cyrus-imapd-2.4.17.lmtp_patch/imap/lmtpd.c 2014-09-29 15:27:55.0 +0200
@@ -186,56 +186,44 @@
global_sasl_init(1, 1, mysasl_cb);
-if (config_mupdate_server &&
- (config_mupdate_config == IMAP_ENUM_MUPDATE_CONFIG_STANDARD) &&
- !config_getstring(IMAPOPT_PROXYSERVERS)) {
- /* proxy only -- talk directly to mupdate master */
- r = mupdate_connect(config_mupdate_server, NULL, , NULL);
- if (r) {
- syslog(LOG_ERR, "couldn't connect to MUPDATE server %s: %s",
- config_mupdate_server, error_message(r));
- fatal("error connecting with MUPDATE server", EC_TEMPFAIL);
- }
-}
-else {
- dupelim = config_getswitch(IMAPOPT_DUPLICATESUPPRESSION);
+dupelim = config_getswitch(IMAPOPT_DUPLICATESUPPRESSION);
#ifdef USE_SIEVE
- mylmtp.addheaders = xzmalloc(2 * sizeof(struct addheader));
- mylmtp.addheaders[0]
Re: Why are user inboxes called user.some-user ?
On 07/19/2015 06:21 AM, Conrad Kleinespel wrote: my question was meant to ask why we even need to separate things into user/... and netnews/... and shared/... instead of just handling everything through the ACL extension (which should allow to have shared mailboxes by given read only access, right?). I understand that we have those abstractions in place but I don't yet understand why we need those abstractions. For instance, why couldn't we put everything in the same namespace: root comp.mail.imap fred and when a user fred wants access to the mailbox, just request fred instead of user.fred ? Ah, sorry, that wasn't quite clear to me. Historical artifact is my assumption, and the fact that for several years, at CMU, the pre-existing bboard system (net news-like discussion boards) was integrated into Cyrus. Separate namespaces for users vs shared folders vs netnews, etc. makes sense to some; common namespace makes sense to others. Changing from the former to the latter could be a real mess, however. Cyrus history discussion here: http://www.cyrusimap.org/mediawiki/index.php/Cyrus_History Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Why are user inboxes called user.some-user ?
Conrad, It's important to keep clear the difference between what the server knows about, such as user, news, some-shared-folder and what the client presents to you, such as Other Users, Shared Folders, etc. The former map to actual hierarchy elements, whereas the latter are purely abstractions. Similarly, there is abstraction between a user's mailboxes and what they see in their client. The user fred will, by default, have the mailbox named user.fred (or user/fred if unixhierarchysep is enabled) but it will appear to them as INBOX in their client. Depending upon the setting of altnamespace, a user's mailbox named user.fred.Stuff may appear as INBOX.Stuff or as Stuff. If you're exporting NNTP via IMAP, then the 'newsprefix' option is used to determine the root of the net news hierarchy. For example, if imapd.conf has newsprefix: netnews then the comp.mail.imap newsgroup would be found in the netnews.comp.mail.imap folder, which might appear in, for example, Thunderbird as Shared Filders/netnews/comp/mail/imap Check out the docs here: http://www.cyrusimap.org/docs/cyrus-imapd/2.4.17/overview.php Cheers, -nic PS - I've listed the 2.4.17 link on the old site as some of the stuff on the new site, docs.cyrus.foundation, aren't working yet. On 07/16/2015 03:02 PM, Conrad Kleinespel wrote: Hello everyone, I hope you are all having a nice week :-) I am wondering why user inboxes have to be created as user.some-user instead of just some-user within the Cyrus IMAP server. I have a few ideas, but am unsure: - is it because all user.* inboxes have, by default, the same permissions as user ? - is it just so that emails are stuffed inside the /var/spool/imap/user/some-user folder on disk ? - something else ? Also, what are some cases where using something other than user.* might be useful ? I noticed shared mailboxes are sometimes created as shared.some-shared-user, which creates a /var/spool/imap/shared/some-shared-user directory for incoming email. But that's all I have noticed about it. Thanks a lot for your help. Best regards, Conrad Kleinespel conr...@conradk.com +33 6 23 82 42 79 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 1442 N Farwell Ave., Suite 600v. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: autocreateinboxfolders
On 06/18/2015 09:40 AM, Nikos Gatsis - Qbit wrote: Strange, I have autocreateinboxfolders command in older distros. So, what should I do? Nikos, Some packagers added their own patches to support autocreatequota, autocreateinboxfolders, etc. If you depend on such added functionality, then you're probably best off using similar packages rather than building from source. The reason this wasn't included in older versions of Cyrus, by default, had to do with deciding where to locate such auto-created mailboxes in a complex murder environment. Cheers, -nic On 18/6/2015 5:25 ??, Dan White wrote: On 06/18/15 17:18 +0300, Nikos Gatsis - Qbit wrote: Hello list I have install cyrus 2.4.17 in a Centos 7 distro and i find out that autocreateinboxfolders doesn't work. I mean, imap users doesnt auto create Sent or Trash folder automatically. Is something I miss? My conf is: configdirectory: /var/lib/imap partition-default: /var/spool/imap admins: cyrus some sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail allowanonymouslogin: no hashimapspool: true sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN allowplaintext: yes anyoneuseracl: 0 createonpost: 0 munge8bit: 0 autocreateinboxfolders: Sent|Drafts|Trash autosubscribeinboxfolders: Drafts|Sent|Trash These two options are not valid for version 2.4.17, and appear to have been added in one of the 2.5.x releases. tls_cert_file: /var/lib/imap/server.pem #tls_cert_file: /etc/pki/cyrus-imapd/cyrus-imapd.pem tls_key_file: /var/lib/imap/server.pem #tls_key_file: /etc/pki/cyrus-imapd/cyrus-imapd.pem tls_ca_file: /etc/pki/tls/certs/ca-bundle.crt # uncomment this if you're operating in a DSCP environment (RFC-4594) # qosmarking: af13 -- Untitled Document *?? ? - Gatsis Nikos* Web developer tel.: 2108256721 - 2108256722 fax: 2108256712 email: ngat...@qbit.gr http://www.qbit.gr Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 1442 N Farwell Ave., Suite 600v. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: single instance message store problem.
On 05/29/2015 03:30 PM, Michael Neumann wrote: Am 29.05.2015 um 22:19 schrieb Ken Murchison: Also, are you sure that your MTA isn't breaking up the recipients into separate LMTP transactions? lmtpd can/will only do single instance store for recipients that are part of the same transaction (MAIL FROM, RCPT TO, DATA sequence). If the recipients are sent one at a time with duplicate DATA commands, there are treated as distinct messages. That is the problem, postfix default local transport does only one at a time, that breaks single instance storage. We had to redefine it to: local_transport = lmtp:unix:/lmtp/lmtp Please read about the consequences in postconf manual. Hope that helps Michael is right on the money here. I hadn't noticed that you had defined mailbox_transport rather than local_transport. This is our typical postfix configuration in support of singleinstancestore: local_recipient_maps = ldap:/etc/postfix/local_recipient_map.ldap, ldap:/etc/postfix/alias_map.ldap local_transport = lmtp:unix:/mailstore/lib/imap/socket/lmtp local_destination_recipient_limit = 300 local_destination_concurrency_limit = 5 The warnings Michael was referring to are covered in http://www.postfix.org/LOCAL_RECIPIENT_README.html Specifically, if one overrides the local_transport, it's important that one also properly qualifies all local_recipients (quoting): Problem: you don't use the default Postfix local(8) http://www.postfix.org/local.8.html delivery agent for domains matching $mydestination http://www.postfix.org/postconf.5.html#mydestination, $inet_interfaces http://www.postfix.org/postconf.5.html#inet_interfaces, or $proxy_interfaces http://www.postfix.org/postconf.5.html#proxy_interfaces. For example, you redefined the local_transport http://www.postfix.org/postconf.5.html#local_transport setting in main.cf http://www.postfix.org/postconf.5.html. Solution: your local_recipient_maps http://www.postfix.org/postconf.5.html#local_recipient_maps setting needs to specify a database that lists all the known user names or addresses for that delivery agent. In our case we most often use LDAP for this, as shown above, but whatever DB is best for you, etc. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: single instance message store problem.
On 05/29/2015 02:19 PM, John McMonagle wrote: On Friday 29 May 2015 2:08:58 PM you wrote: On 05/29/2015 01:48 PM, John McMonagle wrote: Having trouble getting single instance message store to work. Running debian jessie with cyrus imap 2.4.17+caldav~beta10-18 postfix 2.11.3-1. Am following instructions in: https://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-configure.php master.cf has: lmtp unix - - n - - lmtp main.cf has: mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp local_destination_recipient_limit = 200 local_destination_concurrency_limit = 5 imap.conf has singleinstancestore: 1 lmtpsocket: /var/run/cyrus/socket/lmtp Delivery works but each is an independent file. Any suggestions? John John, At the risk of sounding insulting, have you checked the link count (via 'ls -l') on these duplicate copies? For example, here I have part of my Inbox: -rw--- 1 cyrus cyrus 5821 2013-07-09 12:26 17201. -rw--- 6 cyrus cyrus 36816 2013-07-09 14:22 17202. -rw--- 1 cyrus cyrus 17305 2013-07-09 14:43 17203. -rw--- 3 cyrus cyrus 44952 2013-07-09 14:53 17204. -rw--- 3 cyrus cyrus 44942 2013-07-09 14:56 17205. -rw--- 1 cyrus cyrus 1395 2013-07-09 15:00 17206. The 2nd, 4th 5th messages have multiple hard-links (second column), which is how singleinstancestore does its thing. Cheers, -nic No problem Yes I checked. -rw--- 1 cyrus mail 3919 May 29 10:35 145026. -rw--- 1 cyrus mail 87189663 May 29 12:34 cyrus.squat drwx-- 2 cyrus mail 204800 May 29 13:15 Sent -rw--- 1 cyrus mail 2116 May 29 13:15 145027. The 2 mails should have had links. john John, Okay, I had hoped you'd already checked that. How about this; have you got the duplicatesuppression disabled? If you disable duplicatesuppression, you'll also lose singleinstancestore, as it relies upon the duplicate.db to perform its work. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 1442 N Farwell Ave., Suite 600v. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: single instance message store problem.
On 05/29/2015 01:48 PM, John McMonagle wrote: Having trouble getting single instance message store to work. Running debian jessie with cyrus imap 2.4.17+caldav~beta10-18 postfix 2.11.3-1. Am following instructions in: https://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-configure.php master.cf has: lmtp unix - - n - - lmtp main.cf has: mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp local_destination_recipient_limit = 200 local_destination_concurrency_limit = 5 imap.conf has singleinstancestore: 1 lmtpsocket: /var/run/cyrus/socket/lmtp Delivery works but each is an independent file. Any suggestions? John John, At the risk of sounding insulting, have you checked the link count (via 'ls -l') on these duplicate copies? For example, here I have part of my Inbox: -rw--- 1 cyrus cyrus 5821 2013-07-09 12:26 17201. -rw--- 6 cyrus cyrus36816 2013-07-09 14:22 17202. -rw--- 1 cyrus cyrus17305 2013-07-09 14:43 17203. -rw--- 3 cyrus cyrus44952 2013-07-09 14:53 17204. -rw--- 3 cyrus cyrus44942 2013-07-09 14:56 17205. -rw--- 1 cyrus cyrus 1395 2013-07-09 15:00 17206. The 2nd, 4th 5th messages have multiple hard-links (second column), which is how singleinstancestore does its thing. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 1442 N Farwell Ave., Suite 600v. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Problems with replication
On 05/17/2015 07:56 PM, pl...@bibliothek.uni-kassel.de wrote: Hi, [...] Looks to me that you are running imap server on port 2005, not the sync server. Try telneting to port 2005 on the replica. You should see something like: Connected to replica. Escape character is '^]'. * SASL PLAIN * STARTTLS * COMPRESS DEFLATE * OK replica Cyrus sync server v2.4.17 now I seet it, too. My other install is answering like the above. But I can't see the error; syncserver is configured like this in /etc/cyrus.conf: syncserver cmd=/usr/lib/cyrus/bin/sync_server listen=csync This is strange - anyone with a Debian 8, too ? Have you got csync defined in /etc/services? csync2005/tcp# Cyrus IMAP replication But perhaps the more salient question would be; if the IMAP server is listening on 2005, have you got imap misdefined in /etc/services? Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: ubuntu serve - cyrus fails to start
Lowpass,
BTW; if you're trying to debug an init script, try running it manually
with shell debugging:
# sh -x /etc/init.d/cyrus-imapd start
And then post a sanitized version of that here, if you still need help.
-nic
On 04/28/2015 06:49 PM, lowpass wrote:
Thanks for the quick response, Bron. The symlink is ok.
# ls -l /var/run
lrwxrwxrwx 1 root root 4 Oct 18 2014 /var/run - /run/
I tried creating the dir myself as you suggested:
# mkdir /run/cyrus
# chown cyrus /run/cyrus/
# service cyrus-imapd start
[nothing]
I tried removing the --quiet flag from the startup script with same
(non) results.
What about the pid? As i understand, it's not cyrus that creates that
on startrup. In any case, it's NOT being created. From
/etc/init.d/cyrus-imapd:
NAME=cyrmaster
PIDFILE=/var/run/${NAME}.pid
I've posted a message on the Ubuntu forum as well, as i've a feeling
the problem is not with cyrus. I was hoping, though, that another
cyrus user might have run into this.
On Tue, Apr 28, 2015 at 6:55 PM, Bron Gondwana br...@fastmail.fm
mailto:br...@fastmail.fm wrote:
On Wed, Apr 29, 2015, at 08:46 AM, lowpass wrote:
I do have socket and lock dirs under /var/lib/cyrus but they were
last modified several years ago and seem to be left over from
some other config. Other dirs there have seen more recent
activity. Everything seems to be pointing towards the socket
lock dirs being created under /run but there's nothing there.
/run is a tmpfs which gets created fresh on each reboot.
Cyrus starts as user 'cyrus' and has no permission to create the
directories it needs.
Your init script should create the directories - but if you moved
them somewhere other than where the package expects them to be,
then it won't create intermediate directories for you.
So, here's the thing:
1) double check that /var/run and /run are the same place -
they're mostly a symlink in recent Debian/Ubuntu systems. If not,
I suggest that you audit your configuration to be all in /var/run
or all in /run (probably a good idea anyway for more consistency.
2) run these commands as root:
mkdir /run/cyrus
chown cyrus /run/cyrus
3) either put those commands in a startup script that runs before
Cyrus starts, or edit the init script for Cyrus - though note that
if you edit the init script, you'll have to re-apply those edits
on upgrade.
Unfortunately, this isn't something we can fix in the Cyrus
binaries. They try to create the directories, but they just plain
don't have permissions to do so at that stage of the process.
Regards,
Bron.
--
Bron Gondwana
br...@fastmail.fm mailto:br...@fastmail.fm
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Nic Bernstein n...@onlight.com
Onlight llc. www.onlight.com
219 N. Milwaukee St., Ste. 2A v. 414.272.4477
Milwaukee, Wisconsin 53202 f. 414.290.0335
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Problem with quota
On 04/04/2015 09:02 AM, Patrick Boutilier wrote: Quoting Simon Matter simon.mat...@invoca.ch, Sat, 04 Apr 2015: I guess that's because of single instance store. It's not a bug then but a feature if duplicatesuppression: 1. Duplicate messages are hardlinked on disk, they don't consume space there, but are still calculated in quota usage. Isn't that singleinstancestore:1 ? duplicatesuppression is where lmtpd will suppress delivery of a message to a mailbox if a message with the same message-id (or resent-message-id) is recorded as having already been delivered to the mailbox. Yes Patrick, you're correct. However there is a connection, in that singleinstancestore requires the duplicate DB in order to do its work, so people often conflate the two. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Auto create folders
On 01/26/2015 11:30 AM, Andrew Morgan wrote: On Mon, 26 Jan 2015, John Mok wrote: Hi Andy, Thank you for your prompt reply. How do you create mailboxes now? I used cyradm and createmailbox, e.g. createmailbox user/username@DOMAIN, to create mailboxes. Any idea how to create folder in cyradm? Simply createmailbox user/username@DOMAIN/spam, and then set ACL permissions for user/username@DOMAIN/spam ? Yes, that's exactly what you need to do! Actually, unless you need something out of the ordinary, you can skip setting the ACL for the child mailbox, as it will inherit from its parent (from the docs page http://cyrusimap.org/docs/cyrus-imapd/2.4.17/overview.php#acl ): Initial ACLs for Newly Created Mailboxes When a mailbox is created, its ACL starts off with a copy of the ACL of its closest parent mailbox. When a user is created, the ACL on the user's INBOX starts off with a single entry granting all rights to the user. When a non-user mailbox is created and does not have a parent, its ACL is initialized to the value of the defaultacl option in /etc/imapd.conf Note that some rights are available implicitly, for example 'anonymous' always has 'p' on user INBOXes, and users always have rights on mailboxes within their INBOX hierarchy. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: duplicatesuppression -- why?
Duplicate suppression database is also used in the management of single instance store, which can be a big win. Please check the documentation for that to see why and how it may benefit your installation. http://cyrusimap.org/docs/cyrus-imapd/2.4.17/overview.php#singleinstance I believe it is also used by the sieve vacation feature, but could be wrong about that. Cheers, -nic On 01/10/2015 09:05 AM, Patrick Goetz wrote: On 1/10/2015 5:51 AM, Robert Norris wrote: The major problem with it in my experience is that you might actually prefer the copy of the message that came through the list. For me that's usually because I wanted DKIM headers or similar. The other problem is it involves adding computational infrastructure to correct minor user-error behaviors, which (as a sometimes educator) I'm opposed to philosophically. The MUA I use (Thunderbird) even includes a Reply List button to prevent this. Thanks for that response. It's very clear to me that I *don't* want this feature. FastMail is a completely different use case, but I'm not sure I would turn it on there, either. So, presumably if I use duplicatesuppression: 0 Then the duplicate_db skiplist won't even be created in the first place? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus Replication (example) [was Re: restore from cyrdump]
On 12/19/2014 06:17 AM, Patrick Goetz wrote: Nic, Thanks for that detailed explanation. I still feel myself somewhat stymied by either the documentation (or lack thereof) or perhaps an unfortunate case of being somewhat feeble-minded. Here are some follow up comments/questions: On 12/18/2014 9:59 AM, Nic Bernstein wrote: I will say that the ability to quiesce the application without halting it would be most desirable. Most databases have supported this sort of thing for ages, and it would be great if one could send a signal to Cyrus to achieve the same result. I wonder what would happen if you just stopped lmtp while making a snapshot? Would postfix choke on this and start kicking messages back to the sender, or would they get queued for later delivery? Alternatively, maybe lmtp could temporarily divert new messages to a dummy spool so that postfix/sendmail wouldn't have to know anything about this. This might be the least painful way to implement quiescence in cyrus. But LMTP is only one method affecting the mail store, IMAP and sieve can as well. Granted one can brute-force this by shutting down network ports and the like, but at that point why not just stop cyrus? His initial suggestion -- stop cyrus, snapshot, restart cyrus -- is reasonable, but we feel that the later suggestion -- stop cyrus, tar up data, start cyrus -- is not. It takes data offline for too long. That's why the snapshot capability is necessary in any truly suitable server. I agree. Here is a substitute proposal (and I'll come back to why I'm pushing this point). Serially 1. rsync user mail files 2. rsync configdirectory db files 3. rsync user mail files again That should get you reasonably close to what you get with snapshots. No, not in the least is this close to a snapshot. Snapshots are instantaneous, or near to it. The time an rsync takes, even a catch-up, grows with the size of the mail store and the deltas between attempts. Also, rsync is not well suited to the file-per-message, directory-per-mailbox storage scheme of cyrus, as lots of fstats() result, and this just adds to the time. I don't understand why one wouldn't use snapshots? Every modern OS and distro include filesystems or volume managers which support snapshotting, and several, such as Ubuntu, even recommend snapshot-capable partitioning schemes out of the box. It's just not that hard, and it's exactly the right way to handle this sort of staged backup. * Halt cyrus * snapshot critical filesystems o spool date (/var/spool/imap) o config data (/var/lib/imap or /var/imap) o metadata (i.e. /var/run/cyrus) * start cyrus * mount snapshot * rsync or otherwise backup from snapshot * unmount snapshot * (optionally) destroy snapshot This is so easy to handle via a cron or at job. Why would one do this? If the answer is legacy system, then fine, but legacies can be upgraded or replaced. If you follow the prescribed cyrus directory structure, then this can be simplifed (Arch linux example): 1. rsync -a --delete /var/imap/user [removable disk/other server] 2. rsync -a --delete /var/imap [removable disk/other server] Once you've rsynced the mail files once, rsyncing them again a short time later should be pretty fast. There does need to be a backup solution for people who only have one server, hence can't use replication or imapsync to do backups. There is, snapshots, or hosted mail services (like Fastmail :). Lastly, as to the use of imapsync to achieve user, mailbox or server replication,... So your command line is much like Patrick's example, but with '--user1 user --authuser1 proxyuser --user2 user...' Of course you must create a proxy user, and Cyrus supports this with the 'proxyserver' directive in imapd.conf (man imapd.conf for details), i.e.: 'proxyservers:proxyuser'. Here is the imapd.conf man page entry for proxyservers: proxyservers: none A list of users and groups that are allowed to proxy for other users, separated by spaces. Any user listed in this will be allowed to login for any other user: use with caution. In a standard murder this option should ONLY be set on backends. DO NOT SET on frontends or things won't work properly. That capitalized DO NOT SET on frontends would seem to be cause for concern, especially since I don't understand how this works. Well then, get thee to a website or man page. :-) http://cyrusimap.web.cmu.edu/docs/cyrus-imapd/2.4.17/ag.php No, seriously, this isn't an issue if you're not using a murder. A frontend is the part of a murder aggregation cluster which proxies for the backend servers which actually hold the mail store. A murder consists of one or more frontends, one or more backends and a single mupdate master, which controls the canonical copy of the mailboxes database. In a murder, if one wants to set the proxyservers option, one sets it only
Re: Cyrus Replication (example) [was Re: restore from cyrdump]
On 12/19/2014 01:31 PM, Patrick Goetz wrote:
Super helpful -- thanks!
I only have one additional question:
On 12/19/2014 09:31 AM, Nic Bernstein wrote:
My current plan is to use imapsync for the migration and then
replication to another dummy server for backup, assuming I can figure
out how to set up replication.
I strongly recommend against this course of action. If you're migrating
between two boxes, which it sounds like you are, then you're much better
off rsyncing the spool data between them (once you've halted cyrus) and
then allowing cyrus to perform the necessary DB updates.
It wasn't clear to me why you strongly recommend against this course of
action (other than your recommended course of action is vastly simpler
than messing around with imapsync for multiple users).
Imapsync is slow and finicky. I have used it before and it's great for
what it is, but it doesn't always preserve everything you might want,
and can take several tries to work through that. Given that you may not
immediately recognize a deficient migration (missing message flags, for
example, or seen state) you may find yourself in a predicament if you've
already switched to using the new server. Those sort of things.
What I think imapsync is /really/ good at is migrating between two
wholly different IMAP servers, or between a native IMAP server, like
cyrus or uw-imap, and something with an IMAP-like protocol interface,
like Exchange or Groupwise. It's also great where you need to remap the
user mail store space, as it lets one apply regexes and rearrange the
mail store structure if you'd like.
I believe in using the best tools for the job. Migrating between
different systems requires agnostic tools like imapsync. Upgrading
within a single system, like you're proposing, is best handled by that
system's self-provided tools, in this case ctl_cyrusdb and cvt_cyrusdb.
Also, for the purposes of clarity and documentation:
The only 2 files I need to run cvt_cyrusdb on are:
- mailboxes.db
- annotations.db
the contents of the {configdirectory}/db are generated dynamically, and
the other db files (e.g. deliver.db and tls_sessions.db) are only
relevant to the cyrus instance on the current machine? (I'm not sure
about deliver.db -- this would seem to need to be converted as well.)
Deliver DB is needed if you're using duplicate suppression. If you've
followed this mailing list over the past few years (or read back through
it) you'll find that temporal DBs like tls_sessions.db, can best be
stored on ephemeral storage (RAM-based filesystems) such as /var/tmp,
/var/run or /run (depending upon your flavor). For example, we often
use this in our imapd.conf (adujst your paths as needed):
# These are temporal, thus are stored on tmpfs
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
Your init script may need tinkering with to ensure that /var/run/cyrus
exists before the daemon is started, however, so check that. In the
Debian/Ubuntu world this involves the dpkg-statoverride command, and
modern packages include that in the init script.
Then one can just copy the contents of
- {configdirectory}/user
- {configdirectory}/quota
- {configdirectory}/sieve
to the new machine. If that works, this is vastly simpler than running
imapsync for each individual user.
Yes, but again, check the list in install-upgrade.html for the changes
made between the version you're coming from and going to. You may need,
for example, to perform some upgrade step on the seen files (in
{configdirectory}/user) or something like that.
Also, when going from 2.3.X to 2.4.X there is a new index file structure
which will require each mailbox be reindexed. This can be handled in
one go, by forcing the reindexing, or by letting it happen as each user
logs in. To some extent this will depend, too, on which jobs you have
in the START section of cyrus.conf. Consult install-upgrade.html for
more details.
Cheers,
-nic
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Nic Bernstein n...@onlight.com
Onlight llc. www.onlight.com
219 N. Milwaukee St., Ste. 2A v. 414.272.4477
Milwaukee, Wisconsin 53202 f. 414.290.0335
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Cyrus Replication (example) [was Re: restore from cyrdump]
cmd=/usr/lib/cyrus/bin/sync_client -r
# this is recommended if using duplicate delivery suppression
#delprune cmd=/usr/sbin/cyrus expire -E 3 -D 60 -X 60 at=0400
@@ -55,7 +55,7 @@
##
# Synchronization for remote replication.
# Comment this out on Master, uncomment on replicas
-syncserver cmd=/usr/lib/cyrus/bin/sync_server listen=csync
+#syncserver cmd=/usr/lib/cyrus/bin/sync_server listen=csync
# Experimental httpd for caldav
httpd cmd=httpd listen=8080 prefork=1 maxchild=20
It's just not that hard to implement, and for the security and safety it
provides is well worth it.
Note that if you're using a murder, the server name must be preserved
between the two hosts, in the event of a fail-over, and only the master
should communicate with the mupdate server (as shown in my example). If
you're not using a murder, then most of these differences go away (all
the mupdate stuff). Of course, you'll need to switch DNS or have some
other way of dealing with fail-over on layer 3.
We put all common configuration into /etc/imapd.conf, and then use the
@include directive to include the appropriate file fragment, either
imapd-master.conf or imapd-replica.conf. For the cyrus.conf, it's just
a couple of line edits -- commenting and uncommenting -- so we do that
by hand. You've got to intervene to update the DNS, in any event, so
this much more is trivial.
Lastly, as to the use of imapsync to achieve user, mailbox or server
replication, and the authentication requirements thereof, I would
suggest reading the README file for that application, which includes this:
You may authenticate as one user (typically an admin user), but be
authorized as someone else, which means you don't need to know every
user's personal password. Specify --authuser1 adminuser to enable this
on host1.
So your command line is much like Patrick's example, but with '--user1
user --authuser1 proxyuser --user2 user...'
Of course you must create a proxy user, and Cyrus supports this with the
'proxyserver' directive in imapd.conf (man imapd.conf for details),
i.e.: 'proxyservers:proxyuser'.
However, I must be honest and point out that if you're going to go to
the trouble of figuring out how to use imapsync (and possibly pay for
it, to boot) you may as well just set up a replica. As I've shown,
above, it's just not that hard.
Cheers,
-nic
On 12/15/2014 05:01 PM, Patrick Goetz wrote:
This still leaves the question of how best to back up a cyrus mailstore.
Bron mentioned that most people are using LVM snapshots. I don't see
how using btrfs/LVM/ZFS snapshots can save you from a race condition
between when the cyrus user directory is updated and when mailboxes.db
is updated. The only way I would trust this is by doing this:
1. Stop cyrus
2. Snapshot
3. Restart cyrus
cyrdump: near as I can tell the only useful purpose this serves is to
assemble all email messages into a single mbox file (can anyone
confirm this)?
ctl_mboxlist: this seems useful for making a human readable copy of the
mailboxes.db file, but I'm not sure how this could be useful for
disaster recovery, given the previously mentioned issue about keeping
the mailboxes.db file synchronized with the contents of the user dir.
So, given a simple mail server (i.e. no murder + replication), and when
using a filesystem (e.g. ext4 or XFS) which doesn't do snapshots, it
would appear that the only safe way to backup up a cyrus mailstore is to
either using something like imapsync, or
1. Stop cyrus
2. tar cvf /some/safe/place/user.tar {default-partion}
3. tar cvf /some/safe/place/cyrusdb.tar {configdirectory}
4. Restart cyrus
The way I've used imapsync in the past required copying mail folders per
authenticated user account; i.e. something like
imapsync --host1 my_host1 --authmech1 LOGIN --user1 my_user1 --password1
x --host2 my_host2 --authmech2 PLAIN --user2 my_user2 --password2 x
which in particular means knowing everyone's passwords. This is
entirely unworkable for larger sites, and I'm not sure if there is a
trick for getting around this.
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
attachment: nic.vcf
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: CalDAV?
Um, at the risk of offending; RTFM? The doc/install-http.html document, within the distribution, is fairly complete. Please download the tarball and take a look at that. If you've still got questions, come back with those. Cheers, -nic On 12/16/2014 11:38 AM, Patrick Goetz wrote: On 12/15/2014 04:24 PM, Nic Bernstein wrote: Patrick, You'll find a link to the latest Beta release with CalDav/CardDav support on the Cyrus IMAP website: http://cyrusimap.org/ Thanks for that information. I've had to educate myself on how CalDav works, but this looks fairly promising. How can I find out more about what kinds of calendar functionality is supported (e.g. shared calendars, email-based appointment scheduling, simultaneous access to multiple calendars, etc.)? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: CalDAV?
Patrick, You'll find a link to the latest Beta release with CalDav/CardDav support on the Cyrus IMAP website: http://cyrusimap.org/ It is anticipated that future releases of Cyrus IMAP will include CalDAV/CardDAV/RSS support in the stable download. While in beta status, however, we are offering it as a separate download. http://cyrusimap.org/mediawiki/index.php/Latest_Updates Essentially, this is a patched version of 2.4.17, with a new HTTP server to support the calendar and address book services. New mailbox hierarchies, by default user.username.#calendars and user.username.#addressbooks (but settable by you), hold the calendar and address book entries, and are not exposed via the normal IMAP protocol LIST commands (but may be explicitly accessed). Look for this to be included in 2.5 (per previous postings). -nic On 12/15/2014 04:12 PM, Patrick Goetz wrote: Speaking of calendars, a while back there was talk of a Cyrus CalDAV module. - Did this ever come to fruition? - Does this mean we can finally integrate calendar funtionality into Cyrus, similar to the feature MS Exchange users have? - If so, how does it work? Is there any documentation? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: switch to cyrus murder (aggregator) feedback
) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f40e5891000) libnsl.so.1 = /lib64/libnsl.so.1 (0x7f40e5678000) libc.so.6 = /lib64/libc.so.6 (0x7f40e52ff000) libdl.so.2 = /lib64/libdl.so.2 (0x7f40e50fb000) libresolv.so.2 = /lib64/libresolv.so.2 (0x7f40e4ee3000) /lib64/ld-linux-x86-64.so.2 (0x7f40e64f7000) --- bt on imapd core dump #0 0x0080e130 in ?? () #1 0x7fe5a839334f in ssl3_get_message (s=0x80e430, st1=8347825, stn=-1470427072, mt=optimized out, max=102400, ok=0x7fffcc974d08) at s3_both.c:522 #2 0x7fe5a838ba0d in ssl3_get_key_exchange (s=0x0) at s3_clnt.c:1103 #3 0x7fe5a838dff8 in ssl3_connect (s=0x80e430) at s3_clnt.c:316 #4 0x0046a177 in tls_start_clienttls (readfd=16, writefd=16, layerbits=0x7fffcc975104, authid=0x7fffcc975108, ret=0x7e1fa0, sess=0x7e1fa8) at tls.c:1311 #5 0x004669f4 in do_starttls (s=0x7e16a0, tls_cmd=0x78a4d0 imap_protocol+208) at backend.c:201 #6 0x00467217 in backend_authenticate (s=0x7e16a0, prot=0x78a400 imap_protocol, mechlist=0x7fffcc976468, userid=0x7f5c90 REPLACED_LOGINID, cb=0x80de30, status=0x7fffcc976460) at backend.c:378 #7 0x00467a1a in backend_connect (ret_backend=0x7e16a0, server=0x7a8960 partition.17660 ma03.mail.localhost, prot=0x78a400 imap_protocol, userid=0x7f5c90 REPLACED_LOGINID, cb=0x0, auth_status=0x0) at backend.c:552 #8 0x00426603 in proxy_findserver (server=0x7a8960 partition.17660 ma03.mail.localhost, prot=0x78a400 imap_protocol, userid=0x7f5c90 REPLACED_LOGINID, cache=0x7a3010 backend_cached, current=0x7a3008 backend_current, inbox=0x7a3000 backend_inbox, clientin=0x7be450) at proxy.c:179 #9 0x00426beb in proxy_findinboxserver (userid=0x7f5b20 REPLACED_LOGINID) at imap_proxy.c:145 #10 0x004197c8 in cmd_list (tag=0x7f3720 42.117, listargs=0x7fffcc977510) at imapd.c:6036 #11 0x0040c9ee in cmdloop () at imapd.c:1574 #12 0x0040aea5 in service_main (argc=2, argv=0x7b9010, envp=0x7fffcc97b650) at imapd.c:946 #13 0x00409ba4 in main (argc=6, argv=0x7fffcc97b618, envp=0x7fffcc97b650) at service.c:582 - M.MengeTel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Mail not visible after restore from backup.
Are you sure you've running a version of reconstruct which matches your installation? I ask because the man page for reconstruct from 2.3.16 shows both -r and -f as permissible: -r Recursively reconstruct all sub-mailboxes of the mailboxes or mailbox prefixes given as arguments. -f Examine the filesystem underneath mailbox, adding all directories with a cyrus.header found there as new mailboxes. Useful for restoring mailboxes from backups. from http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/man/reconstruct.8.php Depending upon how you installed Cyrus, from package or source, and which OS/distro you're using, there may be versions of binary utilities laying around from older versions of the software. We've certainly seen that before. Cheers, -nic On 09/15/2014 08:43 AM, Tom Plancon wrote: Version 2.3.16 myEMAILsignature Thomas Plancon CAD/IT Manager B K A Architects, Inc. 142 Crescent Street Brockton, MA 02302 tel: 508 . 583 . 5603 ext 313 fax: 508 . 584 . 2914 www.bkaarchitects.com http://www.bkaarchs.com/ On 9/15/2014 9:40 AM, Egoitz Aurrekoetxea wrote: That's estrange the -r is recursive that should work Which Cyrus version are you running? El 15/09/2014, a las 15:38, Tom Plancon tplan...@bkaarchs.com mailto:tplan...@bkaarchs.com escribió: Hello, Thanks for the response. When I run reconstruct -rf mailbox the response is usage: reconstruct [-r] mailbox. I assume that means it doesn't like the syntax. Thomas Plancon CAD/IT Manager B K A Architects, Inc. 142 Crescent Street Brockton, MA 02302 tel:508 . 583 . 5603 ext 313 fax: 508 . 584 . 2914 www.bkaarchitects.com http://www.bkaarchs.com/ On 9/15/2014 3:15 AM, Egoitz Aurrekoetxea wrote: Hi, try reconstruct -rf mailbox Regards, El 14/09/2014, a las 03:05, Tom Plancon tplan...@bkaarchs.com mailto:tplan...@bkaarchs.com escribió: Hello, I have a user that deleted all mail from his Sent folder. I restored it from a rsync backup, ran reconstruct user.name.Sent. the reconstruct finished instantly, and no emails from the restore can be seen in the user's mail agent, (thunderbird). I konow I've run into this before but can't remember the solution. Any help is greatly appreciated! Thanks! Tom Plancon *Thomas Plancon* CAD/IT Manager B K A Architects, Inc. 142 Crescent Street Brockton, MA 02302 tel: 508 . 583 . 5603 ext 313 fax: 508 . 584 . 2914 www.bkaarchitects.com http://www.bkaarchitects.com/ Cyrus Home Page:http://www.cyrusimap.org/ List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 attachment: nic.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: backup rsync
On 08/30/2014 02:37 PM, Patrick Goetz wrote: On 8/30/2014 10:10 AM, Simon Matter wrote: I suggest -aH to preserve single instance storage in the backup. Does cyrus use a lot of hard links? I use rsync a lot to create snapshot backups, and use hard links across snapshots to preserve space; however, for a single instance backup and unless the filesystem includes hard links (not normal), then the -H won't do much for you. Cyrus uses hard links among copies of the same message in different mailboxes, when singleinstancestore: 1 is set, which is the default. From the man page imapd.conf(5): If enabled, imapd, lmtpd and nntpd attempt to only write one copy of a message per partition and create hard links, resulting in a potentially large disk savings. Of course one should always use -a. The biggest concern I have about backing up mail spools is keeping the index and message stores in sync while the backup is taking place. A long time ago someone suggested using cyrdump, but when I looked into this, I couldn't find any documentation whatsoever. Is cyrdump a real thing, or did I imagine all this? Are you thinking of ctl_mboxlist? It allows one to dump the mailboxes database to a flat file. In an out-of-the-box Cyrus installation the indexes are stored with the messages in the mailbox hierarchy. If you decide to store meta-data separately, you should simply snapshot that at the same time you snapshot your mailstore. At the beginning of this thread, Marcus Schopen wrote this example: ctl_cyrusdb -c ctl_mboxlist -d mailboxes.db.dump stop cyrus lvm snaps start cyrus rsync/var/lib/cyrus/ and /var/spool/cyrus to backup host remove snaps One could simply include any meta-data volumes in the snapshotting process. Cheers, -nic Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Recovering from a broken master...
Wesley, Thanks for your response. This is precisely what we ended up doing. We've got a Perl script which walks LDAP for a user list, and runs sync_client -u user for each account, trapping errors. This gave us a list for reconstruct. In a couple of cases, however, even that didn't remedy the situation, in which cases we resorted to rsync followed by sync_client cleanups. Thanks again. Hopefully this message, with its subject line, will help future unfortunate users grepping the mailing list archives for ideas. Cheers, -nic On 08/11/2014 08:46 AM, Wesley Craig wrote: So, sync server is crashing on the backend you're attempting to replicate back to. Probably the cyrus meta files were corrupted for mailboxes which were actively being written to when you had the array malfunction. To recover, I'd probably run sync client on each individual user to find which users are corrupted. Armed with the list, I'd reconstruct those users and try again. Ideally, you'd get crash reports that you could forward along, since cyrus really ought to be armored against this kind of corruption. After all, why else would you have failed over? :wes On 06 Aug 2014, at 16:03, Nic Bernstein n...@onlight.com wrote: Friends, We've got a simple Murder deployed, 2 front-ends, 1 mupdate-master, 1 backend and 1 replica. Recently, due to an array malfunction, the back-end master took a powder, and we switched to the replica. Now we're trying to recover the original master, and running into lots of problems getting data to sync back. This is all with version 2.4.17-caldav-beta9, from Debian packages, on Ubuntu 14.04 servers. For the record, the servers are KVM QEMU VMs, tho I doubt that matters at all. We've got the roles reversed just fine with changes to the various cyrus.conf and imapd.conf files, and are not worried about that being a problem. Everything is working fine as far as authentication/authorization, etc. It's just the replication that's fubar. We're seeing this sort of error in the logs on the (new) master side: ... Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Promoting: MAILBOX user.connie.yadda - USER connie Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Promoting: MAILBOX user.elly.Junk - USER elly Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Error in do_sync(): bailing out! Bad protocol Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Processing sync log file /var/lib/imap/sync/log-27000 failed: Bad protocol And this on the (new) replica side: Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: executed Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: accepted connection Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: cmdloop(): startup Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: login: mailbox.ia.occinc.com [192.168.220.24] mailproxy PLAIN User logged in Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: created decompress buffer of 4102 bytes Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: created compress buffer of 4102 bytes Aug 6 18:20:59 mailbox.wi cyrus/syncserver[13158]: Repacking mailbox user.ndlocate Aug 6 18:21:05 mailbox.wi master[11811]: service syncserver pid 13158 in BUSY state: terminated abnormally In some cases we've seen problems we believe are due to issues with a particular user's mailbox, and have fixed those by blowing away the user's mailbox hierarchy on the replica, rsync-ing it back over from the master, and then doing a user-sync. But there are hundreds of users, so that's not a practical general solution. The mailstore is currently about 130GB in size, and the master and replica are in different data centers, with only about 3 or 4Mbps available between them (depending upon time of day). This is fine in the normal course of rolling replication, but makes simply re-replication the entire thing a major pain, if that's the only option. So, what's causing this problem, and what's the best course of action to recover from this sort of situation? Thanks in advance for your consideration, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Recovering from a broken master...
Friends, We've got a simple Murder deployed, 2 front-ends, 1 mupdate-master, 1 backend and 1 replica. Recently, due to an array malfunction, the back-end master took a powder, and we switched to the replica. Now we're trying to recover the original master, and running into lots of problems getting data to sync back. This is all with version 2.4.17-caldav-beta9, from Debian packages, on Ubuntu 14.04 servers. For the record, the servers are KVM QEMU VMs, tho I doubt that matters at all. We've got the roles reversed just fine with changes to the various cyrus.conf and imapd.conf files, and are not worried about that being a problem. Everything is working fine as far as authentication/authorization, etc. It's just the replication that's fubar. We're seeing this sort of error in the logs on the (new) master side: ... Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Promoting: MAILBOX user.connie.yadda - USER connie Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Promoting: MAILBOX user.elly.Junk - USER elly Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Error in do_sync(): bailing out! Bad protocol Aug 6 18:21:28 mailbox.ia cyrus/sync_client[27000]: Processing sync log file /var/lib/imap/sync/log-27000 failed: Bad protocol And this on the (new) replica side: Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: executed Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: accepted connection Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: cmdloop(): startup Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: login: mailbox.ia.occinc.com [192.168.220.24] mailproxy PLAIN User logged in Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: created decompress buffer of 4102 bytes Aug 6 18:20:37 mailbox.wi cyrus/syncserver[13158]: created compress buffer of 4102 bytes Aug 6 18:20:59 mailbox.wi cyrus/syncserver[13158]: Repacking mailbox user.ndlocate Aug 6 18:21:05 mailbox.wi master[11811]: service syncserver pid 13158 in BUSY state: terminated abnormally In some cases we've seen problems we believe are due to issues with a particular user's mailbox, and have fixed those by blowing away the user's mailbox hierarchy on the replica, rsync-ing it back over from the master, and then doing a user-sync. But there are hundreds of users, so that's not a practical general solution. The mailstore is currently about 130GB in size, and the master and replica are in different data centers, with only about 3 or 4Mbps available between them (depending upon time of day). This is fine in the normal course of rolling replication, but makes simply re-replication the entire thing a major pain, if that's the only option. So, what's causing this problem, and what's the best course of action to recover from this sort of situation? Thanks in advance for your consideration, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Mailbox last access - most reliable source
On 07/07/2014 03:12 PM, Joseph Brennan wrote: Fabio S. Schmidt fa...@improve.inf.br wrote: I actually need to consider only the last access via IMAP or POP protocols. That can be very misleading, because a device may keep checking for new mail for a very long time after the user abandons the account. A recent timestamp on the user.seen file should be good, but that seems to update mysteriously sometimes. The lastupdated: field of cyradm's info mailbox command will show the last time the mailbox was updated in any way, so that includes deliveries. The timestamp of the user.seen file will only reflect the last time that the seen state of anything in the mailbox changed, but does not tell you when the mailbox was last accessed. I think you'd need to derive this information some other way, such as from authentication logs. Of course the reliability and accessibility of that will depend on your authentication mechanisms. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyrus super user -- able to login in as any user with a superuser password
On 06/18/2014 09:55 AM, mayak wrote hi all, thanks! the proxyservers option is working great -- with one login, i am able to use imapfilter to groom all account/folders of old messages ... cheers Mayak, If that is your purpose, you may be much better served by simply using mailbox annotations and the built-in expiration system. For example, a client of ours uses this script as a daily cronjob to make sure the proper annotations are set on all desired mailboxes: #!/bin/sh # # set_cyrus_annotations.sh - Set the standard annotations for the Spam, #Trash and systems mailbvoxes so they expire #properly. # USER=cyradmin PASS=password HOST=localhost cyradm -u $USER -w $PASS $HOST _EOF_ mboxcfg systems expire 60 mboxcfg user.%.Spam expire 7 mboxcfg user.%.Trash expire 2 _EOF_ The normal expiration mechanisms (cyr_expire in cyrus.conf) of Cyrus will then clean up those mailboxes on the desired schedule. The biggest advantage is that this all happens local to the server, without tying up network resources with protocol discussions, local processing, etc. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Fileinto problem with sieve on a shared mailbox with altnamespace enabled
On 04/21/2014 01:58 PM, Nic Bernstein wrote:
Folks,
I've just added a sieve script like this to file some automated messages
into a specific client-related mailbox:
#
# Sieve script to put customer Rancid messages into specific client
folders
#
require fileinto;
if header :contains [from] ran...@example.com {
fileinto tech.support.rancid-example-com;
stop;
}
if header :contains [from] ran...@example.net {
fileinto tech.support.rancid-example-net;
stop;
}
### End Script ###
Our shared folder hierarchy looks like this:
tech (\HasChildren)
tech.support (\HasChildren)
tech.support.rancid-example-com (\HasNoChildren)
tech.support.rancid-example-net (\HasNoChildren)
However, when sieve runs the script, I get this error:
Apr 21 12:13:27 ujiji cyrus/lmtpunix[18149]: sieve runtime error
for id \
20140421171322.0BAB12955C6@monitor: Fileinto: Mailbox does not
exist
I suspect that altnamespace is the culprit, but if that's the case, what
would the proper name for the destination mailbox be? Would it be
Shared Folders.tech.support.rancid-example-com? Not sure what to do here.
Thanks in advance for any and all help,
-nic
To follow up to my own message, for the benefit of future searchers, the
answer is Yes, the proper target for sieve scripts for shared
mailboxes, when altnamespace is on, is to prepend whatever the
`*sharedprefix:*' value is. as in my example above.
Cheers,
-nic
--
Nic Bernstein n...@onlight.com
Onlight llc. www.onlight.com
219 N. Milwaukee St., Ste. 2A v. 414.272.4477
Milwaukee, Wisconsin 53202 f. 414.290.0335
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Fileinto problem with sieve on a shared mailbox with altnamespace enabled
Folks,
I've just added a sieve script like this to file some automated messages
into a specific client-related mailbox:
#
# Sieve script to put customer Rancid messages into specific client
folders
#
require fileinto;
if header :contains [from] ran...@example.com {
fileinto tech.support.rancid-example-com;
stop;
}
if header :contains [from] ran...@example.net {
fileinto tech.support.rancid-example-net;
stop;
}
### End Script ###
Our shared folder hierarchy looks like this:
tech (\HasChildren)
tech.support (\HasChildren)
tech.support.rancid-example-com (\HasNoChildren)
tech.support.rancid-example-net (\HasNoChildren)
However, when sieve runs the script, I get this error:
Apr 21 12:13:27 ujiji cyrus/lmtpunix[18149]: sieve runtime error
for id \
20140421171322.0BAB12955C6@monitor: Fileinto: Mailbox does not
exist
I suspect that altnamespace is the culprit, but if that's the case, what
would the proper name for the destination mailbox be? Would it be
Shared Folders.tech.support.rancid-example-com? Not sure what to do here.
Thanks in advance for any and all help,
-nic
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: perl script
On 04/16/2014 06:35 AM, Sandra Regina de Souza wrote: Hello! I'm trying to run a perl script which one do a subscribe into a user.test.spam mailbox, for example. The mailbox user.test is ok (has been created first, and is in use). But I have to create another mailbox, for every user in cyrus imap,named for example spam. When I try to do a $err = $imap-subscribe(user.bob), after $my $Err = $Imap-create(user.test.spam) it does nothing. My cyrus imap version is : v2.4.16. How can I do a subscribe in perl script? Thanks in advance. sandra Sandra, Which library are you using for this? You show us the method $imap-subscribe, but we don't know what kind of object $imap is. If you're using the Net::IMAP library, then you may say $imap-subscribe(user.bob) once the session is in the authenticated or selected states (as per the man page). If you're using Cyrus::IMAP::Admin, there is no subscribe method. The Mail::IMAPClient library has a subscribed method much like that in Net::IMAP. I'm sure if we know more about what tools you're using and what you're doing with them, someone can help. -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Remove quota using Cyrus::IMAP::Admin?
Sebastian, Please take a look at this thread from January of last year, which discusses the issue in full. http://comments.gmane.org/gmane.mail.imap.cyrus/36194 -nic On 07/25/2013 10:51 AM, Sebastian Hagedorn wrote: Hi, you can remove the quota for a mailbox with cyradm by setting the quota to none: $ cyradm cyrus Password: server sq user/xxx none remove quota server But when I try to do the same using Cyrus::IMAP::Admin I get an error, because a number is expected as argument. Is that a bug or a feature? Here's my code: $result = $imapcon-setquota(user/$user, STORAGE, $quota); If I set $quota to 'none', I get: Error: xxx, STORAGE: none: not a number Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: sync_client failing with Fatal error: failed to finish reading file!
On 06/17/2013 01:00 AM, Bron Gondwana wrote: On Wed, Jun 12, 2013, at 06:07 AM, Nic Bernstein wrote: Checking the source for dlist.c, here is the context for this error [printfile()]: SNIP No, if size 0 then we've read PAST the end of the file - which is also totally bogus. I can see a case for while (size 0) on the loop though, for this exact case, so we drop out earlier than EOF. There are only two ways to exit that loop: either size gets down to zero, or fread returns a non-positive value. From the man page: RETURN VALUE On success, fread() and fwrite() return the number of items read or written. This number equals the number of bytes transferred only when size is 1. If an error occurs, or the end of the file is reached, the return value is a short item count (or zero). fread() does not distinguish between end-of-file and error, and callers must use feof(3) and ferror(3) to determine which occurred. So we could certainly make the code better about reporting the cause of the error. I suspect 99% probability file permissions problems (your 'cyrus' user can't read it, but can stat it) and 1% probability a corrupt filesystem with that file contents being unreadable. It's probably the very first fread which is failing. The directories and files are all user=cyrus, group=mail and all perms seem to be correct: 700 for directories and 600 for files. Given that we only see this on the middle system in a replication chain, we suspect that perhaps the sync_server is still writing the file while the sync_client starts to slurp it in. Any chance this is the case? What sucks for us about this is that sync_client dies, so the host at the end of the chain falls out of sync, requiring manual intervention. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
sync_client failing with Fatal error: failed to finish reading file!
Friends, We've been running a pair of replicas with Ken's cyrus-imapd-2.4.17-caldav-beta (4 and 5) recently, in preparation for a migration away from a single 2.4.11 server. The configuration is the 2.4.11 box is the master, it replicates to the first 2.4.17 box, which is also running a sync_client instance to replicate to the second 2.4.17 box. The intent is that once the client is ready, we abandon the 2.4.11 box and the first 2.4.17 instance becomes the master and the second the replica. This has all been running pretty well, but lately the sync_client on the middle box has failed a few times. Each time, I see this in the logs (The 2.4.11 master server has nothing in this time interval): # The 2.4.17 replica -- in the middle: Jun 11 13:36:09 mailbox cyrus/sync_client[29338]: sync_client RESTART succeeded Jun 11 13:36:10 mailbox cyrus/sync_client[29338]: COMPRESS received NO response: Compression already active: DEFLATE Jun 11 13:36:10 mailbox cyrus/sync_client[29338]: Failed to enable compression, continuing uncompressed Jun 11 13:36:52 mailbox cyrus/sync_client[29338]: Fatal error: failed to finish reading file! # The 2.4.17 replica, end of the chain: Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: accepted connection Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: cmdloop(): startup Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: login: mailbox.wi.occinc.com [192.168.190.24] mailproxy PLAIN User logged in Jun 11 13:36:59 ia24 cyrus/syncserver[21234]: IOERROR: reading message: unexpected end of file Can anyone tell me what this is indicative of? A search of the web doesn't turn up any hits for Fatal error: failed to finish reading file! Thanks in advance! -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: sync_client failing with Fatal error: failed to finish reading file!
List,
Checking the source for dlist.c, here is the context for this error
[printfile()]:
static void printfile(struct protstream *out, const struct dlist *dl)
{
char buf[4096];
struct stat sbuf;
FILE *f;
unsigned long size;
f = fopen(dl-sval, r);
if (!f) {
syslog(LOG_ERR, IOERROR: Failed to read file %s, dl-sval);
prot_printf(out, NIL);
return;
}
if (fstat(fileno(f), sbuf) == -1) {
syslog(LOG_ERR, IOERROR: Failed to stat file %s, dl-sval);
prot_printf(out, NIL);
fclose(f);
return;
}
size = sbuf.st_size;
if (size != dl-nval) {
syslog(LOG_ERR, IOERROR: Size mismatch %s (%lu != MODSEQ_FMT ),
dl-sval, size, dl-nval);
prot_printf(out, NIL);
fclose(f);
return;
}
prot_printf(out, %%{);
prot_printastring(out, dl-part);
prot_printf(out, );
prot_printastring(out, message_guid_encode(dl-gval));
prot_printf(out, %lu}\r\n, size);
while (size) {
int n = fread(buf, 1, (size 4096 ? 4096 : size), f);
if (n = 0) break;
prot_write(out, buf, n);
size -= n;
}
fclose(f);
if (size) fatal(failed to finish reading file!, EC_IOERR);
}
The only way we can see this happening is if size 0; in other words,
something has written more into the file since we opened it. Is that a
correct interpretation? If so, the error message doesn't really jive
with the error condition. Shouldn't the test be:
if (size 0) fatal...
instead? If size 0, then manifestly we have finished reading the file.
Cheers,
-nic
On 06/11/2013 01:34 PM, Nic Bernstein wrote:
Friends,
We've been running a pair of replicas with Ken's
cyrus-imapd-2.4.17-caldav-beta (4 and 5) recently, in preparation for
a migration away from a single 2.4.11 server. The configuration is
the 2.4.11 box is the master, it replicates to the first 2.4.17 box,
which is also running a sync_client instance to replicate to the
second 2.4.17 box. The intent is that once the client is ready, we
abandon the 2.4.11 box and the first 2.4.17 instance becomes the
master and the second the replica.
This has all been running pretty well, but lately the sync_client on
the middle box has failed a few times. Each time, I see this in the
logs (The 2.4.11 master server has nothing in this time interval):
# The 2.4.17 replica -- in the middle:
Jun 11 13:36:09 mailbox cyrus/sync_client[29338]: sync_client RESTART
succeeded
Jun 11 13:36:10 mailbox cyrus/sync_client[29338]: COMPRESS received NO
response: Compression already active: DEFLATE
Jun 11 13:36:10 mailbox cyrus/sync_client[29338]: Failed to enable
compression, continuing uncompressed
Jun 11 13:36:52 mailbox cyrus/sync_client[29338]: Fatal error: failed to
finish reading file!
# The 2.4.17 replica, end of the chain:
Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: accepted connection
Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: cmdloop(): startup
Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: login:
mailbox.wi.occinc.com [192.168.190.24] mailproxy PLAIN User logged in
Jun 11 13:36:59 ia24 cyrus/syncserver[21234]: IOERROR: reading message:
unexpected end of file
Can anyone tell me what this is indicative of? A search of the web
doesn't turn up any hits for Fatal error: failed to finish reading file!
Thanks in advance!
-nic
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyrus-imapd-2.4.17-caldav-beta1 released
Ken, Much thanks for this -- it's quite welcome indeed. Have you got any documentation on the specifics of collection management, rights assignment, etc.? Given that most clients currently available are pretty brain-dead about creating new calendars, address books, etc., it would be nice to know if it's possible to handle this manually or via the underlying mailboxes. Cheers, -nic On 05/07/2013 10:23 AM, Ken Murchison wrote: Ken Murchison wrote: We are please to announce the release of Cyrus IMAP with integrated calendaring and contacts for beta testing. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. More specifically, the CalDAV and CardDAV modules should be considered beta. The RSS module has been running in production at CMU for over a year and has proven the main HTTP code to be stable. -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyrus-imapd-2.4.17-caldav-beta1 released
On 05/09/2013 08:36 AM, Ken Murchison wrote: Nic, The doc/install-http.html file hopefully should tell you everything you need to know. If not, let me know. Ah, now I see it. Couldn't see the tree for the forest. :) The server will automatically create a Default calendar and addressbook, for dumb clients like Lightning that can't create their own. Otherwise, an admin can create additional collections just by creating a mailbox in the correct location. We are toying with the idea of creating a webpage that allows the end-user to admin their collections (create, delete, rename, acl management) themselves for those not using smart clients like iCal. This would be nice, if possible. We've been working with Davical and, more recently, OwnCloud, for ourselves and considering what to promote to our clients (mostly Open Systems or Windows based) and each have their short comings. Davical seems pretty robust, but the management GUI is not very friendly. OwnCloud feels less robust, but is rapidly developing (which brings its own share of movign target problems). This is not meant to disparage either of these packages, but rather to express the challenges we see in bringing them to a broader audience. Thanks again for your work! -nic On 05/09/2013 09:17 AM, Nic Bernstein wrote: Ken, Much thanks for this -- it's quite welcome indeed. Have you got any documentation on the specifics of collection management, rights assignment, etc.? Given that most clients currently available are pretty brain-dead about creating new calendars, address books, etc., it would be nice to know if it's possible to handle this manually or via the underlying mailboxes. Cheers, -nic On 05/07/2013 10:23 AM, Ken Murchison wrote: Ken Murchison wrote: We are please to announce the release of Cyrus IMAP with integrated calendaring and contacts for beta testing. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. More specifically, the CalDAV and CardDAV modules should be considered beta. The RSS module has been running in production at CMU for over a year and has proven the main HTTP code to be stable. -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Partition selection algorithm and ZFS filesystems
Friends, The man page for imapd.conf contains this note (emphasis added): defaultpartition: none The partition name used by default for new mailboxes. *If not specified, the partition with the most free space will be used for new mailboxes.* However, with the advent of ZFS and other filesystems with Thin Provisioning, it is common for all partitions to have the same amount of free space reported by the filesystem. For example, this from a client's system with 30 data partitions and 30 meta-data partitions: data2/mailstore/1 4.9T 18G4.9T 0% /var/mailstores/1 data2/mailstore/104.9T 12G4.9T 0% /var/mailstores/10 data2/mailstore/114.9T 10G4.9T 0% /var/mailstores/11 data2/mailstore/124.9T 16G4.9T 0% /var/mailstores/12 data2/mailstore/134.9T 15G4.9T 0% /var/mailstores/13 data2/mailstore/144.9T 16G4.9T 0% /var/mailstores/14 ... data2/imapmeta/1 4.9T1.2G4.9T 0%/var/imapmeta/1 data2/imapmeta/10 4.9T283M4.9T 0%/var/imapmeta/10 data2/imapmeta/11 4.9T370M4.9T 0%/var/imapmeta/11 data2/imapmeta/12 4.9T251M4.9T 0%/var/imapmeta/12 data2/imapmeta/13 4.9T369M4.9T 0%/var/imapmeta/13 data2/imapmeta/14 4.9T230M4.9T 0%/var/imapmeta/14 ... In light of this, we intend to have our account creation scheme base its choice on space used, rather than free space. But, would it be possible, in light of the wide spread adoption of thin provisioned filesystems, to have the default behavior changed in 2.5 or some future version of Cyrus imapd? Thanks in advance, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Injecting a mail folder into a users inbox/restore from backup
On 12/12/2012 08:16 AM, Michael Neumann wrote: Am 12.12.2012 10:20, schrieb Sebastian Hagedorn: It pays to read the archive: https://lists.andrew.cmu.edu/pipermail/info-cyrus/2012-January/035731.html Yes, sorry and thanks, that clarifies it. For what it's worth, you can also set expire times, for specific mailboxes, via annotations. We frequently use a script like this to handle such a task on a regular basis, to accommodate users who delete and recreate mailboxes we wish to handle exceptionally: - #!/bin/sh # # set_cyrus_annotations.sh - Set the standard annotations for the Spam, #Trash and systems mailboxes so they expire #properly. # USER=cyrus user PASS=secret HOST=localhost cyradm -u $USER -w $PASS $HOST _EOF_ mboxcfg systems expire 60 mboxcfg user/%/Spam expire 7 mboxcfg user/%/Trash expire 2 _EOF_ - Also, as to documentation, the Kolab folks have some good info available here http://www.cyrusimap.org/%7Evanmeeuwen/cyrus-imapd-2.4-docs/Administrator_Guide/html/chap-Administrator_Guide-Deleting_and_Undeleting_Messages_and_Folders.html, including a step-by-step guide to locating and restoring (via cyradm rename) deleted mailboxes. This is the way to go, and the Perl example there shows how to make sense of the datestamp on folders in the DELETED hierarchy. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Problem recover replica [CheckReplication.pm]
Bron, I'm in need of something like this, but before I delve in too far, does this still work well with 2.4.17? Will it still work with 2.5.x? Thanks! -nic On 02/16/2012 01:25 PM, Bron Gondwana wrote: On Thu, Feb 16, 2012 at 01:32:49PM +0100, Bron Gondwana wrote: It's a big hairy piece of perl. Latest copy attached. [Attachment CheckReplication.pm 22,006 bytes removed] -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
problem with sync_server and CYRUS_SERVICE
Folks,
I have been building and using Cyrus IMAP since 1995, but I've just run
into an issue I've never encountered before. I've had the same issue
with 2.4.16 and 2.5, both built from sources retrieved via Git. This is
on Ubuntu 12.04.01 LTS, in LXC containers on an Ubuntu 12.04.01 LTS host.
When I start cyrus I see this in syslog:
Oct 23 19:08:26 mailbox master[1323]: about to exec
/usr/lib/cyrus/bin/sync_server
Oct 23 19:08:26 mailbox sync_server: could not getenv(CYRUS_SERVICE); exiting
Oct 23 19:08:26 mailbox master[1313]: process 1323 exited, status 70
Oct 23 19:08:26 mailbox master[1313]: unable to setsocketopt(IP_TOS):
Operation not supported
I don't think the getenv problem is related to the IP_TOS issue, is it?
I've checked all around for what can cause the getenv(CYRUS_SERVICE)
issue, which was typically (in the old days) interference from inetd,
but that can't be the problem here, since there is no inetd running on
the container or the parent host.
/etc/cyrus.conf looks like this:
START {
recover cmd=/usr/sbin/cyrus ctl_cyrusdb -r
idled cmd=idled
tlsprunecmd=/usr/sbin/cyrus tls_prune
syncserver cmd=/usr/lib/cyrus/bin/sync_server listen=csync
}
SERVICES {
imapcmd=imapd -U 30 listen=imap prefork=0
pop3cmd=pop3d -U 30 listen=pop3 prefork=0 maxchild=50
lmtpcmd=lmtpd listen=lmtp prefork=1
sieve cmd=timsieved listen=sieve prefork=0
notify cmd=notifyd listen=/var/run/cyrus/socket/notify
proto=udp prefork=1
}
EVENTS {
checkpoint cmd=/usr/sbin/cyrus ctl_cyrusdb -c period=30
delprunecmd=/usr/sbin/cyrus expire -E 3 -D 60 -X 60 at=0401
tlsprunecmd=/usr/sbin/cyrus tls_prune at=0401
squatter_1 cmd=/usr/bin/nice -n 19 /usr/sbin/cyrus squatter -s
period=180
squatter_a cmd=/usr/sbin/cyrus squatter at=0117
}
and /etc/services contains this:
# Local services
lmtp 24/tcp # Cyrus IMAP LMTP transport
csync2005/tcp# Cyrus IMAP replication
Any thoughts?
Cheers,
-nic
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: problem with sync_server and CYRUS_SERVICE
Never mind -- realized I need to list sync_server under SERVICES and not
START.
Cheers,
-nic
On 10/23/2012 02:24 PM, Nic Bernstein wrote:
Folks,
I have been building and using Cyrus IMAP since 1995, but I've just
run into an issue I've never encountered before. I've had the same
issue with 2.4.16 and 2.5, both built from sources retrieved via Git.
This is on Ubuntu 12.04.01 LTS, in LXC containers on an Ubuntu
12.04.01 LTS host.
When I start cyrus I see this in syslog:
Oct 23 19:08:26 mailbox master[1323]: about to exec
/usr/lib/cyrus/bin/sync_server
Oct 23 19:08:26 mailbox sync_server: could not getenv(CYRUS_SERVICE);
exiting
Oct 23 19:08:26 mailbox master[1313]: process 1323 exited, status 70
Oct 23 19:08:26 mailbox master[1313]: unable to setsocketopt(IP_TOS):
Operation not supported
I don't think the getenv problem is related to the IP_TOS issue, is
it? I've checked all around for what can cause the
getenv(CYRUS_SERVICE) issue, which was typically (in the old days)
interference from inetd, but that can't be the problem here, since
there is no inetd running on the container or the parent host.
/etc/cyrus.conf looks like this:
START {
recover cmd=/usr/sbin/cyrus ctl_cyrusdb -r
idled cmd=idled
tlsprunecmd=/usr/sbin/cyrus tls_prune
syncserver cmd=/usr/lib/cyrus/bin/sync_server listen=csync
}
SERVICES {
imapcmd=imapd -U 30 listen=imap prefork=0
pop3cmd=pop3d -U 30 listen=pop3 prefork=0 maxchild=50
lmtpcmd=lmtpd listen=lmtp prefork=1
sieve cmd=timsieved listen=sieve prefork=0
notify cmd=notifyd listen=/var/run/cyrus/socket/notify
proto=udp prefork=1
}
EVENTS {
checkpoint cmd=/usr/sbin/cyrus ctl_cyrusdb -c period=30
delprunecmd=/usr/sbin/cyrus expire -E 3 -D 60 -X 60 at=0401
tlsprunecmd=/usr/sbin/cyrus tls_prune at=0401
squatter_1 cmd=/usr/bin/nice -n 19 /usr/sbin/cyrus squatter -s
period=180
squatter_a cmd=/usr/sbin/cyrus squatter at=0117
}
and /etc/services contains this:
# Local services
lmtp24/tcp # Cyrus IMAP LMTP
transport
csync 2005/tcp# Cyrus IMAP replication
Any thoughts?
Cheers,
-nic
--
Nic bernstein...@onlight.com
Onlight, Inc.www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Importance of servername canonicalization - can/should this be improved?
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 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 -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cannot xfer or rename mailbox in murder
On 05/10/2012 10:47 AM, Marc Patermann wrote: Nic, Nic Bernstein schrieb (04.05.2012 14:32 Uhr): In trying to bring up a murder with 2.4.10 just out of curiosity: Why do you start testing with 2.4.10, which is 3/4 of a year old, and not 2.4.16? This is an in-place system, not just a test platform, so that's one reason. Secondly, at the time we actually got the go-ahead, there was a bug in the then-current release (2.4.14, I believe) which caused problems which we could not cope with. Thirdly, we have been tracking the changelogs, and felt that aside from the fix to the -1 quota issue introduced in 2.4.12, there wasn't anything too important out there. Finally, the main server is an old, hard to support, version of Ubuntu, which we want to move off of before we make any further software packages. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cannot xfer or rename mailbox in murder
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 xfer user.nic mailbox.wi
xfermailbox: bad parameters to function
mail 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 xfer user.nic mailbox.wi
xfermailbox: The remote Server(s) denied the operation
mailbox 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 hostmail
-- cyradmin Fri May 4 07:01:01 2012
13361328614 RLIST
1336132861* LIST (\Noselect) .
4 OK Completed (0.000 secs)
13361328705 XFER user.nic mailbox.wi
13361328715 NO bad parameters to function
13361328986 RENAME user.nic user.nic mailbox.wi
13361328986 NO The remote Server(s) denied the operation
On hostmailbox.wi
-- murder Fri May 4 07:01:10 2012
1336132871Q01 LOGOUT
1336132871* BYE LOGOUT received
Q01 OK Completed
On hostpostman (with clock drift)
-- postman Fri May 4 07:03:26 2012
1336133006X0 ACTIVATE {8+}
user.nic {26+}
mailbox.occinc.com!default {63+}
nic lrswipcda admin d cyrus lrswipkxtea cyradmin
lrswipkxtecda
1336133006X0 OK done
1336133006Q01 LOGOUT
1336133006Q01 OK bye-bye
And from the second:
On hostmailbox.wi
-- murder Fri May 4 07:14:51 2012
1336133691Q01 SETQUOTA {9+}
+user.nic (STORAGE 350)
1336133691Q01 NO Permission denied
1336133691Q01 LOGOUT
1336133691* BYE LOGOUT received
Q01 OK Completed
-- murder Fri May 4 07:15:00 2012
1336133700Q01 SETQUOTA {9+}
+user.nic (STORAGE 350)
1336133700Q01 NO Permission denied
1336133700Q01 LOGOUT
1336133700* BYE LOGOUT received
Q01 OK Completed
On hostpostman (again with clock drift)
-- postman Fri May 4 07:16:38 2012
1336133798X0 ACTIVATE {8+}
user.nic {26+}
mailbox.occinc.com!default {63+}
nic lrswipcda admin d cyrus lrswipkxtea cyradmin
lrswipkxtecda
1336133798X0 OK done
1336133798Q01 LOGOUT
1336133798Q01 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
--
Nic Bernstein n...@onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
Cyrus Home
Re: Cannot xfer or rename mailbox in murder
On 05/04/2012 09:23 AM, Dan White wrote:
On 05/04/12 07:32 -0500, Nic Bernstein wrote:
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 xfer user.nic mailbox.wi
xfermailbox: bad parameters to function
mail 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 xfer user.nic mailbox.wi
xfermailbox: The remote Server(s) denied the operation
mailbox 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 hostmail
-- cyradmin Fri May 4 07:01:01 2012
13361328614 RLIST
1336132861* LIST (\Noselect) .
4 OK Completed (0.000 secs)
13361328705 XFER user.nic mailbox.wi
13361328715 NO bad parameters to function
13361328986 RENAME user.nic user.nic mailbox.wi
13361328986 NO The remote Server(s) denied the operation
On hostmailbox.wi
-- murder Fri May 4 07:01:10 2012
1336132871Q01 LOGOUT
1336132871* BYE LOGOUT received
Q01 OK Completed
On hostpostman (with clock drift)
-- postman Fri May 4 07:03:26 2012
1336133006X0 ACTIVATE {8+}
user.nic {26+}
mailbox.occinc.com!default {63+}
niclrswipcdaadmindcyruslrswipkxtea
cyradminlrswipkxtecda
1336133006X0 OK done
1336133006Q01 LOGOUT
1336133006Q01 OK bye-bye
And from the second:
On hostmailbox.wi
-- murder Fri May 4 07:14:51 2012
1336133691Q01 SETQUOTA {9+}
+user.nic (STORAGE 350)
1336133691Q01 NO Permission denied
1336133691Q01 LOGOUT
1336133691* BYE LOGOUT received
Q01 OK Completed
-- murder Fri May 4 07:15:00 2012
1336133700Q01 SETQUOTA {9+}
+user.nic (STORAGE 350)
1336133700Q01 NO Permission denied
1336133700Q01 LOGOUT
1336133700* BYE LOGOUT received
Q01 OK Completed
On hostpostman (again with clock drift)
-- postman Fri May 4 07:16:38 2012
1336133798X0 ACTIVATE {8+}
user.nic {26+}
mailbox.occinc.com!default {63+}
niclrswipcdaadmindcyruslrswipkxtea
cyradminlrswipkxtecda
1336133798X0 OK done
1336133798Q01 LOGOUT
1336133798Q01 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.
Which version are you running on these 4 systems? Are they all
the same?
Yes, they are all 2.4.10.
The doc at:
http://cyrusimap.org/docs/cyrus-imapd/2.4.16/install-murder.php
claims that the proxy_authenticating user will need to be a full admin
(section: Additional backend configuration):
admins: cyrus cyradmin murder
imapd.conf settings, required and optional, for frontends vs. backends vs. mupdate masters?
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 -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus.index file
Bron, Thanks so much for these tools. Is there anything interesting in CacheFile.pm or HeaderFile.pm which you could share, or is that all Fastmail specific? One assumes that the ME::User and ME::Machine stuff is all Fastmail-centric. Anyhow, thanks for sharing. These already solved some problems for us. Cheers, -nic On 11/07/2011 10:29 AM, Bron Gondwana wrote: The attached bits of perl can read most of the more modern cyrus.index file formats (I haven't backported to version 6 from 2.2.x). Some perl skill required to make it all work though - and you may need to strip out the dependencies on FastMail specific stuff. -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Patch: add new lmtptarget annotation
This looks like a great addition. One question: Where in the documentation should information be added describing this new annotation? Where are available annotations documented currently? Thanks for the contribution! -nic On 05/18/2010 12:47 PM, Wesley Craig wrote: Seems like a reasonable approach and a good patch. I might suggest some feedback, preferably to the deleting / renaming user but a syslog might also do, when the delete / rename failed. Is there a bugzilla number? :wes On 18 May 2010, at 12:38, Stephen Grier wrote: Just submitting a patch I'm supporting locally for consideration. We use shared mailboxes quite extensively for role-based communication. For quite some time we've had a problem with users deleting or renaming mailboxes into which we deliver mail. We can, and do, use IMAP ACLs to dissallow users from deleting the delivery target mailbox. But when a user creates a child mailbox it inherits the ACLs of the parent, and the user is then not able to delete or rename the sub folder. As a fix, I have written a patch against 2.3.16 to add a new lmtptarget mailbox annotation. When enabled, Cyrus won't allow the mailbox to be deleted or renamed. We can then set whatever ACLs we want inherited by child mailboxes, happy in the knowledge the user won't blat the mailbox and cause mail to bounce. The rationale here is that Cyrus treats user.foo with special significance as a delivery target, but does not do the same for shared mailboxes because there is no way for Cyrus to know which shared mailboxes we intend to deliver mail into. Using a mailbox annotation seems a nice way of flagging this. Patch attached. Comments welcome. 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 -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 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
Re: cyrus imap quota
The text file format is a little tricky, as there is trailing whitespace which must be preserved. The quota command is fast, so it is trivial to make a script to modify the quotas on the fly. I have a perl script which sucks quota information of of an LDAP directory and uses Cyrus::IMAP::Admin to update the files. It is fast enough to run every five minutes without any trouble. I've attached my scripts if you want to take a look. Cheers, -nic On 04/07/2010 09:55 AM, Holm Kapschitzki wrote: Simon Matter schrieb: Holm Kapschitzki schrieb: on my debian box running cyrus imap, most of the postboxes have a quota of 100 MB configured. The info is stored in a textfile. On the first line there is the currently quota and on the second line there is the real hardquota, for example 10 (100 MB) Its possible to stop the cyrus mailserver und replace the second line with another value without breaking something for all the defined postboxes? Yes that's possible but you should use Cyrus quota command instead which can be done while Cyrus is up and running. And note that quota information can be stores in other database formats which will make the method above unusable. thx for answer. But i had to change over 5 thousend mailboxes. so its impossible to change this boxes step by step. Thats the reason, i asked for changing directly in the textfile. But you say thats impossible cause it can be stores in other database formats. Do i have another possibility? Holm -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 cyrus_get_quota.pl Description: Perl program cyrus_ldap_quota.pl Description: Perl program # cyrus.conf # # configuration file for perl scripts for Intersweep filter # # Copyright (c) Nic Bernstein, May 26, 2004, for # Onlight, llc., 2266 N. Prospect Ave., Suite 610, Milwaukee, WI 53202 # All rights reserved # The LDAP server to bind to $ldap_host = 'localhost'; # The LDAP port number $ldap_port = '389'; # The base DN for the search $base_dn = 'ou=people,dc=example,dc=com'; # The DN to bind as to complete the search $bind_dn = 'uid=proxyuser,ou=systems,dc=example,dc=com'; # The password to bind to LDAP with for the search $bind_pw = 'secret'; # Filter to get usernames $ldap_user_filter = '(objectClass=inetMailUser)'; # Attribute to return for username search $ldap_user_attr = 'uid'; # Attribute to return for quota search $ldap_quota_attr = 'mailQuota'; # Attribute to return for mail search $ldap_mail_attr = mailRoutingAddress; # The IMAP server to login to $imap_host = 'localhost'; # The IMAP user to login as $imap_user = 'cyrus'; # The IMAP port number $imap_port = '143'; # The IMAP delimiter character $delimiter = .; # The password for the IMAP user $imap_pw = 'secret'; # Prefix for IMAP user mailboxes $imap_prefix = 'user'; # Change this to the proper setting for your site # @time = (localtime)[0..5]; # for local time zone usage @time = (gmtime)[0..5]; # for GMT usage # Whitelist mailbox name and attribute %white = ( 'mailbox' = 'Whitelist', 'attribute' = 'amavisWhitelistSender' ); # Blacklist mailbox name and attribute %black = ( 'mailbox' = 'Blacklist', 'attribute' = 'amavisBlacklistSender' ); # Mail domain for re-sending $mail_domain = 'example.com'; # User spam mailbox $spambox = 'Junk'; # Shared mailbox for missed spam $missed_uce = 'Missed-Junk'; # Shared mailbox for non-spam $not_uce = 'Non-Junk'; 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
Re: cyrus + postfix + lmtpd questions [massively OT]
On 03/18/2010 01:41 AM, Simon Matter wrote:
I just want to get this straight. Please, someone clarify his to me.
Consider Cyrus and Postifx runing on different servers and having to
communicate with each other through lmtp.
1)
Here´s the line we all know from cyrus.conf that is gonna bring lmtp
listening on tcp:
lmtp cmd=/usr/local/cyrus/bin/lmtpd listen=lmtp prefork=1
maxchild=100
Is that enough on the cyrus side ?
That look okay, but see below...
2)
posfix's main.cf :
mailbox_transport = inet:[1.2.3.4]:24
Looks also okay.
In postfix, I would suggest using local_transport instead of
mailbox_transport. The reason I make this suggestion has to do with
getting the most out of the postfix processing and delivery options.
One critical change, however, is that instead of alias_maps you must use
virtual_alias_maps. Those are handled a little bit differently, so
check the README files.
Here I would use:
local_transport = lmtp:inet:imap.example.com:2003 -- or whatever
port you're using
If you wish to stick with mailbox_transport, you should still use
lmtp:inet... so postfix knows to talk LMTP and not SMTP for delivery.
From the postfix documentation:
# Specify a string of the form transport:nexthop, where transport is
# the name of a mail delivery transport defined in master.cf. The
# :nexthop part is optional. For more details see the sample transports
# file.
You can always define a more specific transport in master.cf, and then
cite that in your {mailbox|local}_transport line. For example, we often
pair postfix with amavisd-new, and don't want postfix to overrun the
number of amavis processes, so we add this to master.cf:
# A special lmtp instance to feed amavisd. Keep the maxproc field
# below the max_servers value in amavisd.conf
slmtp unix - - n - 14 lmtp
And then have this for our content_filter line:
content_filter = slmtp:127.0.0.1:10023
I would also recommend investigating whether you would benefit from
concurrency limits (in main.cf), such as:
local_destination_concurrency_limit = 300
local_destination_recipient_limit = 300
These may help prevent bottlenecks when you receive messages destined
for large distribution lists.
3)
On some previous reply someone wrote about adding the following to
relay_domains :
example.com lmtp:unix:public/lmtp# for a local LMTP socket
example.com inet:[1.2.3.4]:24# for a remote LMTP socket
and then to extend transport_maps:
transport_maps=hash:/etc/postfix/transports,hash:/etc/postfix/relay_domains.
Cant figure out why this is necesary.
Well, using a simple mailbox_transport like shown in 2) is the easiest
configuration. Of course you can have very complex postfix configs for
example with complicated transport maps but you don't have to make it
complex if your environment doesn't enforce it.
Adding entries like this to relay_domains is necessary only if the
domains in question are not in your mydestinations setting. Having more
than one entry for the same left-hand value (example.com in this case)
is redundant, as the first match wins in postfix map lookups.
4)
And last but not least. How postfix authenticates in anyway so Cyrus
The question is how you want to communicate. In my case I was using a
local trusted network between postfix and cyrus server so I did the
easiest thing which is running lmtpd without authentication and configure
TCP wrapper to accept only connections from the postfix host. Like so:
In /etc/cyrus.conf I had lmtpd listening preauthenticated:
lmtp cmd=lmtpd -a listen=lmtp prefork=1
In /etc/hosts.deny on the cyrus host I had:
# Allow only specific hosts to send mail via LMTP
lmtp: ALL EXCEPT mailhub.domain.tld
To set the postfix credentials for lmtp, use the lmtp_sasl_*
configuration settings. Check the postfix documentation for exhaustive
discourse on this:
http://www.postfix.org/SASL_README.html#client_sasl
Note: you will be dealing with the lmtp client for postfix and the lmtpd
server for cyrus.
Cheers,
-nic
--
Nic Bernstein n...@onlight.com
Onlight llc. www.onlight.com
219 N. Milwaukee St., Suite 2av. 414.272.4477
Milwaukee, Wisconsin 53202
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
Re: Backup LDAP authentication
On Thu, 2009-12-17 at 14:35 +0100, nunatarsuaq wrote: I'd like to configure cyrus to authenticate via an additional backup LDAP server when the main one fails. Is it possible? You didn't give us much to go on, such as which version of Cyrus or which authentication method you are using -- saslauthd or PTS module, but here's a guess. In /etc/imapd.conf you may specify more than one server using the ldap_uri setting for the PTS loader. From the imapd.conf man page: ldap_uri: none Contains a list of the URLs of all the LDAP servers when using the LDAP PTS module. Full details on the PTS loader options are in the imapd.conf man page. If you are using saslauthd, then the proper parameter is ldap_servers in /etc/saslauthd.conf, which takes a space delimited list of ldap URIs: ldap_servers: ldap://ldap1.example.com ldap://ldap2.example.com You may find full details of the configuration of saslauthd in the LDAP_SASLAUTHD file, which is part of the cyrus_sasl distribution. On many systems with binary installations you may find this file somewhere like /usr/share/doc/cyrus-sasl-2.1.22/LDAP_SASLAUTHD Best regards, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 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
Re: Repeating emails
On 11/03/2009 08:44 AM, Tom Plancon wrote: Hello all, Not sure if this is the place to ask this, just trying to track it down. I'm running Cyrus 2.2.12 with Postfix 2.2.2 for only 45 users. Every once in a while, but much more recently, users are receiving emails sent a few days ago - again. The recent repeat emails were all from users on our network sent to all users on our network. The headers appear like regular, legit emails. Any thoughts as to what could be going on or where to begin looking. Any input is greatly appreciated. Thanks. We saw a situation like this some years back, which was caused by misconfiguration between postfix and cyrus. The specific problem we saw was that when a local user sent a message to a group of local users, and one member of the group (mailing list, alias expansion or whatever) generated a 4XX (temp fail) error on delivery, then we would see the whole list get the message again when the cause of the temp fail was cleared up (such as quota getting fixed). I don't remember the exact fix, but it involved switching from mailbox_transport to local_transport in postfix, and switching from alias_maps to virtual_alias_maps as well. This causes the redelivery attempts to occur post-alias expansion rather than pre-alias expansion. I know this is off topic for the cyrus-imapd list, but thought others may find it helpful. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 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
Re: Cyrus Imap server Questions
If you need to do archival, I recommend that instead of using Sendmail, you look into using Postfix. It has an option always_bcc which can be used to send a copy of each message, internal as well as incoming and outgoing, to a particular mailbox. You can then either have that mailbox put into a separate partition. Or, if you need to be able to support legal discovery, such as for Sarbane Oxley compliance, you should look into using a database backed archival solution, such as with the catchmail.py script or dbmail. As for the Outlook performance issues, do your users have Outlook configured for offline mode support? If so, that may be the cause of the problems. Unless these users are using portable computers there is no real need for this mode to be employed. As far as you hardware choices, they seem reasonable. I have systems with hundreds of users working off of SATA arrays quite happily, though for a modern system I would use SAS. You didn't mention which operating system you are using. If you haven't yet chosen, I would recommend looking into one which supports ZFS, which would mean Solaris, OpenSolaris, NexentaOS or FreeBSD, for example. We have a server with 1500 users on similar hardware to your spec, running on FreeBSD with the mailstore in a ZFS volume with RAIDz2 and are quite happy with the performance. With ZFS RAIDz options you do not really need the RAID controller, and all the problems that go along with them. If you are more comfortable with Linux, which does not have ZFS support, then I recommend NexentaOS, which is the OpenSolaris kernel and core with the Ubuntu userland bolted on. You get the best of both worlds that way. Cheers, -nic On 08/16/2009 06:02 PM, John Duthie wrote: I am currently proving a Cyrus Imap / E-Groupware server will work at my company. (replacing FT gate, Competing against Exchange). We are almost at the stage where we will be getting hardware. I need advice on some points. Hardware. archival. ms outlook IMAP support Issues. The Site: ~50 Users , all accessing email all day (heavy usage can be assumed). IT Company/ Call center. Hardware: Single server Dual Xeon 2 core , 8 GB ram looking at a Intel SAS 256 MB RAID card with 2 Arrays 300 GB SAS - OS / and email and 1 TB SATA - Archival would using SATA for the /var/spool/imap folder limit performance much vs using SAS drives ? would raid5 using 3 or 4 1 TB drives be better than the sas raid 1 ? My test server. is a Dualcore E5200 @ 2.50GHz wwith 2GB ram and a 160 SATA drive. I get delays accessing my email in Outlook (1.5 Gb of email) , I suspect this delay is Outlook Outlook is unresponsive for 2-3 minutes at startup (when syncing) I also get a Message now and then about my connection being closed All of the users currently use Outlook. Outlook Auto Archive does not seem to work with IMAP I am 99% sure this is outlook is the problem, are there workarounds available ? (fairly sure I can convert a lot of people to Thunderbird etc , But the Managers like their Outlook!) Is there a way to Archive Older Messages on the server ? maybe ipurge not purging but moving emails ? ( we need to keep every email Archived for Legal reasons etc. ) (still don't know how to get Sendmail to archive all outgoing messages yet either) also: The RHEL5.3 cyrus rc script runs a database backup on shutdown and a restore on bootup - This is a bit dumb, when the backup progess crashed due to a misconfigeration (test server) and the server was Power reset. it the restored a broken backup and I lost the mailbox database .. - Not your fault but something to watch out for. If anyone out there has set-up a similar system and hit a Stumbling block Please let me know !! also if anyone needs a pam config for imap to authenticate against a egroupware mysql database I have it working. TIA John. 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 -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 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
Re: upgrading a 2.2.12 murder to 2.3.14
On 07/16/2009 09:55 AM, Brian Awood wrote: On Thursday 16 July 2009 @ 05:21, Gavin Gray wrote: replication is significantly slower than xfer, but it shouldn't affect the speed of xfer. We wrote some scripts to prevent xfer from getting too far ahead of replication. Since our replicas are a key part of our DR/backup strategy, we never would want to get in a situation where a large amount of data wasn't replicated. In your situation it shouldn't matter since the data is not replicated currently, you should just be able to enable rolling replication and let it catch up. If you still would like to keep xfer from getting too far ahead of replication, I can probably post the scripts we use for this. -Brian Brian, I certainly would be interested in seeing those. Please post them here, or to the Wiki. Best regards, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 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
Re: Upgrade and Migration
On 07/04/2009 03:04 PM, Garry Glendown wrote: I've been following this thread, I will be doing an IMAP migration from an older to a more current version (albeit, not the newest). I was wondering - is imapsync (or IMAP for that matter) able to copy all the folders, permissions etc. by using the cyrus admin user instead of all the separate users? That would save a lot of work ... Yes, it is, if you first grant the admin account all rights to all mailboxes, which is kind of a pain. My preferred approach, if you can afford to have the mailstore off line for the duration, is to simply bulk-change the passwords to some known value prior to commencing the transfer. For example, if you are using unix system passwords, change the /etc/shadow (or whatever) file. If you are using LDAP change the userPassword attributes, etc. You can stash away a copy of the originals and restore them later. Then I would run a script, written in your favorite scripting language, to walk through a list of users and initiate the transfers. You can run multiple transfers at once, just keep an eye on your I/O loads to make sure you aren't just loading down the systems too much. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 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
Re: Cyrus IMAP mailboxes with LDAP
On 07/03/2009 07:55 AM, Evgeniy Arbatov wrote: I am looking for a way to store mailbox quotas and ACLs for Cyrus IMAP in LDAP. Is there a ready made solution for this purpose? If not, how can it be possibly done? Thank you! Attached is a tar file with the tools we use for exactly this purpose. The files are: * cyrus_get_quota.pl: a perl script to generate an LDIF file suitable for import into an LDAP directory with the current user quotas from Cyrus. This is to bootstrap the directory. You must already have the appropriate schema in place. * cyrus_ldap_quota.pl: a perl script to be run periodically from cron to search the directory for modified quotas and push those into cyrus. * cyrus-utils.conf: a configuration file for the above scripts. The schema used is the Srivastava Draft described here: http://www.watersprings.org/pub/id/draft-srivastava-ldap-mail-00.txt You can download the schema here: http://www.netfrag.org/webnews/article.php?id=89group=nfo.links.computing The code is well documented, but feel free to ask if you have any questions. Best regards, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 219 N. Milwaukee St., Ste. 2A v. 414.272.4477 Milwaukee, Wisconsin 53202 f. 414.290.0335 cyrus-ldap-quota.tar.gz Description: GNU Zip compressed data 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
Re: Multiple IMAP connections from new IMAP clients
On 04/23/2009 01:57 PM, Gary Mills wrote: We've had a problem recently with the number of imapd processes on our Cyrus front-end increasing steadily until it filled the process table. It seems that some recent IMAP clients will normally open a number of IMAP connections to their server, and will open more based on user activity. Each of these causes a new imapd process to be spawned on the front-end. As far as I know, the server treats each connection independantly, even though the client may consider one to be permanent and the others to be transient. What are people doing to protect their Cyrus servers from this increasing number of connections, each of which consumes resources on the server? This problem is going to get worse as more sophisticated clients become popular. Is many small front-ends the solution? We've been using imapproxyd to help solve just this kind of problem. Haven't used it with a murder, but expect it could still be useful. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 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
Re: choosing a file system
On 01/09/2009 12:59 AM, Bron Gondwana wrote: On Thu, Jan 08, 2009 at 10:13:25PM -0800, Robert Banz wrote: There's a significant upfront cost to learning a whole new system for one killer feature, especially if it comes along with signifiant regressions in lots of other features (like a non-sucky userland out of the box). The non-sucky userland comment is simply a matter of preference, and bait for a religious war, which I'm not going to bite. Well, yeah. Point. Though most Solaris admins I know tend to pull in gnu or bsd utilities pretty quickly. I'll take that one back, it was baity. So at the risk of entering into a flame war, I must say I am surprised that no one has mentioned Nexenta/OS. http://www.nexenta.org/os They have bolted the Ubuntu/Debian userland onto OpenSolaris to give the Linux lovers out there a linuxy experience with access to all of that shiny new Solaris bling, such as zfs and dtrace. You may want to give it a look-see. Patching is always an issue on any OS, and you do have the choice of running X applications remotely (booting an entire graphic environment!?), and many other tools available such as pca to help you patch on Solaris, which provide many of the features that you're used to. SNIP And I'm seeing there are quite a few third party tools that people have written to ease the pain of patch management on Solaris (I believe it's actually one of the nicer unixes to manage patches on, but when you're used to apt-get, there's a whole world of WTFery in manually downloading and applying patch sets - especially when you get permission denied on a bunch of things that the tool has just suggested as being missing) Oh yeah, apt-get included. Cheers, -nic PS - This has been a very interesting thread to read. Some of us just don't have the exposure to large systems like the participants in this thread have, and this can be very educational. -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 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
Re: Online ChangeLog
Dave McMurtrie wrote: Wesley Craig wrote: Is there some way that interested people can contribute to the overhaul of http://www.cyrusimap.org/ , Dave? I'm sure we could work something out. The only reason that it's not a high priority for us right now is that we don't have spare people to work on it. Ken and I started talking about doing a complete overhaul to the site about a month or two ago. The plan at the time was to get a student employee to help us out, but that plan didn't work out so we put it on hold until next fiscal year. We're very interested in attracting more contributors to the Cyrus project in any capacity, and this is an area that needs a lot of help. Maybe you, Ken and I should have a conversation about this and see what we can come up with. Since the Wiki infrastructure already exists, would it be possible to set up some sort of review or moderation procedure to allow people to contribute to the site via the Wiki? This could also help with cleaning up vague or missing documentation, etc. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 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
Re: Trying to get Sieve working
Does your /etc/services file have an entry for sieve? Mine (FreeBSD 7) is : sieve2000/tcp Of course yours should refer to whichever port you are using (typically 2000). Cheers, -nic David Korpiewski wrote: This is a very odd problem that I can't seem to dig up much information on. I think the problem itself is very simple, I just don't know how to rectify it: I am trying to set of Sieve filtering on a 10.5.4 OSX mail Server. However, when I turn on the mail server, timsieved is never running! In the logs I get: nodename nor servname provided, or not known, disabling sieve At startup when I bring up the mail server (serveradmin start mail). I don't understand what is missing to get sieve running. Does anyone know? The error nodename nor servname provided is a very common error having to do with the getaddrinfo. Any help would be wonderful and very much appreciated. Thank you David -- Nic Bernstein [EMAIL PROTECTED] Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 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
Re: Reconstruct Syntax Help
Try reconstruct -r user.foo, not [EMAIL PROTECTED] You may need to use other switches, depending upon the problem. Check the man page for further details (man reconstruct). -nic On 12/03/2008 04:40 AM, [EMAIL PROTECTED] wrote: Hello List, i am getting: IOERROR: opening /opt/foo/imap/spool/domain/foo/user/archive/2008/12/cyrus.header: No such file or directory What is the syntax for reconstruct to fix this? I tried: reconstruct -r [EMAIL PROTECTED] but i get Mailbox does not exist. Whats the syntax? Thanks, Mario 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 -- Nic Bernstein [EMAIL PROTECTED] Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 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
Re: Murder + Sieve + multiple backends problem
Juergen Wolf wrote:
Hi
currently, I test a Cyrus IMAP Murder v2.3.13-openpkg on a solaris
sparc host. While the murder setup went all fine and mail comes in and
can be read by users, there is one thing left I could not fix.
If a user has a sieve script like
#Mail filter rules for wolf
#Generated by wolf using SmartSieve 1.0.0-RC2 2008/11/25 09:02:43
require [fileinto];
if allof (header :contains X-Spam-Status Yes,) {
fileinto INBOX.Spam-Tagged;
}
and the Folder INBOX.Spam-Tagged is located on a different backend
server as the INBOX folder, the sieve script does not work. I get the
following errors on the backend server where the INBOX is located:
lmtp[27859]: sieve runtime error for wolf id
[EMAIL PROTECTED]: Fileinto: Mailbox
does not exist
Is there any way to tell sieve to move mails to the correct backend
server ?
From the web site [http://cyrusimap.web.cmu.edu/ag.html section 2.3]:
If a SIEVE http://www.cyrusoft.com/sieve script is present, the
lmtp proxy server must do the processing as the end result of the
processing may result in the mail message going to a different back
end server than where the user's INBOX is. /Note that the current
implementation runs SIEVE on the backend servers, and holds the
requirement that all of a user's mailboxes live on the same backend./
So, you should heed this warning.
-nic
--
Nic Bernstein [EMAIL PROTECTED]
Onlight llc. www.onlight.com
2266 North Prospect Avenue #610 v. 414.272.4477
Milwaukee, Wisconsin 53202-6306 f. 414.290.0335
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
