Jeroen Geilman:
> On 06/04/2013 02:20 PM, Erwan David wrote:
> > On Tue, Jun 04, 2013 at 01:44:46PM CEST, Tom Hendrikx <t...@whyscream.net>
> > said:
> >> On 06/04/2013 01:22 PM, Antonio Guti?rrez Mayoral wrote:
> >>> Hi Wietse,
> >>>
> >>> Yes, its a solution, but these emails should be delivered in
> >>> bussines-time :-(
> >>> (it doesnt matter if it takes 2 hours... but in bussiness time...)
> >>>
> >>> thank you so much!
> >>>
> >> You could run a script as a cronjob that queues x messages when the
> >> active queue contains (100 minus x) messages (where 100 is an arbitrary
> >> number). This means that all mails on HOLD trickle out as quick as
> >> possible, while not overloading the active queue...
> > It means when the queue has 100 messages, you stop sending anything ?
> >
>
> You could check the headers for identifying features (maybe the list ID,
> or a subject part, or...whatever works), and instantly DEFER them.
>
> This will put all messages in the deferred queue, guaranteeing they
> won't choke incoming: if the deferred queue is not empty, one message
> will be taken from incoming and deferred, in turn.
Currently the queue manager can group recipients into jobs when
they share the same queue file, and uses that to prevent a limited
number of many-recipient messages from blocking later email
with fewer recipients.
The fix would be to group recipients into jobs based on the sender
attribute (or size, or whatever) and apply similar logic to prevent
a limited messages from one sender from blocking later email from
other senders (or or to prevent large messages from blocking later
messages that are smaller in size).
However if one sender manages to saturate the queue then it will
take time before other email gets a chance to be scheduled.
Wietse
