From alpine.chappa at yandex.com Sun Sep 8 14:10:57 2019 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Sun, 8 Sep 2019 12:10:57 -0600 (MDT) Subject: RLIST leads to Referral after SELECT Message-ID: Hello, I am trying to understand why the Cyrus IMAP server is doing a referral to SELECT a folder, after a RLIST command, but does not do a referral if no RLIST command has been issued. In other words, the following sequence of commands results in a referral 0 LOGIN credentials 0000000f RLIST "" INBOX.Sent * LIST (\HasNoChildren) "." INBOX.Sent 0000000f OK Completed (0.000 secs 2 calls) 00000010 SELECT INBOX.Sent 00000010 NO [REFERRAL imap://;AUTH=*@some.server.com/INBOX.Sent] Remote mailbox. However, the sequence 0 LOGIN credentials 1 SELECT INBOX.Sent * 692 EXISTS * 0 RECENT * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwarded NonJunk $label1 $MDNSent Junk) .. succeeds to SELECT INBOX.Sent. The server returns the following capabilities 1 login credentials 1 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE WITHIN QRESYNC SCAN URLAUTH URLAUTH=BINARY X-NETSCAPE MUPDATE=mupdate://some.server.com/ LOGINDISABLED AUTH=PLAIN COMPRESS=DEFLATE IDLE] User logged in SESSIONID= The use of RLIST is mandated by RFC 2193, which states: A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB commands in lieu of LIST and LSUB. Does anyone see a reason why this server is returning a NO [REFERRAL ...] to a SELECT command after a RLIST command, but not without it? Thank you for your feedback! -- Eduardo From ellie at fastmail.com Sun Sep 8 19:54:45 2019 From: ellie at fastmail.com (ellie timoney) Date: Mon, 09 Sep 2019 09:54:45 +1000 Subject: RLIST leads to Referral after SELECT In-Reply-To: References: Message-ID: <2ab05252-59fe-44af-bca9-81f07774b56a@www.fastmail.com> On Mon, Sep 9, 2019, at 4:10 AM, Eduardo Chappa wrote: > The use of RLIST is mandated by RFC 2193, which states: > > A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB > commands in lieu of LIST and LSUB. > > Does anyone see a reason why this server is returning a NO [REFERRAL ...] > to a SELECT command after a RLIST command, but not without it? If "a MAILBOX-REFERRALS capable client will issue RLIST and RLSUB", then it's reasonable to suppose that: * a client that issues RLIST or RLSUB supports mailbox referrals (and so the server sends a referral) * a client that issues a regular LIST does not support mailbox referrals (and so the server proxies the remote mailbox instead) In terms of where this happens in code, looks like it gets set up here (and similarly for Rlsub a bit further down): https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/imapd.c#L1873 and then cmd_list saves the "supports_referrals" flag out for other commands to examine, if LIST_SEL_REMOTE was requested and configuration permits it, here: https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/imapd.c#L8112-L8116 From alpine.chappa at yandex.com Sun Sep 8 20:52:42 2019 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Sun, 8 Sep 2019 18:52:42 -0600 (MDT) Subject: RLIST leads to Referral after SELECT In-Reply-To: <2ab05252-59fe-44af-bca9-81f07774b56a@www.fastmail.com> References: <2ab05252-59fe-44af-bca9-81f07774b56a@www.fastmail.com> Message-ID: On Mon, 9 Sep 2019, ellie timoney wrote: > If "a MAILBOX-REFERRALS capable client will issue RLIST and RLSUB", then > it's reasonable to suppose that: > > * a client that issues RLIST or RLSUB supports mailbox referrals (and so > the server sends a referral) > * a client that issues a regular LIST does not support mailbox referrals > (and so the server proxies the remote mailbox instead) I partly agree with this analysis. I agree the client identifies itself as supporting referrals. The conclusion that a referral MUST be sent because of that, I do not follow. The purpose of the RLIST command is to identify folders that will be accessed through a referral. It is the output of LIST command plus the referrals. In this case, the mailbox I want to access appears as the output of the LIST command (this is new information in this message, but it is the case) so the server does not have any reason to do a referral, as it can access it without it. In other words, the problem here is that Cyrus is using a referral when it does not need to. This would not be a problem caused by Cyrus itself, but I find myself in a situation where the referral is to a server that is not possible to connect in any port (143 or 993) so the referral is bogus (nor any other port was specified in the referral). While one can argue that the original server is misconfigured, the point in the previous paragraphs still stands, that is, why is the server issuing a referral when none is needed? I hope you see my point. Thank you. -- Eduardo From listac at nebelschwaden.de Wed Sep 11 13:18:39 2019 From: listac at nebelschwaden.de (Ede Wolf) Date: Wed, 11 Sep 2019 19:18:39 +0200 Subject: migration to 3.0 and virtdomains Message-ID: <567c6dbf-f39e-f823-1a93-d5b29a25ed8e@nebelschwaden.de> Hello, I am in the progress of upgrading from 2.5.10 to 3.0.11 and have a question regarding the virtdomains: setting, that for the sake of calendaring has to change from off (or rather unspecified) to userid and it's implications on the migration path wise. Until now, the mailboxes where located below ../mail/X/user/mary, with "X" of course being an arbitrary letter. Now, the mailboxes are located below ../mail/domain/X/example.com/Y/user/mary At least newly created ones. Technically, there is of course no problem of copying/syncing the old mailboxes below the example.com directory, but cyrus stores a lot of additional information in databases below $configdirectory and I am not sure, how the changed paths of the mailboxes will affect the data, that is stored within the likes of mailboxes.db, annotations.db, *.seen and what else lingers around there. Additionally, $configdirectory and $partition-default had to change their respective path, too. But since those are configurable in imapd.conf, until now I am not worried about this. So I am wondering, is there anything I should be aware of? Or will reconstruct magically take care of all this? Any dos or donts? Any special procedure or precautions required when moving mailboxes below a domain structure? Thanks for any clues Ede From adrien.remillieux at gmail.com Wed Sep 11 16:50:56 2019 From: adrien.remillieux at gmail.com (Adrien Remillieux) Date: Wed, 11 Sep 2019 22:50:56 +0200 Subject: Possible issue when upgrading to cyrus 3.0.8 using replication ? Message-ID: Hello, I have a server that I can't update running cyrus 2.5.10 which contain mailboxes that have existed from 2.3 and earlier (around 300Gb total). My plan is to update by enabling replication with a new server running Debian Buster (so cyrus 3.0.8) and then shutting down the old server. There was a problem when upgrading to 3.x.x with mailboxes created with cyrus 2.3 or before and that was fixed in 3.0.11 (see https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.11.html and https://github.com/cyrusimap/cyrus-imapd/issues/2839 for the bug report) Does this upgrade path suffer from the same issue ? I am not familiar with the inner-workings of cyrus. It appears that the Debian maintainers have not backported the patch in 3.0.8 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933163 and I looked at the source code) Cheers, Adrien -------------- next part -------------- An HTML attachment was scrubbed... URL: From listac at nebelschwaden.de Thu Sep 12 12:53:51 2019 From: listac at nebelschwaden.de (Ede Wolf) Date: Thu, 12 Sep 2019 18:53:51 +0200 Subject: migration to 3.0 and virtdomains In-Reply-To: <567c6dbf-f39e-f823-1a93-d5b29a25ed8e@nebelschwaden.de> References: <567c6dbf-f39e-f823-1a93-d5b29a25ed8e@nebelschwaden.de> Message-ID: <63ba4ac6-d9a4-72bf-cbb1-1fd6d08bf8a5@nebelschwaden.de> Experimental wise, I've set the default domain to example.com, so that new mailboxes are not created under the domain subtree. Doing this I've stumbled into another problem, after copying the old files and having run reconstruct -f -G -V max as user cyrus: When connecting via cyradm as user cyrus (admin), and try to list the mailboxes with a: "lm" command, I see following error in the logs, with the output of "lm" not listing a single mailbox: Sep 12 16:49:22 mail cyrus-imapd/imap[31820]: login: localhost [127.0.0.1] cyrus SCRAM-SHA-1 User logged in SESSIONID= Sep 12 16:49:22 mail cyrus-imapd/imap[31820]: command: 4 Rlist Sep 12 16:49:24 mail cyrus-imapd/imap[31820]: command: 5 List Sep 12 16:49:24 mail cyrus-imapd/imap[31820]: Fatal error: Internal error: assertion failed: lib/cyrusdb_twoskip.c: 1525: cb Sep 12 16:49:24 mail cyrus-imapd/imap[31820]: auditlog: traffic sessionid= bytes_in=<333> bytes_out=<2721> Sep 12 16:49:24 mail cyrus-imapd/master[31803]: process type:SERVICE name:imap path:/usr/libexec/imapd age:2.829s pid:31820 exited, status 75 Sep 12 16:49:24 mail cyrus-imapd/master[31803]: service imap/ipv4 pid 31820 in BUSY state: terminated abnormally However, when using a fresh imapd install and (auto)create a mailbox, "lm" seems to work just fine. Am 11.09.19 um 19:18 schrieb Ede Wolf: > Hello, > > I am in the progress of upgrading from 2.5.10 to 3.0.11 and have a > question regarding the virtdomains: setting, that for the sake of > calendaring has to change from off (or rather unspecified) to userid and > it's implications on the migration path wise. > > Until now, the mailboxes where located below > > ../mail/X/user/mary, with "X" of course being an arbitrary letter. > > Now, the mailboxes are located below > > ../mail/domain/X/example.com/Y/user/mary > > At least newly created ones. Technically, there is of course no problem > of copying/syncing the old mailboxes below the example.com directory, > but cyrus stores a lot of additional information in databases below > $configdirectory and I am not sure, how the changed paths of the > mailboxes will affect the data, that is stored within the likes of > mailboxes.db, annotations.db, *.seen and what else lingers around there. > > Additionally, $configdirectory? and $partition-default had to change > their respective path, too. But since those are configurable in > imapd.conf, until now I am not worried about this. > > So I am wondering, is there anything I should be aware of? Or will > reconstruct magically take care of all this? Any dos or donts? Any > special procedure or precautions required when moving mailboxes below a > domain structure? > > Thanks for any clues > > Ede > ---- > 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 From ellie at fastmail.com Thu Sep 12 20:20:17 2019 From: ellie at fastmail.com (ellie timoney) Date: Fri, 13 Sep 2019 10:20:17 +1000 Subject: Possible issue when upgrading to cyrus 3.0.8 using replication ? In-Reply-To: References: Message-ID: <343a16a2-f5a2-4130-aae0-6a4994ab9556@www.fastmail.com> Hi Adrien, The replication upgrade path should be okay. In-place upgrades (that would use the affected reconstruct to bring mailboxes up to the same version as the server) would get bitten. Whereas if you replicate to a newer version server, the mailboxes on the replica will be created at the replica's preferred version already, so you don't need to reconstruct afterwards. If you have messages that would theoretically be affected by this bug in 3.0, you won't be able to replicate them to 3.0 in the first place, because I think replication won't allow the 0 modseq. If this arises, I'm not sure how to recover from it and replicate the affected messages, since 2.4 and 2.5 won't alter the 0 modseq. If it can't replicate them, it will complain about it, so if you plan for the replication needing some handholding/restarting, you'll at least be able to identify which messages are broken in the process, and then figure out how to handle it once you know the size of the problem? Another option, if you want to stick with the Debian packages, would be to skip 3.0.8 and install 3.0.11 from buster-backports (https://packages.debian.org/buster-backports/cyrus-imapd), and then you'll be immune to the problem. Though you still won't be able to replicate the affected messages to the new server, hmm. Cheers, ellie On Thu, Sep 12, 2019, at 6:50 AM, Adrien Remillieux wrote: > Hello, > > I have a server that I can't update running cyrus 2.5.10 which contain mailboxes that have existed from 2.3 and earlier (around 300Gb total). My plan is to update by enabling replication with a new server running Debian Buster (so cyrus 3.0.8) and then shutting down the old server. There was a problem when upgrading to 3.x.x with mailboxes created with cyrus 2.3 or before and that was fixed in 3.0.11 (see https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.11.html and https://github.com/cyrusimap/cyrus-imapd/issues/2839 for the bug report) > > Does this upgrade path suffer from the same issue ? I am not familiar with the inner-workings of cyrus. It appears that the Debian maintainers have not backported the patch in 3.0.8 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933163 and I looked at the source code) > > Cheers, > Adrien > ---- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrien.remillieux at gmail.com Sat Sep 14 19:12:43 2019 From: adrien.remillieux at gmail.com (Adrien Remillieux) Date: Sun, 15 Sep 2019 01:12:43 +0200 Subject: Possible issue when upgrading to cyrus 3.0.8 using replication ? In-Reply-To: References: Message-ID: Thank you for your answer ! Considering what you said I'll try to enable replication on the new server. If it doesn't work I'll just schedule some downtime, copy the /var/spool/cyrus folder to the new server, install cyrus 3.0.11 from the backports and then upgrade the mailboxes in place. We've been using cyrus since 2004 so there's definitely a lot of old mailboxes around and I don't which versions of cyrus were used. Cheers, Adrien Le dim. 15 sept. 2019 ? 00:35, Adrien Remillieux < adrien.remillieux at gmail.com> a ?crit : > Date: Fri, 13 Sep 2019 10:20:17 +1000 > From: "ellie timoney" > To: info-cyrus at lists.andrew.cmu.edu > Subject: Re: Possible issue when upgrading to cyrus 3.0.8 using > replication ? > Message-ID: <343a16a2-f5a2-4130-aae0-6a4994ab9556 at www.fastmail.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Adrien, > > The replication upgrade path should be okay. In-place upgrades (that would > use the affected reconstruct to bring mailboxes up to the same version as > the server) would get bitten. Whereas if you replicate to a newer version > server, the mailboxes on the replica will be created at the replica's > preferred version already, so you don't need to reconstruct afterwards. > > If you have messages that would theoretically be affected by this bug in > 3.0, you won't be able to replicate them to 3.0 in the first place, because > I think replication won't allow the 0 modseq. If this arises, I'm not sure > how to recover from it and replicate the affected messages, since 2.4 and > 2.5 won't alter the 0 modseq. If it can't replicate them, it will complain > about it, so if you plan for the replication needing some > handholding/restarting, you'll at least be able to identify which messages > are broken in the process, and then figure out how to handle it once you > know the size of the problem? > > Another option, if you want to stick with the Debian packages, would be to > skip 3.0.8 and install 3.0.11 from buster-backports ( > https://packages.debian.org/buster-backports/cyrus-imapd), and then > you'll be immune to the problem. Though you still won't be able to > replicate the affected messages to the new server, hmm. > > Cheers, > > ellie > > On Thu, Sep 12, 2019, at 6:50 AM, Adrien Remillieux wrote: > > Hello, > > > > I have a server that I can't update running cyrus 2.5.10 which contain > mailboxes that have existed from 2.3 and earlier (around 300Gb total). My > plan is to update by enabling replication with a new server running Debian > Buster (so cyrus 3.0.8) and then shutting down the old server. There was a > problem when upgrading to 3.x.x with mailboxes created with cyrus 2.3 or > before and that was fixed in 3.0.11 (see > https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.11.html > and https://github.com/cyrusimap/cyrus-imapd/issues/2839 for the bug > report) > > > > Does this upgrade path suffer from the same issue ? I am not familiar > with the inner-workings of cyrus. It appears that the Debian maintainers > have not backported the patch in 3.0.8 (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933163 and I looked at > the source code) > > > > Cheers, > > Adrien > > ---- > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190913/5ed8a417/attachment-0001.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambert at lambertfam.org Sun Sep 15 15:04:31 2019 From: lambert at lambertfam.org (Scott Lambert) Date: Sun, 15 Sep 2019 13:04:31 -0600 Subject: Possible issue when upgrading to cyrus 3.0.8 using replication ? In-Reply-To: References: Message-ID: If you can create the mailboxes on the new server, without replication, perhaps it would be safer/less downtime to use IMAPsync to move the data to the new server.? It will be slow, but I don't mind slow while the source server is still online and users are happy. On 9/14/19 5:12 PM, Adrien Remillieux wrote: > Thank you for your answer ! > > Considering what you said I'll try to enable replication on the new > server. If it doesn't work I'll just schedule some downtime, copy the > /var/spool/cyrus folder to the new server, install cyrus 3.0.11 from > the backports and then upgrade the mailboxes in place. > > We've been using cyrus since 2004 so there's definitely a lot of old > mailboxes around and I don't which versions of cyrus were used. > > Cheers, > Adrien > > Le?dim. 15 sept. 2019 ??00:35, Adrien Remillieux > > a > ?crit?: > > Date: Fri, 13 Sep 2019 10:20:17 +1000 > From: "ellie timoney" > > To: info-cyrus at lists.andrew.cmu.edu > > Subject: Re: Possible issue when upgrading to cyrus 3.0.8 using > ? ? ? ? replication ? > Message-ID: <343a16a2-f5a2-4130-aae0-6a4994ab9556 at www.fastmail.com > > > Content-Type: text/plain; charset="us-ascii" > > Hi Adrien, > > The replication upgrade path should be okay. In-place upgrades > (that would use the affected reconstruct to bring mailboxes up to > the same version as the server) would get bitten. Whereas if you > replicate to a newer version server, the mailboxes on the replica > will be created at the replica's preferred version already, so you > don't need to reconstruct afterwards. > > If you have messages that would theoretically be affected by this > bug in 3.0, you won't be able to replicate them to 3.0 in the > first place, because I think replication won't allow the 0 modseq. > If this arises, I'm not sure how to recover from it and replicate > the affected messages, since 2.4 and 2.5 won't alter the 0 modseq. > If it can't replicate them, it will complain about it, so if you > plan for the replication needing some handholding/restarting, > you'll at least be able to identify which messages are broken in > the process, and then figure out how to handle it once you know > the size of the problem? > > Another option, if you want to stick with the Debian packages, > would be to skip 3.0.8 and install 3.0.11 from buster-backports > (https://packages.debian.org/buster-backports/cyrus-imapd), and > then you'll be immune to the problem. Though you still won't be > able to replicate the affected messages to the new server, hmm. > > Cheers, > > ellie > > On Thu, Sep 12, 2019, at 6:50 AM, Adrien Remillieux wrote: > > Hello, > > > > I have a server that I can't update running cyrus 2.5.10 which > contain mailboxes that have existed from 2.3 and earlier (around > 300Gb total). My plan is to update by enabling replication with a > new server running Debian Buster (so cyrus 3.0.8) and then > shutting down the old server. There was a problem when upgrading > to 3.x.x with mailboxes created with cyrus 2.3 or before and that > was fixed in 3.0.11 (see > https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.11.html > and https://github.com/cyrusimap/cyrus-imapd/issues/2839 for the > bug report) > > > > Does this upgrade path suffer from the same issue ? I am not > familiar with the inner-workings of cyrus. It appears that the > Debian maintainers have not backported the patch in 3.0.8 (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933163 and I > looked at the source code) > > > > Cheers, > > Adrien > > ---- > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ---- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrien.remillieux at gmail.com Tue Sep 17 06:25:37 2019 From: adrien.remillieux at gmail.com (Adrien Remillieux) Date: Tue, 17 Sep 2019 12:25:37 +0200 Subject: Possible issue when upgrading to cyrus 3.0.8 using replication ? In-Reply-To: References: Message-ID: Thanks ! I'll look into it. Le lun. 16 sept. 2019 ? 18:01, a ?crit : > Date: Sun, 15 Sep 2019 13:04:31 -0600 > From: Scott Lambert > To: info-cyrus at lists.andrew.cmu.edu > Subject: Re: Possible issue when upgrading to cyrus 3.0.8 using > replication ? > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > If you can create the mailboxes on the new server, without replication, > perhaps it would be safer/less downtime to use IMAPsync to move the data > to the new server.? It will be slow, but I don't mind slow while the > source server is still online and users are happy. > > On 9/14/19 5:12 PM, Adrien Remillieux wrote: > > Thank you for your answer ! > > > > Considering what you said I'll try to enable replication on the new > > server. If it doesn't work I'll just schedule some downtime, copy the > > /var/spool/cyrus folder to the new server, install cyrus 3.0.11 from > > the backports and then upgrade the mailboxes in place. > > > > We've been using cyrus since 2004 so there's definitely a lot of old > > mailboxes around and I don't which versions of cyrus were used. > > > > Cheers, > > Adrien > > > > Le?dim. 15 sept. 2019 ??00:35, Adrien Remillieux > > > a > > ?crit?: > > > > Date: Fri, 13 Sep 2019 10:20:17 +1000 > > From: "ellie timoney" >> > > To: info-cyrus at lists.andrew.cmu.edu > > > > Subject: Re: Possible issue when upgrading to cyrus 3.0.8 using > > ? ? ? ? replication ? > > Message-ID: <343a16a2-f5a2-4130-aae0-6a4994ab9556 at www.fastmail.com > > > > > Content-Type: text/plain; charset="us-ascii" > > > > Hi Adrien, > > > > The replication upgrade path should be okay. In-place upgrades > > (that would use the affected reconstruct to bring mailboxes up to > > the same version as the server) would get bitten. Whereas if you > > replicate to a newer version server, the mailboxes on the replica > > will be created at the replica's preferred version already, so you > > don't need to reconstruct afterwards. > > > > If you have messages that would theoretically be affected by this > > bug in 3.0, you won't be able to replicate them to 3.0 in the > > first place, because I think replication won't allow the 0 modseq. > > If this arises, I'm not sure how to recover from it and replicate > > the affected messages, since 2.4 and 2.5 won't alter the 0 modseq. > > If it can't replicate them, it will complain about it, so if you > > plan for the replication needing some handholding/restarting, > > you'll at least be able to identify which messages are broken in > > the process, and then figure out how to handle it once you know > > the size of the problem? > > > > Another option, if you want to stick with the Debian packages, > > would be to skip 3.0.8 and install 3.0.11 from buster-backports > > (https://packages.debian.org/buster-backports/cyrus-imapd), and > > then you'll be immune to the problem. Though you still won't be > > able to replicate the affected messages to the new server, hmm. > > > > Cheers, > > > > ellie > > > > On Thu, Sep 12, 2019, at 6:50 AM, Adrien Remillieux wrote: > > > Hello, > > > > > > I have a server that I can't update running cyrus 2.5.10 which > > contain mailboxes that have existed from 2.3 and earlier (around > > 300Gb total). My plan is to update by enabling replication with a > > new server running Debian Buster (so cyrus 3.0.8) and then > > shutting down the old server. There was a problem when upgrading > > to 3.x.x with mailboxes created with cyrus 2.3 or before and that > > was fixed in 3.0.11 (see > > > https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.11.html > > and https://github.com/cyrusimap/cyrus-imapd/issues/2839 for the > > bug report) > > > > > > Does this upgrade path suffer from the same issue ? I am not > > familiar with the inner-workings of cyrus. It appears that the > > Debian maintainers have not backported the patch in 3.0.8 (see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933163 and I > > looked at the source code) > > > > > > Cheers, > > > Adrien > > > ---- > > > 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 > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > < > http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190913/5ed8a417/attachment-0001.html > > > > > > > > ---- > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190915/83294228/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Info-cyrus mailing list > Info-cyrus at lists.andrew.cmu.edu > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > > > ------------------------------ > > End of Info-cyrus Digest, Vol 170, Issue 5 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwidera at oakton.edu Tue Sep 24 10:57:48 2019 From: jwidera at oakton.edu (John Widera) Date: Tue, 24 Sep 2019 09:57:48 -0500 Subject: cyradm and TLS 1.2 Message-ID: Hi All, We're hoping to find some help on the list... We are running Cyrus-IMAP on RHEL7, using an RPM pkg (CYRUS-IMAPD-2.4.17-13.EL7) built from the Red Hat SRC RPM. We also have SASL, Utils, devel etc pkgs all from RH. Now we're looking to finally move Cyrus completely off insecure TLS versions. But now there is a lingering issue... We removed tls1_0 from impad.conf, and the CYRADM shell stopped working. We can no longer connect at all: CYRADM -U CYRUS [ SSL_CONNECT ERROR -1 ] [ SSL SESSION REMOVED ] [ TLS NEGOTIATION DID NOT SUCCEED ] CYRADM: CANNOT AUTHENTICATE TO SERVER WITH AS CYRUS CYRADM -U CYRUS --NOTLS [ SSL_CONNECT ERROR -1 ] [ SSL SESSION REMOVED ] [ TLS NEGOTIATION DID NOT SUCCEED ] CYRADM: CANNOT AUTHENTICATE TO SERVER WITH AS CYRUS The presumption is (as cyradm is just a wrapper script) any PERL scripts calling Cyrus::IMAP::Admin over a STARTTLS connection could likewise be broken (?) if we block TLS 1.0. cyradm is using TLSv1 per maillog: IMAPS[14096]: STARTTLS: TLSV1 WITH CIPHER Our MAN page for cyradm shows a "--notls" option, which does not work/changes nothing. Oddly, the cyradm HELP FLAG does NOT show this option, yet cyradm doesn't bark when it's passed: USAGE: CYRADM [ARGS] SERVER --USER CONNECT AS (AUTHENTICATION NAME) --AUTHZ AUTHORIZE AS --[NO]RC (DO NOT) LOAD THE CONFIGURATION FILES --SYSTEMRC USE SYSTEM-WIDE CONFIGURATION --USERRC USE USER CONFIGURATION --PORT CONNECT TO SERVER ON --AUTH AUTHENTICATE WITH A web search reveals the MAN page for cyradm in Cyrus v.3, and it shows NOTLS as an option to AUTHENTICATE, after a server connection is made, so its unclear to me what's going on... Does anyone have cyradm working with TLS1.2? Regards & THANKS in advance for any assistance or suggestions offered. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel at prodemge.gov.br Wed Sep 25 14:46:19 2019 From: miguel at prodemge.gov.br (Miguel Mucio Santos Moreira) Date: Wed, 25 Sep 2019 15:46:19 -0300 Subject: =?utf-8?q?kick=5Fmupdate?= refused Message-ID: <2cda-5d8bb600-d-22a70a00@78418971> Hello everybody I've had a weird log information on my frontends servers regards to mupdate connection from frontend to mupdate master. Mupdate Master would be refusing connections from frontend servers. srvimapfprd01 cyrus/imaps[29677]: kick_mupdate: can't connect to target: Connection refused These messages don't appear all day long and I don't notice any problem with the murder cluster All my cluster has cyrus 2.4.16-4 version. Any hints about it? Thanks in advance -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.menge at zdv.uni-tuebingen.de Thu Sep 26 03:31:10 2019 From: michael.menge at zdv.uni-tuebingen.de (Michael Menge) Date: Thu, 26 Sep 2019 09:31:10 +0200 Subject: kick_mupdate refused In-Reply-To: <2cda-5d8bb600-d-22a70a00@78418971> Message-ID: <20190926093110.Horde.JyUS-qtng4Ppi5mNXOnnfin@webmail.uni-tuebingen.de> Hi, Quoting Miguel Mucio Santos Moreira : > Hello everybody > > I've had a weird log information on my frontends servers regards to > mupdate connection from frontend to mupdate master. > Mupdate Master would be refusing connections from frontend servers. > > srvimapfprd01 cyrus/imaps[29677]: kick_mupdate: can't connect to > target: Connection refused > > These messages don't appear all day long and I don't notice any > problem with the murder cluster > > All my cluster has cyrus 2.4.16-4 version. > > Any hints about it? > Does your mupdate master use TLS? https://github.com/cyrusimap/cyrus-imapd/issues/2774 The problem was obvious in Cyrus 3.0 but I hat those connection problems also with 2.4 and I now think it was non-thread-safe usage of openssl -------------------------------------------------------------------------------- M.Menge Tel.: (49) 7071/29-70316 Universit?t T?bingen Fax.: (49) 7071/29-5912 Zentrum f?r Datenverarbeitung mail: michael.menge at zdv.uni-tuebingen.de W?chterstra?e 76 72074 T?bingen From miguel at prodemge.gov.br Thu Sep 26 07:55:12 2019 From: miguel at prodemge.gov.br (Miguel Mucio Santos Moreira) Date: Thu, 26 Sep 2019 08:55:12 -0300 Subject: =?utf-8?q?Re=3A?==?utf-8?q?_kick=5Fmupdate?= refused In-Reply-To: <20190926093110.Horde.JyUS-qtng4Ppi5mNXOnnfin@webmail.uni-tuebingen.de> Message-ID: <608f-5d8ca700-5-7ae72a0@89713396> Hello Michael, We don't use TLS in our Mudpate Master. Thanks for your help. -- 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 Quinta, Setembro 26, 2019 04:31 -03, Michael Menge escreveu:Hi, Quoting Miguel Mucio Santos Moreira : > Hello everybody > > I've had a weird log information on my frontends servers regards to > mupdate connection from frontend to mupdate master. > Mupdate Master would be refusing connections from frontend servers. > > srvimapfprd01 cyrus/imaps[29677]: kick_mupdate: can't connect to > target: Connection refused > > These messages don't appear all day long and I don't notice any > problem with the murder cluster > > All my cluster has cyrus 2.4.16-4 version. > > Any hints about it? > Does your mupdate master use TLS? https://github.com/cyrusimap/cyrus-imapd/issues/2774 The problem was obvious in Cyrus 3.0 but I hat those connection problems also with 2.4 and I now think it was non-thread-safe usage of openssl -------------------------------------------------------------------------------- M.Menge Tel.: (49) 7071/29-70316 Universit?t T?bingen Fax.: (49) 7071/29-5912 Zentrum f?r Datenverarbeitung mail: michael.menge at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbulfon at sonicle.com Thu Sep 26 10:52:10 2019 From: gbulfon at sonicle.com (Gabriele Bulfon) Date: Thu, 26 Sep 2019 16:52:10 +0200 (CEST) Subject: strange sort order of these emails Message-ID: <502130238.636.1569509530124@www> Hello, someone received these two emails in the inbox, but strangely?sorting by date descending was showing them swapped (they have same date but different hour). I did not beleive my eyes, so I downloaded the two eml files and uploaded them into a cyrus folder of mine, on another server. Same effect: the SORT command with descending DATE, will always returns indexes in swapped order, so the one at 3am is before the one at 9am. ? I looked at all the headers but didn't find anything strange. Cyrus is version 2.5.11. Any idea?! Thanks! Gabriele ? Sonicle S.r.l.? :? http://www.sonicle.com Music:? http://www.gabrielebulfon.com Quantum Mechanics :? http://www.cdbaby.com/cd/gabrielebulfon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: =?UTF-8?Q?L=27Eco_di_Bergamo?= Subject: Aggiornamento Newsletter L'Eco di Bergamo di luned? 23 settembre Date: Mon, 23 Sep 2019 3:43:42 +0200 Size: 196852 URL: -------------- next part -------------- An embedded message was scrubbed... From: =?UTF-8?Q?AIMnews=2Eit?= Subject: AIM Breakfast: novit? dalle quotate Date: Mon, 23 Sep 2019 9:04:53 +0200 Size: 48291 URL: From hpj at urpla.net Mon Sep 30 07:12:37 2019 From: hpj at urpla.net (Hans-Peter Jansen) Date: Mon, 30 Sep 2019 13:12:37 +0200 Subject: sieve filter based on utf-8 encoded text part of address Message-ID: <3404478.SVmyWBeI9G@xrated> Hi, I try to filter based on the text part of an utf-8 encoded address, but the string matches neither decoded nor encoded. This is a periodic mail from one of a couple of different routers, where only the text part defines a useful origin: From: "=?UTF-8?B?RlJJVFohQm94IDc0OTAgU0ZK?=" which decodes to: FRITZ!Box 7490 SFJ sieve filter script except: ; my requirements require ["fileinto", "reject", "regex", "vacation"]; ; the filter rule if address :contains "From" [ "FRITZ!Box 7490 SFJ", "=?UTF-8?B?RlJJVFohQm94IDc0OTAgU0ZK?=" ] { fileinto "INBOX.some.folder"; stop; } How do I do this correctly? Thanks in advance, Pete