Open micah opened 6 years ago
@ikedas - the change is for 6.1.22, and would not apply to 6.2.32. We are having some trouble understanding what needs to be done to make it work for 6.2.32, otherwise we would have submitted a MR.
Hi @micah,
I rethought of this issue, and realized Sympa may have max_list_members
parameter for each list. Is it useful for you?
A couple times now we've had a list admin subscribe tens of thousands of people without their permission and then send mail to the list. Then a bunch of those people reply saying "please remove me" and their replies go to the list because the list is configured to allow that. This is an amusing, and annoying situation, but it actually snowballs and totally takes out the listserver.
It would be helpful if we could have a feature for lists over a certain size that prohibits them from sending to types that allow anybody or member posting.
We did implement a certain version of this feature in 6.1.22 (https://github.com/evoltech/sympa/blob/sympa-6.1.22-GH/6.1.22/patches/08_2821_max_list_dispatch.patch). The point of this patch was to put limits in place for how large of a message they were allowed to send; two limits, one for admin one for subscribers.
To implement this feature two new config directives were added: max_list_dispatch, and max_list_dispatch_from_subscriber. max_list_dispatch will set the the maximum list size that can have messages sent to it even if moderated or sent from a owner/editor. max_list_dispatch_from_subscriber will set the maximum list size that can have messages sent to it from list subscribers (unless the subscriber is a list owner/editor). Messages sent to a list on a robot whose subscriber count is greater then the limit will have the message placed in the moderate queue. A list editor can dispatch messages that have been placed in the queue so long as the number of subscribers in the list is less then max_list_dispatch (or not defined).
However, this patch will no longer apply to 6.2.32, and it makes more sense for the broader sympa community to benefit from this, so I wanted to submit this bug.
We did spend some time trying to figure out how to port this patch to 6.2.32, and came out with this evaluation:
but did not figure out enough of what needs to be done to make it work. Perhaps there is a better method to do this that sympa devs would rather implement?