Re: negative expiries

[Matti Aarnio <mea@nic.funet.fi>]

On Wed, Oct 04, 2000 at 10:19:28AM -0300, Trent MacDougall wrote:
> I am running ZMailer 2.99.52.
> I have changed the scheduler.conf file to reduce the expire times for
> certain smtp connections.  I restarted zmailer and the messages that have
> already gone past the new expiry are now showing negative expiries that are
> increasing.  Is there some graceful way for me to expire these messages so
> that they will bounce back to the sender?
> 
> Otherwise, I guess I will have to go looking at the code. :-)

	When the expiration goes negative, AND one delivery attempt
	is done (e.g. goes to timeout, or sends, or whatever), then
	such message does timeout from the queue.

	There have been *issues* with how to behave when attempt fails,
	but I think most have been resolved over this summer for the smtp
	ta program.


	A way to shunt the whole sub-queue is to use "manual-expirer"
	script at $MAILBIN directory:

		$MAILBIN/manual-expirer -c smtp -h that.some.domain

	Adding there a "-s" option would *silence* the beast.
	As shown above, all mail to   smtp/that.some.domain  presently
	in the queue will be nuked with diagnostic report telling that
	"your message has been administratively deleted from the queue"
	(I recall there is option also to define the message string.)


	The "issues" I mean above are about the smtp TA getting into
	disagreenment with the scheduler about what is the state of
	some recipient(s) in a message in several problem cases.
	(Some recipients got multiple diagnostics sometimes, others
	 got none -- that "none" harms more.  2.99.54 has them ok.)

	Also (before 2.99.54), even in a long queue the delivery will
	not be retried for *all* messages in there, only for the oldest
	or for one random pick (depending on existence of "ageorder"
	flag at the scheduler group clauses).

	As such leads to difficulties at auto-pruning fast accumulating
	destination queues in case the delivery fails, very recently I
	did add some rules to try the delivery also for other than the
	queue's "delivery probe" job (the first one).
	

> -- 
>                 Trent MacDougall @ InfoInterActive Inc.
>                  Trent.MacDougall@InfoInterActive.Com

-- 
/Matti Aarnio	<mea@nic.funet.fi>