We've currently got sendmail version 8.11.6 in the tree.  It works,
but it's getting a little out of date.  The sendmail 8.12.x series has
been available for a while, had a few bugs shaken out, and seems like
a good place to go.

:: THE OVERVIEW ::

The main benefit is that the 8.12.x series offers the ability for
sendmail to be installed as a *non-setuid root* binary; instead, it
will be *setgid to a new group called smmsp*.  This is a good step
forwards in terms of security.  There are a few issues, however.

(1) When sendmail is collecting mail from a user, it looks for a
submit.cf file in /etc/mail.  If it finds one, it reads it, and stuffs
the mail that it collects into the queue named therein (the queue
directory is group writeable, but not readable by "other").  I shall
refer to this queue as the "client queue".  Once it has finished
accepting it, it tries to relay it to the SMTP server listening on
127.0.0.1:25 for actual delivery.  This means that most "outbound"
mail will appear in your log file twice.  Typically, the main sendmail
listener (that also runs the main queue), the optional "client queue
runner", and any sendmail instances that collect mail from users will
all use different tags in their log entries, though, so the actions of
each can easily be differentiated.  For example:

Jun 11 17:13:59 noc sendmail[13737]: g5BLDxG8013737: from=andrew, size=29, class=0, nrcpts=1, msgid=<200206112113.g5BLDxG8013737@noc.untraceable.net>, relay=andrew@localhost
Jun 11 17:14:00 noc sm-mta[13738]: g5BLDx5l013738: from=<andrew@noc.untraceable.net>, size=339, class=0, nrcpts=1, msgid=<200206112113.g5BLDxG8013737@noc.untraceable.net>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Jun 11 17:14:00 noc sendmail[13737]: g5BLDxG8013737: to=andrew@echonyc.com, ctladdr=andrew (204/20), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30024, relay=localhost.untraceable.net. [127.0.0.1], dsn=2.0.0, stat=Sent (g5BLDx5l013738 Message accepted for delivery)
Jun 11 17:14:00 noc sm-mta[13740]: g5BLDx5l013738: to=<andrew@echonyc.com>, ctladdr=<andrew@noc.untraceable.net> (204/20), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30334, relay=echonyc.com. [198.67.15.2], dsn=2.0.0, stat=Sent (g5BLE0h16651 Message accepted for delivery)

Note that the "mta" process calls itself "sm-mta", and the collection
process calls itself "sendmail".

(2) Since sendmail is no longer setuid to root, the mailq command will
no longer function for non-root users if they can't read your main
queue directory.  Non-root users also can no longer cause the queue
(or queues) to be flushed.

(3) The sendmail -bv and -bt operating modes (probably not commonly
used) will also not function as well (or at all) for non-root users.
The -bt and -bv modes are different address testing modes.  When run
with -bt, sendmail presents the user with a prompt and the user can
pass various addresses to various rewriting rulesets to check the
results.  The -bv option causes sendmail to run the recipient
addresses given on the command line through all the appropriate
rulesets and emit the final delivery "tuples".  They require access to
maps and other lookup methods that may be unavailable to non-root
users.

(4) Since the default action for sendmail becomes "deliver to the
local relay", the out-of-the-box sendmail configuration will no longer
be able to "just work", since it requires that there be an active
listener (ie, a proper SMTP server listening on port 25 on the
loopback interface).  On the plus side, the mail will just accumulate
in the client queue until it is flushed.  It won't just disappear, and
it won't result in masses of messages getting syslogged as repeated
tries are made to hand off the message to another process.

(5) The client queue (the queue into which locally collected messages
are first placed by the setgid sendmail process) isn't flushed by
anyone by default, and requires that the admin start a "client queue
runner" for that queue specifically, or periodically (eg, from cron)
start a "one time queue runner" to clean it out.  This means that if
sendmail is invoked with the -odq flag (sets delivery mode to
queue-only), it will leave queue files in the "client queue" for an
indeterminate period of time.

Issues (1) through (3) seem, to me, to be "admin issues" rather than
"user issues".  the average user is not, I think, going to be mucking
with those features unless the average user is also root.  Issues (4)
and (5) are a bit of a bother, but not terrible.

:: THE DETAILS ::

(1) There's a new uid and gid for this, both called smmsp (which
stands for SendMail Message Submission Program, I believe).  They are
both used by during message collection as the TrustedUser and the
RunAsUser.

(2) There's a new queue directory called /var/spool/clientmqueue.  it
will be owned by user smmsp, group smmsp, with no permissions for
other.  NOTE: the mail queue directory is called, by default,
/var/spool/mqueue, and I would also like to alter the permissions on
this to be read/write/execute for root, and nothing for group or
other.

(3) The sendmail binary will be owned by root and setgid to smmsp (so
that it can write to the client queue directory).

(4) A new config file exists in /etc/mail called submit.cf.  It's
relatively trivial and the default file that we'll be including ought
to suffice for *everyone*.  The sample that ships with sendmail 8.12.4
is, effectively, 5 lines of m4 and is not platform dependent in any
way.

This stuff can all be checked in /etc/postinstall and in
/etc/rc.d/sendmail.  I'm whipping those bits of code up now.

:: THE OPTIONS ::

(1) For those that really want to run sendmail as a setuid root
program, you can.  All you have to do is remove the submit.cf file and
change the mode on the sendmail binary.  Both.  Not just one or the
other.

(2) sendmail is currently, via rc.conf and friends, either on or off.
This would have to be augmented by another variable that indicated
whether the admin wanted a client queue runner lurking in the
background.  Perhaps something called "sendmail_clientq" (defaulting
to NO).  I'm not good with names sometimes.  Perhaps it ought to
default to something "sensible" based on the environment?

(3) For those who wish to continue to use a setuid root sendmail,
perhaps a third variable called sendmail_suidroot (also defaulting to
NO) should be added?

(4) The start up script rc.d will be checking:

  (a) The version of the cf file (this will be version 10 cf file)

  (b) The value of sendmail_suidroot (if we go this route) such that

	YES implies that the sendmail binary must be suid root and
		the submit.cf file must not exist
	NO implies that the sendmail binary must be sgid smmsp,
		the submit.cf file must exist
		the client queue directory must exist
		the client queue directory must have the proper permissions

  any deviation would result in sendmail not starting.

(4) The new postinstall script would be checking (and potentially)
fixing these upgrade issues.

(5) Should the client queue runner be started at the same time as
sendmail, from the same script, or should it start from a separate
script?

Ideally.  Any comments?  Questions?  Concerns?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."