I asked:
We recently reverted to Sun's V8 sendmail from real V8 (8.6.13) while Sun
come out with a vacation patch that works with V8.x sendmail (i.e. non
Sun).
I carefully (so I thought) continued to use our original .cf file and all
is fine except when I restart the daemon and it cannot connect during an
initial queue run. I get the above error.
What do I need to fix/alter/remove to avoid it?
Thanks.
I received 3 replies:
"Karl E. Vogel" <vogelke@c17mis.region2.wpafb.af.mil>
matthew zeier <mrz@3com.com>
Alan I <Chian-Shan.I@East.Sun.COM>
As far as I can see , my original question was not answered but it is a
real bug and not something I'd missed :-)
Thanks.
From: "Karl E. Vogel" <vogelke@c17mis.region2.wpafb.af.mil>
To: Alan.Thew@liverpool.ac.uk
In-reply-to: <Pine.SUN.3.93.971030001110.20089A-100000@mail.liv.ac.uk>
Subject: Re: Q: sendmail: Cannot send message for zero seconds
Organization: Sumaria Systems Inc.
X-Disclaimer: I don't speak for the USAF or Sumaria.
>> On Thu, 30 Oct 1997 00:15:38 +0000 (GMT),
>> Alan Thew <Alan.Thew@liverpool.ac.uk> said:
A> We recently reverted to Sun's V8 sendmail from real V8 (8.6.13) while
A> Sun come out with a vacation patch that works with V8.x sendmail
A> (i.e. non Sun).
That's a very old version of sendmail which has tons of security holes in
it. Your safest bet is to upgrade to sendmail-v8 plus the latest
named/bind release.
The M4 macros in the sendmail source code make it very easy to generate
most sendmail.cf files.
Source code:
ftp://ftp.cs.berkeley.edu/pub/sendmail
ftp://ftp.vix.com/pub/bind/release/4.9.5/bind-4.9.5-REL.tar.gz
Compiled binaries:
http://smc.vnet.net/solaris_2.5_nof.html
From: matthew zeier <mrz@3com.com>
Received: (from mrz@localhost) by nimba.nsd.3com.com (8.8.5/8.8.5)
id JAA12520 for Alan.Thew@liverpool.ac.uk;
Thu, 30 Oct 1997 09:30:34 -0800 (PST)
Message-Id: <199710301730.JAA12520@nimba.nsd.3com.com>
Subject: Re: Q: sendmail: Cannot send message for zero seconds
To: Alan.Thew@liverpool.ac.uk
Date: Thu, 30 Oct 1997 09:30:34 -0800 (PST)
In-Reply-To: <Pine.SUN.3.93.971030001110.20089A-100000@mail.liv.ac.uk> from "Alan Thew" at Oct 30, 97 00:15:38 am
X-Phone: 408/764-8420
X-Pager: 888/602-4131
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
>
> We recently reverted to Sun's V8 sendmail from real V8 (8.6.13) while Sun
> come out with a vacation patch that works with V8.x sendmail (i.e. non
> Sun).
What problem where you having? I've been running UCB Sendmail 8.8.7 on
2.5.1 and 2.6 machines without any problems.
- mz
>
> I carefully (so I thought) continued to use our original .cf file and all
> is fine except when I restart the daemon and it cannot connect during an
> initial queue run. I get the above error.
>
> What do I need to fix/alter/remove to avoid it?
>
> Thanks.
>
> --
> Alan Thew alan.thew@liverpool.ac.uk
> Computing Services,University of Liverpool Fax: +44 151 794-4442
>
From: Alan I <Chian-Shan.I@East.Sun.COM>
Reply-To: Alan I <Chian-Shan.I@East.Sun.COM>
Subject: Re: Q: sendmail: Cannot send message for zero seconds
To: Alan.Thew@liverpool.ac.uk
Message-ID: <libSDtMail.9710292026.9254.alani@opera>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 44sntlwhd7eUBcWloclpUA==
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4m sparc
Hi:
It's a bug when:
Synopsis: sendmail deferred delivery fails if using a non-Sun vendor config file
Description:
If you run sendmail with a V5 config file (or any other config version without
the sun vendor switch enabled) mail deferring will fail with the error:
Cannot send message for zero seconds
This seems to be due to a (my)TimeOuts->to_q_return not being initialised
correctly.
There is some Sun vendor specific code in readcf.c, where :
If ! Sun config, then set TimeOuts.to_q_return to be the value in option T
else initialise u,n and t TimeOuts.to_q_return to the required values.
When it comes to delivering the mail, (envelope.c) always sets
(my)TimeOuts->to_q_return to be one of the u,n or t TimeOuts.to_q_return
values, even if you are not running a Sun vendor config. So these variables are
uninitialised for non sun vendor files and deferring fails.
Here is an example from a host "broon" mailing to a downed host "ale"
# /usr/lib/sendmail -C/etc/mail/sendmail.V5.cf -v ianba@ale </etc/motd
ianba@ale... Connecting to ale.uk.sun.com (ether)...
ianba@ale... Deferred: No route to host
Cannot send message for zero seconds
Saving message in /home/ianba/dead.letter
/home/ianba/dead.letter... Sent
where /etc/mail/sendmail.V5.cf is a V5 config file which has OT set to OT3d
Justification:
Work around:
Use a V1/Sun config file
Suggested fix:
State triggers:
Accepted: yes
Evaluated: yes
Evaluation:
john.beck@Eng 1997-July-09
This will be fixed when we roll to 8.8 .
Commit to fix in releases:
Fixed in releases:
Integrated in releases:
Verified in releases:
Closed because:
Incomplete because:
Duplicate of:
Introduced in Release:
Root cause:
Program management:
Fix affects documentation: no
Exempt from dev rel: no
Fix affects L10N: no
Interest list: mynam@eng
Patch id:
Comments:
john.beck@Eng 1997-July-09
This will be fixed when we roll to 8.8 .
satish.mynam@Eng 1997-10-08
This behaviour also exists in 4.1.x V8 sendmail patch as the source base is
taken from 2.6 sendmail 8.6+. Use the workaround to fix this problem.
Summary:
Deferred delivery fails if using a on sun vendor config file.
Delivery fails with the error:
Cannot send message for zero seconds
john.beck@Eng 1997-July-09
This will be fixed when we roll to 8.8 .
Alan I