2020/12/04

Fork 1: use old server

Posted on Discord:

Trying to set up Dovecot on an older Ubuntu server so that @Harena can resume using Win98 Eudora to download her email...
(in 20.04, they dropped support for the newest version of TLS that w98Eudora supports)
...and I can't seem to get login to work right.
Dovecot seems to be working ok -- Thunderbird sees it and is able to autodetect the correct security settings...
...but it insists I have the wrong password...
...and when I try to connect with ssh to verify the password, it says
Permission denied (publickey).
...which I guess makes sense, because normally I connect with a public key (albeit from a different username).
So I'm not sure what's going on. I suspect that the publickey message is what's happening when Thunderbird tries to connect, but I don't know how to check that (maybe the email log file... will check...) and I don't know how to make it go away.

mail.log says:

improper command pipelining after EHLO

Will websearch that...

NHellFire suggested: "Dovecot's auth failures should be in auth.log"

will check auth.log
hmm, nothing gets added there when I try to log in.
I'll try to enable password logins, at least temporarily, just to find out if that's the problem.
re-enabled, password verified, IMAP login still failing. Ok, so that's not the problem.
(good; I don't like leaving password logins open on that server.)
...and now I'm not getting that message anymore; just errors indicating a certificate issue. hmm.
Used the server (sub)domain instead of the site domain -- that works.
(This removes the temptation to offer email on the toot.cat domain, which is probably a good thing. I don't need to be taking on more projects right now. >.<)

Now #Postfix is delivering mail to a different place than Dovecot is looking for it.
I don't know how to tell Postfix where to deliver, and telling Dovecot to look in the place where Postfix is delivering doesn't seem to work.

[...] Dovecot is picking up email from ~/Maildir (which is fine) but Postfix is delivering incoming messages somewhere else, I think it's /var/mail/[username], and I don't know how to tell it to deliver the mail where Dovecot wants it.

NHellfire suggested adding home_mailbox = Maildir/ to Postfix's main.cf file, which worked (after restarting Postfix).

Mail sent to this server is now retrievable with Dovecot.

Fork 2: reconfigure new server

Turning on a couple of debug flags in #Dovecot's config now shows this in mail.log when #Eudora tries to connect:

Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL: where=0x10, ret=1: before SSL initialization
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL: where=0x2002, ret=-1: before SSL initialization
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL alert: where=0x4008, ret=582: fatal protocol version
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL: where=0x2002, ret=-1: error
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL error: SSL_accept() failed: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=107.15.53.219, lip=68.183.140.54, TLS handshaking: SSL_accept() failed: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol, session=</enhGK21wTFrDzXb>
Dec  5 00:58:54 cloud1 dovecot: pop3-login: Debug: SSL error: SSL_accept() syscall failed: Invalid argument

The flags I changed:

• auth_verbose = yes - didn't immediately change anything
• verbose_ssl = yes - the extra info appeared after I made this change

As far as I can tell, Eudora should support up through TLSv1.1. I tested Dovecot with TLSv1 and TLSv1.1, and both were successful -- so I really don't understand what's going on here oh wait, maybe "Verification: OK" doesn't mean success. It does say "no protocols available" for 1.0 and 1.1, but gives all kinds of additional certificate info for 1.2.

TLSv1 test:

openssl s_client -connect mail.vbz.net:993 -tls1

Output:

CONNECTED(00000003)
140056042988864:error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available:../ssl/statem/statem_clnt.c:1112:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 7 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So, going on the theory that it's actually refusing TLSv1 and TLSv1.1 connections, I searched for "no protocols available" and found this piece of advice which says that the openssl server configuration is what needs to be changed. Unfortunately, changing it doesn't seem to change the error. It would help if I knew whether I needed to restart something after each change, and what that might be, rather than rebooting all the time.

12/5 Note

Enable TLS 1.0 and TLS 1.1 on Ubuntu 20.04 seems to be identifying the same problem, except with Nginx rather than Dovecot. The solution they worked out is via configuring Nginx rather than configuring OpenSSL, suggesting that perhaps Dovecot can be configured to override OpenSSL as well -- but a few attempts to do this were not successful. The Nginx settings given don't translate directly, though there are some analogous config options in Dovecot.