Le 04/11/2024 à 17:05, Wietse Venema via Postfix-users a écrit :
Yvan Masson via Postfix-users:
Hi list,
I have a Postfix 3.7.11 server configured with the following lines:
smtpd_milters = inet:xx.xx.xx.xx:9900
milter_default_action = quarantine
When the milter server is unavailable, incoming emails are properly
placed into the "hold" queue, so that I can process those latter.
How can I identify which emails are in the hold queue because of a
failing milter, and not because of another reason?
I suppose that you configured "milter_default_action = quarantine".
Indeed :-)
The Milter protocol actually has a 'reason' field, but Postfix isn't
using it because 'hold' was implemented before Milter support was
added.
I know it can be done by parsing Postfix logs, but it is not really
practical (I would need to automate more things). Ideally, this could be
done with "postqueue -p" or "postqueue -j", but in this case the
"delay_reason" (as documented in postqueue manpage) is empty.
When a message enters the 'hold' queue, then there is no corresponding
file in the 'defer' queue subdirectory with a reason for non-delivery.
That file is currently cleared when a message delivery starts, and
it is updated only after an attempt to deliver a recipient.
Storing the reason for 'hold' in a 'defer' like file would require
many changes because there are so many ways to put a message on
hold: SMTP server access table, header/body_checks, Milter response,
and last but not least the postsuper command which may be run at
any time whether Postfix is running or down.
Currenly, putting a message on 'hold' is an atomic action. It is
one file rename action, and that action either succeeds or it did
not happen. That makes the postsuper command very reliable.
To also store a 'hold' reason, the postsuper command would have to
respect the locking protocol for updating a 'defer' like file while
Postfix is running. If a Postfix daemon is stuck while holding such
a lock, then the postsuper command would become stuck as well.
Wietse
Thanks Wietse for this very informative answer. I really appreciate
understanding the rational leading to a behavior I do not expect at
first sight.
So I will go with the logs.
Regards,
Yvan
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org