On Sun, Jan 19, 2020 at 08:03:14AM -0500, Wietse Venema wrote:
> A radically different approach would be to introduce a new 'expired'
> queue and move messages there when they need to be expired, and to
> introduce a new postqueue flag to flush the expired queue (the queue
> manager should not normally scan the expired queue because that
> would slow down all deliveries).
My instinct is to not optimize for very large numbers of expired
messages, and add another queue for the administrator to think
about.
Bounces back to the sender for messages one is expiring rather
than simply deleting are presumably for an internal authorized
user, and so their delivery should not incur much latency.
IMHO expiration should leave all messages in whatever queue they were
found (including "hold"), and if the message was deferred I would
try to preserve its (postdated) modification time, so as not to
trigger expedited processing. It will bounce before the next
delivery attempt.
If the message is active, the queue manager will not have seen
the "expired" flag yet, and will likely defer the message, when
the pending delivery attempts complete, it will bounce before
the next retry.
That said, instead of a queue file record, this could be one
of the "mode" bits of the file, in particular, we could set
the queue file group execute bit to indicate expiration,
this would be cheap for the queue-manager to re-check before
deciding whether to defer the message, and could alternatively
be used for expedited processing from the deferred queue.
--
Viktor.
