[Mimedefang] Bigger MAX_QUEUE_SIZE, why is there a hardcodedlimit ?

[Martin Blapp]

Hi,

> Timeouts, - make the code more resiliant towards DNS, and once a problem is
> identified, deal with it in the code (IE RBL lookups start taking a long
> time (>5s) switch em off for 15 secs (then 30 then 60 till they behave) etc
> <-- you get the idea

Of course we could do that, just take away some tests and let more spam trough.
But that's not the idea.

> Again, Code resilance, to check for said lock and start to throttle based on
> it (451's) rather than overload the box with 60 million locks trying to gain
> a table... (you know what i mean)

Check for a lock while the database is deleting 1000 graylist entries (which 
lasts 5 seconds) ?

> Schedule Maintance to be done offline (difficult with Mysql granted) rather
> than during online periods.

Nope. If we do this the mailservers are offline for 30 minutes or longer.
Thats really no option at all.

> if you end up with > 128 processess concurrent then you are either running
> hotmail, or have code issues that are causing {start} -> {finish} mail
> processing to take wa(aaaaaaaaaaaaaaaaaaa)y to long.

Wrong. We have 30 processes on each box. And yes, we have a large setup.

> Throttle the mail, that's way to gain an advantage.... lesser hardware to
> process more !

Queueing in mimedefang is nothing else than trotteling. Do you see the
point ?

I just said that we have too many situations where the queuing is going up
to 128 mails, and currently I see it going up to 150 processes. Of course
only if a spam-attack is running.

--
Martin