By isolating the upd process, verifying backend connectivity, and performing a clean restart of the entire Postfix subsystem, you can resolve the error within minutes. For ongoing health, implement database connection hardening and filesystem monitoring.
# For MySQL connect_timeout = 5 timeout = 2 option = 3 # MYSQL_OPT_RECONNECT connect_timeout = 5 keepalive = 1 keepalive_idle = 60
When Postfix says "unknown," it is asking you, the administrator, to become the detective. Your logs, your postcat output, and your database error logs hold the real answer. Your logs, your postcat output, and your database
postmap -q "test@example.com" mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf An error here (e.g., Can't connect to MySQL server ) means Postfix cannot talk to the DB. Check your *.cf files for correct host, port, and password. mailq | grep -B1 "temporarily suspended" Or use qshape deferred to see the age of stuck emails. If all emails are failing, it's a system-wide transport issue. Permanent Solutions Depending on your diagnosis, apply one or more of these fixes. Fix 1: Restart Postfix Cleanly (Not Just Reload) A simple postfix reload does not restart the upd processes. You need a full stop/start:
restorecon -Rv /var/spool/postfix restorecon -Rv /etc/postfix setsebool -P httpd_can_sendmail on # If using webmail or scripts If an update caused the issue: mailq | grep -B1 "temporarily suspended" Or use
grep "delivery temporarily suspended" /var/log/maillog | tail -20 You will see a Queue ID (e.g., 3F4A1A0B2C ). Use it to inspect the message:
df -h /var/spool/postfix df -i /var/spool/postfix # Check inode usage dmesg | grep -i "error\|corrupt" A malformed entry in your transport file can cause this. For example: your postcat output
# On Debian/Ubuntu apt-cache show postfix | grep Version # Find previous version apt install postfix=3.5.6-1 # Example old version # Hold the version to prevent auto-upgrade apt-mark hold postfix On Red Hat/CentOS: