Outgoing mail problems

[Julian Field]

It's likely to be load-related. Once the load average reaches a level set
in the sendmail.cf file, sendmail will ignore requests to deliver messages
and will just queue them. MailScanner can cause a very high load figure
(though most of the processes are waiting on network input, so the figure
is misleading) and this can cause sendmail to stop delivering for a while.

Check your sendmail.cf file for the lines
O QueueLA
O RefuseLA
O DelayLA

and the "uptime" command will show your current 1 min, 5 min and 15 minute
load averages. It's the first one that matters to sendmail.

At 22:00 05/12/2002, you wrote:
>OK, I've confirmed that mailscanner scans all the files, and added to
>Mail.pm a line to log how mamny messages it is attempting to deliver
>(via sendmail)
>
>For some reason, one particular file (the largest in a set) will fail to
>be called for delivery by mailscanner, but not always, and not always
>the same file, just the largest.
>
>Is it possible mailscanner is calling for delivery only those files that
>are ready, and missing some that aren't quite, possible still being
>written to disk?  Then it never gets a chance to see that it was done?
>
>On Thu, 2002-12-05 at 16:07, Thomas DuVally wrote:
> > On Thu, 2002-12-05 at 06:48, Julian Field wrote:
> >
> > > MailScanner is not involved in the delivery of mail at all, except for
> > > telling sendmail to try delivering messages it has scanned (when using
> > > "Delivery Method = batch").
> > >
> > > Once the messages are in /var/spool/mqueue, they are sendmail's problem,
> > > not MailScanner's.
> > >
> > >
> >
> > Right, but how are we sure that mailscanner is telling sendmail about
> > them all?  I've been noticing in v4.10-1 that occasionally one or two
> > messages (out of 100) are getting left in the outgoing queue, and they
> > are all local delivery that sendmail has not even attempted yet.  The
> > logs don't show sendmail knowing anything about them.
> >
> > I run a couple of cleanup scripts that will eventually attempt to
> > deliver them, but I think they got forgotten, rather than defered.
> >
> >
> > > --
> > > Julian Field
> > > www.MailScanner.info
> > > MailScanner thanks transtec Computers for their support
> > --
> > Thomas J. DuVally
> > Lead Systems Prog.
> > CIS, Brown Univ.
>--
>Thomas DuVally
>Lead Sys. Prog.
>CIS, Brown Univ.
>401.863.9466

--
Julian Field
www.MailScanner.info
MailScanner thanks transtec Computers for their support