4.2 lost mail (part 2 of 2)

[Chuck Privitera]

Index:	usr.lib/sendmail/src/envelope.c 4.2BSD

Description:
	When delivering queued mail, sendmail incorrectly invokes
	the mailer with the -r or -f (set sender) option, causing
	local mail to be dropped on the floor. Remote mail goes
	O.K.
Repeat-By:
	Force mail to a local user to be queued either by cranking
	the load up over 8, specifying -odq on the command line, or
	adding Odqueue to ~/.mailcf. If you have not installed the
	fix to /bin/mail suggested in the previous article, the local
	user will never get the message, and /usr/spool/mqueue/syslog
	will say that the letter was sent. If you have installed the
	fix to /bin/mail, the mail will be returned with an insufficient
	permission error.
Fix:
	There are actually two (or more?) possible fixes for this.
	The first one (not listed here) is to change /bin/mail's
	-r option to allow the user to specify the from person,
	iff they are a trusted user, or if the  person they are
	trying to become is the same as the person that they are.
	Just as sendmail's -f option is documented to work. This does
	not seem unreasonable, but it does seem more like a kludge
	AROUND the problem instead of a fix FOR the problem.
	(This was the first approach we took here with much
	success, but I had a bit of a guilty concience about
	doing it this way). The real problem is with a check in
	sendmail/envelope.c/setsender(), around line 592, there is a
	permission check that looks like:
		...
		... && getuid() != 0)
			from = NULL;

	I've ommitted the rest of the statement on purpose, because
	of its (documented in the code) questionable security. It
	will also be ommitted in the fix, but there is only one
	check that looks anything like this so ... The check for
	getuid() != 0 is to allow su'ed people to use the -f option to
	sendmail. However, when running the queue, this check
	is false (i.e. getuid() == 0).  The correct test should
	be:
>                   questionable code  && 
>                   (QueueRun || getuid() != 0) )