lars@salt.acc.com (Lars J Poulsen) (11/22/88)
> Date: Sat, 19 Nov 88 21:34:34 PST > From: brian@ucsd.edu (Brian Kantor) > Message-Id: <8811200534.AA20838@ucsd.edu> > To: lars@ACC-SB-UNIX.ARPA > Subject: The problem with DEBUG (was: Worms and fixing blame) > > DEBUG in sendmail is invaluable for troubleshooting mail problems; > I use it quite often. Having DEBUG able to invoke a shell is > inexcusable. Do not make the same mistake so many have in asserting > that DEBUG is the problem, when it is the shell invocation that > really is. Turning off the debug command was just a convenient > quick hack to stop the shell problem, and as soon as you've patched > out the shell invocation, you can probably re-enable debug. > - Brian Brian, I agree that it is valuable to have trace and debug features for troubleshooting. Almost every tool needs one, and with the enormous complexity of sendmail, it needs more than most. I would even be tolerant of a debug feature that would let you spawn a shell (though it probably should do password validation). What I take VIOLENT exception to, is' that the feature is (1) undocumented. The "Sendmail Installation and Operation Guide" mentions the "-d" command line flag, and says that this causes sendmail to print out information. I have found no mention of The "debug" and "showq" commands anywhere in the documentation set. (2) turned on by default. I would allow for a complete and suicidal test feature so long as it needed to bve turned on by a command line argument which was not normally turned on in the rc.local file as distributed. (And if the feature that it enabled was undocumented, how about making the command line option just as undocumented). In my opinion, the Ultrix team did the right thing, and SUN should have done the same. If this causes a strong distaste for commercial software supplied in binary form, it will be understandable. / Lars