We're runnging a mailman server with a lot of lists. Today somebody sent quite a large mail (attachment) to a newly created list with 14.000 recipients.
This caused all other mail via Mailman to be more or less stalled. Is there a way of assigning priorities to lists, like giving all lists "normal" priority and large lists "low" priority?
OTOH sending small mails to large lists is ok, so maybe the product of "size_of_mail" and "number_of_list_recipients" could be used to adjust the priority accordingly....
-- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebrandt@charite.de Campus Benjamin Franklin https://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
On 10/18/18 1:01 AM, Ralf Hildebrandt wrote:
This caused all other mail via Mailman to be more or less stalled. Is there a way of assigning priorities to lists, like giving all lists "normal" priority and large lists "low" priority?
OTOH sending small mails to large lists is ok, so maybe the product of "size_of_mail" and "number_of_list_recipients" could be used to adjust the priority accordingly....
The architecture of both Mailman 2.1 and Mailman 3 doesn't really allow for this to be done too easily. Messages are queued for delivery in a FIFO queue for the outgoing runner(s). Slicing the queue space into multiple ranges for multiple runners doesn't solve the problem as other messages in the range with the "big" message will still have to wait.
What could be done is to create multiple outgoing queues, say normal_out and big_out and then have separate instances of the outgoing runner processing the two queues. Then the handler that queues outgoing messages could decide which queue based on whatever criteria are desired.
This wouldn't make the "big" message wait until after the normal messages were all processed, but the "big" message would be processed by a separate process and the normal messages wouldn't have to wait for it to complete.
I don't think it would be too difficult to implement this, but my advice would be to use content filtering and maximum message size to prevent the problem which could have been easily avoided in this case by making the attachment web accessible and including only a link in the post.
Note that if your list owners don't understand the importance of maximum message size, there is for Mailman 2.1 an example handler that implements a global maximum at <https://www.msapiro.net/scripts/GlobalTooBig.py>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
- Mark Sapiro <mark@msapiro.net>:
On 10/18/18 1:01 AM, Ralf Hildebrandt wrote:
This caused all other mail via Mailman to be more or less stalled. Is there a way of assigning priorities to lists, like giving all lists "normal" priority and large lists "low" priority?
OTOH sending small mails to large lists is ok, so maybe the product of "size_of_mail" and "number_of_list_recipients" could be used to adjust the priority accordingly....
The architecture of both Mailman 2.1 and Mailman 3 doesn't really allow for this to be done too easily. Messages are queued for delivery in a FIFO queue for the outgoing runner(s). Slicing the queue space into multiple ranges for multiple runners doesn't solve the problem as other messages in the range with the "big" message will still have to wait.
Yeah, exactly what I encountered.
What could be done is to create multiple outgoing queues, say normal_out and big_out and then have separate instances of the outgoing runner processing the two queues. Then the handler that queues outgoing messages could decide which queue based on whatever criteria are desired.
This wouldn't make the "big" message wait until after the normal messages were all processed, but the "big" message would be processed by a separate process and the normal messages wouldn't have to wait for it to complete.
That's something!
I don't think it would be too difficult to implement this, but my advice would be to use content filtering and maximum message size to prevent the problem which could have been easily avoided in this case by making the attachment web accessible and including only a link in the post.
Yes, *I* would have done this (especially since this allows to change the PDF AFTER it had been sent...)
Note that if your list owners don't understand the importance of maximum message size, there is for Mailman 2.1 an example handler that implements a global maximum at <https://www.msapiro.net/scripts/GlobalTooBig.py>.
Will look at this.
-- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebrandt@charite.de Campus Benjamin Franklin https://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
participants (2)
-
Mark Sapiro -
Ralf Hildebrandt