[comp.mail.sendmail] Sun's new sendmail

msir@uhura.cc.rochester.edu (Mark Sirota) (02/07/90)

I have grabbed Sun's latest sendmail binary from UUNET and have a question
or two about its behavior.  I'm using sendmail.mx.sun[34].

In /var/adm/messages, I'm getting errors like the following:
	gethostbyaddr: Princeton.EDU != 128.112.129.117
My observation is that princeton.edu has more than one IP address, and my
guess is that the one my nameserver returns isn't the one that princeton.edu
is giving back.  The messages don't hang around, though, so they are
apparently getting through eventually.  My guess is that the top-level
nameservers aren't in line for some period of time, and then later get
updated and agree with each other.  Could this be the case, or is this a
more serious problem?  I get several of these messages each day with a
variety of hosts, but all have at least two IP addresses.

The other new behavior is that I get messages like:
	SYSERR: rewrite: cannot prescan canonical hostname: 
With no hostname following it...  Any ideas?  Should I be concerned about
these?  This happens a couple of times per day also.  The messages for which
this happens stick around in the queue, with lock files still existing, so
I'm sure there's really something wrong on this one.
-- 
Mark Sirota - University of Rochester, Rochester, NY
 Internet: msir@cc.rochester.edu
 Bitnet:   msir@uordbv.bitnet
 UUCP:     {decvax,harvard,ames,rutgers}!rochester!ur-cc!msir

ault@its.rpi.edu (Jim Ault) (02/07/90)

We have been running Sun's new sendmail.mx (4.0.3) for some time now
(5 or 6 months) without problem.  Just last week I installed the
latest sendmail.mx.sun3 from uunet on our mail gateway, after reading
the CERT advisory.  This week, we began encountering some very strange
sendmail behavior.  It was spawning new processes and creating null
queue files almost one per second, and our machine almost ground to a
halt.   Worse yet, I backed out the uunet sendmail binary, and went
back to the 4.0.3 binary, and the condition continues!  Is anyone else
experiencing similar problems with the new sendmail.mx.sun3 from uunet
(~ftp/sun-fixes)? 

I have also compiled sendmail.5.61 from berkeley on our Sun3, but with
very unpredictable and undesirable results.  I tried using it also,
but the same thing happened.

Any help would be most appreciated. 
Please reply by email to ault@pawl.rpi.edu, or
aultj@turing.cs.rpi.edu.  Or by phone (518) 276-2750.

-- 
---Jim Ault, ITS Postmaster, Rensselaer Polytechnic Inst, Troy NY, 12180
   Postmaster@mts.rpi.edu   post@pawl.rpi.edu   Postmast@rpitsmts.BITNET
   518-276-2750 (vox)   ...uunet!pawl.rpi.edu!post    518-276-2809 (fax)

emv@math.lsa.umich.edu (Edward Vielmetti) (02/13/90)

In article <5093@ur-cc.UUCP> msir@uhura.cc.rochester.edu (Mark Sirota) writes:

   The other new behavior is that I get messages like:
	   SYSERR: rewrite: cannot prescan canonical hostname: 
   With no hostname following it...  Any ideas?  Should I be concerned about
   these?  This happens a couple of times per day also.  The messages for which
   this happens stick around in the queue, with lock files still existing, so
   I'm sure there's really something wrong on this one.

As far as I can tell this happens when a host puts its CNAME name and not
a name with an A or MX record into the SMTP FROM header.  In one case
this little exchanged caused sendmail to core dump (Sun 4/260, SunOS 4.0.3,
sendmail.mx from uunet).

Be liberal in what you accept, I guess, but not in this case.

--Ed