Worms and fixing blame

[Lars J Poulsen]

> Date: Sat, 19 Nov 88 21:34:34 PST
> From: brian at ucsd.edu (Brian Kantor)
> Message-Id: <8811200534.AA20838 at ucsd.edu>
> To: lars at 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