DDG search drop in powered by ddg.patdryburgh.com
Recently while doing some server-administration tasks (setting up the server, enabling email, TLS, etc) on a Ubuntu 14.04 system, I ran into some problems with dovecot. For some reason, no matter what I tried, I could not get Thunderbird to auto-configure properly with the newly stood up web server’s SMTP server (postfix + dovecot).
Maybe interesting to note that I never really had these issues on Arch Linux servers that I mentain… maybe the starting documents/wiki is just that much better/more thorough.
tldr;Fix was a combination of Turns out to be a Thunderbird issue, also I forgot to enable wrapper mode for postfix.
Below you’re going to see my basic steps/methodology as I tried to track down the issues. I’ve set up Postfix+Dovecot setups before and somehow have never had this much trouble, so thought I’d write about it.
My first inkling was that maybe I just didn’t configure ufw correctly. UFW actually has app profiles for Postfix and Dovecot, so it was very easy to just enable those app profiles.
After checking that the relevant ports for secure IMAP (AKA IMAPS, port 993 usually) and secure SMTP (AKA SMTPS, port 465 usually) were open according to UFW, I made sure to reload the config (for ufw, via sudo ufw reload) and even restart ufw’s service (via sudo systemctl reload ufw).
Of course, to actually ensure that my gut prediction was wrong (that the firewall wasn’t the issue), I needed to prove to myself I could properly connect from the outside (my own machine).
A simple telnet <ip of machine> 993 and telnet<ip of machine> 465 that didn’t timeout (or weren’t outright rejected) were enough to convince me of this.
There is a lot of configuration involved/possible in postfix. postfix is a very robust piece of software and has definitely stood the test of time – it’s documentation is fantastic, bordering on tedious at some points for someone who isn’t an expert. To test whether configuration for postfix was working properly took two forms:
alpine/mutt. mutt was giving me issues so I often fall back to Alpine which I used in my college days and seems to be much more resilient to bad configuration/user error (which one might expect).I also started to check/ensure that the SMTP server was working from the localhost, by checking SSL/TLS over telnet. The command looks something like:
openssl s_client -debug -starttls smtp -crlf -connect localhost:25
After doing all this, after solving the issues with Thunderbird that prevented me from connectiong properly, I also realized I forgot to enable wrapper mode on postfix.
Checking dovecot configuration was a little bit easier, as dovecot provides a utility called doveadm that has a built in sanity check in forms of doveadm config. Much like postfix, dovecot also has excellent documentation, and I was able to follow the guide repeatedly just to make sure that I wasn’t missing any crucial steps and my (surface-deep) knowledge on how dovecot worked wasn’t flawed.
After a while I started to doubt Thunderbird itself. I could connect to the server on the right port, and I could actually perform the manual authentication method for dovecot. It started to perplex me that Thunderbird would fail the automatic tests for some reason, and even more bafflingly, not be able to connect at all.
Well it turns out there is an issue with Thunderbird, but much less of an issue, and more of just slightly confusing/unclear UI. Long story short, the issue is that autoconfig doesn’t quite work without a specific DNS A entry, but you can do manual config by entering the parameters yourself, then clicking “Manual Config” or something to that effect at the lower middle of the dialog, NOT the “Test” button to the lower right of the dialog.
I never did try adding the autoconfig DNS entry but instead just went with the advanced config, since I knew the settings were right.
Honestly for the combination of postfix and dovecot, it’s actually better to just start with the actual documentation. Blogs (like this one), often offer to get you started quick, but as soon as you encounter a problem, you start asking questions that were answered relatively early in the proper documentation (as they knew it would be necessary later on).
Hopefully this blog has helped some people at least look at the process I went through to try and fix my problem and maybe even find the solution to theirs.