The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.2.4
Download URLs:
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.2.4/cyrus-imapd-3.2.4.tar.gz
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.2.3
Download URLs:
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.2.3/cyrus-imapd-3.2.3.tar.gz
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus
The Cyrus team is proud to announce the immediate availability of new legacy
versions of Cyrus IMAP.
The primary motivator for these releases is to allow XFER to correctly
recognise newer Cyrus backends. If you run a legacy Cyrus installation in a
murder configuration, and ever wish
hread dies with this assertion:
Jul 15 18:01:54 snow imaps[28108]: Cannot notify event Login: missing
parameters: serverAddress clientAddress
Jul 15 18:01:54 snow imaps[28108]: Fatal error: Internal error:
assertion failed: imap/mboxevent.c: 743: filled_params(type, event)
If I remove ev
verAddress clientAddress
Jul 15 18:01:54 snow imaps[28108]: Fatal error: Internal error:
assertion failed: imap/mboxevent.c: 743: filled_params(type, event)
If I remove event_groups and event_extra_params then notify never calls
my external script and notify breaks.
If I define "event_groups: a
clientAddress timestamp service
>
> Then the imapd thread dies with this assertion:
>
> Jul 15 18:01:54 snow imaps[28108]: Cannot notify event Login: missing
> parameters: serverAddress clientAddress
> Jul 15 18:01:54 snow imaps[28108]: Fatal error: Internal error:
> assertion fail
snow imaps[28108]: Cannot notify event Login: missing
parameters: serverAddress clientAddress
Jul 15 18:01:54 snow imaps[28108]: Fatal error: Internal error:
assertion failed: imap/mboxevent.c: 743: filled_params(type, event)
If I remove event_groups and event_extra_params then notify never calls
On Wednesday 01 July 2020, ellie timoney wrote:
> Yes, please. If you don't, I will, but then you won't get
> automatic notifications of updates.
https://github.com/cyrusimap/cyrus-imapd/issues/3090
> Are they appearing in a log somewhere, or is this output
> from an analysis tool you're
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 https://github.com/cyrusimap
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
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 was
there before, but I was no need to use AC_SYS_LARGEFILE.
Programs for x32
On Tuesday 30 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
> >
> > Tests have issued a new warning compared to 3.0.x (building in Linux):
> > verify-elf: WA
he immediate availability of a new
> > version of Cyrus IMAP: 3.2.2
>
> Tests have issued a new warning compared to 3.0.x (building in Linux):
>
> verify-elf: WARNING: ./usr/lib64/libcyrus.so.0.0.0: found executable
> STACK entry:
> GNU_STACK 0x00 0x00
On Friday 16 October 2015, Sergey wrote:
> I wanted to build Cyrus-IMAP with libpcre but it did not success.
> System libpcre-devel package install headers to /usr/include/pcre.
I returned to this question. 3.2.2 still does not find /usr/include/pcre/pcre.h
$ pkg-config --cflags libpcre
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
Tests have issued a new warning compared to 3.0.x (building in Linux):
verify-elf: WARNING: ./usr/lib64/libcyrus.so.0.0.0: found exec
On Monday 29 June 2020, ellie timoney wrote:
> If you _want_ to use the hardware CRC32c algorithm
No. I want for Cyrus-IMAP works on systems without SSE4 when it built
on system with SSE4.
> > Can Cyrus-IMAP be running on systems without SSE4 at this case?
>
> Yep, it'll
on a brand new deployment
> (and know what you are doing), I believe at this stage you would need to
> patch Cyrus to use it -- the code is there, but it is never called.
>
>> Can Cyrus-IMAP be running on systems without SSE4 at this case?
>
> Yep, it'll work just fine. Th
Can Cyrus-IMAP be running on systems without SSE4 at this case?
Yep, it'll work just fine. The hardware CRC32c code will simply not be
compiled, which, since it isn't used anyway, will have no effect.
> If no, can I set limit to SSE2 ?
There's currently no configurability for this at all.
Hello.
I saw what Cyrus-IMAP use SSE:
Hardware support:
SSE4.2: yes
Can Cyrus-IMAP be running on systems without SSE4 at this case?
If no, can I set limit to SSE2 ?
--
Regards,
Sergey
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http
Hi
I'm dealing with a very old cyrus server (cyrus-imapd-2.2.12-27.2).
Two days ago we had a problem that made "/var" full (/var/lib/imap/
is the cyrus imap directory).
After cleaning the postfix queue and restarting cyrus daemon
everything looked to be fine.
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.2.2
Download URLs:
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.2.2/cyrus-imapd-3.2.2.tar.gz
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus
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
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?
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 find more details about these deployment
Interestingly, through no action on my (as admin) part, this problem
seems to have resolved itself on May 31. According to my backup, on
May 29 for my main inbox, user.brian, there were 13339 files on the
disk but on May 31's backup there are only 4136.
IMAP has always reported
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 fail these tests:
ERRORS:
Rename.rename_inbox
Perl exception: Errors found in syslog
at Cassandane/Instance.pm
nterpret it's output to this task.
Or maybe there other/better tools?
Any suggestions?
Have you looked in some of the orphaned messages to see if they are
emails you have deleted before? My thought would be to move these
orphaned messages out of /var/spool/imap/b/user/brian . Then delete and
expunge
You could try 'reconstruct -R' which should force a re-parsing of all
message files in the mailboxes directory. Note that if this works, you
will have 8k new messages show up in your mailbox. Adding -n may just
report what reconstruct will do rather than actually doing it.
On 6/4/20 6:45
te mail user. Copy your existing
> message
> over via imap to the new folder.
> Delete and expunge the original mailbox and recreate, recopy.
I have considered that. But I suspect that is going to cause the
message numbers on the disk to be recreated. Since this seems to
affect many (al
On Wed, 2020-06-03 at 19:35 -0400, Ken Murchison wrote:
> Brian,
>
> Trying running 'unexpunge -l' on the mailbox in question.
This avenue has already been explored earlier in this thread:
https://lists.andrew.cmu.edu/pipermail/info-cyrus/2020-May/041258.html
To save the effort of re-reading
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 find more details about these deployment,
other than the brief description in imapd.conf man page.
In particular I would like
appears to correlate with
the message file name.
At a guess something appears significantly awry.
To resolve the immediate issue.
Have you tried create a separate mail user. Copy your existing message
over via imap to the new folder.
Delete and expunge the original mailbox and recreate, recopy
Hi Brian,
The answer to your question is that yes, UID appears to correlate with
the message file name.
At a guess something appears significantly awry.
To resolve the immediate issue.
Have you tried create a separate mail user. Copy your existing message
over via imap to the new folder
On Tue, 2020-05-26 at 09:33 -0400, Brian J. Murrell wrote:
> Hi.
>
> Every IMAP client I query my cyrus imapd 2.4.17 server with says I
> have
> ~4K messages in my INBOX. However when I do a listing of
> /var/spool/imap/b/user/brian/ it shows almost 13K files.
>
> None o
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.2.1
Download URLs:
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.2.1/cyrus-imapd-3.2.1.tar.gz
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus
original post more
completely. My bad.
-nic
As shown in this excerpt from the manpage
<
http://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html>
;,
the default is now "delayed," since v2.5.0.
Again, I am running 2.4.17, so does this apply?
Those files on d
On Tue, 2020-05-26 at 16:21 +0200, Simon Matter wrote:
>
> How did you install your 2.4.17 server?
From packages supplied by the CentOS 7.x distribution.
> If so it's possible that you distribution uses different
> configuration
> than the default, at build time. You should check this.
But
> On Tue, 2020-05-26 at 08:47 -0500, Nic Bernstein wrote:
>>
>> |expunge_mode:| delayed
>>
>> The mode in which messages (and their corresponding cache
>> entries) are expunged. “semidelayed” mode is the old behavior
>> in
>> which the message files are purged at the
re purged at the time of the
> EXPUNGE,
> but index and cache records are retained to facilitate
> QRESYNC.
> In “delayed” mode, which is the default since Cyrus 2.5.0,
So this doesn't apply to my 2.4.17 then does it?
> As shown in this excerpt from the manpage
On 5/26/20 8:33 AM, Brian J. Murrell wrote:
Hi.
Every IMAP client I query my cyrus imapd 2.4.17 server with says I have
~4K messages in my INBOX. However when I do a listing of
/var/spool/imap/b/user/brian/ it shows almost 13K files.
None of these include messages which have been deleted
Hi.
Every IMAP client I query my cyrus imapd 2.4.17 server with says I have
~4K messages in my INBOX. However when I do a listing of
/var/spool/imap/b/user/brian/ it shows almost 13K files.
None of these include messages which have been deleted but not
expunged. I manually expunge my mailbox
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
Il 15/05/2020 02:03, ellie timoney ha scritto:
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?
Ouch... I will try
Thank you for the hint
Marco
Cyrus Home
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
Hello Michael,
On 11/05/2020 10:45, Michael Menge has written:
RedHat systems use SELinux by default and SELinux has the habit to
block access to files, sockets, ... Especial if software from
non-Redhat repos is used.
thank you for the hint, I think that this is not my issue.
I disabled
Quoting ellie timoney :
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
Instance::_fork_command[1562] setting core size limit to 104857600
=> Instance::_start_master[1153] _start_master: waiting for PID file
=> Instance::_start_master[1153] _start_master: PID file present and correct
=> Instance::_start_master[1153] _start_master: PID waiting for services
ting syslog calls" might be a security default
of some sort.
> A list of known failing tests for each stable supported version of Cyrus
> IMAP could be very appreciated, but I understand that this could be
> difficult to achieve...
Yeah, this would not really be workable, cause
unless you
know that it won't!)
I see Robert has already fixed the SearchFuzzy problems (thanks!). I
didn't read the wall-of-errors in your earlier followup, since you had
already followed up with the syslog detail. Do you have other tests
that are failing still?
A list of known fail
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 th
Il 07/05/2020 12:15, Robert Stepanek ha scritto:
2) The SearchFuzzy.striphtml_alternative fails for the following reason:
3) The SearchFuzzy.striphtml_rfc822 fails for the following reason:
These fail because they test a feature on the development branch. I have
fixed that on the cassandane
On Thu, May 7, 2020, at 11:51 AM, Marco wrote:
> 1) The Rename.rename_inbox fails for this syslog error:
Probably ellie knows more for this one?
> 2) The SearchFuzzy.striphtml_alternative fails for the following reason:
> 3) The SearchFuzzy.striphtml_rfc822 fails for the following reason:
These
On 06/05/2020 19:59, Jason Tibbitts has written:
"M" == Marco writes:
M> thank you for the info. I trusted an old commit which I found on a
M> SPEC file for Fedora Cyrus IMAP 3.0.x. I'm trying to build an RPM
M> file.
Yes, you shouldn't trust that as I froze the
>>>>> "M" == Marco writes:
M> thank you for the info. I trusted an old commit which I found on a
M> SPEC file for Fedora Cyrus IMAP 3.0.x. I'm trying to build an RPM
M> file.
Yes, you shouldn't trust that as I froze the Cassandane version in
Fedora's packagi
different versions of it for testing different versions of Cyrus,
you need the most recent version of it so that you have the most-accurate and
most-thorough tests currently available.
thank you for the info. I trusted an old commit which I found on a
SPEC file for Fedora Cyrus IMAP 3.0.x. I'm
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
Il 04/05/2020 08:18, ellie timoney ha scritto:
The Cyrus team is proud to announce the first stable release from the new Cyrus
IMAP 3.2 series: 3.2.0
The main https://www.cyrusimap.org/ website now shows content for the 3.2
series.
Hello,
I'm trying to build this release, but I see many
The Cyrus team is proud to announce the first stable release from the new Cyrus
IMAP 3.2 series: 3.2.0
The main https://www.cyrusimap.org/ website now shows content for the 3.2
series.
The website for the previous stable 3.0 series is still available, now at
https://www.cyrusimap.org/3.0
The Cyrus team is proud to announce the first release candidate from the new
Cyrus IMAP 3.2 series: 3.2.0-rc1
While 3.2 is still in pre-release, the main https://www.cyrusimap.org/ website
will continue to be focused on the stable 3.0 series. The 3.2 website is
available at https
expect, since rfc2047_utf8 is, by default, off.
>
> Strangely, if I enable rfc2047_utf8, I still get "ProvaXX" as a subject.
https://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html
| munge8bit: 1
|
| If enabled, lmtpd munges messages with 8-bit characters in t
On 2020-03-28 04.59, Andrea Venturoli wrote:
> Any idea for a similar tool which can use UTF8SMTPS, so I can repeat
> that tests?
I would be going low-tech and using telnet or netcat or socat to
converse directly with your mail server's port 25. Craft the client's
side of the conversation in
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
The Cyrus team is proud to announce the fourth beta release from the new Cyrus
IMAP 3.2 series: 3.2.0-beta4
While 3.2 is still in beta, the main https://www.cyrusimap.org/ website will
continue to be focused on the stable 3.0 series. The 3.2 website is available
at https://www.cyrusimap.org
On 2020-03-17 20:13, Andrea Venturoli wrote:
On 2020-03-17 15:52, Andrea Venturoli wrote:
Also,
https://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html#std:cyrusman-imapd.conf(5),
says "reject8bit: 0" is the default.
From this I understand my setup should NOT r
On 2020-03-17 23:38, Deborah Pickett wrote:
On 2020-03-17 23:49, Andrea Venturoli wrote:
_ sendmail is SMTPUTF8-aware (this is confirmed by EHLO); however
Cyrus isn't?
Could be. This option in imapd.conf might be relevant:
rfc2047_utf8: 0
If enabled, imapd will parse any non-encoded
messages were received by Cyrus at this time. But it is
possible that bad messages are not accepted for some signs
that I consider spam tags: about 80K messages were rejected.
sendmail 8.16.0.41 (but 8.15.2 was used some years ago).
Cyrus IMAP 2.5.15. I use 3.0.13 on experimental server but
mail
. This is useful for installations that either
advertise the UTF8SMTP (RFC 5335) extension or receive mails with
improperly escaped UTF-8 byte sequences. It is recommended that this
option is left disabled unless there is good reason to do otherwise.
[source:
https://www.cyrusimap.org/imap
On 2020-03-17 15:52, Andrea Venturoli wrote:
Also,
https://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html#std:cyrusman-imapd.conf(5),
says "reject8bit: 0" is the default.
From this I understand my setup should NOT reject 8bit headers (but
change non-ASCII chara
oultion to non-ASCII characters in headers is offered by RFC 2047
# and its predecessors.)
#
#reject8bit: no
Also,
https://www.cyrusimap.org/imap/reference/manpages/configs/imapd.conf.html#std:cyrusman-imapd.conf(5),
says "reject8bit: 0" is the default.
From thi
On 2020-03-17 11:58, Deborah Pickett wrote:
Hi Andrea,
Hello and thanks a lot for your interest.
Finally I get some useful information on this!
The status 5.6.7 seems to be related to encodings. It's defined in RFC
6531, SMTP Extension for Internationalized Email:
When the
On Tuesday 17 March 2020, Andrea Venturoli wrote:
> From time to time, I receive some message that are refused
> and bounce. Do to possible blacklisting, I *really* want to
> avoid bounces.
I use Sendmail+Cyrus a very long time and I not remember this
problem exactly. Cyrus is not receive
Hi Andrea,
On 2020-03-17 20:57, Andrea Venturoli wrote:
From time to time, I receive some message that are refused and bounce.
Do to possible blacklisting, I *really* want to avoid bounces.
Here's a sample log:
sm-mta[97841]: 00DI1r4x097841: from=, size=37059,
class=0, nrcpts=1,
msgid=,
Hello.
I'm running sendmail 8.15.2, delivering to Cytus IMAP 3.0.13.
From time to time, I receive some message that are refused and bounce.
Do to possible blacklisting, I *really* want to avoid bounces.
Here's a sample log:
sm-mta[97841]: 00DI1r4x097841: from=, size=37059,
class=0, nrcpts
The Cyrus team is proud to announce the third beta release from the new Cyrus
IMAP 3.2 series: 3.2.0-beta3
While 3.2 is still in beta, the main https://www.cyrusimap.org/ website will
continue to be focused on the stable 3.0 series. The 3.2 website is available
at https://www.cyrusimap.org
The Cyrus team is proud to announce the second beta release from the new Cyrus
IMAP 3.2 series: 3.2.0-beta2
While 3.2 is still in beta, the main https://www.cyrusimap.org/ website will
continue to be focused on the stable 3.0 series. The 3.2 website is available
at https://www.cyrusimap.org
The Cyrus team is proud to announce the first beta release from the new Cyrus
IMAP 3.2 series: 3.2.0-beta1
While 3.2 is still in beta, the main https://www.cyrusimap.org/ website will
continue to be focused on the stable 3.0 series. The 3.2 website is available
at https://www.cyrusimap.org
apartition-: Meta-Files of the Mailboxes on the partition
archivepartition-: Old Mails of Mailboxes on the partition
You can use cyrus-replication to transfer all user/information to the
second server and keep them in sync.
https://www.cyrusimap.org/imap/reference/admin/sop/replication.htm
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 explain how it is done?
Thanks,
--
*** e-Mail
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.0.13
This release contains a fix for CVE-2019-19783, a privilege escalation
vulnerability that permits creation of arbitrary mailboxes using the 'fileinto'
directive in user sieve scripts. If you
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 2.5.15
This release contains a fix for CVE-2019-19783, a privilege escalation
vulnerability that permits creation of arbitrary mailboxes using the 'fileinto'
directive in user sieve scripts. If you
ave 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.
> >
> &g
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 Cy
I run my own smtp, imap & card/cal-dav services.
Atm, none are using Cyrus.
I'm well aware of Cyrus Imap's Cal/Card-dav support; particularly as the basis
for FastMail's excellent services.
My current card/cal-dav is Radicale. To my read, the project's crumbling.
I need to implement/de
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
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.0.12
I'm trialling hosting the release files using Github's releases feature.
Please use the Github download links if possible, and advise if you have any
problems! (It may even download faster
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 2.5.14
This release contains a fix for CVE-2019-18928, a session hijacking
vulnerability in the httpd daemon. If you compile cyrus with HTTP support
enabled, your cyrus.conf contains SERVICES
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
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
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
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,
today i've runned into a very suspicious problem never seen before:
While any other IMAP and POP3 ports with and without
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
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:
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.0.11
I'm trialling hosting the release files using Github's releases feature.
Please use the Github download links if possible, and advise if you have any
problems! (It may even download faster
the immediate availability of a new
>> version of Cyrus IMAP: 3.0.10
>>
>> This release contains a fix for CVE-2019-11356, a buffer overrun
>> vulnerability in the httpd daemon. If you compile cyrus with HTTP support
>> enabled and your cyrus.conf contains SERVICES
at 5:28 AM ellie timoney wrote:
> The Cyrus team is proud to announce the immediate availability of a new
> version of Cyrus IMAP: 3.0.10
>
> This release contains a fix for CVE-2019-11356, a buffer overrun
> vulnerability in the httpd daemon. If you compile cyrus with HTTP su
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 3.0.10
This release contains a fix for CVE-2019-11356, a buffer overrun vulnerability
in the httpd daemon. If you compile cyrus with HTTP support enabled and your
cyrus.conf contains SERVICES
The Cyrus team is proud to announce the immediate availability of a new version
of Cyrus IMAP: 2.5.13
This release contains a fix for CVE-2019-11356, a buffer overrun vulnerability
in the httpd daemon. If you compile cyrus with HTTP support enabled and your
cyrus.conf contains SERVICES
1 - 100 of 3880 matches
Mail list logo
