Mailman-Developers May 2013

mailman-developers@python.org

18 participants
34 discussions

Re: [Mailman-Developers] GSOC Project Discussion

by Stephen J. Turnbull

varun sharma writes: > 1. The mail delivery will be stopped for moderators as well as list > owners. So the moderators should also not receive any "add request > pending" email during the vacation period. Moderators and owners need to have their vacations treated differently from other users, especially for mail forwarded from the -owner alias. ("Hi, this is your friendly ISP. You have 24 hours to fix the backscatter or we will consider you in breach of our AUP and terminate your account.") One possibility would be to switch notifications to "batch" (once a day, once every couple of days) and send them as a digest rather than individually. This might also be a good possibility for users (but the relevant batching period might be longer).

7 years, 10 months

Re: [Mailman-Developers] GSOC Project Discussion

by Richard Wackerbarth

On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw <barry(a)list.org> wrote: > >> On May 13, 2013, at 10:52 PM, varun sharma wrote: >> >> Question: Should you be able to add a vacation stop to moderator or owner >> emails? > > I think the owner or moderators also should be allowed to use the in > vacation suspension of mails from the mailing lists they moderate or own, > given all the administrative tasks that need their attention must be added > to their ToDo queue. > eg: > Lets say there is a mailing list that requires moderator's approval for any > new user to join. If one of the moderator has set "on vacation" for his > account, then he should only get "pending approval request" in his ToDo > task list. If some other moderator responds to that request, then it will > be automatically removed from the ToDo list of all the moderators, > including the one "on the vacation" and the moderator "on vacation" will > never know if there was any request. > > Also there can be email alerts as soon as some task is added to the ToDo > list but if the user is "on vacation" then he will not receive any of these > emails until he disables his "on vacation" flag. All the pending ToDo > tasks/(tasks done in his absence) may be emailed him at once when he comes > back from the vacation. Barry, You have used some phrases that cause me to infer that the -core would have to keep extensive information about moderation requests. For example: "(tasks done in his absence) may be emailed him at once when he comes back from the vacation." I hope that you meant "tasks NOT done". Otherwise, someone would have to maintain a history of the tasks. (Although such an archive would appear to be a task more appropriate for the KittyStore and HyperKitty retrieval mechanisms. Now, since "-core" maintains the queue of pending tasks and is also the agent that sends out emails, do you propose the add an "on demand" type of "digest" for the moderation queue? We might think of this as a rendering of the current task queue in an RFC-822-styled format analogous to the REST request that is delivered in a JSON based format. Presumedly, since this is a "push" notification, the "return from vacation" process could trigger this request. Richard

7 years, 10 months

GSoC discussion

by Manish Gill

Hey guys. This is in response to Richard's email for project discussions. Richard and I have been having discussion regarding how to proceed with the project and he has been very helpful in getting me started with the project. Right now, I'm focusing on the internal data representation of various Resources in the system and how they might translate on an API level. So, for example, in trying to expose `MailingList` objects, as of now, there is no way to post messages to a list externally. Similarly, something to extend the Member model so that privileges make sense on an API level - with Owners and Moderators being able to perform certain actions that are not exposed to regular members, etc. Here is a summary of what we discussed : Discussion regarding data flow: 1. Where is the data for various sources coming from? Where is it going? 2. Where should we provide hooks to extend/modify or perform any number of required operations on that data? 3. What operations should we provide on what type of data? As an example, starting with List and Member resources, as they are now represented in Postorius: List Resources ========= Current Operations on individual lists. - Subscription/Unsubscription - Addition/deletion of various roles in a list, like owner, moderator. - Message moderation (accept, defer, discard, reject) - .settings for various list settings to control the list preferences. What will be useful to have: - Methods to provide filtering based on various criteria. - Member Resources ================ Members are Subscribers to public or non-public lists. As of now, they don't have much anything they can do. - Methods that allow posting of messages. As Wacky noted, User has no need to concern herself how it might be done (could be RESTful, could simply be an internal Email object sent over to the -core) - The API only exposes owners and moderator email addresses. You can't DO anything with them yet. (Say, an owner needs to post an announcement via the API - how might we achieve that via the REST Interface?) Moderators and Owners don't stricly have a 'model' in the API. How might exposing their functionality make sense? Wacky: 1. One way to look at moderators is that it is nothing more than another mailing list (with different policies about subscribing, etc.) 2. Another way is to consider it to be an additional roster of a different class of subscribers. 3. Another way is to treat each subscription as having one or more roles. Similarly, conceptual models for other resources that should be exposed, and how might they be used by clients should be made/extended. Thoughts? Comments?

7 years, 11 months

GSOC Project Discussion

