From: e07@nikhefh.nikhef.nl (Eric Wassenaar)
Newsgroups: comp.mail.sendmail,comp.sys.hp
Subject: Lost mail because of SIGTERM from window system
Date: 13 Dec 92 15:56:18 GMT
Organization: Nikhef-H, Amsterdam (the Netherlands).

Summary:
	Some window systems send a SIGTERM signal to an entire
	process group when a window is deleted. Some mail user
	agents do not wait() for the sendmail child to exit.
	This causes mail to be lost, and leftover garbage queue
	files. To be more robust, sendmail should establish its
	own process group.

Problem description:
	If one uses the HP-VUE mailtool window (with elm as user
	agent) under HP-UX 8.07 on a HP700 series machine to send
	mail, the mail may not be delivered, and garbage df*, qf*,
	or tf* files may be left in /usr/spool/mqueue.

Repeat-By:
	Pop up a mailtool window, send some mail, and when elm
	says "Mail sent!" delete the window.

Analysis:
	The HP-VUE mailtool uses a probably old version of elm
	as the user agent. If you click the window, use elm to
	compose and send the mail, the mail is handed over to
	sendmail, but elm does not wait for the forked sendmail
	process to terminate. Immediately elm says "Mail sent!".
	If you then drop the window, a SIGTERM signal is sent to
	the process group, which includes the sendmail process
	still busy building the queue files before delivery is
	being attempted. sendmail catches the signal, removes
	the lf* and xf* files, leaves everything else (in a still
	undefined state), and quits.

	(It could be that elm really wants to wait() for sendmail,
	but uses 'wait3(&st, WNOHANG, (struct rusage *)&rusage)'
	which fails with EINVAL under HP-UX. However, this seems
	unlikely. Probably elm does not wait() at all).

Fix:
	The following workaround is possible: let sendmail establish
	its own process group, by inserting the following code

		(void) setpgrp(0, getpid());

	at the point where it has figured out that it has to send
	mail, i.e. in main.c before the code fragment
		initsys();
		setsender(from);

Comments:
	I see no harm in making this a standard sendmail behaviour.
	There are other mail user agents which do not wait() either.
	sendmail thus protects itself against such mailers and
	hostile window systems, and becomes more robust.

	I do believe that mailers should wait(). Usually, sendmail
	is configured such that after the setup phase of accepting
	the message, constructing the headers, and building the queue
	files, it forks again to perform the actual delivery.
	By wait()ing for the completion of the initial sendmail child,
	the user agent can be sure that the setup phase is finished.

	When sendmail forks for delivery, the subchild disconnects,
	but remains part of the process group. A SIGTERM to this
	subchild would also be highly undesirable, but would not be
	destructive, since the df* and qf* files are properly set up,
	and delivery would be resumed during the next queue run.
	Establishing a separate process group in the initial sendmail
	child also protects the subchild against unwanted signals.

	On HP-UX, if you don't link with -lBSD, and on other XPG3 based
	platforms, you need to use setpgid() instead of setpgrp().

Eric Wassenaar
-- 
Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 592 5012, Home: +31 20 6909449, Telefax: +31 20 592 5155
Internet: e07@nikhef.nl