Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!seismo!brl-smoke!smoke!bzs%bostonu.csnet@csnet-relay.arpa From: bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) Newsgroups: net.unix-wizards Subject: Sendmail Bug Message-ID: <893@brl-smoke.ARPA> Date: Thu, 13-Feb-86 11:45:51 EST Article-I.D.: brl-smok.893 Posted: Thu Feb 13 11:45:51 1986 Date-Received: Sun, 16-Feb-86 06:01:33 EST Sender: news@brl-smoke.ARPA Lines: 138 This didn't seem to make it out, sorry if you got it twice. ----- SYSTEM: 4.2bsd PROGRAM: sendmail FILE: usr.lib/sendmail/src/deliver.c PROBLEM: If a forked mailer dies a 'horrible' death (eg. by interrupt) sendmail makes almost no attempt to indicate or analyze the problem. DIAGNOSIS: in endmailer() in deliver.c there is a check: if ((st & 0377) != 0) { syserr("endmailer %s: stat %o", name, st); ExitStat = EX_UNAVAILABLE; return (EX_UNAVAILABLE); } where st is the status returned by wait() (actually, waitfor() which calls wait and returns status.) FIXES: The first problem is that the returned status is printed in octal without any hint of the base. FIX 1: change call to: syserr("endmailer: %s: stat 0%o", name, st); or syserr("endmailer: %s: stat %d", name, st); the latter probably being more sensible as the codes are documented (in sigvec(2)) in decimal, not octal. In either case give us a hint. FIX 2: This fix obviates FIX 1, is a little harder to maintain but probably much closer to what people want. Sending random numeric codes back to the user in the mail message is useless to most users except sendmail wizards with the source code either in hand or in head and similarly for the sigvec(2) manual page. Build a string table of codes mapping to reasonable messages and change syserr() call to use them (generated from the manual page): /* into conf.c */ char *enderr[] = { "IMPOSSIBLE" "hangup" "interrupt" "quit" "illegal instruction" "trace trap" "IOT instruction" "EMT instruction" "floating point exception" "kill" "bus error" "segmentation violation" "bad argument to system call" "write on a pipe with no one to read it" "alarm clock" "software termination signal" "urgent condition present on socket" "stop" "stop signal generated from keyboard" "continue after stop" "child status has changed" "background read attempted from control terminal" "background write attempted to control terminal" "i/o is possible on a descriptor" "cpu time limit exceeded" "file size limit exceeded" "virtual time alarm" "profiling timer alarm" "window changed" } ; /* into conf.h */ extern char *enderr[]; #define MAXENDERR (sizeof(enderr)/sizeof(enderr[0])) Notice that some of these error values are impossible or at least very unlikely ("stop") to come from a mailer but at least they act as place holders and make it easy to regenerate the table if the manual page changes. This table will have to be modified from time to time. Even those error messages leave something to be desired but the likely ones are self-explanatory (see below for MRC's.) Change the syserr call above: From syserr("endmailer %s: stat %o", name, st); To something like: syserr("Sendmail: fatal error from mailer %s: %s",name, ((st < 0) || (st >= MAXENDERR)) ? "Impossible Error?" : enderr[st]); In MRC's case it SIGXFSZ (31(8) == 25(10)) or File Size Limit Exceeded, probably due to a policy on the remote host (note that unless it was an administrative error this is not a temporary condition as it is an upper limit on the largest single file, not the total file quota necessarily, so sendmail rejecting the letter was an appropriate, if not friendly, response, the message was not.) Well, that would make it at least as 'friendly' as MIT-MC when it gets a file that is too large. MC also suggests using FTP which may or may not be appropriate here. Perhaps some energetic person will supply a list of nicely explanatory error messages with built-in suggestions where possible. WARNING: I have not tried this fix but if you understand what is going on it should be trivial to install and check (if you can force an appropriate error on your system.) -Barry Shein, Boston University