> Aside: I think if you actually use such a list you'll discover that > most "shy" people are far more afraid of being flamed than they are of > social stigma *outside* of the discussion thread. OTOH, it is likely > to bring out the worst in trolls. IMHO YMMV etc. We can't overlook the fact here that shy people and most of the others facing one social stigma or other do benefit from anonymous conversations and 12-step program lays focus on such websites. Though one of the many ill-effects is that some people may get dependent on the virtual society totally avoiding confrontation from the real one as referenced in [1]. Second ill effect is that internet anonymity is more vulnerable to abuses as people don't hold any responsibility of their behaviour in such a system. Hence, internet anonymity is a double edged sword (reference [2]). The shortcomings are considerably significant but we can't overlook the advantages of using anonymity to treat such cases as the research suggests. > > > In my opinion the requirements are: > > 1) Keeping list members anonymous from each other. > > OK, that follows from the above motivation. However, do you want the > list identity to be consistent within threads, or will you assign a > new list identity to a poster address for each post? Do you want list > identity to be consistent across threads, or will you assign a new > list identity to a poster address each time they first post to a new > thread?
I plan on keeping list identity of a poster constant in a thread, i.e., I generate a new list identity for a first post to a new thread. Reasons of this were mentioned by me in http://www.mail-archive.com/mailman-developers%40python.org/msg15283.html > If identity is consistent within threads but not across > threads, how do you determine that two posts are in different threads? > For example, if post B points to post A in the References field, but > the subject was changed in a significant way (ie, other than listrivia > prefixes, Re: and friends, and whitespace changes that occasionally > creep in due to mishandling of folding whitespace), are they in > different threads? I had been following this topic on discussions list by Aanand Shekhar Roy and had also read about it online as I had realised that grouping messages in threads is a trivial necessity for my implementation. Hence we will not be relying on the subject header of a mail because of the problems you have mentioned. So, we will be using the In-Reply-To header of the mail to map the messages to their respective threads. Hence tweaking with subject will not be treated as a new thread as long as the user is using Reply-To feature, which is essential while conversating in a thread. Also using references won't be reliable as after the length of thread becomes large few entries from the references are dropped > > 2) Not allowing any way out for revealing any one's identity except > > if the user chooses to reveal it himself. > > That's not a reasonable requirement. It is often possible to deduce > an author's identity from their choice of argument or writing style, > or their employer's automatically added footer. You could argue that > message content is a user choice, but I don't think many users would > be happy with that point of view. > > I think you want to limit yourself to stuff that MUAs and MTAs put in > the headers, including but not limited to originator addresses, > display names, and comments. Speaking of "originator", what do you > propose to do about non-subscribers who are CC'd? > We can remove the CC and BCC fields as if sent to a non-subscriber using CC the original id of the originator will be displayed and if a subscriber is CC'd then the mail bounces as posting address is a fake address. The originator can use one of the many available anonymous mailer services for personal anonymous mails. > You might also propose removing standard signatures (ie, everything > after a string matching "\n-- \n"). > > Removing other footers is much more chancy, but you could try to catch > them. > Yes, we can modify all footers and signatures in handlers. > I'm not sure that requirements 1) - 3) are a good fit for several of > your use cases, but these requirements seem like a reasonable start. I'll try to improvise on this part. Regards Rashi _______________________________________________ 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
