I’ve been building an email/webserver using Rockylinux 9.2. I have postfix running and am receiving inbound emails. I can also send emails from the command line and using Thunderbird. What I cannot do, is read inbound emails using T-bird.
Maillog says T-bird is failing to authorize. However, the user login and password is correct and works for other applications. Here’s the maillog entry.
Something new I just noticed. I’m getting MTA errors. It started last evening, after I was gone. One error mention a malformed smtp socket. Postfix had been working, processing inbound emails and putting them in the appropriate mailboxs. Now it isn’t…and the system had not been touched since yesterday!
I do not have automatic updates—don’t trust them. I’m not sure what happened. It’s a step backward. I’m tempted to wipe it all clean and redo the instalation.
its almost the same with smtp except you run
telnet host 25
helo server.domainname
MAIL from: someone@someplace
RCPT to: user@hostname
data
this is a message
.
helo is spelt correctly in this context, and the dot is needed on the last line followed by enter/CR
regards peter
Another text based/cli e-mail client you can try is alpine. RPM is available for Rocky 9.2. I used to use it to read my home e-mails when I was at work and only had a cli console available for remote access to my home systems. Supports both IMAP and POP.
BTW, what version of Rocky? I’m getting ready to move a CentOS 7 install of Dovecot and Postfix to R9 so kind of interested.
You have not provided enough information, such as how your services are configured. Without that information, no one will be able to further assist you. We cannot just make guesses on what the issue is.
I realized that I should be able to set up dovecot on one of my local R9 systems even if its not the system that normally handles my local e-mail. Got that done and I’m getting “Component returned failure code: 0x80550014” when I try to connect with a known good account and password. I noticed the following in /var/log/maillog:
Nov 5 13:42:04 abuse dovecot[189873]: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42 (no auth attempts in 0 secs): user=<>, rip=192.168.0.4, lip=192.168.0.4, TLS handshaking: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42, session=
Guessing that this has something to do with the failure to authenticate. I’ll need to do a little more research like finding out which SSL cert dovecot is using and try fixing it. BTW, this is with the default dovecot configuration as provided by the RPM.
So, I also tried to log into my CentOS 7 dovecot instance from my R9 box and got the same login credentials error. The R9 version of TBird seems to thinks it knows how i want to set up my e-mail as it keeps changing various fields in the server setup pane so not sure whether I’m getting valid results. I access my local dovecot server every day C7 to C7 so something weird with TBird connecting to R9 dovecot. TBird connects to my Google mail account just fine on R9.
Got alpine installed and it is also failing to connect to dovecot . Looks like the cert problem that showed up in the logs is the problem since I’m getting:
There was a failure validating the SSL/TLS certificate for the server
abuse.local.davenjudy.org
The reason for the failure was
self-signed certificate (details)
Update: Still digging but I finally hit on Googling for the right stuff. Hit Google with: >> sslv3 alert bad certificate ssl alert number 42 dovecot << and you’ll find out we have lots of company. The search comes from what gets logged in maillog. Known problem. Some folks have some suggestions for a workaround.
I finally gave up and downgraded my thunderbird to https://www.rpmfind.net/linux/centos-stream/9-stream/AppStream/x86_64/os/Packages/thunderbird-102.15.0-1.el9.x86_64.rpm (current for R9 is 115.4.1). I tried several solutions for generating self-signed SSL certs that would supposedly work with Tbird but thunderbird still didn’t like them. Another option that others say will work is to generate SSl certs using Let’s Encrypt (free, on-line SSL CA). My understanding is the Let’s Encrypt certs are good for a year and one of the things I like about self-signed certs is I can give them say a 10 year expiration.
let’s encrypt certificates are only valid for 90 days and you should run a script, that updated the certificate automatically - you don’t need a 10 year valid certificate. Nowadays they also support wildcard certificates.
Once set up you will never hassle with (self signed) certificates again. Give it a spin.
Final (?) update: I’m not really happy with running and staying with an old e-mail client due to the posibility of security issues, bugs, etc. so I kept looking for solutions. I ran across this discussion linux - Make Thunderbird request certificate on port 993, not 443 - Super User which rang a bell since one of the problems in the chain of issues was that TBird wanted to access port 443 (https) to retrieve the self-signed certificate and correcting it to port 143 or some other iMAP port didn’t work. The really simple solution someone suggested was to add:
inet_listener https {
port = 443
ssl = yes
}
to the /etc/dovecot/conf.d/10-master.cong file so that dovecot would also listen on port 443. Turns out that I also had to allow (SELinux) dovecot to listen on that port:
semanage port -m -t pop_port_t -p tcp 443
and then dovecot was allowed to listen and was listening on where TBird decided it should. Seems to work although my working install of TBird 115.4.1 is now after getting everything working with 102.15.0-1 so 115 may just be using the self-signed certs I allowed and got TBird to accept with 102. YMMV.
So, if you downgrade TBird to 102 and get your self-signed cert(s) accepted and then update to 115 things should still work. I just hope my other solution works and we don’t have to downgrade TBird to 102 every time we need to have it accept a new self-signed cert.