by Stephen J. Turnbull

varun sharma writes: Thanks for the introduction! > In my project "Better user settings management", i need to extend the > Client class of mailman.client and i will be adding a lot of instance > methods and variables to the class. Is this the right approach? What are you adding (some examples will do at this time)? Specifically, there's been a lot of talk about providing extensible user settings *outside* of the core DB. The idea is to provide access to existing enterprise databases (eg, LDAP organization directories) or special-purpose "social networking" databases. How does your idea fit into or deal with this class of extensions?

7 years, 11 months

Re: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface.

by Peter Markou

First things first, I would like to thank you all for this kind of brainstorm. I went through all your replies and I'm about to express my opinion for each of them below: 1) I totally agree with Steve and Richard regarding the split of the Posting functionality from Hyperkitty. After all, DRY is one of the best principles that Django offers and we should conform with it. 2) What Barry proposed seems like an excellent candidate to join the inventory of features, 3) And lastly, the way I approach a new project could use the inventorying possibilities task, since it offers a good way of determining the specifications. Hence, it will give a crystal clear understanding of the application in order to proceed with the design and the implementation. On Wed, May 8, 2013 at 4:13 PM, Peter Markou <markoupetr(a)gmail.com> wrote: > Hello to all the members of the community, > > I've applied a proposal on Melange for the Web Posting Interface. > The major subject of this project, as described in the wiki, is to > allow logged in users to post message from the web interface and > integrate it into the appropriate pages(e.g the hyperkitty archives, > the postorius list settings pages). > > Now regarding Richard's email, "GSoC Applicants". After having a > comprehensive examination in Hyperkitty I found that the functionality > for posting messages through web exists. After having a conversation > with abompard, that was confirmed. I suppose that if I complement this > functionality with some unit tests wouldn't mind(since unit tests are > missing). > So what's left for me is to: > -integrate/implement this functionality in the postorius list settings > pages and > -implement the features that I proposed, in order to make the mailman web > interface usable as a web forum. > > These features are: > - User's filter tools, > - User Profiles(support for name, photo, bio, past posts & files, > statistics about posts) > - Top X Threads Of All-Time, > - Monthly List Health, > - Mentioned in Thread references, > - Keyword-Based Thread Browse(HK has support for tags on threads). > > I would like to ask if someone is going to add any existing information to > User's > profile, so I could leverage this functionality. From mentors-developers > I would > like their opinion/feedback about these features and if they fit to > Mailman's > web interface. > > Best regards, > Peter Markou. >

7 years, 11 months

Re: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project

by Stephen J. Turnbull

