How to inspect queued messages

I have searched the forum for similar issues

on

This category is for general issues(=something is broken) regarding YunoHost, NOT apps.

on

This form is written in English but feel free to write in French if you’re more comfortable!

on

What type of hardware are you using

Internet Cube with VPN

What YunoHost version are you running

12.1.41.2

How are you able to access your server

SSH

Are you in a special context or did you perform specific tweaking on your YunoHost instance ?

No

Describe your issue

I’ve got the following warning message :
‘1283 mails are in your mail queue’
I want to know about these messages and run ‘mailq’ as ssh root.
I got a list of id a date and a sender/recipient which is invariably ‘root’ or ‘jirafeau’
I saw on https://www.hostmycode.com/tutorials/mail-queue-troubleshooting-tutorial-2026-fix-stuck-emails-vps-postfix that the command ’ postcat -vq QUEUEID | sed -n ‘1,160p’’ could help me inspect the QUEUEID message but I get a ‘command not found’ error.

What would be the good way of inspecting these message to know where they come from and what to do to avoid them ?

Thanks a lot !

Share relevant logs or error messages

1283 mails are in your mail queue

postcat -vq 957AF15C0CF5 | sed -n ‘1,160p’

Command not found

might by a copy paste of quote character

postcat -vq 957AF15C0CF5 | sed -n '1,160p'

Hi @artlog ,

I tried by copying your command but get

# postcat -vq 957AF15C0CF5 | sed -n '1,160p'

bash: postcat: command not found


:face_with_peeking_eye:

@harpogit

postcat is a command that is part of postfix debain package , a package that is usauly part of yunohost.

what returns followinfg commands

which postcat

dpkg -l | grep postfix

which postcat returns nothing

dpkg -l | grep postfix returns :

ii  postfix                               3.7.11-0+deb12u1                                   armhf        High-performance mail transport agent
ii  postfix-ldap                          3.7.11-0+deb12u1                                   armhf        LDAP map support for Postfix
ii  postfix-pcre                          3.7.11-0+deb12u1                                   armhf        PCRE map support for Postfix
ii  postfix-policyd-spf-perl              2.011-2                                            all          Simple Postfix policy server for RFC 4408/7208 SPF checking

@harpogit

so i think your current user has no right to run postcat. Those command can help to diagnose that matter

ls -la /usr/sbin/postcat

dpkg -L postfix

echo $PATH

id

you might want to try to log as an administrator or as root

So !
I had su command BUT I had to begin with sudo !
:zany_face:

Then the sudo postcat goes on.

For instance, sudo postcat -vq 7471C15C6260 | sed -n '1,160p'

returns :

postcat: name_mask: all
postcat: inet_addr_local: configured 4 IPv4 addresses
postcat: inet_addr_local: configured 8 IPv6 addresses
*** ENVELOPE RECORDS maildrop/7471C15C6260 ***
message_arrival_time: Fri Mar 6 03:16:02 2026
named_attribute: rewrite_context=local
sender_fullname: CronDaemon
sender: jirafeau
named_attribute: encoding=8bit
recipient: jirafeau
*** MESSAGE CONTENTS maildrop/7471C15C6260 ***
regular_text: From: root (Cron Daemon)
regular_text: To: jirafeau
regular_text: Subject: Cron <jirafeau@mondomaine> /usr/bin/php8.4 /var/www/jirafeau/admin.php clean_async
regular_text: MIME-Version: 1.0
regular_text: Content-Type: text/plain; charset=UTF-8
regular_text: Content-Transfer-Encoding: 8bit
regular_text: X-Cron-Env: <SHELL=/bin/sh>
regular_text: X-Cron-Env: <HOME=/var/www/jirafeau>
regular_text: X-Cron-Env: <PATH=/usr/bin:/bin>
regular_text: X-Cron-Env: <LOGNAME=jirafeau>
regular_text:
regular_text: 0 old unfinished transfers deleted.
*** HEADER EXTRACTED maildrop/7471C15C6260 ***
*** MESSAGE FILE END maildrop/7471C15C6260 ***

Once you have a message id or timestamp you can also look for it in the log, e.g.

less -p <string> /var/log/mail.log

If your problem came with the yunohost 12 upgrade maybe see:

Ah, note that some failure modes from Issues to fix email breakages caused by upgrades (regression) can make localy sent emails vanish, so there are only e.g. “bounce” or “loops back to myself” error traces in the log.

