Hi Viktor, thank you for the hint.
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? 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 ... 🙂 Thank you Frank Frank Brendel Administrator Rechenzentrum Telefon: +49 811 9595-157 Telefax: +49 811 9595-199 Internet: https://www.eurolog.com EURO-LOG AG Am Söldnermoos 17, D-85399 Hallbergmoos Vorstand: Jörg Fürbacher Aufsichtsratsvorsitzender: Markus Quicken Registergericht: AG München HRB 140857 Steuer-Nr.: 115/118/10169 Ust-ID-Nr.: DE 811547361 Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Am Mittwoch, dem 31.08.2022 um 09:11 -0400 schrieb Viktor Dukhovni: > On Wed, Aug 31, 2022 at 09:56:49AM +0000, Frank Brendel wrote: > > > > You really should do something about that, build a table of over- > > > quota recipients, and tempfail new mail for such users when > > > briefly > > > over quota, and ultimately reject if long-term over-quota. > > > > but is that possible with remote mailboxes? > > If this is outbound mail to a remote domain, then it is much harder > to > know that the mailbox is full, you'd need to monitor the logs or the > content of the deferred queue for recipients deferred with an > extended > status code of 4.2.2 <https://www.rfc-editor.org/rfc/rfc3463#section- > 3.3>, > and then you could attempt to propagate this upstream, by tempfailing > further traffic to the destination until the backlog of deferred mail > to that recipient falls below a low water mark. > > But if you managed in less that $max_queue_lifetime to accumulate > 250,000 messages to the same mailbox, something is wrong on the > sender > end. Whatever is generating the flood should be dealt with. >
