On Sunday 08 March 2015 09:50 AM, Aanand Shekhar Roy wrote: >> One concern here is that "Thread" is a fragile term in email. Unless you >> are planning on some form of message body analysis to group messages >> together, you are going to need to rely on the In-Reply-To and >> References headers of the incoming email, which can have its >> difficulties. If you are going to thread by something else, like the >> subject, you may find people making minor changes in the subject to >> bypass the moderation. > > Yes, I agree ,but having a system that curbs this problem will not again > be a very good solution, for eg. A thread regarding discussion on mailman2 > can have the name of the thread "Mailman 2", and for mailman3, the thread > will be named as "Mailman 3". Now ,it can also appear that someone has > made a minor change to avoid moderation but it is not so.
Yes, exactly! So what do you think would be a solution to the problem Richard mentioned? You cannot simply say that we are are not going to use any such system since there are drawbacks of it. We need a clear definition of what you mean by a "thread". What type of message would be a part of a thread and which all would be not? Is this kind of auto moderation system just based on subject lines and headers even reliable? I would ask you to dig through standards and implementations in MUAs about how threads are actually created. And then answer the questions above. >> First, these headers are optional, and some mail agents may not generate >> them, and more importantly, the subscriber can bypass this linking by >> creating a reply as a "new message" thus bypassing the auto moderation. > > Since I wish to implement this system as a plug-in it will be optional for > the list admins and having an MTA that generates headers can be kept as a > requirement. It isn't a good idea to impose a restriction on MTA to use a plugin. Even this very email of yours was not listed under the same thread in my MUA (thunderbird) for some reason I don't know. >> Second, there is an unreliability in these headers as they will not >> necessarily reference the "start" of the thread, but may only list >> messages later in the thread, and to get your "Thread Name", you are >> going to have to keep a full history (for some period back) of messages >> and what thread you determined them to be in to figure out what thread >> this message is in. > > What we can do is to remove general keywords like "Re:[ ]" and "Fwd:[ ]" > from the thread and then add to the database, so we don't need to store > all the history, just information about last one does the job, we check > that through Table1. How do you know where does the thread started from the information in your table? >> This means that any system that ties to limit the rate "in thread" must >> also have a similar (but perhaps different value) limit on total >> postings or creation of new threads. > > We do not aim at limiting threads or posts on a thread we are just slowing > it down to provide room to other users. If we decrease no of posts on a > thread it might affect the discussion going on as some threads are very > long and also important and can't be shortened. I don't understand the use case of "slowing" down the delivery of emails at all. Why would someone want his email to be sent to the list a later time? What does "provide room to other users" mean in this context? How is one person sending a lot of mails stop others from doing the same? -- thanks, Abhilash
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
