Bugzilla Bug 13836

With the new mail submission program feature sendmail looks up submit.cf for
sendmail mail when invoked from command line or by a program on the local
machine. Mails submitted by the msp if deferred are placed in the msp queue
located in /var/spool/clientmqueue. In /etc/init.d/sendmail a msp queue cleaning
daemon should be started.

example:

sendmail -Ac -q30m -L sendmail-msp

-q30m is already being passed to the starting of sendmail.
If you have a cron daemon running then sendmail will do it's queue flushing properly.

sendmail -bd -q30m flush only /var/spool/mqueue

an additional instance is needed for flushing /var/spool/clientmqueue.


From sendmail/SECURITY:

The daemon must be started by root as usual, e.g.,

/PATH/TO/sendmail -L sm-mta -bd -q1h

(replace /PATH/TO with the right path for your OS, e.g.,
/usr/sbin or /usr/lib).

Notice: if you run sendmail from inetd (which in general is not a
good idea), you must specify -Am in addition to -bs.

Mail will end up in the client queue if the daemon doesn't accept
connections or if an address is temporarily not resolvable.  The
latter problem can be minimized by using

	FEATURE(`nocanonify', `canonify_hosts')
	define(`confDIRECT_SUBMISSION_MODIFIERS', `C')

which, however, may have undesired side effects.  See cf/README for
a discussion.  In general it is necessary to clean the queue either
via a cronjob or by running a daemon, e.g.,

/PATH/TO/sendmail -L sm-msp-queue -Ac -q30m

*** Bug 13951 has been marked as a duplicate of this bug. ***

The ebuild in portage has been updated with your suggestions. Log messages are
marked as sm-mta and sm-cm for the individual daemons.

This fix is now detrimental to recent versions of sendmail. The two daemons
will step on each others' toes.

I commented out the clientqueue copy of the daemon in /etc/init.d/sendmail and
problems with empty messages/open failures went away. The single daemon is
flushing both queues (mqueue & clientmqueue).

That's not true, /var/spool/clientmqueue still needs a separate flushing
daemon. This is confirmed from the documentation and a simple test with 'lsof'
(also there is a logic in this behaviour).  Could you please post your
sendmail.mc? Maybe you got a non-standard configuration.  Also exactly what
kind of problems were you experiencing?