On Fri, 24 Jan 2020, at 4:38 AM, ego...@sarenet.es wrote:
> - Does it regenerate all mailboxes indexes?. Just the non-indexed emails?. I
> assume it should be extremely slow… so could this be launched?. Could you
> advise me please, if another way is preferred?
Normally, just the non-indexed
On Thu, 23 Jan 2020 at 11:34, Daniel Gultsch wrote:
> /usr/bin/ld: warning: libicui18n.so.57, needed by
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libxml2.so,
> may conflict with libicui18n.so.64
At first guess, maybe update libxml (or libxml-devel) package? It
looks like you've
> I found some entries like:
> [...] cyrus/imap[5918]: Expunged 1 messages from
> test.tld!user.test.spam
> What is the difference between the above entry and the below entry
> (lower and capital
> expunged)?
> [...] cyrus/cyr_expire[14039]: Expired 0 and expunged 0 out of 144674
> messages from
Anything in the logs showing email being expunged? Look for Expunged
with the capitol E.
On 1/17/20 10:41 AM, Horst Häberlen wrote:
hi Adam Tauno Williams,
What happens if you su to the cyrus user and try to run the command you
see in cyrus.conf ?
This makes no difference. I tried both
Hi
I suspect a confusion about "marked as Deleted", Expunged and Expired
See
https://www.cyrusimap.org/imap/reference/faqs/o-deleted-expired-expunged-purged.html
of more information.
E-Mails "marked as Deleted" need to be Expunged by the imap
EXPUNGE or UID EXPUNGE command.
The cyr_expire
> This command seems to work on Ubuntu 18.04. (cyrus-imapd 2.5.10-
> 3ubuntu1)
> In /usr/sbin there is no cyr_expire but now i found a
> /usr/lib/cyrus/bin/cyr_expire
> The result is the same, no files were deleted, the log file entry is
> the same as when i
> use the "/usr/sbin/cyrus expire [..]"
Looks to run cyr_expire as /usr/sbin/cyrus is a script.
https://www.apt-browse.org/browse/ubuntu/trusty/universe/all/cyrus-common/2.4.17+caldav~beta9-3/file/usr/sbin/cyrus
On 1/17/20 8:11 AM, Nikos Gatsis - Qbit wrote:
delprune cmd="cyr_expire -E 3" at=0400
Οn centos 7:
Version: 2.4.17
Title: Untitled Document
delprune cmd="cyr_expire -E 3" at=0400
Οn centos 7:
Version: 2.4.17
Release: 15.el7
On 17/1/2020 12:11 μ.μ., Horst Häberlen
wrote:
Hi Sebastian Hagedorn ,
i have no idea how follow-up works
Hi,
Am 17.01.20 um 09:52 Uhr schrieb Horst Häberlen:
> my Mail Server stores spam mail via spamassassin in users
> (user/t...@testdomain.tld) spam
> mailboxes (user/test/s...@testdomain.tld)
>
> For removing too old spam mails, i do use a script on all mailboxes which
> marks the spam
>
On 2020-01-14 16:51, Savvas Karagiannidis wrote:
> 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
Hi Niels
Thank you very much for looking into this.
Initially, I would like to get this working like I got in a real CentOS 8.
I have here a virtual machine where I did the same steps I did in
Dockerfile. But in VM I start services "*systemctl start cyrus-imapd*"
and "*systemctl
start
Am Dienstag, 14. Januar 2020, 16:47:52 CET schrieb Fabio Montefuscolo:
> I'm trying to build a simple docker image based on CentOS 8, which brings
> cyrus-imapd 3.0.7. I'm having troubles to authenticate on cyrus imap
> service for unknown reasons. There is no syslog facility working inside
> the
Hi,
That's a known issue, it's been down for months, and we don't really expect it
to come back.
All our releases are available over HTTPS from https://cyrusimap.org/releases/
Cheers,
ellie
On Tue, Jan 14, 2020, at 9:33 AM, Roar Brænden wrote:
> Hi,
>
> I've tried to install a calendar
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
On 2020-01-02 16:22, Mark wrote:
>
>
> Then, when starting up again, I get a message about skiplist shutdown
> file being missing:
>
> ctl_cyrusdb[29750]: skiplist: clean shutdown file missing, updating
> recovery stamp
>
Digging into the code a bit, I find this (below) in cyrusdb_skiplist.c.
://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
Da:
Gabriele Bulfon
A:
Vladislav Kurz
Mark
info-cyrus
Data:
17 dicembre 2019 7.26.35 CET
Oggetto:
Re: Squatter segfault on big mailbox
Hello, we're having the same problem with Cyrus
Il 02-01-2020 00:01 ellie timoney ha scritto:
I think, in that case, you should be fine! It wasn't clear if your
installation had only ever been 2.3, or had previously been upgraded
to 2.3 from some earlier version in the past, so I thought I'd better
point it out just in case :)
Cheers,
On Mon, Dec 30, 2019, at 8:59 PM, Gionatan Danti wrote:
> Are you referring to the problem described here [1]? If so, from the
> linked page I read:
> "Versions of 3.0 prior to 3.0.11 contained a bug (Issue #2839) that
> could lead to loss of seen state/flags during reconstruct for some
>
Il 30-12-2019 01:51 ellie timoney ha scritto:
You're both right. Since 2.4ish (?? MAILBOX_MINOR_VERSION=12,
anyway), a user's seen status on their own mailboxes is stored in the
mailbox index. But the separate userid.seen database is still used
for storing their seen state on mailboxes that
On Fri, Dec 27, 2019, at 11:40 PM, Gionatan Danti wrote:
> Il 27-12-2019 04:07 Scott Lambert ha scritto:
> > Didn't the seen status database get moved from it's own file to the
> > message index database for 3.x? I'm not running 3.x yet but think I
> > remember seeing something about that.
>
>
Il 27-12-2019 04:07 Scott Lambert ha scritto:
Didn't the seen status database get moved from it's own file to the
message index database for 3.x? I'm not running 3.x yet but think I
remember seeing something about that.
Hi, from what I read here [1], and from my experience when testing the
On 12/24/19 1:52 AM, Gionatan Danti wrote:
On 23/12/19 18:28, Patrick Boutilier wrote:
Only thing I can think of is that a different config file is actually
being used?
Hi Patrick, I double-checked my config and it seems the same (within
the limits imposed by the Cyrus version change).
If
On 23/12/19 18:28, Patrick Boutilier wrote:
Only thing I can think of is that a different config file is actually
being used?
Hi Patrick, I double-checked my config and it seems the same (within the
limits imposed by the Cyrus version change).
If seems to me that when default for
On 12/23/19 7:04 AM, Gionatan Danti wrote:
On 20/12/19 09:51, Gionatan Danti wrote:
Hi all,
I am tasked to migrate an old cyrus 2.3.x CentOS6 installation to a
new CentOS8 server with cyrus 3.0.7.
I'm following the instructions at
https://cyrusimap.org/imap/download/upgrade.html
On 20/12/19 09:51, Gionatan Danti wrote:
Hi all,
I am tasked to migrate an old cyrus 2.3.x CentOS6 installation to a new
CentOS8 server with cyrus 3.0.7.
I'm following the instructions at
https://cyrusimap.org/imap/download/upgrade.html (compresive of berkeley
db format change to skiplist)
Hi James,
Quoting "James B. Byrne via Info-cyrus" :
We are transferring an existing cyrus-imapd 3.0.11 mailstore to
another host also running cyrus-imapd 3.0.11. I cannot find any
documentation on how one transfers user quotas. Can someone provide
me with the link to the documentation or
://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Vladislav Kurz
A: Mark
info-cyrus
Data: 11 ottobre 2017 9.37.21 CEST
Oggetto: Re: Squatter segfault
Since there are no answers I can assume I'm alone with the problem.
Apparently lmdc has hit a limit someplace but I have no idea how to fix.
Maybe be someone can answer the following instead:
If I want to switch from lmdb to twoskip for the conversations.db, can
I simply,
set
I think you might run into problems with calendar notifications like that,
because Cyrus will think it owns the accounts' email, and try to send
notifications to its own mailboxes instead of over smtp to the real mail server?
On Mon, Dec 16, 2019, at 3:34 PM, Anatoli wrote:
> You can have a
You can have a complete Cyrus install but only use the DAV features. You
just don't open the IMAP ports in firewall and that's it.
On 16/12/19 01:12, PGNet Dev wrote:
> I run my own smtp, imap & card/cal-dav services.
>
> Atm, none are using Cyrus.
>
> I'm well aware of Cyrus Imap's
On 12/13/19 5:48 PM, Michael Menge wrote
which cyrus version did you use with CentOS7?
I can't be certain since the jump to CentOS 8 killed off my CentOS 7 install, but the latest packages listed for CentoOS
7 is cyrus-imapd-2.4.17-15.el7.x86_64.rpm
Can you post the sieve script. I don't
Hi Patrick
Quoting Patrick Boutilier :
At first glance it looks like you need to change your sieve rules to
use . as the mailbox separator. Something like:
user.jim.System Messages
I don't think the hierarchy separator is the problem. Some log outputs use the
internal format e.g.
At first glance it looks like you need to change your sieve rules to use . as
the mailbox separator. Something like:
user.jim.System Messages
On December 13, 2019 11:08:54 AM AST, Jim Sculley
wrote:
>Hello. I'm a new member of this list but a long time user of
>cyrus-imapd with postfix on my
Quoting Tod Pike :
Hello:
I am running a 3.X cyrus setup with master/slave replication. I
have discovered that one of my replicas has gotten out of sync with
it's master server, not in the sense that the mailboxes are not
replicated, but that the mailboxes live in different partitions on
the
On 12.12.2019 21.26, Niels Dettenbach wrote:
Am Donnerstag, 12. Dezember 2019, 21:06:46 CET schrieb Jesper Schmitz
Mouridsen via Info-cyrus:
It has self service support. The system has 3 roles "admin","domain
admin" and "account user".
If you are interested take a look at
sounds very
Am Donnerstag, 12. Dezember 2019, 21:06:46 CET schrieb Jesper Schmitz
Mouridsen via Info-cyrus:
> It has self service support. The system has 3 roles "admin","domain
> admin" and "account user".
>
> If you are interested take a look at
sounds very interesting - i planned to write a similiar open
On 03/12/19 14:13, Raphaël Halimi wrote:
Le 11/11/2019 à 13:53, Helder Guerreiro via Info-cyrus a écrit :
It happened again, the entropy available never got bellow 3600 (logged
it every minute or so).
Is Cyrus installed in a VM ?
It's not.
I had the same problem after upgrading Debian
Dne úterý 3. prosince 2019 15:13:54 CET, Raphaël Halimi napsal(a):
> Le 11/11/2019 à 13:53, Helder Guerreiro via Info-cyrus a écrit :
> > It happened again, the entropy available never got bellow 3600 (logged
> > it every minute or so).
>
> Is Cyrus installed in a VM ?
>
> I had the same problem
Le 11/11/2019 à 13:53, Helder Guerreiro via Info-cyrus a écrit :
> It happened again, the entropy available never got bellow 3600 (logged
> it every minute or so).
Is Cyrus installed in a VM ?
I had the same problem after upgrading Debian from 9 to 10, on some
virtual servers, with OpenSSH and
Hi Anatoli;
Thanks for your reply; I’ll be focusing on the MKCOL for now:
I don’t know about permission to overwrite quite yet, but from looking at the
source it seems the break (at
https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/http_dav.c#L5590) is
what causes HTTP_FORBIDDEN to be
Hi Johan,
In RFC 7231 (HTTP 1.1) section 3.1.1.5
(https://tools.ietf.org/html/rfc7231#section-3.1.1.5) it says that CT
header SHOULD be present, otherwise the recipient may interpret it the
way it wants, so IMO no problem on the Cyrus side here. For
application/json for example it MUST be
On Wed, Nov 20, 2019, at 4:41 PM, Deborah Pickett wrote:
> > I'm curious how these are working for you, or what sort of configuration
> > and workflows leads to having #calendars and #addressbooks as top-level
> > shared mailboxes? I've only very recently started learning how our DAV bits
> >
> I'm curious how these are working for you, or what sort of configuration
and workflows leads to having #calendars and #addressbooks as top-level
shared mailboxes? I've only very recently started learning how our DAV bits
work (they have previously been black-boxes for me), and so far have only
On Wed, Nov 20, 2019, at 11:06 AM, Deborah Pickett wrote:
> On 2019-11-20 10:03, ellie timoney wrote:
>>> foo also includes "#calendars" and "#addressbooks" on my server so there
are weird characters to deal with.
>>>
>> Now that's an interesting detail to consider.
>>
> I should restate my
On 2019-11-20 10:03, ellie timoney wrote:
foo also includes "#calendars" and "#addressbooks" on my server so there
are weird characters to deal with.
Now that's an interesting detail to consider.
I should restate my original message because I'm being fast and loose
with the meaning of
On Tue, Nov 19, 2019, at 9:38 AM, Deborah Pickett wrote:
> > Food for thought. Maybe instead of having one "%SHARED" backup, having one
> > "%SHARED.foo" backup per top-level shared folder would be a better
> > implementation? I haven't seen shared folders used much in practice, so
> > it's
Food for thought. Maybe instead of having one "%SHARED" backup, having one
"%SHARED.foo" backup per top-level shared folder would be a better implementation? I
haven't seen shared folders used much in practice, so it's interesting to hear about it.
Looking at your own data, if you had one
g, please edit your Subject line so it is more specific
> than "Re: Contents of Info-cyrus digest..."
>
>
> Today's Topics:
>
>1. Cyrus doesn't preserve hard-links on replication
> (Adrien Remillieux)
>
>
> --
But without rolling replication, or with mailboxes that were already DELETED.*
before the backup service was configured, I'm not sure what to expect. I'm not
sure if this is a case that I considered and did something for, but have since
forgotten about, or if it's a case that I hadn't
il, send a message with subject or body 'help' to
> info-cyrus-requ...@lists.andrew.cmu.edu
>
> You can reach the person managing the list at
> info-cyrus-ow...@lists.andrew.cmu.edu
>
> When replying, please edit your Subject line so it is more specific
>
the likelihood of the compressed byte
> stream being the same is slim. That will confound the rsync rolling
> checksum algorithm and the entire backup file will likely have to be
> transmitted again.
Yeah, these files are append-only even within the backup system's own tool
On Fri, Nov 15, 2019, at 5:12 PM, Deborah Pickett wrote:
> Semi-related questions about how Cyrus backup servers deal with deleted
> stuff.
>
> I have the following settings on the main mail server:
>
> deletedprefix: DELETED
> delete_mode: delayed
> expunge_mode: delayed
>
> My first question
Further progress report: with small chunks, compaction takes about 15
times longer. It's almost as if there is an O(n^2) complexity
somewhere, looking at the rate that the disk file grows. (Running perf
on a compaction suggests that 90% of the time ctl_backups is doing
compression,
On 2019-11-11 11:10, ellie timoney wrote:
This setting might be helpful:
Thanks, I saw that setting but didn't really think through how it would
help me. I'll experiment with it and report back.
That would be great, thanks!
Progress report: I started with very large chunks (minimum 64 MB,
Title: Untitled Document
Thank you very much!
On 14/11/2019 1:49 μ.μ., Patrick
Boutilier wrote:
On
11/14/19 7:38 AM, Nikos Gatsis - Qbit wrote:
Hello list.
Does somebody knows witch version on cyrus-imapd centos 8
On 11/14/19 7:38 AM, Nikos Gatsis - Qbit wrote:
Hello list.
Does somebody knows witch version on cyrus-imapd centos 8 install?
Thank you in advance.
yum list|grep cyrus-imapd
cyrus-imapd.i686 3.0.7-15.el8_0.1
On Thu, 14 Nov 2019 at 08:44, Michael Menge
wrote:
> here is the why only addresses are show and not function names
> you need the debug package for your cyrus imapd
To be fair, you also need to run
gdb /path/to/imapd coredump
as per
>
Quoting Marco :
Hello Michael,
I've generated the dump, but it isn't easy for me to understand
the content...
[root@cyrus ccpp-2019-11-13-07:04:30-19177]# gdb coredump
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+:
Hello Michael,
I've generated the dump, but it isn't easy for me to understand the
content...
[root@cyrus ccpp-2019-11-13-07:04:30-19177]# gdb coredump
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or
Hi Marco,
can you generate a coredump and generate a backtrace (e.g. with gdb
https://stackoverflow.com/questions/5115613/core-dump-file-analysis )
You might need to install some debug packages.
Quoting Marco :
Il 12/11/2019 22:58, ellie timoney ha scritto:
On Tue, Nov 12, 2019, at 2:51
Il 12/11/2019 22:58, ellie timoney ha scritto:
On Tue, Nov 12, 2019, at 2:51 AM, Marco wrote:
An user user/a has full ACL to another mailbox user/b. When the user/a
SELECT a folder on user/b where he has access the imap process crashes.
If you set up a couple of test accounts with the same
On Tue, Nov 12, 2019, at 2:51 AM, Marco wrote:
> An user user/a has full ACL to another mailbox user/b. When the user/a
> SELECT a folder on user/b where he has access the imap process crashes.
If you set up a couple of test accounts with the same sharing arrangement, do
those crash in the same
Hello Helder,
If there is no enough random seed OpenSSL will not hang, just return an error.
Even /dev/random is opened in non-blocking mode. This is true only if OpenSSL
is built with non-blocking mode.
https://github.com/openssl/openssl/blob/master/crypto/rand/rand_unix.c
If it hangs after
> Hello,
>
> we are experiencing a strange problem on cyrus-imapd 2.4.17.
>
> An user user/a has full ACL to another mailbox user/b. When the user/a
> SELECT a folder on user/b where he has access the imap process crashes.
>
> $ telnet cyrus.example.com 143
> Trying 10.10.10.10 ...
> Connected
On 10/11/19 00:19, Helder Guerreiro via Info-cyrus wrote:
On 09/11/2019 23.34, Patrick Boutilier wrote:
Almost sounds like you are running out of entropy. What does this show?
cat /proc/sys/kernel/random/entropy_avail
Right now it's at 3769 bytes. I'll monitor this.
It happened again, the
Yes i have server handles invitations and same thing with thunderbird
Le 10/11/2019 à 15:13, Adam Tauno Williams a écrit :
i ve got this in the log
imip_send_sendmail(t...@test.domain.com): Sendmail process terminated
normally, exit status 0
But if i look in the calendar of titi or in the
Answering my own question:
... or do I need to establish my own SSH tunnel from master to backup
server?
I do have to supply my own tunnel. The Cyrus backup daemon currently
(3.1.7) doesn't support the STARTTLS command.
if (!strcmp(cmd.s, "Starttls") && tls_enabled()) {
On Fri, Nov 8, 2019, at 1:35 PM, Deborah Pickett wrote:
> I didn't know if copying
> the filesystem of a (paused) Cyrus replica was a supported way of
> backing up, but now I do.
Yeah, as long as there are no cyrus processes running, the database/index files
can just be copied about and won't
> i ve got this in the log
> imip_send_sendmail(t...@test.domain.com): Sendmail process terminated
> normally, exit status 0
> But if i look in the calendar of titi or in the mailbox I see nothing (I
> ve have been testing with thunderbird and evolution)
> There is nothing explaining well how it
On 09/11/2019 23.34, Patrick Boutilier wrote:
Almost sounds like you are running out of entropy. What does this show?
cat /proc/sys/kernel/random/entropy_avail
Right now it's at 3769 bytes. I'll monitor this.
Note that STARTTLS works fine.
Cyrus Home Page: http://www.cyrusimap.org/
List
Almost sounds like you are running out of entropy. What does this show?
cat /proc/sys/kernel/random/entropy_avail
On 11/9/19 7:16 PM, Helder Guerreiro via Info-cyrus wrote:
Hi all
I'm having this exact same problem. Once the daemon is up it takes a
while (a random while) to get to this
Hi all
I'm having this exact same problem. Once the daemon is up it takes a
while (a random while) to get to this state.
I'm on Debian 9.11 (stretch) which still is on Cyrus imap 2.5.10.
Any help would be very much appreciated.
/Helder
On 13/01/2015 10.22, Niels Dettenbach wrote:
Hi all,
Thanks Patrick. I wonder if I inadvertently compiled out support for TLS when I
built my binaries. I’ll try it again with the stock binaries rather than my
patched ones.
> On 8 Nov 2019, at 22:42, Patrick Boutilier wrote:
>
> Odd, works here.
>
>
> telnet localhost 2005
> Trying ::1...
>
Just noticed that I am running an older version of Cyrus though.
On 11/8/19 7:35 AM, Patrick Boutilier wrote:
Odd, works here.
telnet localhost 2005
Trying ::1...
Connected to localhost.
Escape character is '^]'.
* SASL PLAIN
* STARTTLS
* COMPRESS DEFLATE
* OK domain Cyrus sync server
Odd, works here.
telnet localhost 2005
Trying ::1...
Connected to localhost.
Escape character is '^]'.
* SASL PLAIN
* STARTTLS
* COMPRESS DEFLATE
* OK domain Cyrus sync server v2.4.20
STARTTLS
OK Begin TLS negotiation now
On 11/8/19 2:12 AM, Deborah Pickett wrote:
... or do I need to
On 2019-11-08 09:13, ellie timoney wrote:
I'm not sure if I'm just not understanding, but if the chunk offsets were to
remain the same, then there's no benefit to compaction? A (say) 2gb file full
of zeroes between small chunks is still the same 2gb on disk as one that's
never been compacted
I'm not sure if I'm just not understanding, but if the chunk offsets were to
remain the same, then there's no benefit to compaction? A (say) 2gb file full
of zeroes between small chunks is still the same 2gb on disk as one that's
never been compacted at all!
And if you don't use the compaction
x RENAME
should work
On 10/29/19 5:04 AM, David Phan wrote:
Hi,
Any update on this topic?
Regards,
David Phan
06.73.38.77.00
BlueMind
+33 (0)5 81 91 55 60
Hotel des Télécoms, 40 rue du village d'entreprises
31670 Labège, France
www.bluemind.net / https://blog.bluemind.net/fr/
Hi,
Any update on this topic?
Regards,
David Phan
06.73.38.77.00
BlueMind
+33 (0)5 81 91 55 60
Hotel des Télécoms, 40 rue du village d'entreprises
31670 Labège, France
www.bluemind.net / https://blog.bluemind.net/fr/
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info:
Hi Ellie,
On 2019-10-16 13:53, ellie timoney wrote:
> On Mon, Oct 14, 2019, at 10:29 AM, ellie timoney wrote:
>
> I think this is fixed now, on both master and 3.0 branches. Testing
> and feedback appreciated, of course!
This is looking a lot better.
$ imtest -a cyrus localhost
[...]
BBB
On Mon, Oct 14, 2019, at 10:29 AM, ellie timoney wrote:
> I've created a github issue
> (https://github.com/cyrusimap/cyrus-imapd/issues/2893), and am about to make
> a test case to reproduce the problem, so I can get on with fixing it. :)
I think this is fixed now, on both master and 3.0
Thanks! You have the more correct fix:
From: https://www.openssl.org/docs/man1.1.0/man3/TLSv1_client_method.html
"TLS_method(), TLS_server_method(), TLS_client_method()
These are the general-purpose version-flexible SSL/TLS methods. The
actual protocol version used will be negotiated to the
Thanks for reporting back. For whatever its worth, the equivalent fix on 2.5+
uses "TLS_client_method()", not "TLSv1_2_client_method()". I'm not sure what
difference it makes, but maybe it requires a newer OpenSSL than you have?
Here's the commit to master, fyi:
Turns out imclient (at least in the latest RHEL7 pkg) is hardcoded to
use TLSv1. Since we're building binary RPMs from Source RPMs anyway we
modified imclient.c, rebuilt the RPMs, reinstalled the cyrus-imapd-utils
package: Here's the patch we used:
Am 14.10.19 um 03:00 schrieb Deborah Pickett:
> So how are people currently backing up shared folders, if they’re not
> using Cyrus backupd?
FWIW, we just take snapshots of the file systems and backup those. Mail
files aren't databases, so I don't think you have to worry about
corrupted files as
ralian owned and operated for over 30 years
From: ellie timoney
Sent: Monday, 14 October 2019 10:29
To: Deborah Pickett ; info-cyrus@lists.andrew.cmu.edu
Subject: Re: XBACKUP and backupd not backing up public folders (3.0.8)
Hi Deborah,
Thanks, that's all useful! Looks like in both
Hi Deborah,
Thanks, that's all useful! Looks like in both places it's struggling with lack
of a userid, which makes some sense because it's a shared mailbox, and shared
mailboxes don't have userids.
I guess this means that in its current state, the backup system can't handle
shared mailboxes.
Hi Ellie,
Thanks for helping me look at this.
On 2019-10-09 16:17, ellie timoney wrote:
> Does the same problem occur if you use sync_client (on the master server, as
> the cyrus user) to replicate the shared mailbox to the backup server (rather
> than using XBACKUP over IMAP)? Something like
Hi Deborah,
Does the same problem occur if you use sync_client (on the master server, as
the cyrus user) to replicate the shared mailbox to the backup server (rather
than using XBACKUP over IMAP)? Something like "sync_client -n rsync -m
supp...@polyfoam.com.au" I think? What about if you
Hi Gabriele,
I suggest you send the actual headers of both emails here as plain text
in the body of the email, as people may not want to open attachments
from unknown sources. Also it's easier to analyze and reply this way.
Regards,
Anatoli
On 26/9/19 11:52, Gabriele Bulfon wrote:
> Hello,
>
Hi Pete,
I guess the 'address' test command matches only the actual address, not
the description. In your example it would match "my@address".
I suggest you check
https://www.cyrusimap.org/imap/reference/admin/sieve.html and
https://thsmi.github.io/sieve-reference/en/index.html.
Regards,
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
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]:
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@lists.andrew.cmu.edu
> Subject: Re: Possible issue when upgrading to cyrus 3.0.8 using
> replication ?
> Message-ID:
&g
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
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
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
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
On 8/20/19 11:01 AM, Sebastian Hagedorn wrote:
>
> Am 20.08.19 um 10:45 Uhr schrieb Lars Schimmer:
>> Hi!
>>
>> I did setup a debian buster system with cyrus 3.0.8-6
>> We setup cyrus to use saslauth to authenticate against AD.
>>
>> So far all known windows/linux IMAP clients do fetch their IMAP
Am 20.08.19 um 10:45 Uhr schrieb Lars Schimmer:
> Hi!
>
> I did setup a debian buster system with cyrus 3.0.8-6
> We setup cyrus to use saslauth to authenticate against AD.
>
> So far all known windows/linux IMAP clients do fetch their IMAP mails
> without issues.
>
> But we got a issue with
201 - 300 of 31205 matches
Mail list logo
