Re: [Mailman-Developers] [Queries] Related to List Styles in mailman
hi, The advantage of first is that we will gonna have all the styles at a single place and no need to call for the default page from other places as we will gonna do in the second method. Here but we have to apply the constraints on the default entries and not on other entries. On other hand in second point we will have a unify table with same functionality for all the entries but we have to call the default styles which will be at different place. Thanks, Prakhar Joshi DA-IICT,Gandhinagar On Mon, Mar 16, 2015 at 8:48 AM, Stephen J. Turnbull wrote: > prakhar joshi writes: > > hi, > > I am Prakhar Joshi (irc name :- _pjoshi). I have few things to > discuss > > about the storage of new styles for the list that will be created > through > > rest API. I think we should create a separate table for the list styles > and > > there we can add the entries for the newly created styles in those > tables. > > Now we have to work around for storing these default styles in the > > database. Here what I think is we can do it in 2 ways :- > > 1) We have two default entries in the table and can only have "GET" > > request for these two and "GET"/"POST" request for rest of the entries > in > > the table. > > 2) We can have these 2 default styles out of the table and these 2 > can > > be called as they are now from their places in the web interface > directly. > > What are the advantages and disadvanatages of the two approaches as > far as you are concerned? > > Steve > ___ 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
[Mailman-Developers] Reagarding A "Dashboard for Admins/Owners/Moderators"
Shreyas Lakhe writes: > Ihttps://moqups.com/srlakhe/weZugpFL The "I" is a typo? Note that Activity should be tri-state: approved, rejected, pending. In the case of held messages, there may be more states (each reason for holding mail could be treated as a separate state). ___ 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] GSOC, Anonymous Lists
Pavan Koli writes: (a generally good description of an approach to the problem) > hidden from him. But if someone tries to spam the mailing list, > that person can be caught by noting his anonymous id. I'm not sure what use case you have in mind. Why would a spammer post to the anonymous list from the same address twice? If subscription (and posting) requires owner approval, such spamming is very rare anyway. > 3. I didn't come across a single mailing list for whistleblowers, > activists, or people trading very sensitive information. You won't. They have alternative channels for transmitting information, just like spies employed by governments or corporations. > Mail spoofing attempts can be stopped by encrypting mails, Encrypted lists is a different use case. You'd use digital signatures in this case. > using PGP, but there is one problem. The person encrypting the mail > would have to share their public key with everyone on the mailing > list, which can be a tedious task as the mailing lists keep on > changing in size, Key distribution in this case is easy. Just post it to the mailing list. :-) > and also mails can be leaked if public key falls into wrong hands. This isn't a real use case. Think carefully about your definition of "wrong hands" in the context of "whistleblower". > I've come up with a solution for this, these mailing lists will be > kept in a very different category from others. Here when ever a > user will register, they'll have to also provide their public key. This is in fact the same basic approach as a previous GSoC project which hasn't been integrated yet. > Problem- The list manager has to be authentic, using their public > key list subscribers can verify their authenticity I don't understand what you mean. > (Or I propose a public key for the list itself and then people can > use it to verify lists authenticity). I think this is the right solution anyway. One possibility would be to use DKIM signature technology (RFC 6376, I think). ___ 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
[Mailman-Developers] Gsoc 2015 : A Dashboard for Admins/Owners/Moderators
Heshan Jayasinghe writes: > I am interested on your project "A Dashboard for > Admins/Owners/Moderators".I read your Documentation given about > these projectI want to know the path I should follow to contribute > your company. Start by (re)reading the ideas page, paying specific attention to the (new) section "Mentors Are Not Teachers". Note that there is a lot of competition for this project. (If I'm counting correctly, yours is the 4th inquiry about it.) You will get more attention and are more likely to be accepted into GSoC as you provide more of the planning and design ideas yourself, rather than asking the mentors to do it for you. By the way, a point of English usage: GNU Mailman is not a company (at least in common use in American English). It is a cooperative project by volunteers. ___ 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] Gsoc 2015 : A Dashboard for Admins/Owners/Moderators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Heshan, On Monday 16 March 2015 01:35 AM, Heshan Jayasinghe wrote: > Hi, I am Heshan Jayasinghe.I am 2nd year undergraduate in > University of Moratuwa,Srilanka.I am an Open source developer and i > really like to contribute your company in this GSOC 2015.In my > university i did several android base applications.and noSQL (RDF) > based web applications.i am good at in front end development in > HTML java script and ajax > > I am interested on your project "A Dashboard for > Admins/Owners/Moderators".I read your Documentation given about > these projectI want to know the path I should follow to contribute > your company. > > I am looking forward for your reply We need something more than "I am interested in project X" to reply to. Please read the Ideas Page carefully, you'd find most of the details to getting started there. In case you have questions, you are welcome to post them here. - -- thanks, Abhilash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVBmx7AAoJEJ2bK6Bh0KZ8d9sP/1DqtVTvZKRzvwBSwj2z9acj MVBJz2O7kNRmEq3kiH+p0uXDlGDDWlOC23Is58MnjtCVUX4rZfdr6indSTVrbxVs H6zJ5JftUHv0RXxcS9dPaXLBnhN31pYwsFhuMmouYxQnZ+H0uLblek/AyFgyepa8 U4pqVudADuYXLdT2VICDx7JTnW/WERgwZHso+JiC/wxR/8OjaZ6sXp8U//hUoz49 ziZmUoxkCkCyM8HqbURnJTksttEOP2uuK3ZJXD80benuzAxERerhXYYzB3IaN5EB Suxc5No7OzRZo2o/It8mhROcsapLUipkzawb1AMsuWe87SnZWWRBTCUpSoP2pdBs eLh7jwJTr3twYf+Zn1cADNelerhLFlyce69uGQdi0PLJ2kbtSGFbIFkECZvC4fm5 VruuLN3m2pe84zfj7ygXLJ3xAeaJikgHC4jsYE4H2jqZ+QOm9UweJtAzuLxzckh5 +8y6ipcEFBqWNj/tcoVMvVnHWfcAhkr5/yu2m4bwUmCekeXU2mzbADV3Cn/g1UIe 4MgPyve3IfjHe9kNZA332QYiho0/dZYD86WXWWDfyxRqQOJf2gdJ+e0CEPWmmJm5 ctjXFC8YJSYFPpGMbhTBNvTlLMSISEK0Sx0gGetHq7Ns+13OqA2BwlIXV2/QxJwO 5qkOM0pixZYhUEY+TzNl =aG2t -END PGP 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
[Mailman-Developers] Reagarding A "Dashboard for Admins/Owners/Moderators"
Hi, I have started working on making a more detailed prototype for the "Dashboard for Admins/Owners/Moderators" project and I am thinking about including the following features in the admin interface: 1.General options(modifying list name , info, admins) 2.Password options(change the owners and administrators password) 3.Membership management(subscribe users, unsubscribe users with mass subscription/removal options) 4.Tending to pending moderator requests The above mentioned points could be the base admin interface: To allow the admins to manage multiple lists we could have: 1.add a new list 2.remove a list (1 & 2 would be primary) The other features would be grouped into two categories 1. a common listing of pending messages and requests for lists from the last seven days 2. a list by list listing of the pending messages and requests , wherein the above admin interface would work for individual lists Here is a link implementing some of the features. Ihttps://moqups.com/srlakhe/weZugpFL Suggestions on it are welcome. Thanks, Shreyas Lakhe ___ 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] GSOC, Anonymous Lists
> >I have the same doubt. You need to define "anonymous list". In > particular, specify who is, and who is not, supposed to be able to > >1. See email addresses of subscribers. > >2. Figure out whether two posts are from the same person. > as well whether you need to > >3. Ensure that subscribers' posts can't be spoofed. > These sites already are using anonymous lists http://www.na.org.za/mailing-lists, http://www.12stepforums.net/mailinglist.html, http://www.e-aa.org/maillist.html. >From the above I deduced that there can be three different use cases. 1. The list manager is a doctor, treating their patients. In this case they'll be able to view patients e-mail ids. The e-mail ids will be mapped to something like "anonymous_timestamp@domain". The list manager in this case will have an interface where the anonymous ids will be listed along with the real e-mail ids. This shall help them know whether two posts are from the same patients or not. Also be able to communicate with patients, if time arises.This list can be like an online support group where the list manager is the doctor and the members are his patients. Lists like http://www.12stepforums.net/mailinglist.html, will come under that category. 2. The second use case can be when the list manager himself cannot be trusted with the details, like suppose there is an online mailing list for drug addicts to overcome their addiction, created by an ex-drug addict. But we cannot trust our mail ids with this person, as we don't know clearly his intentions. In this cases where the list manager cannot be trusted fully or the list manager has no use, knowing my email id. Here the list manager won't have any interface mapping anonymous ids with the original ids. But can identify if two mails are by the same user or not by seeing the header- From: anonymous id, on the two mails. Lists like http://ottawana.org/, here members help each other, in such case the list manager has no business knowing e-mail ids of members as he is not offering any help, like the doctor in the previous case, so it would remain hidden from him. But if someone tries to spam the mailing list, that person can be caught by noting his anonymous id. 3. I didn't come across a single mailing list for whistleblowers, activists, or people trading very sensitive information. Suppose there is a group of whistleblowers and journalists, who are connected with this mailing list. Obviously in this case the list manager won't be able to note my real e-mail id, but can verify me using my public key(X.509 certificate), the mails in such cases would be regarding national interests. Hence, there can be hacking attempts on the database or mail spoofing attempts. Hacking attempts can be made futile as the people registering for this mailing list are definitely not going to register with their actual mail ids, hence even if those stored mail ids are exposed. There is very less chance of them getting caught. Sites like (http://www.sendanonymousemail.net/, http://www.33mail.com/, https://www.hushmail.com/) provide anonymous mail id creation. Mail spoofing attempts can be stopped by encrypting mails, using PGP, but there is one problem. The person encrypting the mail would have to share their public key with everyone on the mailing list, which can be a tedious task as the mailing lists keep on changing in size, and also mails can be leaked if public key falls into wrong hands. I've come up with a solution for this, these mailing lists will be kept in a very different category from others. Here when ever a user will register, they'll have to also provide their public key. So now it will work in this way- *User A will encrypt a message using his private key(PGP) and send on the mailing list. *On receiving a message, it will de decrypted by the public key provided from the database. *Now a sessions key will be generated, and it will be encrypted for different users using their public keys. So suppose ABC is a sessions key and user B, user C and user D are there. The sessions key will be encrypted differently for different user using their public key. (Although another way can be used is to encrypt the contents of the message using the public keys of users, so every message will be encrypted differently depending on the users public key. But in this situation there can be a lot of time loss as the time taken would increase with the size of the mailing list, but it can be implemented in cases where security is more important than time, so it'll depend on further details like size of the list) *The message contents will be encrypted using the sessions keys to overcome the time overhead associated as mentioned above. *The users will first decrypt the sessions key using their private keys and use it (session key) for decrypting the original message. This can be thought as a safe method as people trying to spoof the messages won't be able to do anything which is what I suppose. Maintaining a mail archive
[Mailman-Developers] [Queries] Related to List Styles in mailman
prakhar joshi writes: > hi, > I am Prakhar Joshi (irc name :- _pjoshi). I have few things to discuss > about the storage of new styles for the list that will be created through > rest API. I think we should create a separate table for the list styles and > there we can add the entries for the newly created styles in those tables. > Now we have to work around for storing these default styles in the > database. Here what I think is we can do it in 2 ways :- > 1) We have two default entries in the table and can only have "GET" > request for these two and "GET"/"POST" request for rest of the entries in > the table. > 2) We can have these 2 default styles out of the table and these 2 can > be called as they are now from their places in the web interface directly. What are the advantages and disadvanatages of the two approaches as far as you are concerned? Steve ___ 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
[Mailman-Developers] Fwd: GSoC 15
Please *always* include the project you're working on in the subject and again in the text. Shreyas Lakhe writes: > I have started working on making a more detailed prototype and I am > thinking about including the following features in > the admin interface: > > 1.General options(modifying list name , info, admins) > 2.Password options(change the owners and administrators password) > 3.Membership management(subscribe users, unsubscribe users with mass > subscription/removal options) > 4.Tending to pending moderator requests > > The above mentioned points could be the base admin interface: > To allow the admins to manage multiple lists we could have: > 1.add a new list > 2.remove a list > (1 & 2 would be primary) > The other features would be grouped into two categories > 1. a common listing of pending messages and requests for lists from the > last seven days > 2. a list by list listing of the pending messages and requests , wherein > the above admin interface would work for individual lists > > Here is a link implementing some of the features. > Ihttps://moqups.com/srlakhe/weZugpFL ___ 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
[Mailman-Developers] Regarding Subscribe/unsubscribe policy for lists Edit
Ashish Kumar writes: > Hi, > > I have been contributing to mailman since last two weeks. I found this bug > in the list "Subscribe/unsubscribe policy for lists" [ > https://bugs.launchpad.net/postorius/+bug/1095552]. > > Can someone please tell me what's the current status of this bug and how > may I help in fixing it. The status is whatever is posted to the bug. The people who are following the bug may be working on it but most likely are hoping to hear somebody is fixing it. If you're interested in working on it tell us what you propose to do to fix it (even if at the moment that's limited to "studying postorius code", which you should already have checked out ;-). Steve ___ 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
[Mailman-Developers] Regarding Subscriber profile pages project
Ashish, Aside from Abhilash's advice (to which +1), you should also look into the Syster's implementation (IIRC it lives in github/systers somewhere) of Mailman, which already implements a similar feature. You can ask (politely! you're a guest there) on systers-...@systers.org (you may need to subscribe) or on Freenode IRC #systers-dev or #systers-soc. ___ 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
[Mailman-Developers] GSOC 2015: Seeking Information
Nakul Gulati writes: > After reading about mailman and going through the code base and > scope of different ideas, my interest align with the project > *Mailman Client written in Javascript* in particular. Hence, I'd > like to pursue it as part of GSOC 2015. Sounds good to me. See http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt for hints on how to write a proposal. > I would like to discuss further about the project. There's nothing to discuss until you tell us what you think needs to be done. See Mentors Are Not Teachers on the wiki (which I just wrote and posted): http://wiki.list.org/DEV/Google_Summer_of_Code_2015 ___ 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
[Mailman-Developers] GSOC - Dashboard for Admins/Owners/Moderators
Yash Mehrotra writes: > *My Ideas - * > 1. One issue currently as mentioned is owners of multiple lists have to go > through all the pages for changes. I think we should show all the mailing > list's requests,subscriptions etc. all in one page. This isn't a dashboard-level issue; this should be a facility at the core level -- the core knows which lists the user is responsible for, and what the pending tasks are for each. Are you sure Mailman 3 + Postorius doesn't have this capability already? > 2. The new list features should be opened from a different tab as a list > admin doesnt do this every day. > > *The primary focus should be - to make it easy for an admin to do his daily > activities.* I agree with the general statement, but are the new list operations really a problem if displayed on the main dashboard? > 3. So, the index page will contain stuff mentioned on point 1, and the > there will be different pages for other stuff like - create/delete > list, view statistics ( see next point) My experience with a non-web-based moderation system is that most moderation/subscription requests can be judged from a one-line display, and for more complex operations (eg, banning an apparently abusive would-be subscriber) use Web 2.0 tech like Javascript popup menus. Of course they have to degrade gracefully if JS is disabled, and even if CSS is disabled. But the main interface probably can include list creation/deletion and a few interesting stats. > 4. We can also provide some basic statistics for a mailing list > like which user is most active, how many avg, mails are sent in a > day etc. I don't understand why this belongs specifically on an admin dashboard. In most cases subscribers probably care more about it than admins do. > 5. We also also give each list its individual page, so the admin > can do list specific functions like, say change settings , That's an ancient interface, and doesn't really come up to the expectations people have when they hear "dashboard". All your pending tasks (including those you initiate like list creation) should be available conveniently as soon as you log in, and as much as possible which features are available should not depend on the currently. > ban user etc. This will almost certainly turn out to be horrible UI. Experience shows that banning a user based on an abuse detected during moderation or subscription approval, and so it should be available without leaving the dashboard. > 6. One more cool feature would be to color code different types of things > for visual ease. Eg. Subscription requests can be color A. Held messages > can be color B. and so on. This will not only help the administrator but > also would visually good to look at. Maybe. On the other hand, maybe users will prefer to have the tasks grouped (a group for subscription requests, a group for moderation, a group for admin-initiated actions like list creation if permitted, etc). Maybe color coding will "look nice", but IMHO it's unlikely to be a big efficiency enhancement compared to grouping. > I will add more stuff based on your feedback. Sorry, that's not the way this works. Part of GSoC to determine requirements. You tell us what you plan to do, we decide whether we like it better than somebody else's proposal. Most likely, if you seem to have overestimated your productivity we'll tell you you can cut back your proposal, and where to cut. But if you propose something trivial, mostly you'll get the simple comment "this is not enough to be a good GSoC project." A dashboard that gives convenient access to all tasks a user is assigned seems like a GSoC-sized project to me (maybe bigger). The main thing you need to add is a schedule. See also http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt. ___ 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
[Mailman-Developers] Gsoc 2015 : A Dashboard for Admins/Owners/Moderators
Hi, I am Heshan Jayasinghe.I am 2nd year undergraduate in University of Moratuwa,Srilanka.I am an Open source developer and i really like to contribute your company in this GSOC 2015.In my university i did several android base applications.and noSQL (RDF) based web applications.i am good at in front end development in HTML java script and ajax I am interested on your project "A Dashboard for Admins/Owners/Moderators".I read your Documentation given about these projectI want to know the path I should follow to contribute your company. I am looking forward for your reply regards, Heshan Jayasinghe. ___ 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
[Mailman-Developers] [Queries] Related to List Styles in mailman
hi, I am Prakhar Joshi (irc name :- _pjoshi). I have few things to discuss about the storage of new styles for the list that will be created through rest API. I think we should create a separate table for the list styles and there we can add the entries for the newly created styles in those tables. Now we have to work around for storing these default styles in the database. Here what I think is we can do it in 2 ways :- 1) We have two default entries in the table and can only have "GET" request for these two and "GET"/"POST" request for rest of the entries in the table. 2) We can have these 2 default styles out of the table and these 2 can be called as they are now from their places in the web interface directly. I will really need to discuss these things. Any new suggestions are also welcome. Thanks, Prakhar Joshi DA-IICT,Gandhinagar ___ 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
[Mailman-Developers] Some bare minimums for submitting patches (GSoC students take note)
A quick note for GSoC students, although this can apply to anyone submitting merge proposals to the core. You really need to run the test suite before submitting your branch. If the test suite fails, I am going to mark your branch 'needs fixing' and move on. Of course, ideally your branch would include any tests needed to illustrate the problem too. If there are no tests, then it's a red flag to me that maybe the fix doesn't actually fix the problem. One technique I use when looking at your branch is to unapply the fix and just run your tests. If I see a failure, that's a *good* thing because I then expect to reapply your fix to see the failure go away. This is just an extension of test driven development (TDD) of which I'm a fan. As we say, "untested code is broken code". Cheers, -Barry pgpekIRRK3AVf.pgp 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
Re: [Mailman-Developers] full anonymisation approach
Rashi Karanpuria writes: > > Sorry, I forgot to add the footnotes for the previous mail on this thread. > > footnotes: > [1] http://counseling.caltech.edu/general/InfoandResources/Shyness > [2] The Internet: Biographies (google books) OK, Thanks. I've been going through mail in order due to connectivity problems. Didn't see this before the last message. All cool on the references! ___ 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] full anonymisation approach
Rashi Karanpuria writes: > > 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. I'm not overlooking the possibility, and if you want to use the word "fact" you should cite serious research (or reliable textbooks that cite the serious research). Psychology (especially clinical) is a field that's rife with real crap (see Kahnemann _Thinking Fast and Slow_ for an introduction). For GSoC purposes, I'm willing to assume that there are benefits for the use case you describe. What you're overlooking is that you use words like "anonymous" and "conversation" without specifying them properly. Is an "anonymous" mailing anonymous enough for the users? How about the FUD effect if there is a public incident where a stalker manages to identify a victim through your anonymous list implementation? The design of your implementation is going to depend sensitively on the answers you give to these questions. > 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 OK. Remember that identifying threads is inaccurate. I wonder if it would be useful to have a feature where a user could change her ID, or link an old ID to a current one. (That's not a requirement for this product, but IMHO you should consider the possibility with designing modules/internal APIs.) > 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 I disagree. You should use both. The RFC for References does not specify which, if any, References are to be kept, but most implementations keep all, most of the others I've seen keep the most recent. If any are kept, they help verify the members of the predecessor set, even if the order can't be fully relied on. > > 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. I don't understand what you mean by "posting address is a fake address." > The originator can use one of the many available anonymous mailer > services for personal anonymous mails. You absolutely cannot rely on originators to be clueful about this (in fact, isn't that your original motivation: the obvious answer is "if you want to be anonymous on a list, use an anonymizer service"). ___ 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
