On Wed, Aug 31, 2022 at 02:32:33PM +0000, Frank Brendel wrote:
> Monitoring the logs is on the list.
>
> If I understand the Postfix architecture right all I have to do in case
> of failed recipients is to write something like
> b...@recipient.com REJECT Mailbox full
> into a $smtpd_recipient_restriction table and wait for $max_use or
> $max_idle?
If the messages to the full mailbox are tempfailing at "RCPT TO:" rather
than ".", then Wietse's suggestion of recipient verification probes is
better (with a positive cache lifetime that's not too long).
> Regarding the tons of messages: it's a process which send these
> messages to a customer. Don't ask me why via SMTP of all things.
> The process doesn't see any problems on the receiver site because
> Postfix response is always OK. But if Postfix can block the process now
> because of broken recipients ... 🙂
Well, Postfix would tempfail the delivery, so if the remote source has a
queue, the flood will ultimately resume.
You really need to have a chat about reasonable mail volume expectations
with customer in question. Nobody reads 250,000 email messages in a
few days, and a machine-to-machine data stream is better handled by
other means.
At Morgan Stanley, we wrote a flood detector that quarantined high
volume repetitious mail from same sender to same recipients with similar
subjects. After enough flood garbage, further messages landed in the
"hold" queue, and periodically a notice went to the ops team to look
into either deleting the junk or release it in rare cases.
The culprits were invariably naïve developers who thought that a new
email message for each unexpected error in their software was a good
monitoring design.
--
Viktor.
