Re: [Mailman-Developers] Approach for Post-Throttling
database 1 will be required for counting post on threads, also, whether the threads are same or not will be decided according to the subject header. For a subject header abc we consider the following subjects as the same: Re: abc Fwd: abc abc We will strip the prefixes Re, Fwd off before adding them to database 1. We already have code to do that kind of thing, if not in Mailman 3, in Mailman 2 (pipermail) and in HyperKitty. Make sure you consider existing implementations, possibly including those outside of Mailman if they do a better job. With the help of Richard and Aurelien Bompard, I found a better way to group the threads, Hyperkitty currently use this mechanism to group their threads, we will use In-Reply-To header of the message to determine the thread instead of using subject-header, by this, user will not be able to bypass the throttling system by causing minor changes in the subject. By this, suppose the starting thread is abc and if the user replies to this thread even by using different name in subject like def, then also it will fall under the same thread. To get it done, we will have to decompose the database 1 into 2 parts, One mapping Message_IDs to Threads,we will need to keep one of these records for every message, not just every user/thread as someone may well reply to not the last post by a user. (we can let them expire after a given period of time) 1.user_id | msg_id | thread_id Second the users activity on a given thread, the second thus only needs one record per user-thread) 2.user_id | thread_id | count One way to bypass this system is by composing new mail. This can also be avoided to an extent if we provide limit on the number of new threads one can start on the list. Regards Aanand ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Approach for Post-Throttling
Aanand Shekhar Roy writes: I think you should provide an option to just throttle the user on a given list, too. Possibly with different default throttling parameters. Should I provide an option to combine both of these options into one ? Or an option to use any one of the two throttlings? I haven't thought about that. Anyway, it's your job to do that first, then the mentors will discuss it in terms of their experience and implementation knowledge. I don't see why you would have a separate table for messages. Just add the post_after_time attribute to the message's metadata. Yes, since we will make changes in the msg metadata so now we will not require database 2, OK. database 1 will be required for counting post on threads, also, whether the threads are same or not will be decided according to the subject header. For a subject header abc we consider the following subjects as the same: Re: abc Fwd: abc abc We will strip the prefixes Re, Fwd off before adding them to database 1. We already have code to do that kind of thing, if not in Mailman 3, in Mailman 2 (pipermail) and in HyperKitty. Make sure you consider existing implementations, possibly including those outside of Mailman if they do a better job. Also I had to ask, would it be good if we provide the list-admin with an option to bypass this throttling for some people? Like the mailman-developers in this case, we may allow few mailman developers bypass this throttling effect and those developers will be decided by the list-admin. Don't know. On the developer lists I know of, I would just moderate abusers and be done with it. Non-core people rarely post enough to cause issues. Discussion lists are a little bit different but again in my experience it has never happened that enough people cause problems that a throttle was useful, anyway. Typically when traffic gets too large lists split topically. That doesn't mean that this feature isn't useful, it just means I can't be very helpful in telling you what the uses are. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Approach for Post-Throttling
I think you should provide an option to just throttle the user on a given list, too. Possibly with different default throttling parameters. Should I provide an option to combine both of these options into one ? Or an option to use any one of the two throttlings? I don't see why you would have a separate table for messages. Just add the post_after_time attribute to the message's metadata. Yes, since we will make changes in the msg metadata so now we will not require database 2, database 1 will be required for counting post on threads, also, whether the threads are same or not will be decided according to the subject header. For a subject header abc we consider the following subjects as the same: Re: abc Fwd: abc abc We will strip the prefixes Re, Fwd off before adding them to database 1. Also I had to ask, would it be good if we provide the list-admin with an option to bypass this throttling for some people? Like the mailman-developers in this case, we may allow few mailman developers bypass this throttling effect and those developers will be decided by the list-admin. Regards Aanand ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
