Hi,
I'm working with Fastmail to transition the Cyrus mailing lists from
lists.andrew.cmu.edu over to cyrus.topicbox.com.
Our plan is to transition the active mailing lists as follows:
cyrus-annou...@lists.andrew.cmu.edu -> annou...@cyrus.topicbox.com
cyrus-de...@lists.andrew.cmu.edu ->
Sebastian,
Thank you for the response.
I have never heard of this tool but it looks interesting. I will give it a
try.
Will let you all know if I find anything.
-Ez
On Thu, Oct 15, 2020 at 9:28 AM Sebastian Hagedorn
wrote:
>
> Am 15.10.20 um 15:49 schrieb Ezsra McDonald:
> > I wonder if
Am 15.10.20 um 15:49 schrieb Ezsra McDonald:
I wonder if there is a way to test LMTP manually to verify LMTP can see
the imap accounts? I have not done much with LMTP because it always
worked for us in the past.
My favorite tool for mail delivery testing is swaks. You can test LMTP
this
Albert,
Thank you for your response.
LDAP is only used for the Postfix/Imap servers. We do not configure Pam to
use LDAP. We are using saslauthd.
I wonder if there is a way to test LMTP manually to verify LMTP can see the
imap accounts? I have not done much with LMTP because it always worked
Le 14/10/2020 à 14:30:31-0500, Ezsra McDonald a écrit
> I am building a new mail server to replace an older EL6 server. The new server
> is Centos 8. I keep getting this response when trying to deliver email to a
> local account stored in LDAP.
>
> host mail.example.org[/var/lib/imap/socket/lmtp]
I am building a new mail server to replace an older EL6 server. The new
server is Centos 8. I keep getting this response when trying to deliver
email to a local account stored in LDAP.
host mail.example.org[/var/lib/imap/socket/lmtp] said:
550-Mailbox unknown. Either there is no mailbox
Sorry for the delay. Yes, this does seem like the right thing to do. The
conversation root being the user is a convenience for a ton of things to the
point that we're basically using "fake users" for storing related things for a
business.
But doing the same thing for mailshare would be quite
Jean Charles Delépine écrivait (wrote) :
> 2020-10-06T10:51:45.070636+02:00 cyrus-3.0.8 cyrus/imap[2714758]: IOERROR:
> fetching subscriptions for user1
user1.sub didn't have correct tab line termination. Certainly my fault
sometime in the past.
Jean Chales Delépine
Cyrus
Hello,
While replicating one 3.0.9 server to a 3.2.3 server 2 accounts failed to
synchronise with this error :
OK success
cyrus/sync_client[2745008]: IOERROR: fetching subscriptions for user1
Error from sync_do_user(user1): bailing out!
cyrus/sync_client[2745008]: Error in
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
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,
Jean Charles Delépine écrivait (wrote) :
> Jean Charles Delépine écrivait (wrote) :
>
> > Hello,
> >
> > I'm on the way to migrate one quite big murder config with Cyrus IMAP
> > 3.0.8-Debian-3.0.8-6+deb10u4
> > to Cyrus IMAP 3.2.3-Debian-3.2.3-1~bpo10+1.
> >
> > My plan is to replicate
Hello list,
I had a working replication between to cyrus 3.0 servers running.
The sync_client is started once a day.
In the last days the sync_client bails out with
do_folders: failed to order folders correctly
every time on a specific mailbox of a specific user.
I can't see that there is
ellie timoney écrivait (wrote) :
> 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,
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
Jean Charles Delépine écrivait (wrote) :
> Hello,
>
> I'm on the way to migrate one quite big murder config with Cyrus IMAP
> 3.0.8-Debian-3.0.8-6+deb10u4
> to Cyrus IMAP 3.2.3-Debian-3.2.3-1~bpo10+1.
>
> My plan is to replicate 3.0.8's backends on 3.2.3 ones. This plan has work
> before for
Hello,
I'm on the way to migrate one quite big murder config with Cyrus IMAP
3.0.8-Debian-3.0.8-6+deb10u4
to Cyrus IMAP 3.2.3-Debian-3.2.3-1~bpo10+1.
My plan is to replicate 3.0.8's backends on 3.2.3 ones. This plan has
work before for 2.5
to 3.0. migration.
Il can replicate empty
Hello,
I noticed that Cyrus does not keep track of conversations in
mailshare folders.
There is a code comment addressing this issue in
conversations.c:
/* only users have conversations. Later we may
introduce the idea of
* "conversationroot" in the same way we have
quotaroot, but for now
*
Problem resolved, or resolving. This version of Cyrus may be old, but
it's been rock solid and compared to previous versions I've had no
problems with sync_client dying. It turns out the behavior I was seeing
is normal recover behavior. There are still errors I have not seen
before, but they
On 14/09/2020 11:43, Ismaël Tanguy has written:
Hello,
cyrus-imapd-3.0.7-16.el8.src.rpm installed on Centos 8.2
An user fails to receive an email from a mailing list of 1000
subscribers.
From SMTP server, I found the uid of the mail and look for it in the
IMAP store logs.
While the
I have confirmed that running sync_client on individual mailboxes works,
as does running sync on the accumulated log files. But rolling
replication is not working. After sync_client is restarted there is a
burst of sync activity on the accumulated log, then nothing. The new
log file
Okay, these errors may be admin error. In running the old logs I
specified -u, instead of -m.
I am still concerned about the DBERROR, but those did not appear after I
restarted cyrus. And rolling replication is still not working.
Mike
On 9/15/20 10:49 AM, Michael Sofka wrote:
Sep 15
Before I proceed, I am seeking advice.
This is on Cyrus IMAP Murder v2.4.18-Debian-2.4.18-3
On one of our back-end servers sync started failing. I restarted
sync_server on the replication, and on the backend server, which did not
work. There are the following errors in the logs
Sep 15
On 14/09/2020 11:43, Ismaël Tanguy has written:
Hello,
cyrus-imapd-3.0.7-16.el8.src.rpm installed on Centos 8.2
An user fails to receive an email from a mailing list of 1000 subscribers.
From SMTP server, I found the uid of the mail and look for it in the
IMAP store logs.
While the
Hello,
cyrus-imapd-3.0.7-16.el8.src.rpm installed on Centos 8.2
An user fails to receive an email from a mailing list of 1000 subscribers.
From SMTP server, I found the uid of the mail and look for it in the
IMAP store logs.
While the delivery is OK for the most part, I found 5 mistakes :
Hi,
I used ptlaoder quite successfully up to version 2.4 of cyrus. Since the
upgrade to 2.5 I get SEGFAULTs.
After the upgrade to 3.2.2 I tested it again, but still:
process type:SERVICE name:ptloader path:/usr/lib/cyrus/bin/ptloader
age:0.665s pid:19082 signaled to death by signal 11
Hi Andrea,
> What I found really annoying is "non-read" receipts.
Ouch, I did not know about this! I will file it away in case it ever bites me.
> > Rarely, Outlook will decide that a folder is local-only
> > [...]
> Does it at least shows the folder is local?
> Then I could train the users to
On 2020-09-05 03:11, Deborah Pickett wrote:
On 2020-09-04 18.30, Andrea Venturoli wrote:
What's the status of interoperability today?
Will OL 2013 work reliably with CyrusIMAP 3.0? 3.2?
What about newer versions of OL?
Hi Andrea,
Hello.
I can offer anecdata of interoperability between
On 2020-09-04 18.30, Andrea Venturoli wrote:
What's the status of interoperability today?
Will OL 2013 work reliably with CyrusIMAP 3.0? 3.2?
What about newer versions of OL?
Hi Andrea,
I can offer anecdata of interoperability between Cyrus 3.0.x and Outlook
2016 from ten months of
Hello.
A long time ago I had a customer who used OutLook with a Cyrus-IMAP
server (I think it was 2.2 at the time).
Up to OL 2010 everything was (almost) fine, but upgrading to OL 2013 was
a disaster, e.g. local-only folders, ability to move messages to folders
which didn't exist on the
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
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
I am using Cyrus 3.2.2 on Debian Buster 10 (package from buster-
backports).
I am having lots of errors similar to these in the logs:
cyrus/imaps[24052]: IOERROR: conversations_audit on store:
/var/lib/cyrus/user/e/example.conversations Bff62cd0852db22e1 0 (1452110 1 0 0
() ((1 1452109 1 1 0))
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 to
On 8/12/20 11:59 AM, Marco wrote:
[...]
> I suggest to use the Cyrus::IMAP::Admin version provided by the Cyrus
> IMAP server. So, when you upgrade Cyrus IMAP, upgrade the Perl admin
> utility too and use that.
Thanks a lot. My problem came from installing cyrus from the debian
backports
Il 12/08/2020 11:16, Rainer Ruprechtsberger ha scritto:
Hi,
not sure if it is only after the upgrade to 3.2.2 since the features are
not that much in use. But I did set 'expire' and 'sharedseen' before.
Now I get 'Remote does not support ANNOTATEMORE' using 'mboxconfig ..
expire' or
Hi,
not sure if it is only after the upgrade to 3.2.2 since the features are
not that much in use. But I did set 'expire' and 'sharedseen' before.
Now I get 'Remote does not support ANNOTATEMORE' using 'mboxconfig ..
expire' or 'sharedseen' or even 'info'.
My admin account seems to be admin
Hello,
I'm trying event notifications. I would like to see if there are some
methods to track all messages moved on a folder named "Spam", for instance.
First, I see that event filters in imapd.conf don't allow to specify a
folder name... so the notifications produced are very large.
A way
Gionatan,
I believe the tool you're looking for is 'mbtool' From the man page:
DESCRIPTION
mbtool is a tool for performing various actions on the indexes
of a
list of mailboxes. The only actions currently supported are -t,
which
will normalize the
Hi all,
I just noticed the dates of some old emails are wrongly displayed on
roundcube webmail.
In short, the list view shows the filesystem date of the affected
messages (ie: mtime of u.1 file), rather than what is found in the
"Date:" header field
These were emails migrated from an old
Hello, I'm trying to replicate from Cyrus IMAP 2.4.20 to Cyrus IMAP
3.2.2 using replication.
Because Cyrus 2.4 doesn't support IMAP replication (is this true?), I
configured the replica with
replica2to3syncserver cmd="/usr/libexec/cyrus-imapd/sync_server"
proto=tcp4 listen="csync"
in
Ouch, sorry, ignore this.
I suppose to have found the problem.
My goal is to sync from Cyrus IMAP 2.4 to 3.2, and to 3.2 to a backupd host.
I see it works just starting by hand the sync_client in Cyrus IMAP 2.4,
meanwhile in the middle host the rolling mode is sufficient with
sync_log_chain.
For Sieve the new path "C"
is reported by mbpath, but sync_client replicates the sieve scripts
elsewhere.
Sorry, I would mean "For Sieve the new path with "H" is reported by
mbpath, but sync_client replicates the scripts elsewhere (in the path
with "S").
Many many thanks for every help
Hello,
I have a replication issue from Cyrus IMAP 2.4.20 to 3.2.2 about sieve
path.
Let suppose there is a user in Cyrus IMAP 2.4.20 with
# mbpath user/gianni.ferromagne...@example.com
/maildata/example.com/maildata1/domain/C/example.com/S/user/gianni^ferromagnetic
and the Sieve is in:
Hello,
I would ask an help with a new replication error in backup channel.
I have this never-ending loop error:
2020-07-22T11:35:16.212126+02:00 tst-msg03 cyrus/sync_client[22465]:
MAILBOXES received NO response: IMAP_PROTOCOL_BAD_PARAMETERS Bad parameters
2020-07-22T11:35:16.212185+02:00
Bug filed:
https://github.com/cyrusimap/cyrus-imapd/issues/3115
On 7/17/20 1:52 AM, Matthew Schumacher wrote:
HI Ellie,
I agree that it's probably a bug. I'll open a github issue.
I'll report back with the issue number.
Thanks,
Matt
On 7/16/20 5:47 PM, ellie timoney wrote:
Hi,
I've seen
HI Ellie,
I agree that it's probably a bug. I'll open a github issue.
I'll report back with the issue number.
Thanks,
Matt
On 7/16/20 5:47 PM, ellie timoney wrote:
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
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
I'm trying to use external notifications on 3.2.2 but it doesn't work.
If I define
event_notifier: external
notify_external: /usr/cyrus/bin/cyrus_notify
event_groups: access
event_extra_params: clientAddress timestamp service
Then the imapd thread dies with this assertion:
Jul 15 18:01:54
CMU report that it's been fixed, and it does indeed seem to be working again
for me now. The usual caveats about DNS propagation probably apply.
I don't know why the entry disappeared, and if the cause was something
automated I suppose it might disappear again... I guess we'll keep an eye on
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,
currently the hostname www.cyrusimap.org cannot be resolved.
cyrusimap.org still works, but it appears to point to Github, from where
there is a redirect to www.cyrusimap.org
--
.:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum
Hello,
we have separate our Postfix Server from our old Cyrus Server and so
pass LMTP on TCP :
#lmtpunix cmd="/usr/cyrus/bin/lmtpd -C /etc/imapd.conf"
listen="/var/lib/imap/socket/lmtp" prefork=10 maxchild=240
lmtp cmd="lmtpd" listen="lmtp" prefork=1
We are not facing
Am 09.07.20 um 11:47 Uhr schrieb Stephan:
> Hello,
>
> I am having trouble with a mail stuck in the queue, it can't get
> delivered because lmtpd has some problem, it says:
>
> lmtp: FATAL: Trying to unput wrong character
>
> I'm not sure what to do about this. I found the error message in
>
Hello,
I am having trouble with a mail stuck in the queue, it can't get
delivered because lmtpd has some problem, it says:
lmtp: FATAL: Trying to unput wrong character
I'm not sure what to do about this. I found the error message in
prot_ungetc() which is sitting in lib/prot.c but don't know
Hi Ellie,
On 08/07/2020 06:23, ellie timoney has written:
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 it would just be
the dot in the name, cause something like that should be fairly easy 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
Hello,
On 03/07/2020 05:08, ellie timoney has written:
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?
I copied the content of the failing
Hi
Thanks for the debugging hints!
client_timeout sat to 30M and the UID THREAD REFS US-ASCII ALL actually
completes.
But first after ~10 mins on a CPU: Intel(R) Celeron(R) CPU N2930 @ 1.83GHz
(1833.38-MHz K8-class CPU)
and after 69.484 secs on a CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
Hello,
During the upgrade of a master backend server (~15k mailboxes) from
Centos7 to Centos8, we fail over on a replica.
Before the failover, we run a last time sync_client -r, to flush
entirely sync log.
Everything went fine, except that the replica was not allowed to
mupdatepush
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.
I recently upgraded Cyrus to 3.2.2 from 3.0.13.
Now threading "UID THREAD REFS US-ASCII ALL" on one specific folder with
>50K mails,
makes imapd process use 100 CPU% without any progress. truss[1] or dtrace
shows no output. The process seems totally stuck.
I installed in a FreeBSD 12.1
On 19/06/2020 03:01, ellie timoney has written:
Rolling mode only makes incremental updates, so if you're starting from a
server that already has existing data, you should do the first manual initial
backups before enabling the rolling mode.
Hello,
about this error, I retried more times.
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
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 was
> there before, but I
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 cannot
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: WARNING: ./usr/lib64/libcyrus.so.0.0.0:
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 the immediate
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 executable
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 work just fine. The
Ellie,
I also had the doubt about this feature, though I'd already seen a mention that
the result of the hw implementation is incompatible (and before your last mail
completely forgot about it).
Maybe it makes sense to remove its mention (and detection) from configure
altogether, until it
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,
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:
Am 26.06.20 um 14:18 schrieb Jean Charles Delépine:
Stephan écrivait (wrote) :
sieve_rebuild: [path to script] parse failed: script errors:#015#012line
5: header 'resent-from': not a valid header for an address test
I had the same error with a 2.5 to 3.0 migration.
Corrected with
I'm in the process of testing the upgrade from a CentOS 6 box running
2.3.16 to a CentOS 8 box running 3.0.7.
The upgrade has been less troublesome than expected, but I'm seeing a
strange problem with newly received mail being marked as "read" even
though they have not been opened by the
Stephan écrivait (wrote) :
> sieve_rebuild: [path to script] parse failed: script errors:#015#012line
> 5: header 'resent-from': not a valid header for an address test
I had the same error with a 2.5 to 3.0 migration.
Corrected with 'rfc3028_strict: 0' :
rfc3028_strict: 1
If enabled, Sieve
Hi all,
I'm having trouble upgrading version 3.0.13 to 3.2.2. I am running two
systems, one of them is a replica. I upgraded on the replica first and
had issues with "intermediate" mailboxes being created which seems to be
expected if I read the release notes right.
Now I'm seeing errors on the
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. But today
> 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
On Tue, Jun 23, 2020 at 04:10:56PM +0200, Albert Shih wrote:
>
> In fact I just notice, I've no idea...how to remove a mailbox in cyrus
>
> With dovecot it's rm -rf ;-) Something I famillar with.
cyradm deletemailbox user/xxx
Regards,
Ken
Cyrus Home Page: http://www.cyrusimap.org/
Le 14/06/2020 à 21:51:49+0200, Sebastian Hagedorn a écrit
Hi,
Thanks for your answer.
> Am 09.06.20 um 16:32 schrieb Adam Tauno Williams:
> > On Tue, 2020-06-09 at 15:51 +0200, Albert Shih wrote:>
> >> After switching to cyrus imap, I think about how to do that.
> >> If I'm correct I cannot
Hullo
I have a cyrus implementation on Fedora for a small (~10) users that’s been
migrated through many versions of the various components, including several
different of IMAP clients.
Realising the fragility of the setup, I thought I’d restore from a backup.
However, I’m finding that several
Hi everyone.
Just like to know if some can tell me until when the cyrus 3.0.x will be
maintained ?
The mail are super top critical for me, so I don't like to change major
version during the life of the hardware.
I see they are still update on 2.x so...maybe I'm lucky and the 3.0.x will
ben
Are you talking about removing this from the body of error responses?
Currently you can't, but I will patch master so that it obeys the
serverinfo option.
On 6/23/20 8:19 AM, Zorg wrote:
Hi
for security reason i want to get rid off
Cyrus-HTTP/3.0.6-Debian-3.0.6-6+deb1u1 Cyrus-SASL/2.1.23
Hi
for security reason i want to get rid off
Cyrus-HTTP/3.0.6-Debian-3.0.6-6+deb1u1 Cyrus-SASL/2.1.23 OpenSSL/1.1
Zlib/1.2.10 LibXML2.9.5 SQLite/3.21.1 LibiCal/3.0 ICU4C/63.1
Jansson/2.12 Server at cyrus.domain.com Port 9443
like apache using
ServerTokens Prod or ServerSignature Off
Have
Hello,
On 22/06/2020 03:29, ellie timoney has written:
[...]
So like, maybe a user has deleted some stuff, and you don't want to mess around figuring out which
individual messages they need restored, so you just want to restore everything, and let the user
figure it out. This is what -x is
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
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.
2020. 06. 21, vasárnap keltezéssel 10.53-kor Simon Matter ezt írta:
> 2020. 06. 20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
>
> The deliver.db still about 48MB.
>
I just deleted deliver.db and restart cyrus.
Restarting was pretty quick, takes only some seconds.
New deliver.db
2020. 06. 21, vasárnap keltezéssel 10.53-kor Simon Matter ezt írta:
> 2020. 06. 20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
> Please make sure the options here are also valid for your cyrus version.
> However, I also guess your deliver.db is corrupted somehow. From my own
>
> 2020. 06. 20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
>> Hi,
>>
>> The question is why is the deliver db > 2GB in skiplist format? Is it
>> normal or do you have a corrupt BDB db or does your db pruning not work
>> for deliverdb. I think that should be something like 'delprune
>>
2020. 06. 20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
> Hi,
>
> The question is why is the deliver db > 2GB in skiplist format? Is it
> normal or do you have a corrupt BDB db or does your db pruning not work
> for deliverdb. I think that should be something like 'delprune
>
2020. 06. 20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
>
> Hi,
>
> The question is why is the deliver db > 2GB in skiplist format? Is it
> normal or do you have a corrupt BDB db or does your db pruning not work
> for deliverdb. I think that should be something like 'delprune
>
> Hi,
>
> I run into a problem on an old clearos server, where the cyrus shutdown
> always failed at step exporting databases.
> As I checked the situation using ps ax on an other console, I found
> that, it was exporting deliver.db.skiplist file, which failed after a
> lng time (some
Hi,
I run into a problem on an old clearos server, where the cyrus shutdown
always failed at step exporting databases.
As I checked the situation using ps ax on an other console, I found
that, it was exporting deliver.db.skiplist file, which failed after a
lng time (some minutes).
I checked
1 - 100 of 42724 matches
Mail list logo
