Re: mail stuck in transport queue

[Carlos G Mendioroz <tron@huapi.ba.ar>]

May be you have some special delivery setup for utoronto.ca,
and it is not working or even it is not there any longer.
(May be you are upgrading ?)

-tron

Matti Aarnio wrote:
> On Wed, Jun 18, 2003 at 12:05:56PM -0400, Francis Lau wrote:
> 
>>Hi All,
>>
>>For some reason, my zmailer (version 2.99.55) can't send mail to email 
>>addresses in the form of user@utoronto.ca.  The mail gets stuck in the 
>>transport queue when zmailer tries to send it:
> 
> 
> Unless "mailq -Q" lists  utoronto.ca  as "too busy", or some such,
> you may get some additional clues from scheduler's log-file.
> "tries=0" is -- sort of give-away, there is definite problem, but what ?
> 
> Things may go "boom", e.g. the transport agent drops a core for some
> reason (it has happened in the past, can't say it won't happen in the
> future), and when that happens, internal state becomes rather blurred.
> 
> The "tries" counter gets incremented only when the transport agent
> reports "defer" (or "retryat") condition, "ok*" and "error*" conditions
> are rather definite removals from the queue.
> 
> 
>>[root@setup5 zmailer-2.99.55]# mailq
>>smtp/utoronto.ca:
>>        X/208465-2902:  (retry in 29s, expires in 2d23h, tries=0)
>>
>>I am using the default scheduler.conf.
>>
>>Initially, I thought it was a problem with smtp/*, but when I try to send 
>>a message to user@uwaterloo.ca it is fine.
>>
>>Any ideas would be helpful.
> 
> 
>  Check  $MAILLOG/scheduler   and if the transport agents are dropping
>  core.  If the core-files are of name "core",  the  "mailq -ss" will
>  report them.  (Latter systems have begun to make  "core.xyz.123",
>  perhaps I should add a way to detect those, too.)   For cores to
>  drop, "ulimit -c unlimited" is possibly necessary.
> 
> 
>>Thanks a lot,
>>Francis
> 


-- 
Carlos G Mendioroz  <tron@huapi.ba.ar>  LW7 EQI  Argentina

-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi