Cross script vulnerability (XSS) in httpd
Hi, not sure if this is an actual issue, so I'm posting it here first, in case someone knows better. We recently ran a vulnerability assessment using nessus against our server running cyrus and it detected the following medium risk XSS issue (the actual report is at the bottom of the email) 9080 is the custom port https is configured to listen on. >From what I understand it seems that someone could craft a special request and enter script code via the headers sent, code that appears in the response and could actually be executed in case a browser is used. The report had multiple example requests, but technically they were all the same, so I'm just attaching the first example request that confirms the issue. Regards, Savvas Karagiannidis Here's the related part of the report: Synopsis The remote web server is affected by a cross-site scripting vulnerability. Description The remote host is running a web server that fails to adequately sanitize request strings of malicious JavaScript. A remote attacker can exploit this issue, via a specially crafted request, to execute arbitrary HTML and script code in a user's browser within the security context of the affected site. See Also https://en.wikipedia.org/wiki/Cross-site_scripting Solution Contact the vendor for a patch or upgrade. Risk Factor Medium CVSS Base Score 4.3 (CVSS2#AV:N/AC:M/Au:N/C:N/I:P/A:N) CVSS Temporal Score 3.7 (CVSS2#E:H/RL:OF/RC:C) References BID 5011 <http://www.securityfocus.com/bid/5011> BID 5305 <http://www.securityfocus.com/bid/5305> BID 7344 <http://www.securityfocus.com/bid/7344> BID 7353 <http://www.securityfocus.com/bid/7353> BID 8037 <http://www.securityfocus.com/bid/8037> BID 14473 <http://www.securityfocus.com/bid/14473> BID 17408 <http://www.securityfocus.com/bid/17408> BID 54344 <http://www.securityfocus.com/bid/54344> CVE CVE-2002-1060 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2002-1060> CVE CVE-2002-1700 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2002-1700> CVE CVE-2003-1543 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2003-1543> CVE CVE-2005-2453 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-2453> CVE CVE-2006-1681 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-1681> CVE CVE-2012-3382 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3382> XREF CWE:79 <http://cwe.mitre.org/data/definitions/79> Plugin Information Published: 2001/11/30, Modified: 2018/07/06 Plugin Output tcp/9080 -- Request #1 -- The full request used to detect this flaw was : GET /cgi-bin/llknxx7s.html HTTP/1.1 Host: alert(Host):9080 Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1 Accept-Language: en Connection: Close User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0) Pragma: no-cache Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* The output was : HTTP/1.1 404 Not Found Date: Thu, 23 Jan 2020 18:13:22 GMT Connection: close, Upgrade Upgrade: Vary: Accept-Encoding Content-Type: text/html; charset=utf-8 Content-Length: 437 [...] Jansson/2.9 Server at alert(Host) Port 9080 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 3.0.8 and purging/removing emails
Hi, according to the documentation for cyr_expire ( https://www.cyrusimap.org/imap/reference/manpages/systemcommands/cyr_expire.html) you also have to add -X parameter in order to completely delete messages from mailboxes and -D parameter in order to remove deleted mailboxes from the server. -E is only for expiring old entries in the duplicate messages databases. Note that the parameter "3" specified there is in days by default (3d). So, if you only want to keep data that was deleted the last, let's say, 7 days, and delete anything older than that, you enter the following in the EVENTS section of cyrus.conf: delprunecmd="/usr/sbin/cyrus/cyr_expire -E 3d -X 7d -D 7d" at 0400 The path to cyr_expire is not clear in your email, so please adjust it accordingly. "at 0400" specifies that the command must be executed daily at 04:00, you can of course change it. Regards, Savvas Karagiannidis On Tue, Jan 14, 2020, 16:52 Lars Schimmer wrote: > Hi! > > We do run a debian cyrus 3.0.8-6+deb10u3 mailserver, new setup, but we > did copy over some coonfigs from a older cyrus. > > I recently discovered lots of emails in the local storage of the email > server, although the mailbox is empty. > In this case a IMAP shared folder, not a user INBOX. > IMAP tells the folder is empty, but in the folder on the disk still 800 > files/mails available, partly 3 month old. > > It seems I did miss the automatic removal of mails. > > The cyrus.conf shows the line delprunecmd="/usr/sbin/cyrus > expire -E 3" > > But it seems I did miss some important point. > > On a cyrus restart it shows: > > cyrus/cyr_expire[13235]: Expired 0 and expunged 0 out of 1449266 > messages from 3993 mailboxes > > > Anyone has a idea what I did miss, or where to look? > > thank you. > > MfG, > Lars Schimmer > -- > - > TU Graz, Institut für ComputerGraphik & WissensVisualisierung > Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at > Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 > > > > > 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
Re: Upgrade report debian cyrus
Thanks for clarifying this Ellie, I thought the two issues are actually related. And thanks for adding the mention to -G to the release notes. Regards, Savvas Karagiannidis On Mon, Aug 5, 2019 at 3:22 AM ellie timoney wrote: > On Thu, Aug 1, 2019 at 5:13 PM Lars Schimmer > wrote: > > and on second run it did find a lot of mails with "reappending" messages. > > > Actually, this sounds like this bug: > https://github.com/cyrusimap/cyrus-imapd/issues/2839 (fixed last week in > 3.0.11) > There is a Debian report for it too: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933163 > > I guess we're going to see a lot of this here, as people start upgrading > older systems to the new Debian stable and getting Debian's 3.0.8 instead > of whatever they had before. > > > On Fri, Aug 2, 2019, at 12:44 AM, Savvas Karagiannidis wrote: > > there was an issue when upgrading to 3.0.x from older versions (2.x). The > issue is this: > https://github.com/cyrusimap/cyrus-imapd/issues/2208 > > Ellie explains the exact issues with old mail in the last comment before > closing the issue mentioned above and I'm surprised to not see any mention > of this (the -G parameter) in the 3.0 release notes and upgrade > instructions... > > > Oh, I'd forgotten about that! I'm going to add a note about this to the > reconstruct -G documentation as well as the upgrade notes. > > It is a different issue though: the impact of #2208 (since the crash was > fixed in 3.0.8, anyway) is being unable to replicate due to missing > GUID's. You need reconstruct with -G before upgrading if you plan to build > a new server and replicate your old store to it (which you will find out > when you try to replicate). But it won't affect in-place upgrades until > you try to replicate them somewhere later. > > #2839 is rather more annoying because it affects in-place upgrades and > copy-files-and-reconstruct upgrades! > > Cheers, > > ellie > > On Fri, Aug 2, 2019, at 12:44 AM, Savvas Karagiannidis wrote: > > Hi Lars, > there was an issue when upgrading to 3.0.x from older versions (2.x). The > issue is this: > https://github.com/cyrusimap/cyrus-imapd/issues/2208 > > From my experience, the only way to safely upgrade to 3.0 was to run > reconstruct -G -V max on all mailboxes while still in the older version. > Ellie explains the exact issues with old mail in the last comment before > closing the issue mentioned above and I'm surprised to not see any mention > of this (the -G parameter) in the 3.0 release notes and upgrade > instructions... > You can still run reconstruct -G -V max on the new system with the latest > version but the result will probably be that these older messages will > appear as unread. > > > Regards, > Savvas Karagiannidis > > On Thu, Aug 1, 2019 at 5:13 PM Lars Schimmer > wrote: > > Hi! > > Just upgraded my old debian cyrus 2.4.16-4+deb7u2 to cyrus 3.0.8-6. > I did use a new hardware system for this, copied over all mailbox, > sieve,.. data and did a recontruct. > > It seems the reconstruct needs a few uns to reconstruct our 100GB mail > archive (in ~120 mailboxes). > > I did a reconctruct -V max and it did not find all mails, I did run it > twice, and on second run it did find a lot of mails with "reappending" > messages. > > Also, after migration, some users did not seem to have a inbox, I needed > to "cm user.xcy" and copy mailbox data into it and recontruct manually. > (seems like those are new mailboxes and are not in the copied data of > main cyrus db). > > But some mailboxes were existent, but empty after the 2 reconstruct (and > quota) run, I did explicit run reconstruct -r -f user.xyyya on those. > To bad they got all mails as unseen. > > On the most accounts all worked fine, but all mails prior to sept 2011 > are set to unseen. > Seems like some change of dataformat, as I did upgrade in sept 2011 :-) > > Now I sit here and wait for more error reports from the users. > > > > MfG, > Lars Schimmer > -- > - > TU Graz, Institut für ComputerGraphik & WissensVisualisierung > Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at > Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 > > > > > 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/inf
Re: Upgrade report debian cyrus
Hi Lars, there was an issue when upgrading to 3.0.x from older versions (2.x). The issue is this: https://github.com/cyrusimap/cyrus-imapd/issues/2208 >From my experience, the only way to safely upgrade to 3.0 was to run reconstruct -G -V max on all mailboxes while still in the older version. Ellie explains the exact issues with old mail in the last comment before closing the issue mentioned above and I'm surprised to not see any mention of this (the -G parameter) in the 3.0 release notes and upgrade instructions... You can still run reconstruct -G -V max on the new system with the latest version but the result will probably be that these older messages will appear as unread. Regards, Savvas Karagiannidis On Thu, Aug 1, 2019 at 5:13 PM Lars Schimmer wrote: > Hi! > > Just upgraded my old debian cyrus 2.4.16-4+deb7u2 to cyrus 3.0.8-6. > I did use a new hardware system for this, copied over all mailbox, > sieve,.. data and did a recontruct. > > It seems the reconstruct needs a few uns to reconstruct our 100GB mail > archive (in ~120 mailboxes). > > I did a reconctruct -V max and it did not find all mails, I did run it > twice, and on second run it did find a lot of mails with "reappending" > messages. > > Also, after migration, some users did not seem to have a inbox, I needed > to "cm user.xcy" and copy mailbox data into it and recontruct manually. > (seems like those are new mailboxes and are not in the copied data of > main cyrus db). > > But some mailboxes were existent, but empty after the 2 reconstruct (and > quota) run, I did explicit run reconstruct -r -f user.xyyya on those. > To bad they got all mails as unseen. > > On the most accounts all worked fine, but all mails prior to sept 2011 > are set to unseen. > Seems like some change of dataformat, as I did upgrade in sept 2011 :-) > > Now I sit here and wait for more error reports from the users. > > > > MfG, > Lars Schimmer > -- > - > TU Graz, Institut für ComputerGraphik & WissensVisualisierung > Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at > Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 > > > > > 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
Re: Cyrus IMAP 3.0.10 released
Hi Ellie, is there any link for details about CVE-2019-11356? Tried googling it but couldn't find anything related or in cyrus mailing lists or in reported issues, other than this: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11356 Regards, Savvas Karagiannidis On Mon, May 27, 2019 at 5:28 AM ellie timoney wrote: > The Cyrus team is proud to announce the immediate availability of a new > version of Cyrus IMAP: 3.0.10 > > This release contains a fix for CVE-2019-11356, a buffer overrun > vulnerability in the httpd daemon. If you compile cyrus with HTTP support > enabled and your cyrus.conf contains SERVICES entries that run the httpd > daemon, you will need this upgrade. > > I'm trialling hosting the release files using Github's releases feature. > Please use the Github download links if possible, and advise if you have > any problems! (It may even download faster due to Github's content > delivery network.) > > Download URLs: > > > https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.0.10/cyrus-imapd-3.0.10.tar.gz > > https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.0.10/cyrus-imapd-3.0.10.tar.gz.sig > > https://www.cyrusimap.org/releases/cyrus-imapd-3.0.10.tar.gz > https://www.cyrusimap.org/releases/cyrus-imapd-3.0.10.tar.gz.sig > > Please consult the release notes and upgrade documentation before > upgrading to 3.0.10: > > > https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.10.html > https://www.cyrusimap.org/imap/download/upgrade.html > > And join us on Github at https://github.com/cyrusimap/cyrus-imapd to > report issues, join in the deliberations of new features for the next Cyrus > IMAP release, and to contribute to the documentation. > > On behalf of the Cyrus team, > > Kind regards, > > ellie timoney > > 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
Re: Purging old email files from Cyrus-IMAPD v.3.0.9 on FreeBSD-12.0
Hi James, I think deleted and expunged are explained well in the documentation. Deleted: In IMAP when a user deletes an email, the email is actually only flagged as deleted. The user can still see the message and even unset the flag recovering the email. Expunged: When the user issues the expunge command the flagged as deleted messages above become inaccessible by the user. Without delayed delete this is also where the message file gets deleted from the filesystem (purged). The confusion is probably between purged and expired. For every email message cyrus keeps a file on the mailbox folder and also an entry in the cyrus index file for that message. For a clean delete, both the file and the index entry must be deleted. For some reasons they may not be both removed at the same time... I think for performance reasons, replication etc. So: Purged: when the message file is deleted, it is considered purged. The actual email can in no way be recovered. Expired: The index entry for the message is removed. This usually happens after it has been purged. Cyrus has no longer any knowledge of the message ever existed. Hope this clarifies things. For simplicity just consider cyr_expire purging and expiring the messages. Regards, Savvas Karagiannidis On Thu, May 16, 2019, 23:08 James B. Byrne wrote: > > > On Thu, May 16, 2019 11:00, Savvas Karagiannidis wrote: > > Hi James, > > the command that performs the actual removal of the files from the > > file system is cyr_expire > > < > https://www.cyrusimap.org/imap/reference/manpages/systemcommands/cyr_expire.html > > > > According to your cyrus.conf and the manual of cyr_expire, the > > operation is performed daily at 04:00. The command is executed > > by the main cyrus process, so you don't have to do anything > > else manually... > > The parameters -D 180d and -X 180d specify that only mailboxes and > > messages that are at least 180 days old will be deleted. > > > > When cyr_expire is executed you should see a line in your log file > > like these: > > > > Thanks. I have a question though. If expunge == purge then why does > the documentation distinguish between them? > > When is What ... Deleted, Expired, Expunged or Purged? > > https://www.cyrusimap.org/imap/reference/faqs/o-deleted-expired-expunged-purged.html > > Expunged > > The message (which has been flagged as \Deleted) is also expunged, > meaning that the user can in no way retrieve the message > autonomously. > > Purged > > The message’s index record may still exist (until they are > expired), but the message file is removed from the filesystem, or > in the context of folders, the mail folder is removed from the > filesystem. > > > This is what has me confused. > > Regards, > > -- > *** e-Mail is NOT a SECURE channel *** > Do NOT transmit sensitive data via e-Mail > Do NOT open attachments nor follow links sent by e-Mail > > James B. Byrnemailto:byrn...@harte-lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > > 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?
Oh sorry Nic, didn't notice that it was you on that thread. Then you are probably way ahead of me :) I guess only Bron can answer this then. We had this issue when upgrading large installations and the first one was a real nightmare, costing a night of sleep to bring the system back to operational status, since we didn't know the details we do now.. The fix you mentioned on the thread is for 3.0.x. >From my experience, running reconstruct 3.0.x only creates further issues. Reconstruct 2.5.x also crashes sometimes which is really frustrating and restarting it for all mailboxes after each crash was really not an option. So we ended up with a perl script that I could probably share here that gets the list of mailboxes, checks which are still v12 and performs a reconstruct on them only, one by one. If reconstruct crashes it restarts it until it completes successfully or a limit of failures is reached... At the end all mailboxes were v13. On some very rare cases, a mailbox was really corrupt, so it had to be manually fixed by something more drastic, like deleting cyrus.index file. I have to check with my boss tomorrow morning just to get an ok and I'll share that script here if it helps. Regards, Savvas Karagiannidis On Wed, Aug 1, 2018 at 12:26 AM Nic Bernstein wrote: > On 07/31/2018 02:32 PM, Savvas Karagiannidis wrote: > > Hi Nic, > as far as I know there are currently a couple of nasty open issues when > upgrading old mailboxes, created from earlier versions of cyrus, that have > not been upgraded to v13 index using reconstruct. These issues are: > > https://github.com/cyrusimap/cyrus-imapd/issues/2171 > https://github.com/cyrusimap/cyrus-imapd/issues/2208 > > The main problem is frequent crashes with error message "assertion failed" > when accessing these mailboxes. > > In issue #2208 a reconstruct command was proposed as a workaround: > reconstruct -G -V max [mailboxname] > > Note that -G parameter seems necessary, otherwise the problem persists... > > Note also, that this should be done while still in version 2.5.x! The > behavior of version 3.x reconstruct is not the same and you will not have > the same results. > > As for the cyrdump you mention, it would be better if you compared the > results before running reconstruct and after that. > I guess what you would see is that the uidlist before would probably be in > the range 6 - 9 (or you'd see a crash). cyrus 3.0.x considers that part of > the index corrupt so simply cannot access those uids (1-5). Reconstruct > detects this issue and what it does is that *reappends *those "newly > found" messages, giving them a new uid, so that's what uids 10-14 probably > really are. Note that this causes these messages to appear unread, since > they have no flags (not something you want for your clients' mailboxes). > > Bron mentioned something about this bug in the cyrus devel list a few days > ago: > > https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-July/thread.html#4313 > but I didn't see any related commit or anything mentioned in the above > issues, so I'm not sure if there is a fix at the moment... > > > [Cross posting to cyrus-devel, as am now dumping core] > > Savvas, > Thanks for your response. I think, however, that we've already tackled > the issue of assert failures in reconstruct. If you follow the entire > thread of the message you linked to, Bron's message from the other day, he > was actually writing to me, and his patch, referenced with a commit, within > that message, worked just fine for me, as addressed in my follow up: > > https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-July/004315.html > > But I can see that you're correct about the cyrdump issue. That's a real > mess. Here's the top of a cyrdump from the old host, running 2.5.10: > > onlight@mail:~$ sudo su cyrus -c "/usr/lib/cyrus/bin/cyrdump user.onlight" | > head -12 > Content-Type: multipart/related; boundary="dump-10426-1533070392-23406623" > > --dump-10426-1533070392-23406623 > Content-Type: text/xml > IMAP-Dump-Version: 0 > > > imap://mail.ahwi.us/user.onlight > 0 > 10 > > 1 2 3 4 5 6 7 9 > > which comports with the existing mailbox directory: > > onlight@mail:~$ sudo ls /var/spool/cyrus/mail/I/user/onlight/ > 1. 2. 3. 4. 5. 6. 7. 8. 9. cyrus.annotations cyrus.cache > cyrus.header cyrus.index Drafts Sent Spam Trash > > And here's what it looks like after reconstructing on the new server: > > root@newmail:~# ls /var/spool/cyrus/mail/I/user/onlight/ > 10. 11. 12. 13. 14. 6. 7. 8. 9. cyrus.annotations cyrus.cache > cyrus.header cyrus.index Drafts Sent Spam Trash > > But I cannot even run cyrdump on the new mailbox now, I
Re: Is "reconstruct -V max..." needed when upgrading from 2.5.10 to 3.0.7?
Hi Nic, as far as I know there are currently a couple of nasty open issues when upgrading old mailboxes, created from earlier versions of cyrus, that have not been upgraded to v13 index using reconstruct. These issues are: https://github.com/cyrusimap/cyrus-imapd/issues/2171 https://github.com/cyrusimap/cyrus-imapd/issues/2208 The main problem is frequent crashes with error message "assertion failed" when accessing these mailboxes. In issue #2208 a reconstruct command was proposed as a workaround: reconstruct -G -V max [mailboxname] Note that -G parameter seems necessary, otherwise the problem persists... Note also, that this should be done while still in version 2.5.x! The behavior of version 3.x reconstruct is not the same and you will not have the same results. As for the cyrdump you mention, it would be better if you compared the results before running reconstruct and after that. I guess what you would see is that the uidlist before would probably be in the range 6 - 9 (or you'd see a crash). cyrus 3.0.x considers that part of the index corrupt so simply cannot access those uids (1-5). Reconstruct detects this issue and what it does is that *reappends *those "newly found" messages, giving them a new uid, so that's what uids 10-14 probably really are. Note that this causes these messages to appear unread, since they have no flags (not something you want for your clients' mailboxes). Bron mentioned something about this bug in the cyrus devel list a few days ago: https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-July/thread.html#4313 but I didn't see any related commit or anything mentioned in the above issues, so I'm not sure if there is a fix at the moment... Hope this helps, Regards, Savvas Karagiannidis On Tue, Jul 31, 2018 at 6:43 PM Nic Bernstein 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 > 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 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
Hi James, Users' subscription files are normally saved in /var/imap/user in directories based on the user's initial. Search for username.sub files in there. Seen status used to be in there too in username.seen files but that changed in more recent versions, where seen status information is stored inside the cyrus.index file for each mailbox. For the users' subscription information just copy the .sub files in the same directory structure. For the seen status information try copying the .seen files too. Migrating that information used to be an automatic procedure in version 2.4, the first time the user logged in but not sure if it still applies to 3.x.. Regards, Savvas Karagiannidis On Thu, May 17, 2018, 22:25 James B. Byrne via Info-cyrus < info-cyrus@lists.andrew.cmu.edu> wrote: > I have managed to move the 2.3.16 mailstore and mailboxes.db to the > 3.0.5 host and reconstructed the mailboxes using 'reconstruct -f -r > -G -V max user/*' Connections between squirrelmail and the new > service appear to be working fine. However, I have a couple of > glitches and I would like to know if there is anything I can do to > eliminate them before thae actual switchover, scheduled for this > Saturday. > > 1. All of the use folders are unsubscribed following the reconstruct. > > 2. All of the messages show as unread following the reconstruct. > > Is there any way to avoid these consequences of transfer and reconstruct? > > -- > *** e-Mail is NOT a SECURE channel *** > Do NOT transmit sensitive data via e-Mail > Do NOT open attachments nor follow links sent by e-Mail > > James B. Byrnemailto:byrn...@harte-lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive > <https://maps.google.com/?q=9+Brockley+Drive=gmail=g> > vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > > > 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
Re: Moving from cIMAP-2.3.16 to 3.0.5
Hi James, note that you will probably fall into this bug on the new system: https://github.com/cyrusimap/cyrus-imapd/issues/2208 Try running "reconstruct -G -V max" on the new system before switching to it. This will upgrade the mailboxes avoiding the issue. Regards, Savvas Karagiannidis On Mon, May 14, 2018 at 4:15 PM James B. Byrne via Info-cyrus < info-cyrus@lists.andrew.cmu.edu> wrote: > > On Sat, May 12, 2018 19:47, Nic Bernstein wrote: > > 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: > > > > Thank you both. I will try this approach and report if I somehow > manage to get it wrong again. > > Regards, > > -- > *** e-Mail is NOT a SECURE channel *** > Do NOT transmit sensitive data via e-Mail > Do NOT open attachments nor follow links sent by e-Mail > > James B. Byrnemailto:byrn...@harte-lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 <(905)%20561-1241> > Hamilton, Ontario fax: +1 905 561 0757 <(905)%20561-0757> > Canada L8E 3C3 > > > 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
Shared calendars on apple devices
Hello everyone! I am trying to set up a public calendar on apple devices (iPhone, iPad) but I am probably missing something, cause I can't get it to work... When setting up personal calendars, the http://[servername]/dav/principals/user/ URL is used and it works fine. All personal calendars can be accessed and even new calendars can be created using apple's Calendar app. But how can public/shared calendars be accessed? They do not show up using the principals URL and when I attempt to use the direct calendar URL ( http://[servername]/dav/calendars/[calendar_name]/) the Calendar app still only discovers and displays the user's personal calendars and not the public calendar... Am I doing something wrong? What are the proper settings for apple devices? ACLs are properly configured, so the user has access to the shared calendar and I have successfully set up shared calendars on other clients like Thunderbird and android devices (using DAVdroid) Thanks in advance, Savvas Karagiannidis 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
