Marvin Renich:
> * Wietse Venema <wie...@porcupine.org> [200119 08:04]:
> > 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).
> >
> > Pro: Less complexity. No 'expired' state inside queue files.
> >
> > Con: More complexity. When expired mail needs to be deferred because
> > the bounce daemon is failing, it should go back to the expired
> > queue, not to the deferred queue.
>
> Postsuper isn't overflowing with options; perhaps a more flexible and
> simpler design would be to have -e expire and -E expire and release from
> hold (if it is held).
Yes, the idea of a third option came to mind.
> The only con I see to this is "feature creep", which is minimal at this
> point. It only becomes an issue when postsuper starts getting more and
> more options.
There is a limit to what postsuper can do, because by design it has
no dependencies on a running Postfix system.
That is, until someone turns postsuper into a kind of busybox program
that has all the Postfix code linked into it :-)
Wietse
