[Mimedefang] Mimedefang errors: What might be the cause?

[Kris Deugau]

David F. Skoll wrote:

> Kris Deugau wrote:
> 
> 
>>define(`confQUEUE_LA', `2')dnl
>>define(`confREFUSE_LA', `7')dnl
> 
> 
> Bad settings.
> 
> Having REFUSE_LA higher than QUEUE_LA is a surefire way to kill your server.
> Most busy SMTP servers are I/O bound, and running in queue-only mode does
> nothing to reduce your I/O load.  In fact, it *increases* it because the
> messages will need to be pulled from the queue at some point in the future.
> See "Sendmail Performance Tuning" by Nick Christenson.
> 
> If you're running Linux, and those settings work well from you, your
> mail server is *not* busy! :-)

*shrug*  It's not as heavily loaded as it was at one point;  most of the 
real "load" was peaky;  and accepting and queuing mail was the better 
tradeoff than refusing outbound mail connections from customers.  :/  (I 
*did* try it the other way around for a while, but refusing connections 
first causes phone calls asking why $customer can't send email.)  Every 
so often the load spikes to ~12 or so - usually late at night when the 
only mail showing up is inbound mail^Wspam to hosted domains.

It's an all-in-one domain hosting box, so other processes affected mail 
processing too.

On another system I had them set to queue at 1 and refuse at 8, IIRC; 
for a time it was accepting relay mail from a qmail box that kept 
opening *hordes* of parallel connections.  It suffered from the same 
problem with customer's outbound mail, along with complaints about 
delayed *inbound* mail.  Queuing the mail meant that, on the whole, mail 
got delivered faster.  Addition of RBL checks on the qmail system has 
dropped the number of relayed messages by ~80% or so.  (All spam.)

Ah, legacy systems.  <g>  Both are to be retired, neither is 
misbehaving, and the load on each slowly drops as customers cancel their 
service.

-kgd