Path: utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!luth!sunic!nuug!ulrik!ulrik.uio.no!obh
From: obh@ulrik.uio.no (Ole Bj|rn Hessen)
Newsgroups: comp.mail.sendmail
Subject: Re: No '250 Ok' sendmail problem
Message-ID: <1990Jul3.004438.24697@ulrik.uio.no>
Date: 3 Jul 90 00:44:38 GMT
References: <39824@mips.mips.COM>
Sender: news@ulrik.uio.no (USENET News System)
Reply-To: obh@ulrik.uio.no (Ole Bj|rn Hessen)
Organization: University of Oslo, Norway
Lines: 28

In article <39824@mips.mips.COM>, koblas@mips.COM (David Koblas) writes:
|> I'm looking for ideas, sudgestions, or solutions...  The problem that
|> I'm having is that sendmail very nicely delivers a mail message
|> but then does not receive an '250 Ok' message after it sends the
|> '.' for the DATA.  After some quick checking the problem very clearly
|> is that in reply() -> sfgets() -> fgets() does not pick up the final
|> line from the message.

Some versions of sendmail do a setbuf(InChannel, (char *)NULL) in
main.c (smtp-mode) and later tries to do ungetc on InChannel. On some
OS (Ultrix) this fails. Excerpt from the fine manual (Sun's):

     One character of pushback is guaranteed  provided  something
     has  been  read  from  the stream and the stream is actually
     buffered.

Don't think you're bitten by this bug, but anyway, people
running old sendmails should check this out. grep for ungetc
in collect.c, if you find anything, upgrade to 5.64 [or you
should do a setlinebuf in main.c].

Ole Bjorn.

[Ps: Sun's manual continues:
                In the case that stream is stdin,  one  character
     may  be  pushed back onto the buffer without a previous read
     statement.
Why do Sun (and probably other) differ between stdio and other streams?].