*BSD News Article 18660


Return to BSD News archive

Xref: sserve comp.mail.sendmail:8041 comp.unix.bsd:12298
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!howland.reston.ans.net!agate!CS.Berkeley.EDU!eric
From: eric@CS.Berkeley.EDU (Eric Allman)
Newsgroups: comp.mail.sendmail,comp.unix.bsd
Subject: Re: SunOS 4.0 sendmail won't accept end-of-message
Date: 20 Jul 1993 16:57:23 GMT
Organization: UC Berkeley Mammoth Project
Lines: 33
Sender: eric@mastodon.CS.Berkeley.EDU (Eric Allman)
Distribution: world
Message-ID: <22h85j$757@agate.berkeley.edu>
References: <22e6rgINNqtv@kralizec.zeta.org.au> <22gqffINN59j@kralizec.zeta.org.au>
Reply-To: eric@CS.Berkeley.EDU
NNTP-Posting-Host: mastodon.cs.berkeley.edu

In article <22gqffINN59j@kralizec.zeta.org.au>, nick@kralizec.zeta.org.au (Nick Andrew) writes:
|> There is a configuration option 'Oi' with the semantics "Ignore dots in
|> incoming messages" and that option was turned ON in my configuration file.
|> 
|> So much for the "well-known bug". It's my fault. I expected that option
|> would allow sendmail to pass incoming (stdin, not SMTP) mail directly
|> without the "." business.

A reasonable expectation -- it really is a sendmail bug (fixed, of
course, in 8.x).

|> >I am now "porting" 5.67 to SunOS 4.0 however Sun's resolver library
|> >seems to have fewer functions than Sendmail 5.67 expects ... and so I
|> >just got the appropriate BSD lib.tar.Z and include.tar.Z via Ftp.
|> 
|> I compiled and linked them. There are many #ifdefs throughout the resolver
|> functions about which I don't have a clue. I defined only VMUNIX ... can
|> anybody help here? The others are (from a quick scan...) DBM, NDBM, LOG,
|> EXAMPLE_CODE (?), SETPROCTITLE, WNOHANG, DAEMON, NAMED_BIND, SMTP, HOSTINFO,
|> UGLYUUCP (darn right!), QUEUE, NO_WILDCARD_MX, SCANF and SMTPDEBUG.

These are sendmail ifdefs, not resolver ifdefs, and they should all
be described in conf.h.

|> When I run the new Sendmail it is able to function in a limited manner.
|> One problem is that when I connect to it, it takes 3+ minutes to display
|> the "220 Sendmail ... ready at ..." message. Another is that startup
|> processing (reading the .cf file) takes some minutes.

Sounds like the resolver timing out -- I suggest using nslookup as
a simpler interface until you are sure you have BIND working.

eric