Skip to content
OrbixPanel OrbixPanel Tutorials

Fix webmail login and email delivery (Dovecot/Postfix)

If webmail won’t log you in, you can’t change a mailbox password, or the panel shows a mail task failing with something like email-sync: reload dovecot: exit status 1, these are almost always the same problem wearing three hats: the mail service is down.

Your server runs two mail services:

  • Postfix — sends and receives mail (SMTP).
  • Dovecot — serves mailboxes over IMAP/POP3. Webmail logs in through Dovecot, and mailbox passwords are checked by Dovecot.

So if Dovecot has crashed, webmail can’t authenticate (you’ll see a failed login, sometimes a 401), password changes can’t apply, and any panel task that updates mail ends with “can’t reload a service that isn’t running.”

Confirm it in 10 seconds

Run on the server (over SSH):

Terminal window
sudo systemctl status dovecot --no-pager | head -8

If you see Active: failed or inactive (dead) instead of active (running), that’s your answer. A line like Result: core-dump means the process crashed.

Check whether IMAP is even listening:

Terminal window
sudo ss -tlnp | grep -E ':(143|993)' || echo "IMAP is NOT listening"

The fix

1. Is the config actually valid? (Rule out a broken config before restarting.)

Terminal window
sudo doveconf -n >/dev/null; echo "config check exit=$?"
  • exit=0 → config is fine, the service just crashed. Go to step 2.
  • Non-zero → it printed the exact error (a bad setting, or a missing TLS cert referenced in /etc/dovecot/conf.d/10-ssl.conf). Fix that line first, then restart.

2. Restart it:

Terminal window
sudo systemctl restart dovecot
sudo systemctl status dovecot --no-pager | head -5

You want Active: active (running) and IMAP listening on 143/993 again. Now retry the webmail login and the password change — both should work immediately.

3. Re-run the mail sync from the panel (or just edit any mailbox) to clear the failed task status.

Stop it from happening again (important)

By default Dovecot does not restart itself after a crash — which is how a single hiccup becomes a multi-day outage you only notice when someone can’t read their mail. Make it self-heal:

Terminal window
sudo mkdir -p /etc/systemd/system/dovecot.service.d
sudo tee /etc/systemd/system/dovecot.service.d/restart.conf >/dev/null <<'EOF'
[Service]
Restart=on-failure
RestartSec=5
EOF
sudo systemctl daemon-reload
sudo systemctl restart dovecot
systemctl show dovecot -p Restart   # should print Restart=on-failure

Now a crash recovers in ~5 seconds on its own. (Do the same for Postfix if you like — postfix in place of dovecot.)

Why did it crash?

On a small server (1–2 GB RAM), the most common trigger is memory pressure: the kernel’s out-of-memory killer takes a mail child process, and Dovecot aborts. Check:

Terminal window
sudo journalctl -k | grep -i "killed process" | grep -iE "dovecot|imap"

If Dovecot shows up there, it was OOM. The auto-restart above contains the damage, but also avoid running a heavy build (like a site rebuild) on the same box while mail is serving — that’s what spikes memory. See Diagnose high CPU & memory.

Still can’t log in after Dovecot is up?

Prove the mailbox credentials against Dovecot directly, bypassing webmail — use a real mailbox and its password:

Terminal window
openssl s_client -crlf -connect localhost:993 -quiet 2>/dev/null <<'EOF'
a login user@yourdomain.com 'the-password'
a logout
EOF
  • a OK … → Dovecot auth works; the problem is in webmail’s config, not the mail server. Reset the mailbox password from the panel and retry.
  • a NO … → the password itself is being rejected. Reset it from the panel’s Email section (that rewrites the stored hash), then test again.