Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 62618 - submit.mc, /var/spool/clientmqueue not flushed
submit.mc, /var/spool/clientmqueue not flushed
Product: Red Hat Public Beta
Classification: Retired
Component: sendmail (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Florian La Roche
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-04-03 00:34 EST by Jay Berkenbilt
Modified: 2007-04-18 12:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-05 17:32:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jay Berkenbilt 2002-04-03 00:34:25 EST
Description of Problem:

This bug report is a little vague at the moment, but I feel compelled to get it
into the system.  I will update it as I have more information.

The basic problem is that sendmail 8.12 has a new way of handling initial mail
submission with a new configuration file called submit.mc.  It seems that the
invocation of sendmail has to be changed for this to work (based on reading
sendmail/SECURITY from the source which I suggest in bug 62617 should be part of
sendmail-doc).  As far as I can tell, the necessary steps have not been taken.

The result is that Bad Things (TM) happen if you send mail while not on the
network and then reconnect.  I often send mail on my laptop when not connected,
then connect and run my queue.  These messages now end up in
/var/spool/clientmqueue rather than /var/spool/mqueue (which is by design) but
that queue appears never to get flushed.

Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:
1. send a mail message while not connected to the network
2. observe the queue files in /var/spool/clientmqueue

Actual Results:

The files stay there indefinitely even after subsequent connect to the network
including subsequent reboots or restarts of sendmail while connected to the network.

Expected Results:

This queue should be flushed periodically.

Additional Information:

Here is an excerpt from sendmail/SECURITY:


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')

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


As far as I can tell, this is not being done anywhere.  Someone should study
this sendmail change and make sure that RedHat's init scripts and configuration
files are suitably adjusted.  If someone else doesn't get to it first and I
figure it out, I'll post.  I've been a sendmail user since the late 80's, have
written many sendmail configurations from scratch, and so consider myself a
sendmail expert.  I will certainly try to suggest a proper resolution of this
problem and post a patch, but it will take me several days before I have time to
look at the problem in depth and didn't want to wait until then to report the
Comment 1 Jay Berkenbilt 2002-04-05 17:32:50 EST
I have observed several more very bad breakages in sendmail 8.12 from skipjack
beta-1, some of which result in total inability to send mail under some
conditions.  However, I see that RedHat has made the wise decision of backing
down to 8.11 in skipjack beta-2.  I am therefore not going to continue to work
on figuring out my sendmail problems.
Comment 2 Florian La Roche 2002-04-07 00:51:53 EST
I am closing since we reverted back to 8.11.6.
A 8.12 one will be on http://people.redhat.com/laroche/


Florian La Roche

Note You need to log in before you can comment on or make changes to this bug.