Re: Stalled queues and holding mail

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

Now I am back at the office, and slowly going thru my email pile..

...
> Thank you for the idea. I did not know about the TURNME command.
> 
> I just found the problem a little bit ago. This past weekend, I also
> recreated the zmailer RPM that I have been working on. Because of this,
> I had to create a second log directory. The error logs were getting put
> in the new directory. I did not think to look in there until I started 
> to clean up. 
> 
> The problem was that there was no command entry for the two domains. I 
> thought that the smtp/* entry was above my entries. At least I assume 
> that the smtp/dbc-mifco.com entry would take on all the settings from
> smtp/* and */*. Am I wrong?

	The defaults are pulled in from  */*,  and it does not have any
	"command=" entry in it.  Defaults are NOT pulled in from  "smtp/*",
	because it is LATTER in the parsing, than  "smtp/*.foo".  If it
	weren't, then the  "smtp/*" would always match all hosts in the
	smtp channel, and  "smtp/*.foo"  would never match anything.

> Now that leaves the question: how are the hold channels used?

	The hold channel is for deferred routing processing of some
	particular target addresses.  It is NOT for freezing out
	some destination addresses until further notice.

	Ok, perhaps there could be a weird special route that defers
	all messages until N hours has passed, but to do it, we would
	need a new hold attribute (hold time:123h ?), AND the channel
	must not expire the messages before the longest hold-time has
	passed.

	The message would also be stripped of the delay triggering pseudo-
	domain/uucp-nodename before it would be placed into hold/time, of
	course...

> --
> Gerard Hickey			hickey@kernelrom.com
> 58 Lower Main St.		+1 207 676 8491
> North Berwick, ME    03906

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