Abhilash Raj writes: > Let me divide the project in a few pieces so that each can be > discussed upon separately. This is a good idea, but you should take them up one at a time, unless you have a good approach and are expecting "sounds good, get started" as the reply to that point. > * Firstly a utility to encrypt or decrypt the message. Well i found > [python-gnupg][1] for this purpose and would try to write a wrapper > around it for the use by mailman. But I found another option for it > [GnupgInterface][2]. GnupgInterface was used in the > [mailman-pgp-smime][3] patch for mailman and also has options to sign > and encrypt in one call of a function( unlike python-gnupg ). If > anyone has ever used any of these two would you please suggest which > one is better? This isn't first. Don't be so eager to write code when you have not stated the requirements with any precision. *First* you need to describe the life of a message from a thought in the sender's mind until it hits the receiver's eyes. (It could actually be somewhat shorter than that, but these endpoints ensure you'll get everything we need somewhere in between.) Which steps are required for every message? Which are optional, depending on the list policy and/or user choices? Which are implemented in Mailman? Which in MTAs/MDAs? Which in MUAs? You also need to decide what threats this process is suppose to protect the users from. The combination of these two will determine what Mailman needs to be able to do with incoming and outgoing posts. Then you need to see what Mailman already does perfectly, what needs to be modified, and what needs a new implementation. This description of requirements doesn't need to be as authoritative as Scripture, but we need something fairly detailed to start with. Once that's done, we can talk about implementing crypto operations. But I don't think it matters much which module you start with. (Why not? The answer is a general concept of software engineering.) > * The point of encryption and decryption in the various queues. I was > of the opinion that the message is decrypted as soon as it enters the > IN queue and while its about to leave the queue it is encrypted with a > symmetric key algorithm using the list's secret key. And then it is > subsequently decrypted in the next queue and finally in the OUTGOING > queue it is signed and encrypted with each user's pub-key. > Any suggestions about this? I think the concerns about decrypted material hitting disk are valid. Therefore I would recommend that you avoid decrypting until necessary. (It may not even be necessary. When? What exactly do I mean by "not decrypting"? This requires a good understand of the OpenPGP format, as well as Mailman queue processing. Don't hurry, feel free to ask questions -- as long as they don't amount to "I don't know, tell me"!)

7 years, 11 months

GSoC Project Discussion - Web Posting Interface.

by Stephen J. Turnbull

Peter Markou writes: > Now regarding Richard's email, "GSoC Applicants". After having a > comprehensive examination in Hyperkitty I found that the functionality > for posting messages through web exists. I think it should be split out as a separate Django app, independent of HyperKitty.

7 years, 11 months

Additional GSoC discussion - Better User Settings Management

by Sneha Priscilla

Hi , My GSOC proposal is to do with the project idea - "Better User Settings Management". I too would like to discuss what help or functionality I'm looking for from the rest of the community. 1. More clarity on the interface. Stephen suggested an interface to me in one of his comments on my proposal. I'd like to continue discussing that. 2. REST functionality for the different preferences of the user. 3. Extra profile information: Information such as twitter handles, picture or skype id would be best implemented separately from the rest of the Mailman core. For this purpose, we could use Django User Models to set up a customized user model . If this separation of user info from the core is achieved, I would love to provide an interface to access/modify them. This functionality can also be useful for Systers,if we stick to Postorius while upgrading to Mailman 3. I would like to know more about which of the above is feasible and whether my sole focus should only be on the interface for now. Regards, Sneha Priscilla

7 years, 11 months

Re: [Mailman-Developers] GSoC discussion

by Richard Wackerbarth

On May 8, 2013, at 5:33 PM, Florian Fuchs <flo.fuchs(a)gmail.com> wrote: > 2013/5/7 Manish Gill <mgill25(a)outlook.com>: >> Hey guys. This is in response to Richard's email for project discussions. >> >> Richard and I have been having discussion regarding how to proceed with the >> project and he has been very helpful in getting me started with the project. >> >> Right now, I'm focusing on the internal data representation of various >> Resources in the system and how they might translate on an API level. So, >> for example, in trying to expose `MailingList` objects, as of now, there is no >> way to post messages to a list externally. > > I don't know if posting messages through the API is a priority. I'd > suggest to start with the more fundamental functionality, like > creating domains/lists, list configuration, subscribing and > unsubscribing, adding owners and moderators, moderating subscriptions > and messages. I agree. I have ask that he organize the set of objects that he wishes to present and the interactions between them. For example, "persons", "mailinglists", "configuration parameters", and actions such as "subscribe". "posting a message" might be an action that gets included on the list. However, it first assumes that there is some "message" object and, additionally, some way to have received it. Only when we have established the context will we be able to determine what capability is already present and what might be needed if we were to add or change it. But, the same can be said for "subscribe". Therefore, at this time, I place both of them in the category of "possible interactions" until we have a more complete statement of the system model. > Regarding owners and moderators: It's true that the core's REST API > does not expose them as single models, but as membership records with > a 'role' attribute. How the -core, or postorius, presents something is not the only factor. It is perfectly permissible to have alternate presentations of the same data. The only requirement is that there be a translation to and from the presentation representation and the storage representation. > In Postorius, the permissions that are granted to each of these roles > are static, for example a moderator can moderate messages as well as > subscription requests, but it's currently not possible to create > groups of moderators that can only moderate messages *or* > subscriptions. In theory it would be possible to ignore the roles > given by the core and grant more fine-grained permissions to separate > groups or users. But (at least for now) Postorius does not do that for > various reasons. The "role" model for authorization is quite adequate, even desirable, in a historical sense. However, it should not be the responsibility of the REST interface to DETERMINE the policy. Rather, it should IMPLEMENT a policy, whatever it is, that the system installation provides. Further, there are a number of ways that the policy can be presented. We should not presuppose how it will be accomplished. > There has been some discussion on IRC and elsewhere if the public API > should be implemented as part of Postorius (as the project title on > the ideas page says) or as separate app. My personal opinion is that I > don't have a problem with any of the two options. But I *do* think > that if we provide an "official" admin web ui and and "official" > public facing REST API, both of them should reflect the role system > reflected in the core and both should have the same authorization > logic -- meaning: A list owner/moderator/member in Postorius should be > allowed the same things as a list owner accessing the public REST API. I agree that, unless the system is explicitly installed otherwise, it would be confusing if they are not the same. However, a case can be made for the presence of both a "simplified" version of something (because it is adequate, and less confusing and a more powerful representation (for the "power user") coexisting on the same system. The presence of the "simple" version should not dictate restrictions on every version Richard

7 years, 11 months

Re: [Mailman-Developers] GSoC discussion

by Richard Wackerbarth

7 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers May 2013