Known issue: a distribution MTA (exim) can hijack /usr/sbin/sendmail and stop mail — cause, check and permanent fix

[admin]

Summary

If a distribution MTA (most often exim) gets installed on your server — usually as a side effect of a routine dnf upgrade or apt install — it silently takes over /usr/sbin/sendmail from Panelica's Postfix, and mail stops working. This post explains why it happens, how to confirm it, and how to fix it permanently.

A self-healing fix is scheduled for the next Panelica update. Until it reaches you, the steps below are the complete fix.

Why it happens

Panelica runs its own isolated Postfix under /opt/panelica/services/postfix. At install time we link the system entry point to it:

/usr/sbin/sendmail -> /opt/panelica/services/postfix/sbin/sendmail

That is a plain symlink. On RHEL-family systems the owner of that path is really the alternatives registry, and we were not registered in it. So when a package like exim is installed, it registers itself as the MTA provider and the registry replaces our link — with no warning and no log entry:

/usr/sbin/sendmail -> /etc/alternatives/mta -> /usr/sbin/exim

Reproduced on a clean AlmaLinux 9 system: before the exim install, sendmail was Panelica's Postfix; immediately after, sendmail -bV reported Exim version 4.100.1.

What breaks

• Outgoing website mail. PHP's sendmail_path is the compiled default, /usr/sbin/sendmail -t -i. Every mail() call from every site (WordPress notifications, contact forms, store orders) goes through that link. Once it points at exim, those messages never reach Panelica's Postfix.
• Incoming mail. On EL9, exim ships with daemon_smtp_ports = 25 : 465 : 587 — the same three ports Panelica's Postfix uses. If the exim daemon is started, it competes for them and inbound delivery can stop completely.

How to check

readlink -f /usr/sbin/sendmail
/usr/sbin/sendmail -bV
alternatives --display mta
ss -lntp | grep -E ':(25|465|587) '

If readlink does not end inside /opt/panelica/services/postfix, or sendmail -bV mentions Exim, you are affected.

Do NOT just remove exim

Removing the package on its own deletes /usr/sbin/sendmail entirely, because the alternatives registry owns that path once exim claimed it. Mail does not come back — PHP then fails with "no such file". This was measured, not assumed.

The fix

1. Stop the exim daemon and keep it from starting at boot:

/usr/bin/systemctl stop exim
/usr/bin/systemctl disable exim

2. Register Panelica's Postfix as the MTA provider, at a higher priority than exim:

alternatives --install /usr/sbin/sendmail mta /opt/panelica/services/postfix/sbin/sendmail 50 \
  --slave /usr/bin/mailq      mta-mailq      /opt/panelica/services/postfix/sbin/mailq \
  --slave /usr/bin/newaliases mta-newaliases /opt/panelica/services/postfix/sbin/newaliases

3. Verify:

readlink -f /usr/sbin/sendmail
/usr/sbin/sendmail -bV
ss -lntp | grep ':25 '

Step 2 is the important one: we verified that after this registration, installing exim again does not take the link back — priority 50 beats exim's 10 — so a later upgrade cannot repeat the problem. You can leave exim installed if something else needs it; just keep its daemon stopped.

What we are changing

This is our gap, not a misconfiguration on your side. We placed the link outside the alternatives registry, our installer does not neutralise a distribution MTA, and our repair routine only checked that /usr/sbin/sendmail exists — not where it points — so it treated a hijacked link as healthy.

The next update adds a self-healing check at every panel start: it verifies where /usr/sbin/sendmail actually points, restores it to Panelica's Postfix if a distribution MTA has taken it, registers us properly as the provider so it cannot be taken again, and warns in the panel if another process is holding ports 25, 465 or 587.

If you hit this and the steps above do not fully restore delivery, post your ss -lntp output and the last lines of /opt/panelica/var/logs/backend/backend.log and we will take a look.