The issue is that you want your smtpd to run as some non-root
user. When it pipes to some user program, you want it to run as
the owner of that program (or at least configure it that way),
so that user hooks cannot do anything except to their own files.

Having procmail be setuid was one (bad) way of dealing with this.

=head1 uid/gid issues

Apache suEXEC http://httpd.apache.org/docs/suexec.html
   Apache license. "suexec -V" as root indicates its hard-coded compiled-in options. this includes a mandatory doc root
CGIWrap http://cgiwrap.unixtools.org/ http://sourceforge.net/projects/cgiwrap
    GPL C. many many compile-time options
sudo http://www.courtesan.com/sudo/  http://www.sudo.ws/sudo/
    ISC license. put the mail server in sudoers, so it can impersonate the target user

mailman has a fixed set of groups that it wants its wrapper run as.
this can be changed by 'configure --with-mail-gid=mail'
    (one part of mailman is compiled C: /var/mailman/mail/mailman) which is setgid
    --with-groupname=${MM_GROUPNAME}
    --with-mail-gid=${MAIL_GID}
    --with-cgi-gid=${CGI_GID}

  "In order to get Postfix to deliver the message to Mailman using
   the correct GID, you have to set the permissions correctly on the
   Mailman alias file. When Postfix makes a normal local delivery,
   it assumes the identity of the recipient of the message. In the
   case of an alias, Postfix assumes the identity of the owner of the
   alias file. (Unless the owner is root, in which case Postfix uses
   the identity specified in its default_privs parameter.) Make sure
   that the alias file is owned by the mailman user and that the
   mailman user has the mailman GID as its primary group.  Postfix
   will then use the mailman group when it delivers a message to the
   Mailman system."

postfix runs cgis with the owner/group of the aliases file that it uses.
and it supports multiple alias files.

If you are piping to some program that insist on being run with some uid/gid, can use "sudo".
For example, if /etc/sudoers contains: 
   smtpd             ALL = (mailman) NOPASSWD: /var/mailman/mail/mailman
then user smtpd (what we are running as) will be allow to execute:
   sudo -u mailman /var/mailman/mail/mailman [rest of args]
without any password prompt.

Another approach instead of sudo is to take advantage of procmail being setuid:
http://sourceforge.net/tracker/index.php?func=detail&aid=723918&group_id=103&atid=300103

"|/usr/local/bin/procmail -m ACTION=post LISTNAME=listname /usr/local/etc/procmail/mailman"
Where /usr/local/etc/procmail/mailman contains:
----
VERBOSE=1
LOGFILE=/var/log/procmailman.log
LOGABSTRACT=1
LOCKFI/var/run/procmail/mailman1.lock

INCLUDERC=/usr/local/etc/procmail/tag
INCLUDERC=/usr/local/etc/procmail/tag-contents
INCLUDERC=/usr/local/etc/procmail/passthrough

# Deliver spam mail

:0 H :
* $ ^$trash_header
* ! ^$ok_header
/dev/null

:0 : /var/run/procmail/mailman2.lock
|/usr/local/mailman/mail/mailman $ACTION $LISTNAME
-----

although procmail is not as commonly shipped setuid root now.

tcpserver
ipsvd http://smarden.org/ipsvd/
    bsd-licensed
    same problem as tcpserver

qmail-lspawn is run as root, and runs qmail-local as appropriate uid for program or other delivery in .forward.
[qmail-lspawn and qmail-start are run as run; qmail-queue is run setuid root]

postfix has a "mailbox_command" in main.cf. it and ~user/.forward are run with user credentials

in many cases, the command may itself rely no shell features, so that we then have to fork yet again....