I'm trying to migrate my users' mailboxes from my old IMAP Server (CommuniGate Pro on a Mac) to Xeams on QNAP. When I run the Import Wizard with Use SSL ON and port 993, I get a certificate error. This server has a self-signed certificate. So I tried importing via port 143 (unencrypted) with Use SSL OFF and I get the error message Unable to connect to server. STARTTLS failure. This makes no sense to me, since with SSL turned off there should be no STARTTLS negotiation. If I check Use SSL with port 143 I get the error Unrecognized SSL Message. Plaintext connection?

Incidentaly, I'm running Xeam Version 8.3, build 6232 on a QNAP TS-253pro-8G NAS, and it's been working fine for inbound and outbound mail. How can I get these messages off my old server? I believe it uses the MBOX format for message storage, so is there a way I can transfer the files manually and import them via CLI?

I see you posted two questions on the same thread. I am going to answer both of them here.

Trusting SSL certs

Add the following line in the server.properties file:

trust.server.for.starttls=true

Once added, Xeams will trust the self-signed certificate from your other server.

Moving Xeams to Another Server

Check https://www.xeams.com/movexeams.htm for instructions. Xeams does not use the MBOX format. However, copying files from one machine to another will bring the mailbox over. The mailboxes for users are stored in $INSTALL_DIR/UserRepository folder. On QNAP, $INSTALL_DIR should be /share/CACHEDEV1_DATA/.qpkg/Xeams .

I tried adding the line trust.server.for.starttls=true in the server.properties file, but still get the error message "Unable to connect to server. java.security.cert.CertificateException: Certificates does not conform to algorithm constraints" when attempting import using SSL ON and port 993. That port is configured on the source server as "Init SSL/TLS ON". I'm puzzled why I can't just import using plaintext mode over port 143, which the source server is also configure to listen on, with "Init SSL/TLS OFF". But when I try that I get the error message "Unable to connect to server. STARTTLS failure".

I have a feeling the problem with SSL is not related to trust but perhaps it is using an older algorithm/cipher, which is disabled in Xeams for security reasons.

I also think that the server supports STARTTLS on port 143, indicating clients that they can upgrade their non-SSL connections to SSL. Xeams tries to upgrade to encryption on port 143 and fails because of the reason mentioned above. To confirm this theory try the following:

• Using telnet, connect to your IMAP server. The command is:
  
  telnet your.imaps.server.host 143
• Type this command once connected:
  
  abc CAPABILITY
• The server will return a list of supported features. If you see STARTTLS as a feature, my theory is correct.
• In that case, see if you can disable STARTTLS on your IMAP server. Once STARTTLS is disabled, Xeams won't upgrade to SSL on port 143.

Thanks for the excellent diagnostic technique. Here is the result:

telnet xxx.xxx.xxx.xxx 143
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
* OK CommuniGate Pro IMAP Server 5.1.12 at melx.becknet.com ready
abc CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+ QUOTA ID MULTIAPPEND LISTEXT CHILDREN BINARY LOGIN-REFERRALS UNSELECT STARTTLS AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=GSSAPI AUTH=MSN AUTH=NTLM
abc OK completed

The STARTTLS is in  there. Let me see if I can disable it somehow.

Sorry about the anonymous postings earlier. I didn't realize that the forumware wouldn't continue my user ID for replies.

In any event, it looks like this is a hard-coded feature of the server. From the CommuniGate docs:

"The IMAP module supports the STARTTLS command that allows client mailers to establish a connection in the clear text mode and then turn it into a secure connection."

So even though I have "init STARTTLS NO", that apparently just means TLS isn't required, but will be accepted from a client. Is there any way to get Xeams to not try upgrading to TLS on port 143?

Ah ha! I found a workaround. Later in the Communigate Docs it says:

"Set the Init SSL/TLS listener socket option to Ext to tell the Listener component that all connections coming to this socket are SSL/TLS secured, but that there is an external device implementing all SSL/TLS encryption/decryption operations. Connections coming to these ports are clear-text connections, but higher-level CommuniGate Pro components and protocols process these connections as if they come encrypted: clear-text Login operations are considered secure, STARTTLS operations are prohibited, etc."

So I changed it to "EXT" and it appears to be importing!  Thank you for figuring out the root cause!