Sendmail ignoring MinQueueAge after MailScanner upgrade?

[Paul A Sand]

Hi --

I recently upgraded MailScanner to version 4.55.10 from version 4.54.6.
All seemed to go OK, but I soon noticed a dramatic increase in sendmail
processes on the servers. (All running RHEL 4, Sendmail 8.13.1)

Background: the servers typically have 500-1000 entries in their
"outgoing" mail queue, most of them deferred messages either due to (a)
over-quota local users; (b) unresponsive external servers.

Previously, deferred messages would wait at least 4 hours between delivery
attempts. ('O MinQueueAge=4h' in /etc/mail/sendmail.cf). But now,
post-upgrade, this setting seems to be ignored. Each sendmail process
running through the queue seems to attempt to deliver any message it sees,
no matter how little time has gone since the last delivery attempt.

So the result is (typically) 600-700 concurrent sendmail processes,
where previously we'd see 70-80. And a LOT of failed delivery attempts,
all dutifully logged in some impressively-sized logfiles. (About 5x
bigger post-upgrade.)

Fortunately, normal mail seems to flow OK. But I'd prefer not to
have sendmail chatter like this.

I've searched the MailScanner list archives with nothing popping out at
me. Worse, I don't even understand how the upgrade could have caused
this behavior, since MailScanner's involvement in the outgoing queue
seems to be limited to starting up the initial sendmail queue-runner
in exactly the same way it did before, and (of course) putting scanned
messages in there, just like it did before.

I have tried specifying MinQueueAge directly in the MailScanner
startup script, so the command line now looks like

    /usr/sbin/sendmail -q15m -OMinQueueAge=4h \
       -OPidFile=/var/run/sendmail.out.pid

... but that didn't change the behavior.

I am using 

    Lock Type = posix

in /etc/MailScanner/MailScanner.conf, if that matters.

If I run the queue by hand:

    sendmail -q -v

... it dutifully tells me that it's passing over too-young
queue entries. But that doesn't seem to be happening with the
normal queue processors.

I am prepared to have list members point out my idiotic mistake, because
I'm pretty much out of ideas on this end.

-- 
-- Paul A. Sand                 | Personifiers unite!
-- University of New Hampshire  | You have nothing to lose but Mr. Dignity!
-- pas at unh.edu                  | 
-- http://pubpages.unh.edu/~pas |