Greg Moeller <[EMAIL PROTECTED]> wrote:
> > Greg Moeller <[EMAIL PROTECTED]> wrote:
> > > Is there any way to discard any Email the mailer daemon generates?
> >
> > No easy, built-in way, but then again, you shouldn't need it. queue
> > management in qmail is completely automatic.
>
> > Your system is misconfigured. What split value are you using? What
> > filesystem on what operating system? What kind of disk/array is the queue
> > on? If your system bogs down because of the number of (basically
> > inactive) messages in the queue, you've configured your system with values
> > which are inappropriate for the load you're trying to serve.
> The system is dual processor Sparc 450, and an A1000 storage array. Qmail
> is running stock standard, as Dan intended. :) The queue was running on
> it's own bit of the array, multi spindle, mirrored. I've since moved it to
> /tmp, performance has gotten much nicer since then, almost a system crash
> will eat it. (see below for why I don't really care) Also, a large spam hit
> might eat the machine's RAM/swap(which I care about a bit more) (512 Meg of
> RAM, 256 of spool) The system delivers locally about 250,000 Email/day.
You didn't explicitly answer my question about conf-split, but by "stock
standard", I'll assume it's the default of 23. This is probably too low for
your system -- if you have five or ten thousand bounce messages sitting in the
queue, you're getting lots of files in each directory. This is likely what
causes your mail system to "bog down" when there's a bunch of bounce messages
waiting in the queue. On a properly configured system, messages which are
just sitting in the queue waiting for their next delivery attempt won't have
much effect on qmail's performance.
> > qmail's default queuelifetime is 7 days. You can lower it to whatever you
> > want. However, reducing it too far will cause mail to bounce which would
> > otherwise be delivered successfully.
>
> The only deliveries this server does is local, which I hope wouldn't take
> more than a few seconds, anything in the queue for remote delivery is a
> bounce. (which is why I don't care if the queue is lost, since all I lose
> is bounces)
Once your system accepts a message from the internet, and issues a 2xx code in
response to the DATA command of the SMTP conversation, you have agreed to do
one of the following things:
-deliver the message successfully to its final destination
-return a bounce message to the envelope sender stating why delivery
failed
If you're discarding bounces, you're violating these conditions. That's
unacceptable to many/most mail admins.
Instead of trying to fix the symptoms (mail system bogs down when lots of
inactive messages in the queue, most of which are bounces which have been
deferred), why not fix the problem (inappropriate setup of MTA)?
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
