If not, try to re-install Postfix packages to generate them:

apt reinstall postfix

what's the error message in /var/log/maillog when you sent or received an email?

Thanks for your response!

Looking at /var/log/maillog right now, I'm not seeing any error messages. It appears to be receiving mail and making connections and routing messages appropriately.

When I try to run systemctl restart postfix, I don't see error messages in /var/log/maillog either.

The issue at this time is that the postfix service seems to have a problem preventing it from running automatically at boot or when trying to restart it.  It did not start fully (postfix was not running and listening on ports 587 and 25 after a server reboot, and even after running systemctl postfix restart, and I could previously see the error message when running "systemctl status postfix*"

 Process: 33330 ExecStartPre=/usr/lib/postfix/configure-instance.sh - (code=exited, status=1/FAILURE)

The thing that worked was to manually run "postfix start" which allowed me to send and receive mail, but I suspect if I reboot the server, I would have to manually start postfix again because of the inability to fully start the service.

Also, it's weird that doing "systemctl status postfix*" now gives the error messages about missing units, when it was previously showing me the status with the error message about exiting script configure-instance.sh.

I have been searching all over the internet for any other hints at what could be going on, or additional logs/troubleshooting steps, but so far coming up short.

Last Friday, I upgraded from 20.04 to 22.04 successfully following the directions on iredmail forum topic20565-direct-upgrade-ubuntu-2004-to-2204-guide.html

Then, today I upgraded from 22.04 to 24.04 using the instructions: iredmail docs upgrade.ubuntu.22.04-24.04.html

After finishing the release upgrade and rebooting the server on 24.04, and going through the install process again for iredapd, iredadmin and mlmmjm I was unable to send or receive mail but I was also unable to resolve domain names.

I was able to find another instance of this happening on an OpenVZ system where the user does not have the ability to update the kernel (currently running the 5.4.0) and it looked like the only option at this time was to stop using systemd-resolved, due to an issue in systemd-resolved on 24.04 systems running in OpenVZ: the github site /systemd/systemd/issues/34580

#fix dns resolution after update to 24.04 by disabling systemd-resolved
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo rm /etc/resolv.conf
sudo nano /etc/resolv.conf

#paste in /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1

Making that change allowed me to resolve DNS and ping google.com.

So back to the mail issue.
There was nothing happening in /var/log/mail.log (because as I found out later, postfix wasn't running).

Running "lsof -i -P -n | grep LISTEN" didn't reveal anything listening on ports 25 or 587, but I could see dovecot on 993/995/143/110.

systemctl status postfix:

postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2026-05-05 01:37:36 UTC; 45min ago
       Docs: man:postfix(1)
    Process: 33358 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
   Main PID: 33358 (code=exited, status=0/SUCCESS)

but there was an error message in systemctl status postfix*

 postfix@-.service - Postfix Mail Transport Agent (instance -)
     Loaded: loaded (/usr/lib/systemd/system/postfix@.service; enabled-runtime; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-05-05 01:37:36 UTC; 9s ago
       Docs: man:postfix(1)
    Process: 33330 ExecStartPre=/usr/lib/postfix/configure-instance.sh - (code=exited, status=1/FAILURE)

I was able to run:

postfix start

Then I started seeing successful messages in /var/log/mail.log and I could see master
running and listening on 25 and 587. 

postfix check

postfix: Postfix is using backwards-compatible default settings
postfix: See postfixorgwebsite /COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
postfix/postfix-script: warning: /var/spool/postfix/lib/x86_64-linux-gnu/libgcc_s.so.1 and /lib/x86_64-linux-gnu/libgcc_s.so.1 differ

I copied my resolv.conf and x86_64-linux-gnu/libgcc_s.so.1 into the postfix CHROOT in the appropriate locations, and then running postfix check stopped giving the two warnings, and only the messages about backwards compatibility.

But after running systemctl stop postfix and systemctl start postfix, I was still seeing the same error message in systemctl status postfix*.

I tried running /usr/lib/postfix/configure-instance.sh manually to see if I could see any error message output and there was no output, but now when I run the command again, it's giving different output:
systemctl status postfix*

Unit postfix-mysql.so.service could not be found.
Unit postfix-pcre.so.service could not be found.
Unit postfix_groups.pl.service could not be found.

tail -200 /etc/postfix/dynamicmaps.cf

# dict-type     so-name (pathname)      dict-function   mkmap-function
pcre    postfix-pcre.so dict_pcre_open
mysql   postfix-mysql.so        dict_mysql_open

postconf -m also still shows mysql and pcre in the list.

So now I have mail sending and receiving working again, but I think something with postfix is still borked and I'm afraid to restart my server.

checking the processes that are listening on 25 and 587 again now, it looks like it has changed and postscree (postscreen?) is listening on 25 and smtpd is listening on 587, which I'm pretty sure is different from what I saw after I first ran "postfix start".

I have a full backup from before the upgrade on 20.04->22.04 that I could restore, or I could backup the databases and vmail and DKIM and do a VM reinstall from scratch and then migration and reinstall and restore when I have more time in a few days, but I was hoping that this was something that I could figure out and kick a full reinstall down the road further.

Thanks for any other ideas or hints you might have,
natec