://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
Hi Konrad,
> do_folders: failed to order folders correctly
Do you have "improved_mboxlist_sort" enabled in your imapd.conf? My guess is
you don't.
> every time on a specific mailbox of a specific user.
It sounds like this user has two mailboxes where one is an exact substring of
another,
On Thu, 24 Sep 2020, at 1:44 AM, Jean Charles Delépine wrote:
> Is this a known problem corrected after 3.0.9 ?
Off the top of my head I no longer remember, but the current release in the 3.0
series is 3.0.14. I'd suggest, if you haven't already, that you look in the
release notes from
://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
Hi Frederik,
>From the source, it looks like this error is reported when the internal counts
>in the conversations data are out of sync.
I don't have any insight as to what might cause this, but I think you should be
able to run "ctl_conversationsdb" with the "-R" argument for the affected
of the Cyrus team,
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
Hi,
I've seen something like this before, and my gut feel is that this is going to
turn out to be a bug in Cyrus.
I think what's happening is that, somewhere in Cyrus, an event is being
generated with a type that's supposed to contain a serverAddress field, but the
serverAddress field is not
on it
and see what unfolds.
Cheers,
ellie
On Wed, Jul 15, 2020, at 10:39 AM, ellie timoney wrote:
> It's hosted on GitHub Pages. There's supposed to be a DNS CNAME entry at
> "www.cyrusimap.org" pointing to "cyrusimap.github.io", but it seems to have
> disappeared
It's hosted on GitHub Pages. There's supposed to be a DNS CNAME entry at
"www.cyrusimap.org" pointing to "cyrusimap.github.io", but it seems to have
disappeared. /sigh
Without that DNS entry, even going directly to "cyrusimap.github.io" isn't
working, because GitHub Pages wants to redirect to
Hi Marco,
On Tue, Jul 7, 2020, at 12:17 AM, Marco wrote:
> I copied the content of the failing mailbox into another mailbox with a
> name without dots:
Oh that's very curious. It suggests that something about the mailbox contents
is causing it to fail under -A but not under -u. I was hoping
On Wed, Jul 1, 2020, at 11:57 PM, Marco wrote:
> Uhm...
Wow, that's wierd.
I notice that the users that worked correctly with "sync_client -A" don't have
dots in their address localparts. If you create another user that also has a
dot, does it fail under -A in the same way?
Does it fail in
Hi,
I think I would do something like:
0) set client_timeout to a big value (see below)
1) let the imapd start normally
2) connect to it with a minimal imap client (like imtest or telnet)
3) check logs to see which imapd process id your client is connected to (if
there's more than one)
4) use
Hi Sergey,
Quoting out of order, because it's a bit easier to explain that way:
> And there is another problem that is not obvious. -lpcreposix is needed
> in perl/imap/Makefile.PL and in perl/sieve/managesieve/Makefile.PL I seems.
This bit sounds a lot like
On Tue, Jun 30, 2020, at 10:10 PM, Sergey wrote:
> On Monday 22 June 2020, ellie timoney wrote:
>
> > The Cyrus team is proud to announce the immediate availability
> > of a new version of Cyrus IMAP: 3.2.2
>
> There was a problem with AC_SYS_LARGEFILE. Most likely it w
I have no idea what this refers to or where it comes from. Any further
information you could provide would be greatly appreciated!
Thanks
On Tue, Jun 30, 2020, at 5:14 AM, Sergey wrote:
> On Monday 22 June 2020, ellie timoney wrote:
>
> > The Cyrus team is proud to announce t
Hi,
I'm not sure, but it kind of sounds like your mailbox's index version is too
old?
Around 2.4, the storage of the mailbox owner's seen state was moved from the
seen databases to the cyrus.index. (i.e. nowadays the seen database only
stores the seen state for _other_ users who have been
Hi Sergey,
> Hardware support:
>SSE4.2: yes
This is detected for a hardware implementation of the CRC32c algorithm. Cyrus
doesn't actually use it though, because it's not compatible with the existing
CRC32 algorithm: i.e. for the same input, it produces a different checksum,
> I think there isn't a all-in-one command for this use case: a user
> expunged some messages and deleted some folders somewhere. I want to
> recover all expunged messages and all the deleted folders which are no
> more present in the original IMAP server (because they were expired from
>
Hi Tim,
It's worth observing that, in Cyrus, the user "george"'s IMAP inbox is the
"user/george" folder. Which means, on disk, this user has another folder
called "INBOX" within their inbox. Depending on the Cyrus version, and maybe
depending on your server's value of "altnamespace", this is
://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
Hi Marco,
On Fri, Jun 19, 2020, at 6:44 PM, Marco wrote:
> wow, yes, it works. With this config, after the Cyrus restart the
> mailboxes.db and the skipstamps dbs are created and the error disappears
> from syslog.
Great! I've updated the documentation, and the website should update shortly.
Hi Marco,
On Thu, Jun 18, 2020, at 10:19 PM, Marco wrote:
> Hello,
>
> I'm trying to configure backupd in rolling mode as a final setup.
> Running a first backup on few users
>
> sync_client -A -n bck -z -v -v
>
> after a while the process die with:
>
> cyrus/sync_client[9540]: MESSAGE
Hi Marco,
On Thu, Jun 4, 2020, at 11:04 PM, Marco wrote:
> On 29/05/2020 06:20, ellie timoney has written:
> > The Cyrus team is proud to announce the immediate availability of a new
> > version of Cyrus IMAP: 3.2.1
>
> Hello,
>
> in Redhat EL8 I still fa
Hi David,
> Is it possible to enable the "editheaders" sieve extension? if so, how?
Not in 3.0, but it's available in 3.2
> Are sieve actions logged anywhere, e.g. to aid with debugging?
Generally? I don't know. Maybe if you increase your syslog log level to
"debug" and add "debug: yes" to
On Fri, Jun 5, 2020, at 4:48 AM, Albert Shih wrote:
> Le 04/06/2020 à 10:23:12+0200, Marco a écrit
> > Hello,
> >
> >I see that Cyrus IMAP 3 can interface with some Object Storage such as
> > Caringo or OpenIO.
> >
> > Is anyone using these solutions?
> >
> > I would like to know how I can
://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
On Mon, May 18, 2020, at 4:17 PM, Marco wrote:
> Ouch... I will try
>
> Thank you for the hint
> Marco
I think I might have figured out a way to work around (not fix) the problem (by
detecting when the LD_PRELOAD hasn't worked, and ignoring the syslog bits), and
written it down here so I don't
The discussion on github about the lmtpd crash on RHEL7 makes me wonder if
FORTIFY_SOURCE, or something adjacent to it, is the cause of your Cassandane
LD_PRELOAD problem as well?
I don't know much about it -- it's not default on my system, and even though
github reminds me that I've looked at
Hi Marco,
> But it really seems that the LD_PRELOAD or the syslog.so doesn't
> work for me.
Thanks for including that detail. Hopefully someone familiar with RedHat can
chime in with some insight into the LD_PRELOAD issue! At a guess, "preventing
library injection from intercepting syslog
Hi Marco,
On Thu, May 7, 2020, at 7:51 PM, Marco wrote:
> The Instance.pm of Cassandane looks for a log in
>
> {basedir}/conf/log/syslog
>
> but the Cyrus IMAP log to system MAIL syslog, in redhat by default is
> /var/log/maillog.
Did you run "make" in the cassandane directory, like the
Hi Marco,
> I work with
> https://github.com/cyrusimap/cassandane/archive/00bfe0109f80437ed09154aca9fbd53eef8f1b09.tar.gz
> This cassandane release works pretty with 3.0.12. I didn't find build
> changes in Release notes for 3.2.0...
We don't do releases of Cassandane. That thing is just a
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
> Just to clarify here - are not IMAP/POP/LMTP actions logged anyway -
> using sync_log? Won't they grow forever, too?
Yes, but no, because your replica is not taking IMAP/POP/LMTP/etc traffic,
therefore no such actions are occurring on it.
If it is taking that traffic, it's not a replica,
On Thu, Apr 30, 2020, at 12:29 AM, Olaf Frączyk wrote:
> However why the sync_log_chain could be not always active? As the server
> catches all changes from LMTP, IMAP, POP anyway, why to use a special
> option for the synchronization protocol? Why to treat replication
> changes differently
On Wed, Apr 29, 2020, at 1:12 AM, Olaf Frączyk wrote:
> I was wondering why do we need to use this option on middle servers in
> replication chain?
When a user/delivery/admin/etc action happens on a mailbox/user/etc, an entry
is recorded in the sync log saying that something has happened to
I think Michael's got this pretty much covered -- you need to disable the
rolling replication for now, and then use sync_client -u (or if you're brave,
sync_client -A) to get an initial sync of everything. These two options work
entire-user-at-a-time, so they should detect and fix the problems
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
Correction:
https://www.cyrusimap.org/3.2/imap/download/release-notes/3.2/x/3.2.0-beta4.html
https://www.cyrusimap.org/3.2/imap/download/upgrade.html
On Mon, Mar 30, 2020, at 3:13 PM, ellie timoney wrote:
> The Cyrus team is proud to announce the fourth beta release from the
&g
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
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
I don't really understand search in any depth, but it's interesting to observe
that, in addition to the different command (SEARCH vs THREAD), those two
searches are also using different search criteria ("BODY linux" vs "TEXT
linux").
It might be informative to try do the SEARCH search with
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
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
On Mon, Feb 3, 2020, at 11:02 PM, Sebastian Hagedorn wrote:
> just a guess, but isn't LSUB the command for listing subscribed
> mailboxes? I'm not actually sure it makes a difference, but you should
> give it a try ...
>
LIST (\Subscribed) is one of the extensions we support, it should work fine
>> On Mon, Jan 27, 2020, at 9:51 AM, Egoitz Aurrekoetxea via Info-cyrus wrote:
>>> Just for having it slightly clearer… When you upgrade the Cyrus version and
>>> the version you are upgrading to is a too close one… for instance from
>>> 3.0.8 to 3.0.13 and you see the Cyrus version is the same
Hi Daniel,
On Thu, Jan 23, 2020, at 10:34 PM, 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
> /usr/bin/ld: warning: libicuuc.so.57, needed by
>
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
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
>
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.
>
>
.
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
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
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
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
> >
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
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
> Related: I had to apply the patch described in
> (https://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg47320.html),
> "backupd IOERROR reading backup files larger than 2GB", because during
> initial population of my backup, chunks tended to by multiple GB in size
> (my %SHARED user
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
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
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
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
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'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
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 maste
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:
to make a
test case to reproduce the problem, so I can get on with fixing it. :)
Cheers,
ellie
On Fri, Oct 11, 2019, at 6:02 PM, Deborah Pickett wrote:
> 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
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 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
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 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:
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
I think they said 3.0.8, which is not the latest 3.0, but I also don't think
anything about replication/subscriptions/etc has changed since then, so it
might as well be
It would also be very interesting to know whether the master and replica
definitely both have the same value for
rusimap/cyrus-imapd/commit/0930d3af4ed9bd44d328db8cfa4d9f2e2be7bada
Remains to be seen whether more similar issues pop up -- since no-one's tripped
over this previously, I guess you're the first person to try this with a >2GB
backup file :(
Cheers,
ellie
On Fri, Jun 14, 2019, at 3:50 PM, ell
/*aaa_ouuUx9*
>> -rw--- 1 cyrus mail 3.5M Jun 6 16:46
>> /b1/bck/b1/a/aaa_ouuUx9.index
>> -rw--- 1 cyrus mail 2.6K Jun 6 17:08
>> /b1/bck/b1/a/aaa_ouuUx9.index-journal
>>
>> -rw--- 1 cyrus mail 2.9G Jun 6 17:01 /b1/bck/b1/c/ccc_Mqmymx
>> -r
Hi Sven,
On Thu, Jun 13, 2019, at 12:27 AM, Sven Schwedas wrote:
> Is there another way to get ptloader to spit out debug information and
> pinpoint what's not set up correctly?
>
I remember this thing as being very noisy, let me see...
Okay, in your cyrus.conf SERVICES entry, if you add "-d1"
It kinda sounds like your platform might be 32bit? Or your zlib is compiled to
use 32bit integer sizes?
On Mon, Jun 3, 2019, at 10:07 PM, Carlos Larrañaga wrote:
> Hi,
>
> We're testing backup feature un cyrus-imapd 3.0.10. There's no problem when
> backup is created first time, but when the
g 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
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
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
Hi Ismaël,
Which version of perl are you running? (`perl --version` will tell you) A
fairly newish one, I guess?
The cyradm tools were written using a quite old version of perl, which didn't
produce a lot of warnings. I expect it's working fine, but your newer perl
version is producing
Hi Sven,
I don't know much about running it in a production capacity, but our test suite
sets up the following for LDAP pts:
imapd.conf:
...
ptloader_sock: /path/to/some/socket
auth_mech: pts
pts_module: ldap
...
cyrus.conf:
SERVICES {
...
ptloader cmd="ptloader"
On Tue, Mar 26, 2019, at 6:50 AM, Patrick Goetz wrote:
> I believe the version number change (incremental change to stable
> release) indicates you shouldn't have any problems, but of course shut
> down the service while it's being updated.
Yep, no major changes within a single x.y series. Of
On Tue, Mar 19, 2019, at 3:39 PM, Anatoli via Info-cyrus wrote:
> > The Cyrus httpd provides DAV services (which use the HTTP protocol). If
> you want the Cyrus httpd to support HTTP/2, you will need libnghttp2.
> Otherwise it will only support HTTP/1.
>
> Always wanted to ask what the
Hi Patrick,
On Mon, Mar 18, 2019, at 11:33 PM, Patrick Goetz wrote:
> This page on compiling cyrus-imapd:
>
>https://www.cyrusimap.org/imap/developer/compiling.html
This page is in the developer section, so its context is for people who are
Cyrus developers (especially for new contributors
://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
I've raised https://github.com/cyrusimap/cyrus-imapd/issues/2659 to get this
properly fixed
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
On Sat, Mar 2, 2019, at 2:54 AM, Michael Menge wrote:
> Is there an other way than disabling
> - conversation db,
> - restoring the folder,
> - enabeling conversation db again (so that squat files are used for
> header searches),
> - rebuilding conversation db for all users (because there will
Hi Ivan,
> #7 0x56193ed6382e in idle_update ()
> with cyrus-imapd 2.4.17 (cyrus-imapd-2.4.17-13.el7.x86_64 rpm)
It looks like this version is old enough to still be using signal handlers in
its IMAP IDLE implementation. This is known to be a problem, and IDLE was
rewritten to not use
Hi Michael,
On Tue, Jan 22, 2019, at 12:32 AM, Michael Menge wrote:
> Hi Ellie
>
> Quoting ellie timoney :
>
> > Hi Michael,
> >
> > On Wed, Jan 16, 2019, at 10:12 PM, Michael Menge wrote:
> >> Hi,
> >>
> >> because conversations d
Hi Michael,
On Wed, Jan 16, 2019, at 10:12 PM, Michael Menge wrote:
> Hi,
>
> because conversations db seems to be required for search indexes, I
> enabled this option
> on our production servers today and tried to rebuild the conversations
> db for all users with
>
> ctl_conversationsdb -v
Hi Miguel,
On Sat, Jan 19, 2019, at 8:20 AM, Miguel Mucio Santos Moreira wrote:
> Hi folks!
>
> I've had a problem with some huge mailboxes, with a lot of folders and
> subfolders. Problably thousand of folders.> The access on these mailboxes is
> too slow, if you change from INBOX to
> another
ne implementation. Sounds like we've found our bug!
I'll have a bit of a play with it and see if I can find/fix the discrepancy
between the interfaces :)
Cheers,
ellie
On Wed, Dec 19, 2018, at 5:00 AM, Binarus wrote:
> Dear ellie,
>
> On 17.12.2018 23:57, ellie timoney wrote:
> > Hi
Hi Binarus,
Looks like the documentation for the authenticate() function is pretty
incomplete...
> Well, this man page "documents" the method by exactly one line
> (identically in two places):
>
> $client->authenticate;
>From my read of the documentation, this is enough. It will figure out
Hi Binarus,
> Could anybody please tell me what I might do wrong here?
This kind of smells like maybe your system has two versions of perl installed
(or two versions of Term::ReadLine, or maybe even two versions of
Cyrus::IMAP::Shell), and they're getting in each other's way?
I'm having a
Hi Binarus,
> Could anybody please shortly explain why? What exactly are the
> techniques and mechanisms cyradm's xfer uses to do its thing? I had been
> quite sure that it just uses the IMAP protocol, but there seems to be
> more to it ...
You're right, but missing a detail. The XFER
> Would be fine if Bron, Ellie or someone at Fastmail could tell
> something about it to us :) :)
Cheeky! Thing is, at FM our production servers more or less track the
master branch, so we were running "3.0" from the moment 2.5 forked off,
and so our upgrade process only ever really needs to deal
Thanks Sergey, these have been corrected and should update automatically in the
next 15 minutes or so :)
On Sun, Nov 25, 2018, at 11:14 PM, Sergey wrote:
> On Tuesday 20 November 2018, Ken Murchison wrote:
>
> > I'm pleased to announce the release of the long-awaited SASL 2.1.27
> > which can
Hi Kristian,
The "A5" and "A7" are just the "tags" associated with the client's search
commands, they have no semantic value. The client prefixes each command with
some tag, and then the server uses the same tag in the response (so that you
can identify which response applies to which
.
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
On Mon, Oct 1, 2018, at 12:32 PM, ellie timoney wrote:
> You could use the tls_sessions_db_path imapd.conf(5) option to put this
> database onto faster storage?
>
> > tls_sessions_db_path:
> > The absolute path to the TLS sessions db file.
On Sat, Sep 29, 2018, at 8:59 AM, Paul van der Vlis wrote:
> Op 28-09-18 om 15:34 schreef Michael Menge:
> >
> > Quoting Paul van der Vlis :
> >
> >> Hello,
> >>
> >> I am using Cyrus-imapd from Debian stable (2.5.10-3), and starting up
> >> takes very long. I see processes starting, but no
1 - 100 of 237 matches
Mail list logo
