dovecot15–
Nothing. Nothing at all. 31 May 2025, I fetched the e-mail from the mail server in my Virtua.cloud VPS, and there were no messages whatsoever. That’s unusual. Normally there is at least some silly spam, and the occasional LinkedIn update saying some people found my profile, although I’m retired, not looking for work, and I said so somewhere.
I ignored it, thought it might be a coincidence, and went on with what I was doing. But the next time it was the same again. Zero e-mails. I ignored it again, had other things to finish first.
When I dived into the matter days later, I soon found that
dovecot wasn’t running and wouldn’t restart,
because its configuration file was missing:
sudo service dovecot restart
resulted in the error message:
* dovecot: `/etc/dovecot/dovecot.conf' is not readable
* ERROR: dovecot failed to start
Well, not readable, in fact it was not there at all.
I still don’t know how that file got removed. Fact is, after under
Alpine Linux 3.22 I tried to reinstall:
sudo apk del dovecot
sudo apk add dovecot
there was still no /etc/dovecot/dovecot.conf
and neither were there any files in
/etc/dovecot/conf.d, what’s more, that directory
didn’t even exist.
They were there on a temporary test VPS under Debian 12. I used those
config files, or some slightly different ones I had kept
ready for my own server installation script. But
dovecot still wouldn’t run: it said
“failed to start”. No further details.
Details can be obtained from the auxiliary program
doveconf, though, which, as I discovered
later, does the same as dovecot -n .
Under Debian 12, dovecot is version 2.3.19.1, but it’s
2.4.1-4 under Alpine Linux 3.22. And there lies the trouble:
dovecot’s maintainers made a lot of incompatible
changes to its config files between 2.3 and 2.4. I found
documentation
here. There is no way to create config
files that will work for both: 2.4 requires
a setting dovecot_config_version, which in 2.3
isn’t allowed. And many more such stumbling
blocks.
In my humble opinion that is not a proper way to maintain software. Older versions should be upward compatible, i.e. allow unknown future settings with a warning, or simply ignore them. Newer versions should be backward compatible, i.e. should not require newer settings, instead assuming sensible default values if those settings are missing.
But what could I do? I depend on this software.
So I copied the 2.3 config files for Debian, and ran
doveconf or dovecot -n repeatedly,
fixing the single config problem it reported each time. Takes
quite some time and effort, but it can be done. Eventually
dovecot started! But still no e-mails.
How could it not work? After a lot of to and fro and stubbornly
overlooking the actual problem, I finally found it. In
log file /var/log/messages it said that
dovecot had started without any protocols.
So no IMAP and no POP3. Why so?
Config file /etc/dovecot/dovecot.conf
contained a directive
!include_try /usr/share/dovecot/protocols.d/*.protocol
Under Debian that finds
/usr/share/dovecot/protocols.d/pop3d.protocol
But Alpine Linux instead has:
/usr/share/dovecot/protocols.d/pop3d.conf
So the directive should be different, or both should be included:
!include_try /usr/share/dovecot/protocols.d/*.protocol
!include_try /usr/share/dovecot/protocols.d/*.conf
Why such unnecessary differences? Why not standardize and harmonize things?
But doveconf still wasn’t satisfied.
/usr/share/dovecot/protocols.d/pop3d.conf
contains the line
protocols = $protocols pop3
apparently intending to add protocol POP3
to anything already configured earlier. But version 2.4
of dovecot, and/or its Alpine Linux variant,
doesn’t know the variable protocols or the
syntax with the dollar sign. So I had to hardcode
protocols = pop3 .
So now dovecot was running, supporting the POP3
protocol as it should. Eudora could make a connection using
that protocol, but still no e-mails. What could be wrong
this time? Local test:
$ telnet localhost 110 Connected to localhost -ERR Auth process broken Connection closed by foreign host
Authentication was done with the shadow method. In 1985 when I
first got to know Unix, user passwords were encrypted, the
resulting hashes being in a file readable to all, called
/etc/passwd . The encryption was considered
unbreakable, so it didn’t matter that everyone could read
the hashes. Later, with ever faster hardware, making brute
force attacks feasible even in the presence of better hash
algorithms and longer hashes, those were moved to a file
that only user root can read,
/etc/shadow . Hence the name of one of
dovecot’s authentication methods: shadow.
But dovecot 2.4.1 no longer supports shadow. Instead
you must use PAM. OK, so I configured that in
/etc/dovecot/conf.d/auth-system.conf.ext
But it doesn’t help, because dovecot 2.4.1 as
installed by Alpine Linux 3.22 doesn’t have PAM compiled in.
That for me was the limit. I do know how to compile source code. I used to be a profesnional C programmer and I still program from time to time, just for the fun of it. But I find it unacceptable to compile from source in this case. I use Alpine Linux because it is so easy and fast to keep it up-to-date. I instructed my children to keep my website running after I die, by just paying the hosting fees, and hopefully nothing else will need to be done. (Well, but it will suffice to have a web server then, and an e-mail server won’t be necessary any more.)
Anyway, I was so fed up with so many incompatibilities and difficulties,
that I decided to ditch dovecot altogether, and
replace it by something else, something simpler. Did I use
dovecot for more than supporting POP3? Does it
cooperate with postfix the way procmail
works with sendmail and spamassassin?
Tests revealed that it doesn’t, or not in the configuration
that I am using.
popa3dWhat I need is quite simple: just POP3 with port 110, in plain text,
no encryption. I can afford that because I have ssh
set up a mail tunnel, so legacy e-mail client Eudora on my laptop,
running under wine and Bunsenlabs Boron (based on
Debian 12), reads from localhost,
which in fact transparently has been turned into the remote mail
server on the VPS provided by Virtua.cloud. The tunnel is encrypted,
so the mail fetching algorithm need not be. See my article
Mail tunnel for an
explanation.
I found popa3d, which is perfect
for my purpose. The sources are in
popa3d-1.0.3.tar.gz . (Yes, this time I
inconsistently found compiling from source acceptable.) As usual,
unpack this using the command
tar -xf popa3d-1.0.3.tar.gz, which will create a
directory popa3d-1.0.3 . Follow the instructions
in the file INSTALL, and adapt params.h
if necessary. Then run
make
make install
Start the program from /usr/local/sbin/popa3d .
To make it survive a reboot I added the line
@reboot /usr/local/sbin/popa3d
to the crontab instructions. That works under Alpine Linux,
but not under Debian, where some other solution is needed.
How many times I have thought I was almost there? There’s a last hurdle. In the words of Google’s AI, which now presents its results before showing web locations:
“popa3d, a POP3 daemon, generally supports the mbox mailbox format. While it's designed to be secure and reliable, it does not have built-in support for other formats like maildir or dbox, according to the OpenBSD manual and the Openwall website. It primarily focuses on secure operation within the mbox format and the POP3 protocol.”
My mails were in the maildir format, for which there is a directory
Maildir in the user’s home directory. Maildir
has subdirectories cur and new, where
message reside as separate files. But that was easy to solve: in
/etc/postfix/main.cf, turn the line
home_mailbox = Maildir/
into a comment, and restart Postfix:
sudo service postfix restart
From then on Postfix will store all incoming e-mails together
in a single file with the same name as the user, under
/var/mail . That is the mbox format, which
popa3d does support.
Finally, it worked! 5 June 2025, late afternoon.
To salvage the cumulated e-mails that were still in the old format,
the next day I converted them using the script
xfmail2mbox.sh that I
found here. To make it work,
however, I had to change the shebang
#! /bin/sh
to
#! /bin/bash
In Alpine Linux, /bin/sh is actually
dash, no, ash, or whatever, the
point is that apparently this script uses something that
is not supported by the original Bourne Shell, or by rather
conservative modern versions of it. My personal opinion is
that extra features of bash should be avoided
in shell scripts, especially if they are published. But I
know not everybody agrees.
Also, at line 114 in script xfmail2mbox.sh, I had to
insert an extra echo, to achieve that e-mails in the
mbox file are separated by a blank line AND
a line that starts with From: . Otherwise Eudora
would interpret the whole mbox file as a single e-mail, instead
of distinguishing the several different e-mail it contains.
On a temporary test server, I moved the resulting mbox file to
/var/mail/ruudh (ruudh being the
user name that, after applying alias rules as necessary,
receives the e-mails on my e-mail server), created an ssh
mailtunnel from my home laptop to that server, and had Eudora
fetch all those accumulated mails, so I could finally read
them without also seeing all the distracting headers and DKIM
signatures etc.
Mission completed!
Many Linux distibutions, like Debian, are rather conservative in
including newer versions of the software they contain as
standard, or make available for later installation. Debian 12
still has dovecot 2.3.19. Because I have configured
Alpine Linux to automatically update to the latest stable version,
I was confronted with the incompatible dovecot
2.4.1 already about two weeks ago.
Therefore I expect that in the coming months, and even years (e.g.
Ubuntu 22.04 – currently with dovecot 2.3.16
– will be supported until April 2027, and Ubuntu 24.04 –
currently with dovecot 2.3.21 – can safely
be used until April 2029), the POP3 and IMAP facilities of
countless e-mail servers all over the world will suddenly break.
This will cause a lot of annoyance, and will require efforts from
system administrators, either before a carefully planned and
tested upgrade, or in panic if the break was unexpected because
people tend to expect backward and forward compatibility.
So be forewarned.
Copyright © 2025 by R. Harmsen, all rights reserved.