Hello @tmb ,

Here 's what the command less -p 7471C15C6260 /var/log/mail.loggives :

a huge bunch of lines like this :

2026-09-06T00:03:49.473686+00:00 MyUser postfix/cleanup[11355]: warning: hash:/var/virtual is unavailable. open database /var/virtual.db: No such file or directory
2026-09-06T00:03:49.475291+00:00 MyUser postfix/cleanup[11355]: warning: hash:/var/virtual lookup error for "root@MyDomain"
2026-09-06T00:03:49.477073+00:00 MyUser postfix/cleanup[11355]: warning: 6FEE415C0952: virtual_alias_maps map lookup problem for root@MyDomain -- message not accepted, try again later
2026-09-06T00:03:50.483686+00:00 MyUser postfix/pickup[31650]: warning: 7562315C0952: message has been queued for 249 days
2026-09-06T00:03:50.487229+00:00 MyUser postfix/pickup[31650]: 7562315C0952: uid=986 from=
2026-09-06T00:03:50.492539+00:00 MyUser postsrsd[11369]: srs_forward: <jirafeau@MyDomain> not rewritten: Domain excluded by policy

I don’t know what to do.

:thinking:

“message has been queued for 249 days” but the number changes for each record randomly between 304 and 20 !

This looks strange to me.
Only idea, check if email is enabled for your jirafeau domain and the main-domain.

The hash:/var/virtual is unavailable and virtual_alias_maps map lookup problem lines suggest Postfix still points at a map that isn’t provided anymore. To narrow it down, could you share the output of postconf -n | grep -E 'virtual|alias' and ls -la /etc/postfix/virtual* /var/virtual* 2>/dev/null? That would show whether main.cf still references /var/virtual (a stale path) or if yunohost tools regen-conf postfix --dry-run reports pending changes, versus something unrelated to the upgrade regression already linked above.

gives :

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
virtual_alias_domains =
virtual_alias_maps = hash:/var/virtual,ldap:/etc/postfix/ldap-aliases.cf,ldap:/etc/postfix/ldap-groups.cf
virtual_gid_maps = static:mail
virtual_mailbox_base =
virtual_mailbox_domains = /etc/postfix/virtual-mailbox-domains
virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf,hash:/etc/postfix/app_senders_login_maps
virtual_minimum_uid = 100
virtual_transport = dovecot
virtual_uid_maps = static:vmail

and ls -la /etc/postfix/virtual* /var/virtual* 2>/dev/null

-rw-r--r-- 1 root root 142 Aug 23 2025 /etc/postfix/virtual-mailbox-domains

Bonjour,

Je ne suis toujours pas parvenu à passer la migration.

J’ai désinstallé Jirafeau et emailpoublelle qui étaient concernés par ces mails “queued”.

Je remarque des erreurs dans les log de postifix et dovecot :

Dans le /var/log/mail.err/, j’ai par exemple :
Nov 1 17:25:05 User dovecot: lda(nextcloud@MyDomain)<26209><>: Error: auth-master: userdb lookup(nextcloud@MyDomain): connect(/var/run/dovecot/auth-master) failed: Connection refused
Nov 1 17:25:05 User dovecot: lda(26209): Fatal: Internal error occurred. Refer to server log for more information.

La date du 1er novembre est d’ailleurs assez bizarre.

Ou encore :

Nov 1 16:24:22 User dovecot: auth: Error: LDAP: Connection lost to LDAP server, reconnecting
Nov 1 16:24:22 User dovecot: auth: Error: LDAP: Can't connect to server: 127.0.0.1
Nov 1 16:57:00 User dovecot: stats: Error: conn unix:stats (pid=17128,uid=0): Socket supports major version 4, but we support only 3 (mixed old and new binaries?)
Nov 1 17:00:05 User dovecot: lda(nextcloud@MyDomain)<21777><>: Error: auth-master: userdb lookup(nextcloud@MyDomain): connect(/var/run/dovecot/auth-master) failed: Connection refused
Nov 1 17:00:05 User dovecot: lda(21777): Fatal: Internal error occurred. Refer to server log for more information.

Je me demande comment corriger ce problème.

Merci de votre aide !

J’ai pas bien suivi le fil de discussion mais as tu essayé yunohost tools regen-conf --force

Visiblement cette fois, même si je n’ai pas vraiment compris pourquoi, la migration est passée.

Merci @jarod5001 !

:nerd_face: