On Thu, Aug 17, 2000 at 11:59:08AM -0700, Ian Lance Taylor wrote:
> From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
> Date: Thu, 17 Aug 2000 13:49:00 -0500 (CDT)
>
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 17 August 2000 at 11:32:00 -0700
>
> > I can't see much harm in being able to define the queuelifetime on
> > an individual submission - perhaps limited to between 0 and some
> > multiple of control/queuelifetime.
>
> The harm is in the increased complexity of the queue itself, and in
> the programs that manage and access it. Increased complexity costs in
> reliability, security, and resources consumed.
>
> I do agree that that feature has some benefit. I'm doubtful it's
> worth the cost, but I have little idea what the cost would *actually*
> be. Remember that there'd have to be some way to get the information
> passed to the queueing engine, too.
>
> I think my patch shows the actual cost of this feature. It is
> non-zero, but is not high.
>
> The information is passed via the environment variable
> QMAILQUEUELIFETIME to qmail-inject, which uses a new code (L) in the
> todo file. qmail-send moves this new code over to the info file, and
> honors it when bouncing messages.
Hmm. A more devious hack might be to adjust the mtime of the info file to be
time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
much closer to zero then - albeit at the cost of a misleading info file...
Regards.
