On Wed, Jan 15, 2020 at 09:32:43PM +0100, [email protected] wrote:
> >> > Why? Someone was drunk and sent a bad email? Is "postsuper -d"
> >> > not sufficient?
> >> >
> >> > Wietse
> >>
> >> Use case: Users are sending undeliverable e-mails which are filling up
> >> mail queue and you must wait few days until they are bounced. You
> >> cannot simply delete them because, if you do, sender won't know it's
> >> undeliverable and will send something to that address again in the
> >> future.
When you say "filling up mail queue" is that actually a problem, or just
something you could simply ignore with no ill-effect? The mail will
bounce eventually after (by default) ~5 days.
> > Why not set a smaller maximal_queue_lifetime?
As Wietse suggests, you can typically set the queue lifetime a bit
shorter (perhaps 2 days, but generally not much shorter, allowing
remote sites to fix problems they did not notice immediately).
With 5 days, you can wait out an outage that lasts across a long
holiday weekend. With 2 days, an outage that does not get noticed
until the next morning and takes a day to fix.
> Because there can be legitimate situations where it is good to keep
> e-mails longer in the queue (full mailbox, temporary outage of
> recipient server [which can take days] etc.).
Which is why on outbound Postfix instances I tend to set:
delay_warning_time = 2h,
giving my own senders generally same day notice of email that'll likely
never make it, but retries continue for ~2-5 days. In commercial
deployments serving more than a handful of users, I always separate
inbound and outbound processing into separate Postfix instances.
The inbound queue has the default "delay_warning_time = 0h", which
does not leak internal hiccups to outsiders.
--
Viktor.
