I wrote:
Now I started to XFER some mailboxes from backend with 3.2.11 to a new one
with 3.10.2 with an often-used script using Cyrus::IMAP::Admin with:
$cyrus->xfer($folder, $new_backend, $new_part);
die "Error in xfer $folder to $new_backend:$new_part: " . $cyrus->error . "\n" if
$cyrus->error;
It always ends with: Error in xfer user.xxx to yyy:2: Bad protocol
But it seems to have xferred all the e-mails and the sieve scripts. These
are the last log line on backend server (3.2.11) from which the mailboxes
moved away:
Mar 16 15:01:13 porto cyrus/imap[2650095]: mbentry user.xxx has no uniqueid,
needs reconstruct
Mar 16 15:01:13 porto cyrus/imap[2650095]: Deleted mailbox user.xxx
Any idea what this is related to?
It’s related to TLS … I thought it a good idea to request TLS to the
backends with this in /etc/imapd.conf
sasl_minimum_layer: 128
Having this, even an openssl s_client (OpenSSL 3) brings an error when
closing the connection:
openssl s_client -connect backend:143- starttls imap
Connecting to …
…
. logout
* BYE LOGOUT received
. OK Completed
4017319E4E7F0000:error:0A000126:SSL routines::unexpected eof while
reading:../ssl/record/rec_layer_s3.c:698
… and the imapd dies on the server with:
2026-03-25T11:22:23.126505+01:00 … cyrus/master[879511]: process
type:SERVICE name:imap path:/usr/lib/cyrus/bin/imapd age:1101.653s
pid:993757 signaled to death by signal 6 (Aborted)
Bah, this is at the end of *every* TLS connection, also on the frontend.
Searching for this error string leads to
https://github.com/openssl/openssl/discussions/22690
"This usually happens when the remote peer abruptly shuts down the
connection without sending a "close_notify" alert which is what you are
supposed to do."
It is a known bug?
Thanks,
Frank
--
Frank Richter, Chemnitz University of Technology, Germany
------------------------------------------
Cyrus: Info
Permalink:
https://cyrus.topicbox.com/groups/info/Tc654c39c5afc4bc1-M00700703599e06cf3f788db9
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
