On Thu, 12 Apr 2001, Patrick Boutilier wrote:
> I just duplicated the deffered problem by sending to the invalid address
> myself. I read section 33 of spec.txt and it appears that this message
> should eventually just be removed from the queue.
>
> 2001-04-12 11:08:03 14nhlT-0007uC-00 <= boutilpj@???
> H=trademart-2.ednet.ns.ca (ednet.ns.ca) [142.227.51.61] P=esmtp
> X=SSLv3:RC4-MD5:128 S=610 id=3AD5B752.B0A081F2@???
> 2001-04-12 11:08:03 14nhlT-0007uC-00 remote host address is the local
> host: belayr.ednet.ns.ca
> 2001-04-12 11:08:03 14nhlT-0007uC-00 == belayr@???
> R=lookuphost defer (-1): remote host address is the local host
> 2001-04-12 11:08:03 14nhlT-0007uC-00 Frozen
(1) The message is not an error message, so it does have a valid sender
to which a bounce can be sent.
(2) Because it has been frozen, it will stay on the queue unless you have
set timeout_frozen_after, auto_thaw, or force a delivery.
(3) You can use "exinext" to check on the retry status of the address
belayr@???.
(4) As long as you arrange for delivery attempts to happen (either by
timeout_frozen_after, auto_thaw or by forcing), the address should
eventually time out, and a bounce message will then be sent to
boutilpj@???.
HOWEVER: This is different to the problem you posed, because in that
case, the message that was failing was a bounce message. Such messages
do not have a sender to which another bounce can be sent. Therefore,
they cannot time out in the normal way. There are special options for
controlling what happens to bounce messages that fail. They are
ignore_errmsg_errors and ignore_errmsg_errors_after. However,
timeout_frozen_after should also work for such messages.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
