  	MailServiceSerializer						 
  									 
  	Stores incoming mail at first into spool file, keeps tab on it	 
  	and runs them first come first served fashion never hanging for  
  	long time at system mailer's "local delivery" phase to wait for
	a finish of service and thus forcing mailer to wait.

Full call sequence:

    System mailer global aliases:

	mailservice: "|/path/mailserializer /spool/mailservice.spool uid# gid# error-alias program/path program-args"

    (your mailer might not want to have those quotes, my mailer wants them..)


where:
	/path/mailserializer
		Place of "mailser" binary.
	/spool/mailservice.spool
		queue spool file.  It will get associated files
		/spool/mailservice.spool.pid, and /spool/mailservice.spool.lock,
		which are used at queue interlocking (when link(2) works.)
	uid#, gid#
		Numerical uid, and gid of the target program; often
		these are 0 0, but they allow the real service to be run as
		any uid/gid.   If this server is run from user's  .forward,
		these have no real effect, as  setuid() can succeed only for
		super-user.
	error-alias
		Address where to send possible error messages (via email)
	program/path program-args
		The REAL thing -- whatever service (script/binary) is desired
		to run in strict  one-at-a-time  -fashion.
  									 

Execution of the  "mailser"  is suggested to happen with  root  priviledges,
as then  "uid# gid#" have meaning, but it isn't a catastrophe if it is run
at something else as long as it can write  /spool/mailservice.spool* -files..

If   DAEMON_UID   in the source is set to that one used by system mailer for
processes running from `/etc/aliases'-defined aliases, then (and only then)
this program can be setuid-root.

For running this on anything but latest BSD, SunOS, and SysVs, hack on
the source.

Especially  setsid(2) is known to affect  daemon.c

Multitude of details affect  mailser.c.  Somewhat documented in the
beginning of the source.

910906/mea@nic.funet.fi
931231/mea@nic.funet.fi
