91erm@bigbird.cc.williams.edu (05/03/89)
I just saw a strange begavior on our workstations. Yesterday I switched our 3/50s (Running 4.0, no less) from the old "normal" sendmail (patched against the November worm) to use the mx version of sendmail (also patched against the worm). Everything seemed okay and I didn't see any reason to think twice. Today a user reported that none of his mail to our VMS VAX was being delivered. This struck me as odd so I looked into it. My standard check in the beginning of these things is to run a mail -v and watch the SMTP conversation. So I let it go, and sendmail told me that it couldn't find the host. In fact, due to a few omissions in our named files, it couldn't find any of the hosts it wanted, and therefore couldn't even get a message out to postmaster. I won't go into the details about why the host lookups failed and why the postmaster alias wasn't quite robust enough. I think I've got that fixed. The wierd thing is this: there are *NO* entries in log files of any sort, kind or shape. I have a line like the following the /etc/syslog.conf of all our machines: mail.debug /var/log/maillog and there's no trace of these events in the log. Personally speaking, stats about completed messages are great, but if the logs don't record when sendmail cannot deliver a message (to anyone, postmaster especially), what good are they ?? Can someone with source or close ties to Sun explain this behavior ?? Can you also explain why, when a machine fails to appear in the nameserver, sendmail.mx doesn't consult the YP service for its address ?? If this worked this problem never would have occured in the first place. Thanks for the info. Evan R. Moore Academic Computing Group Williams College 91erm@bigbird.cc.williams.edu 91erm@cc.williams.edu 91erm@cs.williams.edu 91erm@williams.bitnet Now you decide ...
zjat02@uunet.uu.net (Jon A. Tankersley) (05/11/89)
I ran into some problems with the sendmail and ypserv/named that I finally solved. Seems that %y (ypmap) lookup was matching my .uucp connections and NEVER dropping through to the uucp mailer. It was hung trying to mail via SMTP. If you are not getting the message back, it could still be queued for delivery (up til 3 days). Try the following after the mail -v /usr/lib/sendmail -bt -d21.12 > 0 address@to.try .lots of sendmail output.... > ^D See what sendmail is doing. Each line of the ruleset is printed as it executes and is resolved. Pretty verbose and pretty handy. -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */ tank@apctrc.trc.amoco.com ..!uunet!apctrc!tank
jeff@tc.fluke.com (Jeff Stearns) (05/18/89)
In Sun-Spots-Digest: Volume 7, Issue 262, message 11 of 14, 91erm@bigbird.cc.williams.edu writes: > [Excess text deleted .. ] >The wierd thing is this: there are *NO* entries in log files of any sort, >kind or shape. I have a line like the following the /etc/syslog.conf of >all our machines: > >mail.debug /var/log/maillog > >and there's no trace of these events in the log.... Sun broke syslogd when they released SunOS 4.0. It's alleged to be fixed by 4.0.3, due out sometime in June. You can run "syslogd -d" to see more clearly what the problems are. On a Sun-3, syslogd does this: - syslogd thinks that all hostnames match "localhost" - syslogd thinks that it's a great idea to prepend define(LOGHOST,1) to the start of the syslog.conf file when sending it through m4. If you have source, lint will identify the problem. Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064 jeff@tc.fluke.COM {uw-beaver,microsoft,sun}!fluke!jeff PS - Calling all users of the Vitalink TransLAN IV Ethernet bridge! Please drop me a line. alink TransLAN IV Ethernet bridge! Please drop me a line.