From spammazz at gmail.com Thu May 2 16:03:52 2013 From: spammazz at gmail.com (Spamm Azz) Date: Thu, 2 May 2013 16:03:52 +0200 Subject: [Mailman-Developers] Email body customization for each recipient Message-ID: I wrote a function in C language that customizes an email body. My target is to integrate this function inside mailman 3 to customize the email for each recipient. To manage an input email is possible inserting an handler, but I don't know how to do the same for an outgoing message. Thanks in advance. From stephen at xemacs.org Thu May 2 17:55:09 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 03 May 2013 00:55:09 +0900 Subject: [Mailman-Developers] Email body customization for each recipient In-Reply-To: References: Message-ID: <877gjhtm02.fsf@uwakimon.sk.tsukuba.ac.jp> Spamm Azz writes: > I wrote a function in C language that customizes an email body. > My target is to integrate this function inside mailman 3 to customize the > email for each recipient. > To manage an input email is possible inserting an handler, but I don't know > how to do the same for an outgoing message. Dunno off-hand (and my time has to be focused elsewhere for a couple weeks) but you can find what you need by looking for code and comments that mentions "personalization" or variations of that word. "Personalization" is the term used in Mailman 2 for messages that have different content for each recipient. I'm quite sure that it's used in Mailman 3, too. :-) Steve From barry at list.org Thu May 2 21:32:10 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 2 May 2013 12:32:10 -0700 Subject: [Mailman-Developers] Email body customization for each recipient In-Reply-To: References: Message-ID: <20130502123210.4cebbb99@anarchist> On May 02, 2013, at 04:03 PM, Spamm Azz wrote: >I wrote a function in C language that customizes an email body. My target is >to integrate this function inside mailman 3 to customize the email for each >recipient. To manage an input email is possible inserting an handler, but I >don't know how to do the same for an outgoing message. You'll first have to expose your C function to Python. You can do this by writing an extension module or by providing shell access to your function. That's out of scope for this discussion. Once you've made your function callable from Python, you'll want to implement an IMailTransportAgentDelivery class that implements a deliver() method that calls your C function. Then in your mailman.cfg, set the [mta]output variale to point to your implementation of that interface. Take a look at src/mailman/mta/deliver.py for how VERP delivery is done. There may be opportunities to provide better extensibility of this basic functionality without having to rewrite it all. Please provide feedback. Cheers, -Barry From spammazz at gmail.com Fri May 3 14:37:39 2013 From: spammazz at gmail.com (Spamm Azz) Date: Fri, 3 May 2013 14:37:39 +0200 Subject: [Mailman-Developers] Email body customization for each recipient In-Reply-To: <20130502123210.4cebbb99@anarchist> References: <20130502123210.4cebbb99@anarchist> Message-ID: Thanks for the help. I'm following the Barry's solution. In my maiman.cfg I have the [mta]outgoing variable, I suppose you was referring to this variable. calls your C function. Then in your mailman.cfg, set the [mta]output > variale > to point to your implementation of that interface. > I'll post news when available. From rkw at dataplex.net Sat May 4 22:41:50 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Sat, 4 May 2013 15:41:50 -0500 Subject: [Mailman-Developers] GSoC Applicants Message-ID: Calling all GSoC applicants -- You have all looked at the current state of MM and made proposals to improve it. Now it is time to discuss what YOU need others to provide so that your contribution fits into the "whole" without your having to implement everything yourself. Let's discuss what you would like from the mentor-developers and, as a "class" how your contributions would complement each other. You can start up the discussion on IRC #mailman or on this mailing list. Let's hear from you. Richard "Wacky" Wackerbarth From raj.abhilash1 at gmail.com Sun May 5 14:23:15 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sun, 5 May 2013 17:53:15 +0530 Subject: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project Message-ID: Hello all, In response to Richard's mail these are the rough bits of what I will be needing from my mentor if I am selected: 1) I need to discuss about the design of the idea that I want to implement. I know the rough bits but need help and comments on what I proposed. This would require views from the whole mailman-community. 2) Apart from the corner cases mentioned in the proposal there might be many other not caught in my eye. I would need them to be pointed out so that a solution of it can discussed and then implemented. 3) There is a lot of cryptography in this project, so I would need a more experienced view to find and remove the security loopholes. 4) Lastly since I am still a noob in programming I would need regular review on the code for the first 2-3 weeks so that I cam improve and write bug free production code. -- Abhilash Raj From rkw at dataplex.net Sun May 5 16:37:54 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Sun, 5 May 2013 09:37:54 -0500 Subject: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project In-Reply-To: References: Message-ID: <1CEF7626-1B78-48A1-BF55-F2DC3C86003F@dataplex.net> Abhilash, Thanks for responding promptly and publicly. You, and the others should expect the discussions you mention without including them in response to my question. The discussion with your mentor is "given" -- That's one of the main responsibilities of a mentor. You may need to initiate community discussion about parts of your design to assure that your design meets the community expectations. But let me take your project as an example of the kind of input that I am seeking. You propose to use public key crypto in the processing stream of mail messages. In order to do so, you will need to associate the appropriate key with the corresponding user. You will also need to have some configuration parameters that describe the list policy and handling of the encryption. Now, I suggest that you need, but might reasonably expect someone else to provide, the following: 1) A framework for storing the keys and handling the association of the key with a particular user. This same framework would be used to associate other methods of identification and authentication with the users. You would be expected to implement the parts that are specific to public key. 2) A mechanism to display and edit parameters that describe the list policy as it refers to encryption. Again, as above, you would specify the parameters and provide the handlers that implement the policies, but you can expect someone else to handle the GUI presentation that turn them on and off, or otherwise configure them. I won't claim that the items that I suggest above are sufficient, or perhaps even necessary, but they can be used as examples for the kind of input that I am encouraging all of the applicants to discuss. There are other applicants who have proposed to develop, for example, GUI components. They should "step up" and declare that their proposed work will provide . Thus, we can observe that the projects complement each other. I hope to see this discussion continue. As for "mentor review" of your design. Let me point out that you do not have to be accepted by GSoC in order to contribute to MM development. I know that I, and I believe the other mentors, as well as other members of the community, would be quite willing to discuss "design" with anyone who wishes to help improve the overall system. That discussion can start at any time. We don't need to wait for the GSoC positions to be announced. Again, thanks for your participation. Richard On May 5, 2013, at 7:23 AM, Abhilash Raj wrote: > In response to Richard's mail these are the rough bits of what I will be needing from my mentor if I am selected: > > 1) I need to discuss > Abhilash Raj From stephen at xemacs.org Sun May 5 18:30:10 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 06 May 2013 01:30:10 +0900 Subject: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project In-Reply-To: References: Message-ID: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> Abhilash Raj writes: > 1) I need to discuss about the design of the idea that I want to > implement. I know the rough bits but need help and comments on > what I proposed. This would require views from the whole > mailman-community. This is place for that, not private consultation with the mentor. Just start spelling out your ideas, and post them here for comment as they're developed to the point you can get useful comment. And don't worry about whether you are doing it right: just do it. Sooner is better. One reason for this approach is that as Google sees GSoC, one purpose is encouraging the student to develop his or her relationship with the community.[1] The best case is somebody who enters with several months of presence on the developer lists (but that is in no way required, it's more an "it would be nice if" example). We actually would like have the proposals posted here, but unfortunately that tends to interfere with evaluation for several reasons. (One important one is that often several students propose similar projects, and if the proposals are public there's a very natural tendency for them to converge, making selection nearly impossible.) Now that we have the proposals in full, we'd like you to start engaging the community by posting your ideas, designs, and questions here. It's probably best *not* to post big chunks of your proposal. Maybe the "short description" as an introduction, but after that you should pick a particular task and get the community to help you start on it. > 2) Apart from the corner cases mentioned in the proposal there might be > many other not caught in my eye. I would need them to be pointed out so > that a solution of it can discussed and then implemented. > > 3) There is a lot of cryptography in this project, so I would need a more > experienced view to find and remove the security loopholes. These are more specific to your topic, but they are also best done on this list, especially the issues related to security. The advantage of the mentor system is that you have somebody who has to look at your stuff. Still, the best way is to get comments from a broad selection of developers and users. > 4) Lastly since I am still a noob in programming I would need regular > review on the code for the first 2-3 weeks so that I cam improve > and write bug free production code. Well, the first thing to learn is that nobody writes bug-free code. Anticipate that your code is going to be buggy, catch as many as you can systematically (I recommend Watts Humphrey's book "Introduction to the Personal Software Process", I'm sure other mentors have their favorites). Then get reviews from others (including but not limited to your mentor(s)). Once again, what we are looking for (Richard posted as representative of the mentor team) is discussion of your plans: the pieces of the design puzzle, of course, but also your motivation for proposing the project, and your plans for advancing it. I emphasize what Richard has already mentioned: this is not a test where you have to do everything yourself to get points. You will be evaluated on the functionality you present to us at the midterm and final evaluations, not on whether you wrote all the code yourself. Some of the code you can borrow from existing modules, and some you can beg from others. Your mentors are going to be working on their own projects, and schedules can be adjusted to provide pieces of the puzzle you need sooner rather than later. Other experienced developers may be willing to help out. In some cases you can get parts of what you need from other students in GSoC (but this requires delicate negotiation and careful management by the mentors involved; we'll cross that bridge if we come to it). The rest of the code you have to write, and there's a minimum (a substantial size, at that) we'll be expecting. But the more code you can get from elsewhere, the better the product you'll produce this summer! Footnotes: [1] The others, of course, are financial support for a student getting practical experience in software development, concentrating on coding, and development of worthwhile software for the mentoring org. From rahul.nbg at gmail.com Sun May 5 21:19:42 2013 From: rahul.nbg at gmail.com (Rahul Gaur) Date: Mon, 6 May 2013 00:49:42 +0530 Subject: [Mailman-Developers] GSOC - Seeking insight on Authenticated RESTful APIs Message-ID: Hi all , I have applied for the project mentioned on the ideas page *Authenticated REST-API in Postorius/Django - *[0] So as per the Project idea, I have been doing some research on my end figuring out what would be the best way to achieve this. Since Postorius is based on Django , I have been trying Django specific solutions to serve the functionality currently offered by the Postorius web interface in the form of RESTful API's. As of now , I have been working on two different Django based frameworks to build RESTful APIs. 1. Django-REST-Framework 2. Django-Tastypie Initially , I was familiar with tastypie and I was strongly considering to use Tastypie only for this project. However after some advice from Richard , I am trying to be more flexible and I am trying to evaluate both the frameworks separately. At the moment I am going through Tastypie Documentation and resources , as I am yet to figure out how to use it with Non-ORM data resources precisely how to integrate it into postorius so I can serve the APIs . I would be glad , if I could get some more help on this. Secondly with the django-rest-framework , I tried certain approach [2] which firstly helped me in integrating the data served by the Mailman Core REST server and relay it via HTTP using the django-rest-framework. I don't know if this is the right approach to the project , but let me try to explain : Since Django-rest-framework has following concept : It provides serializers to convert complex data into python native data type and which could be easily rendered into json. Then these data sets could be structured and served with the class based views. So lets say if I want to GET localhost:8001/ postorius/settings/domains/index I tried took the following approach : # Serializer class MailmanSerializer(serializers.Serializer): mail_host = serializers.CharField(max_length=200) url_host = serializers.CharField(max_length=200) contact_add = serializers.CharField(max_length=200) description = serializers.CharField(max_length=200) # model class MailmanObject(object): def __init__(self, field ,field2 , field3, field4): self.mail_host = field self.url_host = field2 self.contact_add = field3 self.description = field4 And my Views is something like this : #Views class ApiView(generics.ListCreateAPIView): serializer_class = MailmanSerializer def all(self, request, *args, **kwargs): dict = [] dictb = [] dictc = [] dictd = [] for i in client.domains: dictc.append(i.mail_host) dict.append(i.base_url) dictb.append(i.contact_address) dictd.append(i.description) listObj = MailmanObject(field=dictc,field2= dict,field3=dictb, field4=dictd) serializer = self.serializer_class(listObj) return Response(serializer.data) and when I make curl -X GET http://127.0.0.1:8000/postorius/api/settings/domains/index/ *HTTP 200 OK* *Vary:* Accept *Content-Type:* text/html *Allow:* HEAD, GET, POST, OPTIONS {"mail_host":["aregee.com","rahulgaur.info"],"url_host":["aregee.net","rahulgaur.net"],"contact_add":["postmaster at aregee.com","postmaster at rahulgaur.info"],"description":["mail list","mail_list"]} Please let me know If I am working in the right direction and also do point out what are the things I have been overlooking in my approach. I can also use some help in evaluating which of the two frameworks would be suitable for the project. I would be glad if I can more insight on what are the technicals skills I need to focus and some reading recommendations for gaining better insight to complete this project successfully. I am also reading Leonard Richardson's and Sam Ruby's O'Reilly book on RESTful Web Services as recommended by Barry. Now about the authentication part , what would be the best possible solution for providing authentication ? There have been lot of debate on this topic already , I don't want to add more complexities but I would like to know what would be the most workable way of providing authentication for the starters.Maybe we can consider a different approach over the summer. Also there has been a discussion on "Architecture for extra profile info" , wouldn't this feature would be helpful in providing specific set of permission for what part of data can be accessed by authenticated API users ? Would it be more along the lines that any authenticated restful api user would be able to access all the resources offered by public facing RESTful API ? Another thing I have been considering , what would be the end deliverables of this project , what I mean to say is will the Public facing RESTful API be offering functionality currently possible with postorius via RESTful APIs or it should also include more features ? *Stephen Turnbull* May 2, 2013, 7:23 p.m. > > This proposal is very complete. It will take some time to evaluate the > proposal as a whole. But I am still concerned that the proposal seems to > propose a new API to be offered by Postorius. Postorius is already > designed as a client of the core REST API, it seems to me that it would be > more useful to improve the core API rather than relay via Postorius into a > new API. > Steve mentioned the following on melange , maybe we can discuss more on this. As I have already mentioned , I based my proposal upon the idea of introducing the authenticated public facing RESTful API's in Postorius so most of my approach has been Django centric. I have just done with my college practicals and end semester exams would commence from 17th of may up till 31st of may and I would have lot of free time after that. I can still dedicate a week and look into this topic , if this is the actual requirement of the project rather than relaying the core api via postorius into a new api. Thanks & Regards, Rahul ------------------------------------------------------------------------------------------------------- *Rahul Gaur* *irc : iamaregee2* *web: *http://www.rahulgaur.info* * *blogs : *aregee.wordpress.com , http://sanencynicalwriter.wordpress.com/ *fb:* http://facebook.com/iamaregee *github: *https://github.com/aregee From rahul.nbg at gmail.com Sun May 5 21:51:35 2013 From: rahul.nbg at gmail.com (Rahul Gaur) Date: Mon, 6 May 2013 01:21:35 +0530 Subject: [Mailman-Developers] GSOC - Seeking insight on Authenticated RESTful APIs In-Reply-To: References: Message-ID: Links : [0] - http://wiki.list.org/display/DEV/Google+Summer+of+Code+2013 [1] - https://github.com/aregee/rest-mailman [2] - https://github.com/aregee/mailman ------------------------------------------------------------------------------------------------------- *Rahul Gaur* *irc : iamaregee2* *web: *http://www.rahulgaur.info* * *blogs : *aregee.wordpress.com , http://sanencynicalwriter.wordpress.com/ *fb:* http://facebook.com/iamaregee *github: *https://github.com/aregee From stephen at xemacs.org Mon May 6 11:36:09 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 06 May 2013 18:36:09 +0900 Subject: [Mailman-Developers] GSOC - Seeking insight on Authenticated RESTful APIs In-Reply-To: References: Message-ID: <87mws8o3g6.fsf@uwakimon.sk.tsukuba.ac.jp> Before I get started on the content, note that I'm going to be rather critical of most posts of all students for a while, mostly negative. **This is not a reflection of the quality of the candidate or of the proposals involved.** Instead, it reflects the fact that we need to learn to communicate efficiently with each other. Some of that can come from mentor adjustment, but (for reasons I'll go into some other time if asked) mostly adjustment is going to need to be on the student side. It follows that there are two kinds of criticism here. One is of the content of the project. We'll try to be constructive there, but sometimes we can only ask questions which often sounds pretty negative (especially to students with no good answers yet!) I'm sorry about that, but it's necessary. The other is of the presentation, especially of content that is inappropriate and should not be included. That necessarily is going to be mostly negative. Rahul Gaur writes: > Hi all , > > I have applied for the project mentioned on the ideas page *Authenticated > REST-API in Postorius/Django - *[0] > So as per the Project idea, I have been doing some research on my end > figuring out what would be the best way to achieve this. > Since Postorius is based on Django , I have been trying Django specific > solutions to serve the functionality currently offered by the Postorius > web interface in the form of RESTful API's. The above is a good introduction. > As of now , I have been working on two different Django based frameworks to > build RESTful APIs. > > 1. Django-REST-Framework > > 2. Django-Tastypie > > Initially , I was familiar with tastypie and I was strongly considering to > use Tastypie only for this project. However after some advice from Richard > , I am trying to be more flexible and I am trying to evaluate both the > frameworks separately. With all due respect to Richard (if that's what he advised), "being flexible" here is not a good reason to look at multiple frameworks. I would recommend going with the framework you know. > I am yet to figure out how to use [django-tasty-pie] with Non-ORM > data resources precisely how to integrate it into postorius so I > can serve the APIs . This, on the other hand, is a reason to consider changing, if it's really unclear how to use Tasty Pie to do the job. But why are you specifying "non-ORM"? Django already provides the ORM, and Postorius is (eventually) going to provide access to all "user-servicable parts" (where in this context "user" includes site admin, list admin, moderator, and subscriber for sure, and possibly other roles as they are defined). For Postorius's UI face, that is going to pretty much have to go through the ORM. If you need access to something that's not in the ORM, I would suggest fixing the models. > I would be glad , if I could get some more help on this. You need to say what you're trying to access for help on this. Your description of working with the django-rest-framework below is much easier to provide help for. If this is the best you can do for Tasty Pie I'd say you're pretty much blocked on this route, and you should just switch to django-rest-framework, unless you find a clear reason to prefer Tasty Pie. In any case, I think first you should think about the APIs you want to serve, rather than writing code that serves no clear purpose. 1. Who does the API serve (site admin, list admin, moderator, subscriber, ...)? 2. What do they want to accomplish? 3. What needs to be done in the Mailman core to have that effect? 4. What facility does Postorius provide for dealing with Mailman? (In this particular case, why isn't it accessible via the Django ORM and models used by Postorius?) 5. How would you express this in a REST API? On to django-rest-framework: > I don't know if this is the right approach to the project , but let me try > to explain : > Since Django-rest-framework has following concept : > It provides serializers to convert complex data into python native data > type and which could be easily rendered into json. Wacky likes the HAL+JSON approach, I think. http://stateless.co/hal_specification.html http://tools.ietf.org/html/draft-kelly-json-hal-05 I think that's a good place to start for defining structures. It seems very flexible, and there may already be Python modules for implementing it. > mail_host = serializers.CharField(max_length=200) > url_host = serializers.CharField(max_length=200) > contact_add = serializers.CharField(max_length=200) > description = serializers.CharField(max_length=200) "Which of these things is not like the others?" Ie, why "contact_add" and not "contact_list" or "contacts"? > def __init__(self, field ,field2 , field3, field4): > self.mail_host = field > self.url_host = field2 > self.contact_add = field3 > self.description = field4 Give the parameters descriptive names: # n.b. Fixed the commas. def __init__(self, mail_host, url_host, contact_add, description): self.mail_host = mail_host self.url_host = url_host self.contact_add = contact_add self.description = description Maybe it looks a little wasteful (and violates DRY), but this is the best way I've found. > And my Views is something like this : > def all(self, request, *args, **kwargs): > dict = [] This is a list, not a dict. > dictb = [] > dictc = [] > dictd = [] Why a list per attribute? This isn't an very extensible or maintainable API, because you'll have to change all methods like this one every time you add or remove or rename an attribute. > Please let me know If I am working in the right direction Well, I assume you actually ran the program, so you know it works. But I don't see what it's *for*, so I can't say if you're going in the right direction or not. > Now about the authentication part , what would be the best possible > solution for providing authentication ? At this point, no authentication at all. Only allow connections from localhost, and let them do anything the interface permits. Delegate authentication to the client (which has to run on the same host, and presumably will be a web service so the site admin can use HTTPS + HTTP Basic Auth in the webserver). Authorization is another matter. Wacky and I discussed ACLs a little bit, and I *think* (but haven't asked him directly) he would support an "Authorizable" mixin class (or decorator, maybe) that would be applied to every "piece of information" that your API serves. BTW: It should be obviously that I'm not real clear on what "Authorizable" actually does, or what "pieces of information" are. That's your problem, in some sense, although we can discuss it here. > Also there has been a discussion on "Architecture for extra profile > info" , wouldn't this feature would be helpful in providing > specific set of permission for what part of data can be accessed by > authenticated API users ? Well, no; the point of that thread was to try to define the API for extra profile info. The thread got sidetracked into authentication, but there's a serious cart before horse problem here. Some information is so sensitive that it shouldn't be available on the net at all. Does Mailman store anything like that? Are you sure? (Hint: the extra profile information might actually come from an enterprise database.) If you can't answer questions like that, designing authn or authz systems is not possible. I think you should ignore the auth* problem, and concentrate on what information your API should provide, what packages it should come in, and the RESTful API to accomplish that. Once you have some direction on that, where to add the auth* APIs, and what they're going to look like should be much more clear. > Would it be more along the lines that any authenticated restful api user > would be able to access all the resources offered by public facing RESTful > API ? Surely not. For example, subscribers aren't allowed to create lists in Mailman 2, so I would assume any services provided by Mailman 3 should implement the same restriction. > Another thing I have been considering , what would be the end > deliverables of this project , what I mean to say is will the > Public facing RESTful API be offering functionality currently > possible with postorius via RESTful APIs or it should also include > more features ? Well, Postorius is "currently" pretty incomplete, so we'd better do more than "currently possible". > if this is the actual requirement of the project rather than > relaying the core api via postorius into a new api. Since the "consumers" of this API are really Terri and Florian, you'd better talk to them. But since they're interested in "extra" profile information, I think you need to be prepared for extensive additional requirements beyond a mere relay of the core. This is the important question at this stage. I think you're asking too many questions, in fact. You need more focus. I suggest some questions about getting your feet wet with the frameworks are OK, plus discussion of what information your REST API needs to be prepared to provide are what you need now. From rkw at dataplex.net Mon May 6 12:01:04 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Mon, 6 May 2013 05:01:04 -0500 Subject: [Mailman-Developers] GSOC - Seeking insight on Authenticated RESTful APIs In-Reply-To: <87mws8o3g6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87mws8o3g6.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <0EA25BF1-3436-436A-94D8-0A9EDFE66376@dataplex.net> On May 6, 2013, at 4:36 AM, Stephen J. Turnbull wrote: >> Initially , I was familiar with tastypie and I was strongly considering to >> use Tastypie only for this project. However after some advice from Richard >> , I am trying to be more flexible and I am trying to evaluate both the >> frameworks separately. > > With all due respect to Richard (if that's what he advised), "being > flexible" here is not a good reason to look at multiple frameworks. I > would recommend going with the framework you know. > >> I am yet to figure out how to use [django-tasty-pie] with Non-ORM >> data resources precisely how to integrate it into postorius so I >> can serve the APIs . > > This, on the other hand, is a reason to consider changing, if it's > really unclear how to use Tasty Pie to do the job. Let me clarify. The flexibility that I was suggesting was that he not "marry" his proposal to one particular implementation (Tasty Pie vs django-rest-framework) until he has a better understanding of the requirements and capabilities. In other words, let the evaluation of the alternatives be a part of the project rather than a precursor. From my experience, the choice is not clear-cut. > If this is the best you can do for Tasty Pie I'd say you're pretty much blocked on this route, and you should > just switch to django-rest-framework, unless you find a clear reason to prefer Tasty Pie. Just my point. :) From raj.abhilash1 at gmail.com Mon May 6 18:59:15 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Mon, 6 May 2013 22:29:15 +0530 Subject: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project In-Reply-To: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Let me divide the project in a few pieces so that each can be discussed upon separately. * 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? Also from this [document][4] I see that there are two ways to both sign and encrypt the message: * It is stated that the data is first signed as multipart/signature body, and then encrypted to form the final multipart/encrypted body.[5] * A method for signing and encrypting data in a single OpenPGP message. This method is allowed in order to reduce processing overhead and increase compatibility with non-MIME implementations of OpenPGP. I don't have any links to prove, but I think we should use the first one. Any thoughts about which one is easily and more widely used among various MUAs? * Now the second part as wacky mentioned - a framework for storing the keys and handling the association of the key with a particular user. This same framework would be used to associate other methods of identification and authentication with the users. * 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? [1]: http://pythonhosted.org/python-gnupg/ [2]: http://search.cpan.org/~alexmv/GnuPG-Interface-0.46/lib/GnuPG/Interface.pm [3]: http://non-gnu.uvt.nl/mailman-pgp-smime/ [4]: https://tools.ietf.org/html/rfc3156#section-6 [5]: https://tools.ietf.org/html/rfc1847 On Sun, May 5, 2013 at 10:00 PM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > 1) I need to discuss about the design of the idea that I want to > > implement. I know the rough bits but need help and comments on > > what I proposed. This would require views from the whole > > mailman-community. > > This is place for that, not private consultation with the mentor. > Just start spelling out your ideas, and post them here for comment as > they're developed to the point you can get useful comment. And don't > worry about whether you are doing it right: just do it. Sooner is better. > > One reason for this approach is that as Google sees GSoC, one purpose > is encouraging the student to develop his or her relationship with the > community.[1] The best case is somebody who enters with several months > of presence on the developer lists (but that is in no way required, > it's more an "it would be nice if" example). > > We actually would like have the proposals posted here, but > unfortunately that tends to interfere with evaluation for several > reasons. (One important one is that often several students propose > similar projects, and if the proposals are public there's a very > natural tendency for them to converge, making selection nearly > impossible.) Now that we have the proposals in full, we'd like you to > start engaging the community by posting your ideas, designs, and > questions here. > > It's probably best *not* to post big chunks of your proposal. Maybe > the "short description" as an introduction, but after that you should > pick a particular task and get the community to help you start on it. > > > 2) Apart from the corner cases mentioned in the proposal there might be > > many other not caught in my eye. I would need them to be pointed out so > > that a solution of it can discussed and then implemented. > > > > 3) There is a lot of cryptography in this project, so I would need a more > > experienced view to find and remove the security loopholes. > > These are more specific to your topic, but they are also best done on > this list, especially the issues related to security. The advantage > of the mentor system is that you have somebody who has to look at your > stuff. Still, the best way is to get comments from a broad selection > of developers and users. > > > 4) Lastly since I am still a noob in programming I would need regular > > review on the code for the first 2-3 weeks so that I cam improve > > and write bug free production code. > > Well, the first thing to learn is that nobody writes bug-free code. > Anticipate that your code is going to be buggy, catch as many as you > can systematically (I recommend Watts Humphrey's book "Introduction to > the Personal Software Process", I'm sure other mentors have their > favorites). Then get reviews from others (including but not limited > to your mentor(s)). > > Once again, what we are looking for (Richard posted as representative > of the mentor team) is discussion of your plans: the pieces of the > design puzzle, of course, but also your motivation for proposing the > project, and your plans for advancing it. > > I emphasize what Richard has already mentioned: this is not a test > where you have to do everything yourself to get points. > > You will be evaluated on the functionality you present to us at the > midterm and final evaluations, not on whether you wrote all the code > yourself. Some of the code you can borrow from existing modules, and > some you can beg from others. Your mentors are going to be working on > their own projects, and schedules can be adjusted to provide pieces of > the puzzle you need sooner rather than later. Other experienced > developers may be willing to help out. In some cases you can get > parts of what you need from other students in GSoC (but this requires > delicate negotiation and careful management by the mentors involved; > we'll cross that bridge if we come to it). > > The rest of the code you have to write, and there's a minimum (a > substantial size, at that) we'll be expecting. But the more code you > can get from elsewhere, the better the product you'll produce this > summer! > > > Footnotes: > [1] The others, of course, are financial support for a student > getting practical experience in software development, concentrating on > coding, and development of worthwhile software for the mentoring org. > -- Abhilash Raj From salunkeshanu at gmail.com Mon May 6 07:00:13 2013 From: salunkeshanu at gmail.com (Shanu Salunke) Date: Mon, 6 May 2013 10:30:13 +0530 Subject: [Mailman-Developers] GSoC Applicants Message-ID: Hey all, As I understand it, this thread is meant for looking at your project from an implementation point of view (correct me if I'm wrong). Well, my proposed project is called "A Modern Interface for Member's Area" and is basically aims at providing the existing (and some new) MM-HK functionality to daily users (not admins) in a forum like interface. They can view conversations, reply, subscribe, unsubscribe, create public profiles and more like your run-of-the-mill online communities. The main aim is to try and make MM easier to use from a new-user point of view. (And for personal reasons; I have signed up for three MM-using communities and I cannot keep them straight) What I need help with as a starting point (at least) is how to "link" the functionality with the (django) front-end. One solution (thank you abomard) is using the API that (postorius also uses) MM3 and HK have support for. But since I have no experience with REST and I think some other projects are working on the apis... I would like to hear your views. - Shanu Salunke From stephen at xemacs.org Tue May 7 04:04:37 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 07 May 2013 11:04:37 +0900 Subject: [Mailman-Developers] GSoC Applicants In-Reply-To: References: Message-ID: <87wqrblf4a.fsf@uwakimon.sk.tsukuba.ac.jp> Shanu Salunke writes: > What I need help with as a starting point (at least) is how to "link" the > functionality with the (django) front-end. One solution (thank you abomard) > is using the API that (postorius also uses) MM3 and HK have support > for. This isn't your job, IMO. Your proposal is about integrating various functionality in a single UI. I agree that Django is a good implementation technology, because the Postorius and HyperKitty applications use it. How can integration be achieved? Step 1. Arms-length, proof-of-concept technology: use HTML frames to organize Postorius and HyperKitty connections along with any "native" "applets" you need (web-posting, mail-posting, NNTP posting and/or reading) in a single display. Yes, frames suck for various reasons, but they're an easy way to impose organization without *any* cooperation from Postorius and HyperKitty. This step should go to the point of allowing you to conveniently *organize* multiple lists. You probably won't be able to conveniently *manage* individual lists because of the "arms-length" nature of the technology. Don't even try; move on to step 2. Step 2. All these apps are Django apps. Django templates support inclusion and inheritance. It should be possible to get better integration with template inclusion as a substitute for HTML frames. Step 3. Design an "API" for your templates, and propose changes to Postorius and HyperKitty templates to better integrate them into your app. Step 4. Design an API for your views that can cooperate with low-level REST APIs that Postorius and HyperKitty might export, to allow the various apps to reside on different servers. Your Django models can probably be very simple, just a list nickname, some identification (RFC 2919 List-Id), and a bunch of URLs (mail posting, HyperKitty archives, Postorius subscriber and admin interfaces, other functionality if any) in a single model. That's not a promise, of course, but I think you can start there. From stephen at xemacs.org Tue May 7 04:57:55 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 07 May 2013 11:57:55 +0900 Subject: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project In-Reply-To: References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> 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"!) From stephen at xemacs.org Tue May 7 05:23:29 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 07 May 2013 12:23:29 +0900 Subject: [Mailman-Developers] GSoC Applicants In-Reply-To: <87wqrblf4a.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87wqrblf4a.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87ppx3lbgu.fsf@uwakimon.sk.tsukuba.ac.jp> Stephen J. Turnbull writes: > Step 1. > Step 2. > Step 3. > Step 4. Urk. I think I said way too much. Your lucky day! From varunsharmalive at gmail.com Tue May 7 05:39:36 2013 From: varunsharmalive at gmail.com (varun sharma) Date: Tue, 7 May 2013 09:09:36 +0530 Subject: [Mailman-Developers] GSOC Project Discussion Message-ID: Hi Guys, 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. Right now, i am having a look at the mailman core and mailman interfaces to figure out if the method/implementation is already present in the core and if not then i will need some help from barry and other developers to include it in the core. As i am now working on writing the software requirement specification, i hope to get most of the requirements from core by this weekend.I had a chat with wacky on #mailman yesterday about the same and i will post my requirements from the core by monday. Thanks Varun From stephen at xemacs.org Tue May 7 07:09:57 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 07 May 2013 14:09:57 +0900 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: Message-ID: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> 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? From mgill25 at outlook.com Tue May 7 18:48:33 2013 From: mgill25 at outlook.com (Manish Gill) Date: Tue, 7 May 2013 22:18:33 +0530 Subject: [Mailman-Developers] GSoC discussion Message-ID: 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? From mgill25 at outlook.com Tue May 7 18:54:40 2013 From: mgill25 at outlook.com (Manish Gill) Date: Tue, 7 May 2013 22:24:40 +0530 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: References: Message-ID: On 05/07/2013 10:18 PM, Manish Gill wrote: > 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? > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://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: > http://mail.python.org/mailman/options/mailman-developers/mgill25%40outlook.com > > Security Policy: http://wiki.list.org/x/QIA9 > > I should mention that this is for the REST API for Postorius/Django project. From stephen at xemacs.org Tue May 7 20:13:50 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 08 May 2013 03:13:50 +0900 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: References: Message-ID: <87ip2uody9.fsf@uwakimon.sk.tsukuba.ac.jp> Manish Gill writes: > So, for example, in trying to expose `MailingList` objects, as of > now, there is no way to post messages to a list externally. Out of scope. You could do something that would allow a quick, urgent message to be posted, but you are very likely to embarrass yourself, and us. Eg, http://code.google.com/p/soc/issues/detail?id=1843. :-) > 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. I think Wacky would disagree with that strategy. Extending the member model is not a maintainable strategy. There are several alternatives that are more extensible. > What will be useful to have: > > - Methods to provide filtering based on various criteria. Filter what? > 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. Another way is ACLs on resources. From rkw at dataplex.net Wed May 8 01:58:20 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Tue, 7 May 2013 18:58:20 -0500 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: <87ip2uody9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ip2uody9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5D19BE89-57CA-4228-B47A-81DEB41C9E6C@dataplex.net> On May 7, 2013, at 1:13 PM, Stephen J. Turnbull wrote: > Manish Gill writes: > >> So, for example, in trying to expose `MailingList` objects, as of >> now, there is no way to post messages to a list externally. > > Out of scope. You could do something that would allow a quick, urgent > message to be posted, but you are very likely to embarrass yourself, > and us. Eg, http://code.google.com/p/soc/issues/detail?id=1843. :-) > >> 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. > > I think Wacky would disagree with that strategy. Extending the member > model is not a maintainable strategy. There are several alternatives > that are more extensible. > >> What will be useful to have: >> >> - Methods to provide filtering based on various criteria. > > Filter what? I was comparing what a consumer of the Postorius interface might like to see that is not just a proxy forwarding the MM-core interface. As an example, rather than all of the lists, just those lists for which the represented user is the administrator. If the interface is not going to provide full SQL query capability, it can still provide some portion of the selection filtering. >> 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. > > Another way is ACLs on resources. Here I was speaking of ways that an installation might present the information -- trying to show that the "storage model", whatever it happens to be, might not be the view that the implementor wishes to display. I appears that my communication was not as successful as I had hoped. From stephen at xemacs.org Wed May 8 07:09:02 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 08 May 2013 14:09:02 +0900 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: <5D19BE89-57CA-4228-B47A-81DEB41C9E6C@dataplex.net> References: <87ip2uody9.fsf@uwakimon.sk.tsukuba.ac.jp> <5D19BE89-57CA-4228-B47A-81DEB41C9E6C@dataplex.net> Message-ID: <87ehdinjm9.fsf@uwakimon.sk.tsukuba.ac.jp> Richard Wackerbarth writes: > I appears that my communication was not as successful as I had hoped. I don't know about your communication. My point here is that the *student's* communication was insufficient. Posts to the list involve people who are not party to the conversion on IRC and vice versa. Details like the object of "filter" need to be included. "Look at" may be an obvious indication of "we're talking about presentation" in context of a conversation, but it's not enough in a post that summarizes that conversation to those not present. As I wrote earlier, my criticisms are going to be severe, even harsh. There's a good reason for that. What we're doing here is quite different from most uses of mailing lists, which are either much more casual (conversational correspondence) or involve a group whose members are all more or less up to speed on the content. That's not going to be the case here. Important decision-makers (Terri and Barry) are currently not in the loop. The students are going to be very much focused on their own proposals, and will take time to get up to speed on others'. Posts need to avoid presuming very much knowledge on the part of other subscribers, at least early in threads. There's another important point that hasn't been mentioned yet. You GSoC students are Mailman developers now. It's not about your proposal, it's about the Mailman project. Your proposal is important to us in the context of the project, not standing alone by itself. You should help support the other students in their projects, too. You may not have anything constructive to contribute to others' tasks yet, but you *should* be able to ask questions about them. That's important for learning about how Mailman works overall. From mgill25 at outlook.com Wed May 8 12:54:04 2013 From: mgill25 at outlook.com (Manish Gill) Date: Wed, 8 May 2013 16:24:04 +0530 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: <87ehdinjm9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ip2uody9.fsf@uwakimon.sk.tsukuba.ac.jp> <5D19BE89-57CA-4228-B47A-81DEB41C9E6C@dataplex.net> <87ehdinjm9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On 05/08/2013 10:39 AM, Stephen J. Turnbull wrote: > Richard Wackerbarth writes: > > > I appears that my communication was not as successful as I had hoped. > > I don't know about your communication. My point here is that the > *student's* communication was insufficient. I'll be more thorough in the future. > As I wrote earlier, my criticisms are going to be severe, even harsh. > There's a good reason for that. What we're doing here is quite > different from most uses of mailing lists, which are either much more > casual (conversational correspondence) or involve a group whose > members are all more or less up to speed on the content. You can be critical without being harsh. > That's not going to be the case here. Important decision-makers > (Terri and Barry) are currently not in the loop. The students are > going to be very much focused on their own proposals, and will take > time to get up to speed on others'. Posts need to avoid presuming > very much knowledge on the part of other subscribers, at least early > in threads. > > There's another important point that hasn't been mentioned yet. You > GSoC students are Mailman developers now. It's not about your > proposal, it's about the Mailman project. Fair enough. > Your proposal is important > to us in the context of the project, not standing alone by itself. > You should help support the other students in their projects, too. > You may not have anything constructive to contribute to others' tasks > yet, but you *should* be able to ask questions about them. That's > important for learning about how Mailman works overall. > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://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: http://mail.python.org/mailman/options/mailman-developers/mgill25%40outlook.com > > Security Policy: http://wiki.list.org/x/QIA9 > > From markoupetr at gmail.com Wed May 8 15:13:59 2013 From: markoupetr at gmail.com (Peter Markou) Date: Wed, 8 May 2013 16:13:59 +0300 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. Message-ID: 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. From stephen at xemacs.org Wed May 8 17:19:49 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 09 May 2013 00:19:49 +0900 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: References: Message-ID: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> 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. From rkw at dataplex.net Wed May 8 17:31:59 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Wed, 8 May 2013 10:31:59 -0500 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> I agree with Steve. One of the advantages of Django is its "mix and match" capability. Actually, I see two possible apps. One would integrate with HK. The other would be simpler, just providing a posting mechanism that provides authenticated message sender. On May 8, 2013, at 10:19 AM, Stephen J. Turnbull wrote: > 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. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://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: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9 From terri at zone12.com Wed May 8 20:55:00 2013 From: terri at zone12.com (Terri Oda) Date: Wed, 08 May 2013 12:55:00 -0600 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> Message-ID: <518A9F84.1090806@zone12.com> In practical terms, I think the time would be better spent on integrating HyperKitty and Postorius for Mailman suite *first* and then dividing out the posting capability once the integration is done. That way the person who does this has some idea of the pain points of integration so they can be better smoothed for the next piece. Terri On 05/08/2013 09:31 AM, Richard Wackerbarth wrote: > I agree with Steve. One of the advantages of Django is its "mix and match" capability. > Actually, I see two possible apps. One would integrate with HK. The other would be simpler, just providing a posting mechanism that provides authenticated message sender. > > On May 8, 2013, at 10:19 AM, Stephen J. Turnbull wrote: > >> 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. >> _______________________________________________ >> Mailman-Developers mailing list >> Mailman-Developers at python.org >> http://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: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net >> >> Security Policy: http://wiki.list.org/x/QIA9 > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://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: http://mail.python.org/mailman/options/mailman-developers/terri%40zone12.com > > Security Policy: http://wiki.list.org/x/QIA9 > From flo.fuchs at gmail.com Thu May 9 00:33:27 2013 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Thu, 9 May 2013 00:33:27 +0200 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: References: Message-ID: 2013/5/7 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. 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. 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. Postorius reflects the same role system (admin/owner, moderator, member) that is currently implemented in the core (which is also kind of well known from Mailman2). 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. 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. Florian From rkw at dataplex.net Thu May 9 01:52:23 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Wed, 8 May 2013 18:52:23 -0500 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: References: Message-ID: On May 8, 2013, at 5:33 PM, Florian Fuchs wrote: > 2013/5/7 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. > > 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 From rkw at dataplex.net Thu May 9 01:52:23 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Wed, 8 May 2013 18:52:23 -0500 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: References: Message-ID: On May 8, 2013, at 5:33 PM, Florian Fuchs wrote: > 2013/5/7 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. > > 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 From raj.abhilash1 at gmail.com Thu May 9 07:31:20 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Thu, 09 May 2013 11:01:20 +0530 Subject: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project In-Reply-To: <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <518B34A8.9030400@gmail.com> Consider this flow of message from one user to all list-subscribers: * A user sends a message( signed as well as encrypted )which as soon as received by mailman is first queued in "IN" queue. * When the incoming runner wakes up the message is checked if it is for owners, posting or encrypted.An encrypted chain is created for encrypted messages. * Now according to the use case there can be two encrypted chain: 1) Where the posters are fully trusted and thus this rules only checks the signature of a message. If a message signed by a member is received it is sent to pipeline queue in a encrypted form for further processing. 2) Where the posters are not fully trusted. In this case there needs to be various checks on decrypted message like current default-posting-chain. * The messaged is moved in between queues in the encrypted form encrypted by a symmetric key algorithm which uses list's secret key to encrypt the message. * When the pipeline handler wakes up it decides which pipeline the message is to passed through. In this case an encrypted_posting_pipeline is created to process an encrypted message. * This encrypted_posting_pipeline is used to keep the message in plain-text for a minimal time. The message is decrypted, headers and footers are added and the message is signed by list's pub-key. It is then again (symmetrically) encrypted and stored in the outgoing queue. * The outgoing runner personalizes each message by encrypting it with each user's pub key and forwards it to MTA using VERP(Variable Envelop Return Path). Now consider the threat models it addresses. Firstly this verifies the integrity of the message. This is done by verification of signature and matching that sender's address indeed matches the address in signature so that you can sure that message was indeed sent by the sender. Secondly this maintains the confidentiality of the message. Even if the message is intercepted it can only be read by the one whom it is addressed to. There are the threats this does not address: If the keys/system/MUA of a user sending or receiving the message is compromised or contains a virus, no assurance can be provided about the integrity or confidentiality of the message. On Tue, May 7, 2013 at 8:27 AM, Stephen J. Turnbull wrote: > 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"!) -- Abhilash Raj From barry at list.org Thu May 9 18:28:20 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 9 May 2013 12:28:20 -0400 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> Message-ID: <20130509122820.48979b26@anarchist> On May 08, 2013, at 10:31 AM, Richard Wackerbarth wrote: >I agree with Steve. One of the advantages of Django is its "mix and match" >capability. Actually, I see two possible apps. One would integrate with >HK. The other would be simpler, just providing a posting mechanism that >provides authenticated message sender. The real power here would be for someone who is reading the archives to "jump into" a discussion, potentially long after the fact. Imagine you've done a web search for a particular problem you're having and it lands you on a page in an archive. You want to follow up to that message with some additional information or question. Reducing the burden for that type of intermittent involvement in a topic should be the goal. -Barry From dkg at fifthhorseman.net Thu May 9 18:47:43 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 May 2013 12:47:43 -0400 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <20130509122820.48979b26@anarchist> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> Message-ID: <518BD32F.1060309@fifthhorseman.net> On 05/09/2013 12:28 PM, Barry Warsaw wrote: > The real power here would be for someone who is reading the archives to "jump > into" a discussion, potentially long after the fact. Imagine you've done a > web search for a particular problem you're having and it lands you on a page > in an archive. You want to follow up to that message with some additional > information or question. Reducing the burden for that type of intermittent > involvement in a topic should be the goal. A simple step toward this goal would be to add a mailto link on the message's archive page that includes an In-Reply-To field, as outlined in the "Basic Examples" section of the Mailto RFC: https://tools.ietf.org/html/rfc6068#section-6.1 so something like: Reply to this message While this doesn't solve the problem for everyone (i'm sure there are MUAs that don't accept this header when generating mail from a mailto: link), it should be very easy to implement, and if mailman's default archives were to include such a link it would spur people to fix non-compliant MUAs. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From mark at msapiro.net Thu May 9 19:06:00 2013 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 09 May 2013 10:06:00 -0700 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <518BD32F.1060309@fifthhorseman.net> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> <518BD32F.1060309@fifthhorseman.net> Message-ID: <518BD778.9000101@msapiro.net> On 05/09/2013 09:47 AM, Daniel Kahn Gillmor wrote: > > so something like: > > href="mailto:list at example.org?In-Reply-To=%3C3469A91.D10AF4C at example.com%3E">Reply > to this message Go to and look at the mailto: link under 'dkg at fifthhorseman.net'. > While this doesn't solve the problem for everyone (i'm sure there are > MUAs that don't accept this header when generating mail from a mailto: > link), it should be very easy to implement, and if mailman's default > archives were to include such a link it would spur people to fix > non-compliant MUAs. Granted, it doesn't say "Reply to this message", but it's been that way for years. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Thu May 9 19:06:41 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 10 May 2013 02:06:41 +0900 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <20130509122820.48979b26@anarchist> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> Message-ID: <87ppx0f5ge.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > On May 08, 2013, at 10:31 AM, Richard Wackerbarth wrote: > > >I agree with Steve. One of the advantages of Django is its "mix and match" > >capability. Actually, I see two possible apps. One would integrate with > >HK. The other would be simpler, just providing a posting mechanism that > >provides authenticated message sender. I'm not sure what you're proposing in terms of "integration". The way I see it, is HyperKitty or any other app could provide links which could invoke the web posting app or the user's MUA. The web posting app would have an URL like http://list.example.com/HyperKitty/post/MSG_INIT_INFO where MSG_INIT_INFO would have the same format as a mailto: URL. So, HyperKitty would be in a good position to generate References and so on for any message in the archive, but other apps would be able to generate their own special messages. Eg, Roundup could put issue refs in posting URLs it puts in issue pages. Barry Warsaw writes: > The real power here would be for someone who is reading the > archives to "jump into" a discussion, potentially long after the > fact. Imagine you've done a web search for a particular problem > you're having and it lands you on a page in an archive. You want > to follow up to that message with some additional information or > question. Reducing the burden for that type of intermittent > involvement in a topic should be the goal. I think there's something to what you say, but it's not obvious to me how much easier that would be than a mailto: URL. I think basically the use case is for people who want an integrated interface to the list in their browser. From dkg at fifthhorseman.net Thu May 9 19:17:05 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 May 2013 13:17:05 -0400 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <518B34A8.9030400@gmail.com> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> Message-ID: <518BDA11.3020504@fifthhorseman.net> As i about this, i wonder if the OpenPGP integration project shouldn't be broken into two phases, so that the tricky nuances could be handled more simply. I'm imagining a first phase ("message authentication") would not expect or handle encrypted messages, but would just use cryptographic signatures to verify the authenticity of origin of the incoming message, enhancing (and/or replacing) some of the current checks mailman uses to decide if a message should be passed on to the list. Then the second phase ("encrypted messages") would address the possibility of having encrypted message content. If you can get the "message authentication" phase done properly, you'll have a good argument that your keyring management is effective, without getting sidetracked into issues of exactly where the content of the message might leak (since the messages aren't encrypted at all). When the first phase is done, you could focus on the "encrypted messages" phase, based on the assumption that you have decent keyring management, and handle the peculiarities and concerns there separately. I'm not a mailman developer; but I'd be curious to hear what mailman devs think of this breakdown. More comments and questions below, based on the workflow you've outlined that mixes "message authentication" with "encrypted messages" and tries to solve them all at once: On 05/09/2013 01:31 AM, Abhilash Raj wrote: > Consider this flow of message from one user to all list-subscribers: > > * A user sends a message( signed as well as encrypted )which as soon as > received by mailman is first queued in "IN" queue. who does the sender encrypt the message to? are we talking about a public key associated with the list? how does the sender learn of that public key? > * When the incoming runner wakes up the message is checked if it is for > owners, posting or encrypted.An encrypted chain is created for > encrypted messages. what if it is an encrypted message sent to "owners"? how does that get handled? > * Now according to the use case there can be two encrypted chain: > > 1) Where the posters are fully trusted and thus this rules only checks > the signature of a message. If a message signed by a member is received > it is sent to pipeline queue in a encrypted form for further processing. when you say "fully trusted" it might be worth saying what they are trusted for. I think here you mean "fully trusted to post messages without moderation". What happens if the message cannot be decrypted by the mailing list and the signature is inside the encryption? does the message bounce? what if the decryption succeeds but there is no message signature inside it? what if the signature appears to be valid, but was made 3 years ago (or in the future)? what if the signature appears to be valid, and recent, but is the same signature that was used on a previous e-mail to the list? what if the signature is cryptographically valid, but the list member's key has expired? what if only part of the message is signed? > 2) Where the posters are not fully trusted. In this case there needs to > be various checks on decrypted message like current default-posting-chain. One common thing that might happen here is that the message is being held for moderation. if the message is encrypted, how is a moderator supposed to review it and make a decision? > * The messaged is moved in between queues in the encrypted form > encrypted by a symmetric key algorithm which uses list's secret key to > encrypt the message. this doesn't make sense to me. when i hear "list's secret key" i tend to think people are talking about asymmetric encryption, but it seems here that you're talking about symmetric encryption. Maybe it would help to enumerate exactly what secrets each entity holds (and maybe what public data is associated with those secrets, in the case of the public/private keypairs used by asymmetric crypto). If you give those secrets names, you can refer to them more concisely and precisely. > * When the pipeline handler wakes up it decides which pipeline the > message is to passed through. In this case an encrypted_posting_pipeline > is created to process an encrypted message. which case is "this case" are we talking here about every encrypted message or just a subset of them? > * This encrypted_posting_pipeline is used to keep the message in > plain-text for a minimal time. The message is decrypted, headers and > footers are added and the message is signed by list's pub-key. It is > then again (symmetrically) encrypted and stored in the outgoing queue. public keys don't sign messages; secret keys can sign messages, and public keys are used to verify those signatures. what happens to the original sender's signature? is it stripped? or does it remain, nested within the list's signature? How are list members expected to verify these signatures? i'm again confused by the symmetrical encryption proposal here. > * The outgoing runner personalizes each message by encrypting it with > each user's pub key and forwards it to MTA using VERP(Variable Envelop > Return Path). What happens if a user's public key is found to be expired or revoked? How does mailman become aware of revocations, of extensions of the expiration date, or of new keys or certificates for any given user? i hope these questions are useful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu May 9 19:31:13 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 May 2013 13:31:13 -0400 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <518BD778.9000101@msapiro.net> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> <518BD32F.1060309@fifthhorseman.net> <518BD778.9000101@msapiro.net> Message-ID: <518BDD61.6060604@fifthhorseman.net> Hi Mark-- On 05/09/2013 01:06 PM, Mark Sapiro wrote: > Go to > > and look at the mailto: link under 'dkg at fifthhorseman.net'. wow, great! I have never looked at this link before because i always assumed it was a link to e-mail the original sender of the message. i'm sorry i missed it. I've been a mailman user for over a decade now (and a mailman admin for at least half that) :/ > Granted, it doesn't say "Reply to this message", but it's been that way > for years. I probably wouldn't have missed that i could use that link to reply to the message if the link text had been "Reply to this message" :) All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From terri at zone12.com Thu May 9 19:36:35 2013 From: terri at zone12.com (Terri Oda) Date: Thu, 09 May 2013 11:36:35 -0600 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <518BDA11.3020504@fifthhorseman.net> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> Message-ID: <518BDEA3.4070007@zone12.com> On 13-05-09 11:17 AM, Daniel Kahn Gillmor wrote: > I'm imagining a first phase ("message authentication") would not expect > or handle encrypted messages, but would just use cryptographic > signatures to verify the authenticity of origin of the incoming message, > enhancing (and/or replacing) some of the current checks mailman uses to > decide if a message should be passed on to the list. > > Then the second phase ("encrypted messages") would address the > possibility of having encrypted message content. > > I'm not a mailman developer; but I'd be curious to hear what mailman > devs think of this breakdown. Nice timing! This is *exactly* what a few of Mailman devs who are awake were talking about on IRC an hour or two ago. Re-organizing like this would be a great way to make sure that openPGP as a GSoC project can have a useful but smaller scale first goal, leaving full encryption as more of a stretch goal, which might work better for the GSoC timeline. Terri From rkw at dataplex.net Thu May 9 19:57:53 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Thu, 9 May 2013 12:57:53 -0500 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <87ppx0f5ge.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> <87ppx0f5ge.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <2A3CCFF6-C7AD-4D42-8580-299ABC099B91@dataplex.net> On May 9, 2013, at 12:06 PM, "Stephen J. Turnbull" wrote: > Barry Warsaw writes: >> On May 08, 2013, at 10:31 AM, Richard Wackerbarth wrote: >> >>> I agree with Steve. One of the advantages of Django is its "mix and match" >>> capability. Actually, I see two possible apps. One would integrate with >>> HK. The other would be simpler, just providing a posting mechanism that >>> provides authenticated message sender. > > I'm not sure what you're proposing in terms of "integration". The way > I see it, is HyperKitty or any other app could provide links which > could invoke the web posting app or the user's MUA. The web posting > app would have an URL like > > http://list.example.com/HyperKitty/post/MSG_INIT_INFO > > where MSG_INIT_INFO would have the same format as a mailto: URL. So, > HyperKitty would be in a good position to generate References and so > on for any message in the archive, but other apps would be able to > generate their own special messages. Eg, Roundup could put issue refs > in posting URLs it puts in issue pages. Steve, what you are describing is a possible form of the "integration" that I suggest. However, there may be much more information that should be included. As an example, one might want some kind of automatic "seeding" of a part of the message based on the content of the message referenced Another possibility would be a way to avoid extending some of the links from a multi-linked message. I don't know enough about the details avail to attempt to provide a more precise description. However, we need to keep the "level of integration" issue open until someone (presumedly the student) completes an inventory of reasonable possibilities. I was contrasting that situation with another which simply provides an authenticated submission of a message. My point is that these two (and others) need not be mutually exclusive. From 24.sneha at gmail.com Thu May 9 20:35:03 2013 From: 24.sneha at gmail.com (Sneha Priscilla) Date: Fri, 10 May 2013 00:05:03 +0530 Subject: [Mailman-Developers] Additional GSoC discussion - Better User Settings Management Message-ID: 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 From stephen at xemacs.org Thu May 9 20:58:08 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 10 May 2013 03:58:08 +0900 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <2A3CCFF6-C7AD-4D42-8580-299ABC099B91@dataplex.net> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> <87ppx0f5ge.fsf@uwakimon.sk.tsukuba.ac.jp> <2A3CCFF6-C7AD-4D42-8580-299ABC099B91@dataplex.net> Message-ID: <87li7of0an.fsf@uwakimon.sk.tsukuba.ac.jp> Richard Wackerbarth writes: > However, we need to keep the "level of integration" issue open > until someone (presumedly the student) completes an inventory of > reasonable possibilities. I would like to leave that up to Peter. (We should avoid burdening the students with chores like inventorying possibilities, unless it helps them decide requirements, design the application, and code the implementation.) BTW http://tools.ietf.org/html/rfc6068 describes the mailto: URI. It's remarkably flexible, although the body does present some special problems. From rkw at dataplex.net Thu May 9 21:08:40 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Thu, 9 May 2013 14:08:40 -0500 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <87li7of0an.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> <87ppx0f5ge.fsf@uwakimon.sk.tsukuba.ac.jp> <2A3CCFF6-C7AD-4D42-8580-299ABC099B91@dataplex.net> <87li7of0an.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <7A56D09B-325F-4662-80EA-5B4292E25370@dataplex.net> Yes, I, too, would leave it to Peter. And I am not suggesting that he attempt to make any complete "inventory". But I don't see how you can possibly "decide requirements" without taking them into consideration. On May 9, 2013, at 1:58 PM, "Stephen J. Turnbull" wrote: > Richard Wackerbarth writes: > >> However, we need to keep the "level of integration" issue open >> until someone (presumedly the student) completes an inventory of >> reasonable possibilities. > > I would like to leave that up to Peter. (We should avoid burdening > the students with chores like inventorying possibilities, unless it > helps them decide requirements, design the application, and code the > implementation.) > > BTW http://tools.ietf.org/html/rfc6068 describes the mailto: URI. > It's remarkably flexible, although the body does present some special > problems. From mark at msapiro.net Thu May 9 23:24:24 2013 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 09 May 2013 14:24:24 -0700 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: <518BDD61.6060604@fifthhorseman.net> References: <8761yto5wq.fsf@uwakimon.sk.tsukuba.ac.jp> <3F0BEAC3-28CE-459E-A34B-EC3EC09E2508@dataplex.net> <20130509122820.48979b26@anarchist> <518BD32F.1060309@fifthhorseman.net> <518BD778.9000101@msapiro.net> <518BDD61.6060604@fifthhorseman.net> Message-ID: <518C1408.1070807@msapiro.net> On 05/09/2013 10:31 AM, Daniel Kahn Gillmor wrote: > > On 05/09/2013 01:06 PM, Mark Sapiro wrote: >> Go to >> >> and look at the mailto: link under 'dkg at fifthhorseman.net'. > > wow, great! I have never looked at this link before because i always > assumed it was a link to e-mail the original sender of the message. It can be that. If the global setting ARCHIVER_OBSCURES_EMAILADDRS is True (the default) the text will be of the form 'user at example.com' and the link will address the list. If ARCHIVER_OBSCURES_EMAILADDRS is False, the text will be of the form 'userexample.com' and the link will address the user, but in either case, the In-Reply-To= and Subject= fragments will be included. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From raj.abhilash1 at gmail.com Sat May 11 09:17:25 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sat, 11 May 2013 12:47:25 +0530 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <518BDA11.3020504@fifthhorseman.net> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> Message-ID: On Thu, May 9, 2013 at 10:47 PM, Daniel Kahn Gillmor wrote: > As i about this, i wonder if the OpenPGP integration project shouldn't > be broken into two phases, so that the tricky nuances could be handled > more simply. > > I'm imagining a first phase ("message authentication") would not expect > or handle encrypted messages, but would just use cryptographic > signatures to verify the authenticity of origin of the incoming message, > enhancing (and/or replacing) some of the current checks mailman uses to > decide if a message should be passed on to the list. > > Then the second phase ("encrypted messages") would address the > possibility of having encrypted message content. > > If you can get the "message authentication" phase done properly, you'll > have a good argument that your keyring management is effective, without > getting sidetracked into issues of exactly where the content of the > message might leak (since the messages aren't encrypted at all). > > When the first phase is done, you could focus on the "encrypted > messages" phase, based on the assumption that you have decent keyring > management, and handle the peculiarities and concerns there separately. > > I'm not a mailman developer; but I'd be curious to hear what mailman > devs think of this breakdown. > > More comments and questions below, based on the workflow you've outlined > that mixes "message authentication" with "encrypted messages" and tries > to solve them all at once: > After the Barry's comment on my proposal I decided to cut down the proposal to implement use of OpenPGP signatures for posting privileges instead of both signed and encrypted list. Most of the infrastructure for encrypted list will be created along with this project so that later on it can also be implemented easily. Though I would like to continue this discussion on encrypted list for future reference. Some of these questions are already answered in my proposal here[1]. > On 05/09/2013 01:31 AM, Abhilash Raj wrote: >> Consider this flow of message from one user to all list-subscribers: >> >> * A user sends a message( signed as well as encrypted )which as soon as >> received by mailman is first queued in "IN" queue. > > who does the sender encrypt the message to? are we talking about a > public key associated with the list? how does the sender learn of that > public key? Sender encrypts the message to list's pub key. List's pub-private keypair is uploaded by the list's owner when he creates the list. Subscribers gets to download the list's pub-key when he subscribes to it. > >> * When the incoming runner wakes up the message is checked if it is for >> owners, posting or encrypted.An encrypted chain is created for >> encrypted messages. > > what if it is an encrypted message sent to "owners"? how does that get > handled? So for both regular posting and owners we can add separate chains say encypted_posting, encrypted_owners. >> * Now according to the use case there can be two encrypted chain: >> >> 1) Where the posters are fully trusted and thus this rules only checks >> the signature of a message. If a message signed by a member is received >> it is sent to pipeline queue in a encrypted form for further processing. > > when you say "fully trusted" it might be worth saying what they are > trusted for. I think here you mean "fully trusted to post messages > without moderation". > Yes. > What happens if the message cannot be decrypted by the mailing list and > the signature is inside the encryption? does the message bounce? > Yes, it would bounce. > what if the decryption succeeds but there is no message signature inside it? > In that case a notification is sent to the sender with only the headers of the decrypted message that the signature of the message does not match. If it is not sent by him he is asked to ignore the notification. > what if the signature appears to be valid, but was made 3 years ago (or > in the future)? Is that a problem if he has not revoked his signature yet? > what if the signature appears to be valid, and recent, but is the same > signature that was used on a previous e-mail to the list? Can there be same signatures for different messages? I think the digital signature is created by encrypting the message-hash, so if the contents of the message are changed then signature cannot be valid. > what if the signature is cryptographically valid, but the list member's > key has expired? Well a expired key cannot be used to sign messages. If this situation happens this means it was signed in past some time ago. We can bounce the message and notify the user about this. > what if only part of the message is signed? My guess is that you are referring to inline-pgp. I read this article which talks about the inline-pgp as a bad messaging format. I think we should not support this. So if the message is partially signed it should probably bounce back. >> 2) Where the posters are not fully trusted. In this case there needs to >> be various checks on decrypted message like current default-posting-chain. > > One common thing that might happen here is that the message is being > held for moderation. if the message is encrypted, how is a moderator > supposed to review it and make a decision? Yes this might be an issue, will have to think for something for this. >> * The messaged is moved in between queues in the encrypted form >> encrypted by a symmetric key algorithm which uses list's secret key to >> encrypt the message. > > this doesn't make sense to me. when i hear "list's secret key" i tend > to think people are talking about asymmetric encryption, but it seems > here that you're talking about symmetric encryption. Maybe it would > help to enumerate exactly what secrets each entity holds (and maybe what > public data is associated with those secrets, in the case of the > public/private keypairs used by asymmetric crypto). If you give those > secrets names, you can refer to them more concisely and precisely. Sorry to sound so confusing. What I actually meant was that we use public-private key encryption via OpenPGP so send and receive signed and encrypted messages. Now each list has a public-private keypair which the list owner uploads when he creates the list. During processing of the message inside mailman it is decrypted and sometimes stored on disk as python pickles in various queues which is bad for security reasons. I propose that when it is being stored on disk it can be encrypted using a symmetric key encryption algorithm so that only one who has access to list's secret key can decrypt it. When the message is being sent to the subscribers it is encrypted with the user's pub-key so that only he can decrypt it. >> * When the pipeline handler wakes up it decides which pipeline the >> message is to passed through. In this case an encrypted_posting_pipeline >> is created to process an encrypted message. > > which case is "this case" are we talking here about every encrypted > message or just a subset of them? Currently pipeline runner( not handler, typo last time ) decides which pipeline will process the message. For the encrypted message we add another pipeline encrypted_posting_pipeline to process all encrypted message that are to be posted. For message to the owners we can have another different pipeline. > >> * This encrypted_posting_pipeline is used to keep the message in >> plain-text for a minimal time. The message is decrypted, headers and >> footers are added and the message is signed by list's pub-key. It is >> then again (symmetrically) encrypted and stored in the outgoing queue. > > public keys don't sign messages; secret keys can sign messages, and > public keys are used to verify those signatures. Yes, sorry again a typo! > what happens to the original sender's signature? is it stripped? or > does it remain, nested within the list's signature? How are list > members expected to verify these signatures? The original sender's signature is stripped. I guess the list subscribers just have to trust that the list owner. We cannot expect each member of the list to have every other member's pub-key to separately verify himself that the message is indeed from the sender. > i'm again confused by the symmetrical encryption proposal here. > >> * The outgoing runner personalizes each message by encrypting it with >> each user's pub key and forwards it to MTA using VERP(Variable Envelop >> Return Path). > > What happens if a user's public key is found to be expired or revoked? > How does mailman become aware of revocations, of extensions of the > expiration date, or of new keys or certificates for any given user? If the user has his key uploaded to a public key server and wants( he will be given option of whether ot not to) mailman to check , mailman can periodically check for revocation and expiration of the key. Though i don't know how will that be done. New keys will be added by user only from postorius after a confirmation link is sent to him on the address the key verifies. > i hope these questions are useful, Yes, I had not though about revocation and expiration issues. Thanks for it. > > --dkg > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://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: http://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 [1] : https://gist.github.com/maxking/5455462 -- Abhilash Raj From markoupetr at gmail.com Mon May 13 15:49:19 2013 From: markoupetr at gmail.com (Peter Markou) Date: Mon, 13 May 2013 16:49:19 +0300 Subject: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface. In-Reply-To: References: Message-ID: 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 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. > From varunsharmalive at gmail.com Mon May 13 19:22:11 2013 From: varunsharmalive at gmail.com (varun sharma) Date: Mon, 13 May 2013 22:52:11 +0530 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Tue, May 7, 2013 at 10:39 AM, Stephen J. Turnbull wrote: > 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)? Hi, I apologize for replying to this post so late. I was having my end semester exams last week, also i should have given more examples in my previous post. As mentioned in my previous post, now i don't think there is any immediate requirement to add more instance methods to _client module, although some changes can be made in some cases so that more data from mailman core interfaces (which is required to add the proposed features) can be fetched with rest api calls. Below are some examples of an possible implementation and core requirements for getting the required data from mailman core using rest api. New Features: 1. Suspend emails in vacation and post from multiple email ids: IMember interface present in interfaces/member.py is already providing the delivery_status enum in _client module via rest api but the user.save() is currently not functional, so the member preferences are not getting saved right now. Similarly, IUser interface in interfaces/user.py is providing the user.addresses attribute from IAddress interface to _client module but due to the problem of user object not getting saved, this functionality is also not working. For these two features, i don't think there is any requirement from mailman core interfaces. 2. Merge identities : Not exactly sure about additional core requirements, but i think it can be achieved by expanding IAddress interface. 3. User permissions management : role attribute from IMember interface is being called in _Member of _client module. It can be used along with other role options from MemberRole to create a django form for user role management. Only the owner should have the right to modify the member roles. This should be functional if user.save() is fixed and here also i do not see any changes required in the core. 4. Digest subscriptions from selected lists : delivery_mode attribute from IMember interface is called in _Member preferences. As multiple members can point to same user, so digest subscriptions for each member can be managed separately with no additional changes in the core. 5. Domain page for every domain and ToDo Feature : IDomain interface is providing all the required attributes to the _Domain, so creating separate pages for every domain should not be a difficult task. Regarding ToDo feature i need advice and help in creating a possible implementation from community. Right now, what i have in my mind is that all the pending tasks should automatically be added to the ToDo queue and should be removed automatically upon completion of the required task. I think there is a need to create some sort of task queue in the core for that. Improvements: 1. Edit/delete users : delete_user method in _User from IUserManager interface is working fine. Fixing of user.save() should fix this problem of editing user preferences as well. So no change in core is required for this part. 2. Multi-addresses management in postorius: addresses attribute from IUser and IAddress interfaces can be used to manage the multiple addresses. creating a django form to manage the multiple addresses should not take much time. 3. List subscribe/unsubscribe and subscription settings: django template for list settings can be modified according to the delivery_status attribute of member. The list subscription can be queried by get_member method which returns the member object for the list and it can be used in subscriptions settings page also. > 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? > > I may have misinterpreted it completely but I think the additional data can be managed by django models as the additional data is not required in mailman core,so a link can be established between the django User model and mailman user just for the purpose of identifying the additional user data. This will enable a login interface for all the users and the additional user data can be stored in a different django model. So, i think there is a need to do some changes in core for ToDo queue management and for merging of different identities for now. I will be able to find the exact implementation in next few weeks as i am following the book "restful web services" for learning the rest basics and started following some zope interface tutorials. Waiting for feedback from community. Thanks Varun Sharma From dkg at fifthhorseman.net Fri May 17 01:46:23 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 May 2013 19:46:23 -0400 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> Message-ID: <51956FCF.8060506@fifthhorseman.net> On 05/11/2013 03:17 AM, Abhilash Raj wrote: > After the Barry's comment on my proposal I decided to cut down the > proposal to implement use of OpenPGP signatures for posting > privileges instead of both signed and encrypted list. > Most of the infrastructure for encrypted list will be created along > with this project so that later on it can also be implemented easily. I think this is the right decision. Some of the discussion below is only relevant for the larger-scope project. but some of it is relevant to your revised-scope project as well. I've tried to indicate the latter concerns by flagging them with ***SIGNED_POSTS*** > Sender encrypts the message to list's pub key. List's pub-private > keypair is uploaded by the list's owner when he creates the list. > Subscribers gets to download the list's pub-key when he subscribes to > it. You're saying here that the list has a secret key (i'll call that LK_sec) and the corresponding public key is well-known (i'll call that LK_pub). in OpenPGP terms, keys have "usage flags" or "key capabilities": https://tools.ietf.org/html/rfc4880#section-5.2.3.21 It sounds like you're saying that we should mark this key as "encryption capable", which is usually indicated with two bits set: 0xc ***SIGNED_POSTS*** Might there be a reason for the list to have a keypair associated with it even for cleartext messages? e.g. might the list send out signed messages that users might want to verify? >> what if the decryption succeeds but there is no message signature inside it? > > In that case a notification is sent to the sender with only the > headers of the decrypted message that the signature of the message > does not match. If it is not sent by him he is asked to ignore the > notification. you say "with only the headers" -- is there ever a time when a bounce message might contain the message content? >> what if the signature appears to be valid, but was made 3 years ago (or >> in the future)? > > Is that a problem if he has not revoked his signature yet? ***SIGNED_POSTS*** Well, it could be a replay of an old message from 5 years ago from another list member. Should it be sent to the list again? >> what if the signature appears to be valid, and recent, but is the same >> signature that was used on a previous e-mail to the list? > > Can there be same signatures for different messages? I think the > digital signature is created by encrypting the message-hash, so if the > contents of the message are changed then signature cannot be valid. ***SIGNED_POSTS*** it could be a replay of a recent message, which would naturally use the same signature. But the headers could be modified. For example, the Message-ID isn't contained in the signature. >> what if the signature is cryptographically valid, but the list member's >> key has expired? > > Well a expired key cannot be used to sign messages. If this situation > happens this means it was signed in past some time ago. We can bounce > the message and notify the user about this. ***SIGNED_POSTS*** What if the message signature has a date that precedes the key expiry? >> what if only part of the message is signed? > My guess is that you are referring to inline-pgp. I read this article > which talks about the inline-pgp as a bad messaging format. I think we > should not support this. So if the message is partially signed it > should probably bounce back. ***SIGNED_POSTS*** Both inline PGP and PGP/MIME can have partial message signatures. I happen to agree that supporting inline PGP is problematic, so i'm willing to ignore it for now if that's the consensus of the project. be aware that you will find some pushback here, though, because there remain some broken MUAs that not only can't generate PGP/MIME, but can't display a clearsigned PGP/MIME e-mail to their users. When you think of PGP/MIME, you probably think of messages like message A below: A???multipart/signed 3099 bytes B ???text/plain 1527 bytes C ???application/pgp-signature attachment [signature.asc] 1027 bytes But consider a MIME message D of the following form D???multipart/mixed 7346 bytes E ???multipart/signed 3099 bytes F ????text/plain 1527 bytes G ????application/pgp-signature attachment [signature.asc] 1027 bytes H ???text/plain inline 424 bytes the text in part F is signed by the signature in part G. So you could argue that the subtree rooted at E is "a signed message in some sense. What kind of messages look like D? where do they come from? (hint: examine the MIME structure of this message itself) >>> * The messaged is moved in between queues in the encrypted form >>> encrypted by a symmetric key algorithm which uses list's secret key to >>> encrypt the message. >> >> this doesn't make sense to me. when i hear "list's secret key" i tend >> to think people are talking about asymmetric encryption, but it seems >> here that you're talking about symmetric encryption. Maybe it would >> help to enumerate exactly what secrets each entity holds (and maybe what >> public data is associated with those secrets, in the case of the >> public/private keypairs used by asymmetric crypto). If you give those >> secrets names, you can refer to them more concisely and precisely. > > Sorry to sound so confusing. What I actually meant was that we use > public-private key encryption via OpenPGP so send and receive signed > and encrypted messages. Now each list has a public-private keypair > which the list owner uploads when he creates the list. I'm with you so far... > During processing of the message inside mailman it is decrypted and > sometimes stored on disk as python pickles in various queues which is > bad for security reasons. I propose that when it is being stored on > disk it can be encrypted using a symmetric key encryption algorithm so > that only one who has access to list's secret key can decrypt it. And here you've lst me again. the lists's secret key (LK_sec) is by definition for use in asymmetric cryptographic schemes. why are you saying "using a symmetric key encryption algorithm" here? > When the message is being sent to the subscribers it is encrypted with > the user's pub-key so that only he can decrypt it. This hand-waves around the difficult question: how do we know what the user's pub-key is? >> what happens to the original sender's signature? is it stripped? or >> does it remain, nested within the list's signature? How are list >> members expected to verify these signatures? > > The original sender's signature is stripped. I guess the list > subscribers just have to trust that the list owner. We cannot expect > each member of the list to have every other member's pub-key to > separately verify himself that the message is indeed from the sender. there are other options. for example, the list could *add* its signature to the message without stripping the signature of the original author, so that recipients could verify one or the other or both. ***SIGNED_POSTS*** This is also relevant in the reduced-scope project; is it possible that the mailing list might want to re-sign existing signed messages so that people who receive mails from the mailing list can verify that they really came from the mailing list? >> What happens if a user's public key is found to be expired or revoked? >> How does mailman become aware of revocations, of extensions of the >> expiration date, or of new keys or certificates for any given user? > > If the user has his key uploaded to a public key server and wants( he > will be given option of whether ot not to) mailman to check , mailman > can periodically check for revocation and expiration of the key. > Though i don't know how will that be done. ***SIGNED_POSTS*** Why would mailman *not* check the public keyservers? why should this be an option? If you're going to be using the OpenPGP public keyservers as a regular/possibly-heavy-duty client, i recommend asking any questions you have about the interaction with the keyservers over in the development list for SKS (which is currently the dominant keyserver implementation): SKS development list The protocol used is HKP, and there is a major global pool of gossiping keyservers that you can talk to. for more details about the pool, see: https://sks-keyservers.net/ > New keys will be added by user only from postorius after a > confirmation link is sent to him on the address the key verifies. ***SIGNED_POSTS*** Will that confirmation link be sent in the clear, or will it be encrypted to the user's public key? if the answer is "encrypted", what if the user's key is not encryption-capable? If the user is trying to change keys, will the confirmation message be encrypted to the user's old key or to their new one? Mailman has traditionally been accessible to people who do not browse the web by making use of its e-mail interface. will there be a way to add or adjust keys via e-mail as well? ----------- What about the monthly "you're subscribed to this list" e-mails mailman sends out? What about "reset your password" e-mails? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From barry at list.org Fri May 17 21:54:16 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 17 May 2013 15:54:16 -0400 Subject: [Mailman-Developers] GSoC discussion In-Reply-To: <5D19BE89-57CA-4228-B47A-81DEB41C9E6C@dataplex.net> References: <87ip2uody9.fsf@uwakimon.sk.tsukuba.ac.jp> <5D19BE89-57CA-4228-B47A-81DEB41C9E6C@dataplex.net> Message-ID: <20130517155416.4989a4b6@anarchist> On May 07, 2013, at 06:58 PM, Richard Wackerbarth wrote: >I was comparing what a consumer of the Postorius interface might like to see >that is not just a proxy forwarding the MM-core interface. > >As an example, rather than all of the lists, just those lists for which the >represented user is the administrator. This is definitely aligned with how I see an authenticated (i.e. public) REST API working. The private/admin API gives you everything, while the public one would only provide you the limited subset of things you're allowed to do. Or put it another way, the private API doesn't know who you are[1] so it can't limit your access. The public API does know who you are, and so it must only present to you the resources and actions that you're authenticated for. -Barry [1] Except in the sense that you're essentially root to the Mailman core. From barry at list.org Fri May 17 22:16:48 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 17 May 2013 16:16:48 -0400 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20130517161648.5691c17e@anarchist> On May 13, 2013, at 10:52 PM, varun sharma wrote: >1. Suspend emails in vacation and post from multiple email ids: >IMember interface present in interfaces/member.py is already providing the >delivery_status enum in _client module via rest api but the user.save() is >currently not functional, so the member preferences are not getting saved >right now. Similarly, IUser interface in interfaces/user.py is providing >the user.addresses attribute from IAddress interface to _client module but >due to the problem of user object not getting saved, this functionality is >also not working. For these two features, i don't think there is any >requirement from mailman core interfaces. I think to do vacations right, you will need some additional support in the core. One question to answer first is: what's the scope of a vacation stop? Does it apply to an address, user, member, or all of the above? For example: when I go on vacation, do I want all deliveries to stop to all mailing lists I'm subscribed to on a particular site, or just to some subscriptions? My thinking is that two use cases would be good to support: - Stop all deliveries from this site for a user. This would mean setting vacation stops for all of the user's subscriptions to all of their mailing lists on a domain (it probably should not be cross-domain). - Stop all deliveries for a specific subscription or list of subscriptions. For example, when I go on vacation, I might want to only receive mailman-developers traffic but nothing else from python.org. These two use cases imply to me that a vacation stop is tied to a subscription (i.e. an IMember) and a global stop is just a trivial case of a set of specific stops. A few other core-touching changes: - The expiration date for a vacation stop should be set when the stop is created. A user should not have to do anything to start getting their email again. When the expiration date passes, the traffic starts up again. - You should be able to set a vacation stop to start sometime in the future. E.g. I know I am going on vacation from next Tuesday to Friday, so let me set that up now while I'm thinking about it. Don't make me wait until Tuesday morning when I'm freaking out about catching my flight. :) - You should be able to query the system to see what vacation stops you have coming up, or are in progress. Maybe even view the history of your vacation stops (but that implies more record keeping, so maybe not). - You should be able to adjust the start and end dates of the vacation stop, if they haven't already passed. You could use this to extend a vacation, or change the start date to Monday if you have to leave early. A special case of this would also be to cancel a vacation stop right now. - Remember that vacations shouldn't be used as a way to more permanently disable delivery to a mailing list. All of this implies to me a new table/record which records future and non-expired vacation stops. The table would have a start and end datetime and a link to an IMember. Then likely the member_recipients.py handler would take these stops into account when calculating who to deliver this message to. Question: Should you be able to add a vacation stop to moderator or owner emails? >2. Merge identities : >Not exactly sure about additional core requirements, but i think it can be >achieved by expanding IAddress interface. Mostly this will be able sending out and coordinating the various confirmations messages that will be necessary. E.g. you're logged in as anne at example.com and you make a claim to merge aperson at example.com. You need to prove that you own the latter address too in some way. Once you've confirmed ownership of both addresses, you need to IUser.link() them both to the same IUser. This may involve unlinking and deleting an obsolete IUser record from an IAddress. Cheers, -Barry From rkw at dataplex.net Fri May 17 23:58:37 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Fri, 17 May 2013 16:58:37 -0500 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <20130517161648.5691c17e@anarchist> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> On May 17, 2013, at 3:16 PM, Barry Warsaw wrote: > Question: Should you be able to add a vacation stop to moderator or owner emails? Would it be easier if we just treated owners and moderators as a couple of additional mailing lists. In other words, for list XXX at example.com, we also have virtual lists @example.com and @example.com Where the list names are accessible only from within MM. Thus a moderator would be subscribed to the list and that subscription handled just as any other subscription would be handled. From stephen at xemacs.org Sat May 18 04:38:23 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 18 May 2013 11:38:23 +0900 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> Message-ID: <8761yhc8rk.fsf@uwakimon.sk.tsukuba.ac.jp> Richard Wackerbarth writes: > Would it be easier if we just treated owners and moderators as a > couple of additional mailing lists. That would require additional, complex attributes that aren't appropriate for most lists to be given to all lists. They'd have to have a .virtual_list_for attribute, for example. If non-null, you can't post to it. (Or can you? Messy.) The owner list would have to have a .cant_delete_last_subscriber attribute. These lists need to be suppressed when working with the set of "real" mailing lists. These lists should be exempted from spam-checking since only Mailman core ever posts to them. (Or should they? See above.) I think this all violates duck-typing and gets messier, not easier. > Thus a moderator would be subscribed to the list > and that subscription handled just as any other subscription would > be handled. I don't think this will fit users' models of the moderator and owner roles. Mailing lists have moderators, not an auto-generated associated mailing list containing only the moderators. My $0.02. Steve From rkw at dataplex.net Sat May 18 05:55:12 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Fri, 17 May 2013 22:55:12 -0500 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <8761yhc8rk.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> <8761yhc8rk.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <12789451-80F3-40CF-9681-D18F28EB13E6@dataplex.net> I'm not convinced that it would require all of the items that you enumerate. First, you have to look at how messages might get to the list. Since I specified that the list was a virtual list (unreachable), the only source of messages would be from the internal queue handlers. Thus they would bypass spam filters, etc. and go directly to the distribution queue. True, we would have to make the lists "hidden" to normal users. But this is not a significant change in list handling. We already have the requirement to hide other lists. As for "empty lists", that is really a function of how empty lists are handled in general. Perhaps a "divert if empty" policy should be available for all lists. And, at the top of the chain we assure a "last desperation" address because no-one has the right to delete THAT one entry. I agree that it might be messier. But it still might be cleaner if you want the moderators, etc. to have all of the "subscription options" On May 17, 2013, at 9:38 PM, Stephen J. Turnbull wrote: > Richard Wackerbarth writes: > >> Would it be easier if we just treated owners and moderators as a >> couple of additional mailing lists? > > That would require additional, complex attributes that aren't > appropriate for most lists to be given to all lists. They'd have to > have a .virtual_list_for attribute, for example. If non-null, you > can't post to it. (Or can you? Messy.) The owner list would have to > have a .cant_delete_last_subscriber attribute. These lists need to be > suppressed when working with the set of "real" mailing lists. These > lists should be exempted from spam-checking since only Mailman core > ever posts to them. (Or should they? See above.) I think this all > violates duck-typing and gets messier, not easier. > >> Thus a moderator would be subscribed to the list >> and that subscription handled just as any other subscription would >> be handled. > > I don't think this will fit users' models of the moderator and owner > roles. Mailing lists have moderators, not an auto-generated > associated mailing list containing only the moderators. That all depends on how you present it, not on how you implement it. IIRC, the list of moderators is a roster, just like the subscribers. A different template can make two rosters appear to be quite different. > My $0.02. 2 yen :) > Steve From stephen at xemacs.org Sat May 18 07:29:04 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 18 May 2013 14:29:04 +0900 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <12789451-80F3-40CF-9681-D18F28EB13E6@dataplex.net> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> <8761yhc8rk.fsf@uwakimon.sk.tsukuba.ac.jp> <12789451-80F3-40CF-9681-D18F28EB13E6@dataplex.net> Message-ID: <8738tkdffj.fsf@uwakimon.sk.tsukuba.ac.jp> Richard Wackerbarth writes: > I agree that it might be messier. But it still might be cleaner if > you want the moderators, etc. to have all of the "subscription > options" We don't. Some are meaningless (notMeToo, noDups), some should not be available (noMail -- at least not if a vacation facility is available). I don't contest that there are strong similarities between a "list of moderators" and a "mailing list of subscribers". What I'm saying is that they're not the same, there are several variations on the theme, and we must strongly consider deriving them from a more general type. > > I don't think this will fit users' models of the moderator and owner > > roles. Mailing lists have moderators, not an auto-generated > > associated mailing list containing only the moderators. > > That all depends on how you present it, not on how you implement > it. IIRC, the list of moderators is a roster, just like the > subscribers. A different template can make two rosters appear to > be quite different. The developers are users too, though. I think the implementation, not just the presentation, should correspond to our notions of "what things are." Steve From rkw at dataplex.net Sat May 18 13:03:53 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Sat, 18 May 2013 06:03:53 -0500 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <8738tkdffj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> <8761yhc8rk.fsf@uwakimon.sk.tsukuba.ac.jp> <12789451-80F3-40CF-9681-D18F28EB13E6@dataplex.net> <8738tkdffj.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1670790B-F4C2-4C63-B176-77720303F30A@dataplex.net> On May 18, 2013, at 12:29 AM, "Stephen J. Turnbull" wrote: > I don't contest that there are strong similarities between a "list of > moderators" and a "mailing list of subscribers". What I'm saying is > that they're not the same, there are several variations on the theme, > and we must strongly consider deriving them from a more general type. >>> I don't think this will fit users' models of the moderator and owner >>> roles. Mailing lists have moderators, not an auto-generated >>> associated mailing list containing only the moderators. >> >> That all depends on how you present it, not on how you implement >> it. IIRC, the list of moderators is a roster, just like the >> subscribers. A different template can make two rosters appear to >> be quite different. > > The developers are users too, though. I think the implementation, not > just the presentation, should correspond to our notions of "what > things are." Yes. But, as you note, "what things are" can be viewed as two cases of a "distribution list". And that conceptual object can include more of the characteristics of a mailing list than just "a roster". It is often useful to look for similarities rather than differences. > Steve From varunsharmalive at gmail.com Sun May 19 07:56:12 2013 From: varunsharmalive at gmail.com (varun sharma) Date: Sun, 19 May 2013 11:26:12 +0530 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <20130517161648.5691c17e@anarchist> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: Thanks barry, you have very well explained both the use cases to me. On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw wrote: > On May 13, 2013, at 10:52 PM, varun sharma wrote: > > >1. Suspend emails in vacation and post from multiple email ids: > >IMember interface present in interfaces/member.py is already providing the > >delivery_status enum in _client module via rest api but the user.save() is > >currently not functional, so the member preferences are not getting saved > >right now. Similarly, IUser interface in interfaces/user.py is providing > >the user.addresses attribute from IAddress interface to _client module but > >due to the problem of user object not getting saved, this functionality is > >also not working. For these two features, i don't think there is any > >requirement from mailman core interfaces. > > I think to do vacations right, you will need some additional support in the > core. One question to answer first is: what's the scope of a vacation > stop? > Does it apply to an address, user, member, or all of the above? > > For example: when I go on vacation, do I want all deliveries to stop to all > mailing lists I'm subscribed to on a particular site, or just to some > subscriptions? My thinking is that two use cases would be good to support: > > - Stop all deliveries from this site for a user. This would mean setting > vacation stops for all of the user's subscriptions to all of their > mailing > lists on a domain (it probably should not be cross-domain). > > - Stop all deliveries for a specific subscription or list of subscriptions. > For example, when I go on vacation, I might want to only receive > mailman-developers traffic but nothing else from python.org. > > These two use cases imply to me that a vacation stop is tied to a > subscription > (i.e. an IMember) and a global stop is just a trivial case of a set of > specific stops. > > A few other core-touching changes: > > - The expiration date for a vacation stop should be set when the stop is > created. A user should not have to do anything to start getting their > email > again. When the expiration date passes, the traffic starts up again. > > - You should be able to set a vacation stop to start sometime in the > future. > E.g. I know I am going on vacation from next Tuesday to Friday, so let me > set that up now while I'm thinking about it. Don't make me wait until > Tuesday morning when I'm freaking out about catching my flight. :) > > - You should be able to query the system to see what vacation stops you > have > coming up, or are in progress. Maybe even view the history of your > vacation > stops (but that implies more record keeping, so maybe not). > > - You should be able to adjust the start and end dates of the vacation > stop, > if they haven't already passed. You could use this to extend a > vacation, or > change the start date to Monday if you have to leave early. A special > case > of this would also be to cancel a vacation stop right now. > > - Remember that vacations shouldn't be used as a way to more permanently > disable delivery to a mailing list. > > All of this implies to me a new table/record which records future and > non-expired vacation stops. The table would have a start and end datetime > and > a link to an IMember. Then likely the member_recipients.py handler would > take > these stops into account when calculating who to deliver this message to. > > 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. >2. Merge identities : > >Not exactly sure about additional core requirements, but i think it can be > >achieved by expanding IAddress interface. > > Mostly this will be able sending out and coordinating the various > confirmations messages that will be necessary. E.g. you're logged in as > anne at example.com and you make a claim to merge aperson at example.com. You > need > to prove that you own the latter address too in some way. > > Once you've confirmed ownership of both addresses, you need to IUser.link() > them both to the same IUser. This may involve unlinking and deleting an > obsolete IUser record from an IAddress. > > Cheers, > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://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: > http://mail.python.org/mailman/options/mailman-developers/varunsharmalive%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > From rkw at dataplex.net Sun May 19 14:02:14 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Sun, 19 May 2013 07:02:14 -0500 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw 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 From varunsharmalive at gmail.com Sun May 19 18:38:56 2013 From: varunsharmalive at gmail.com (varun sharma) Date: Sun, 19 May 2013 22:08:56 +0530 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: Hi Richard, I think you have misunderstood my paragraph to be barry's. I was suggesting the adding up of pending tasks of moderators and list owners to their "ToDo" list during their vacation period with suspension of email. The phrase which you have mentioned, might be confusing. But actually i was talking about two different operations. 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.The todo queue will remain updated. 2. The second thing is some moderators might be interested in knowing the administrative changes done in their absence. So they should receive a summary of the tasks done(eg. users added) in their absence once they come back from vacation.This was what i was talking about in that paragraph. On 5/19/13, Richard Wackerbarth wrote: > On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw 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 > > From stephen at xemacs.org Sun May 19 19:22:18 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 20 May 2013 02:22:18 +0900 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: <87wqquc2b9.fsf@uwakimon.sk.tsukuba.ac.jp> 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). From rkw at dataplex.net Sun May 19 22:06:22 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Sun, 19 May 2013 15:06:22 -0500 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: <62E713D7-3DB9-466B-A311-43E7F9996CDD@dataplex.net> Varun, Perhaps I did miss-attribute the material. Thank you for pointing it out. I offer my apologies for doing so. Sometimes the "quote levels" get confused and it is not easy to tell which author provided some particular text. Since you appear to be the one responsible for the suggested behavior, would you please address the concerns that I raised about it. In particular, consider what mechanisms would be needed to handle your item 2 below (Knowing changes ...) What if there are multiple moderators who go on overlapping vacations? Richard On May 19, 2013, at 11:38 AM, varun sharma wrote: > Hi Richard, > I think you have misunderstood my paragraph to be barry's. I was > suggesting the adding up of pending tasks of moderators and list > owners to their "ToDo" list during their vacation period with > suspension of email. > The phrase which you have mentioned, might be confusing. But actually > i was talking about two different operations. > 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.The todo queue will remain > updated. > 2. The second thing is some moderators might be interested in knowing > the administrative changes done in their absence. So they should > receive a summary of the tasks done(eg. users added) in their absence > once they come back from vacation.This was what i was talking about in > that paragraph. > > On 5/19/13, Richard Wackerbarth wrote: >> On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw 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 >> >> From varunsharmalive at gmail.com Mon May 20 08:01:54 2013 From: varunsharmalive at gmail.com (varun sharma) Date: Mon, 20 May 2013 11:31:54 +0530 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <62E713D7-3DB9-466B-A311-43E7F9996CDD@dataplex.net> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <62E713D7-3DB9-466B-A311-43E7F9996CDD@dataplex.net> Message-ID: Hi Steve, I think it will be a good idea to provide an option of digests, as the case you have mentioned may occur in a real situation. Hi Richard, Lets take an example of a moderator of some mailing list: ==Before going on vacaton== 1. If someone sends a "new user" request, the moderator will receive an email in real time about request. 2. The task will be added to his and other moderators' ToDo list. ==During Vacation== 1. If someone sends a "new user" request, the moderator "on vacation" will NOT receive any email about pending "add user" request. 2. The task will be added to his and other moderators' ToDo list. ==After Vacation== 1. He will receive all the emails as he was receiving before going on vacation. 2. The pending tasks will show up in his ToDo queue 3. He will receive an email about the tasks done in his absence 4. He will receive email about pending tasks that were added to his ToDo list and are still pending. So, I think the overlapping vacation may be handled in two ways: 1. Follow up the procedure as written above , i.e: If there are multiple moderators going on vacation for same span of time, then the tasks will remain pending in their ToDo list .During vacations, they can login to the postorius and see their pending tasks, but there won't be any email notifications about the pending tasks during the vacation period. But there will be no mailing list delivery. 2. Second option as it came to my mind after you mentioned this case is that, the last moderator(assuming all other moderators have already set thier "on vacation" mode without digests) going on vacation will not be allowed to completely opt-out of emails. As steve suggested, we can provide a digest mode for notifications also. So the last moderator going on vacation will have to choose "digest" mode for notifications as well as mailing list mail delivery if he want to go on vacation :) On Mon, May 20, 2013 at 1:36 AM, Richard Wackerbarth wrote: > Varun, > > Perhaps I did miss-attribute the material. Thank you for pointing it out. > I offer my apologies for doing so. Sometimes the "quote levels" get > confused and it is not easy to tell which author provided some particular > text. > > Since you appear to be the one responsible for the suggested behavior, > would you please address the concerns that I raised about it. > > In particular, consider what mechanisms would be needed to handle your > item 2 below (Knowing changes ...) > What if there are multiple moderators who go on overlapping vacations? > > Richard > > On May 19, 2013, at 11:38 AM, varun sharma > wrote: > > > Hi Richard, > > I think you have misunderstood my paragraph to be barry's. I was > > suggesting the adding up of pending tasks of moderators and list > > owners to their "ToDo" list during their vacation period with > > suspension of email. > > The phrase which you have mentioned, might be confusing. But actually > > i was talking about two different operations. > > 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.The todo queue will remain > > updated. > > 2. The second thing is some moderators might be interested in knowing > > the administrative changes done in their absence. So they should > > receive a summary of the tasks done(eg. users added) in their absence > > once they come back from vacation.This was what i was talking about in > > that paragraph. > > > > On 5/19/13, Richard Wackerbarth wrote: > >> On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw 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 > >> > >> > > From rkw at dataplex.net Mon May 20 13:39:46 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Mon, 20 May 2013 06:39:46 -0500 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <62E713D7-3DB9-466B-A311-43E7F9996CDD@dataplex.net> Message-ID: <1993ED1C-25E5-428C-8509-7F7951AF407F@dataplex.net> Varun, It is easy to say "He will receive an email about the tasks done in his absence". However, how do you propose to compose that email? Where and how is the information used to construct the email stored while the moderator is on vacation. If on a queue, which queue? ... etc. You seem to imply that each individual has a ToDo list of tasks. If that is the case, in the normal course of business, how will you handle the situation when there are two or more moderators and one of them processes a request. Richard On May 20, 2013, at 1:01 AM, varun sharma wrote: > Hi Steve, > I think it will be a good idea to provide an option of digests, as the case you have mentioned may occur in a real situation. > > Hi Richard, > Lets take an example of a moderator of some mailing list: > > ==Before going on vacaton== > 1. If someone sends a "new user" request, the moderator will receive an email in real time about request. > 2. The task will be added to his and other moderators' ToDo list. > > ==During Vacation== > 1. If someone sends a "new user" request, the moderator "on vacation" will NOT receive any email about pending "add user" request. > 2. The task will be added to his and other moderators' ToDo list. > > ==After Vacation== > 1. He will receive all the emails as he was receiving before going on vacation. > 2. The pending tasks will show up in his ToDo queue > 3. He will receive an email about the tasks done in his absence > 4. He will receive email about pending tasks that were added to his ToDo list and are still pending. From varunsharmalive at gmail.com Mon May 20 14:29:34 2013 From: varunsharmalive at gmail.com (varun sharma) Date: Mon, 20 May 2013 17:59:34 +0530 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <1993ED1C-25E5-428C-8509-7F7951AF407F@dataplex.net> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <62E713D7-3DB9-466B-A311-43E7F9996CDD@dataplex.net> <1993ED1C-25E5-428C-8509-7F7951AF407F@dataplex.net> Message-ID: Hi Richard, Currently i have no idea how to implement getting content for tasks done in the absence of a moderator in the core but i am working on understanding core in detail. I found it as an interesting feature, so i suggested it. However it can be skipped also as it is only an add-on feature to vacation suspension. What i have interpreted from ToDo list is that it is a common task queue for every user with same role and will get cleaned up as soon as one of the user with sane role completes the work given in his ToDo list. eg: For a new add user request, if one of the moderator accepts/declines it,then it will get cleaned up from other moderators' ToDo list also. However what i have proposed for core is without knowing the actual implementation of core, so i may have proposed some silly/impossible features for "vacation suspension". Please let me know if there are any. Thanks Varun On Mon, May 20, 2013 at 5:09 PM, Richard Wackerbarth wrote: > Varun, > > It is easy to say "He will receive an email about the tasks done in his > absence". However, how do you propose to compose that email? > Where and how is the information used to construct the email stored while > the moderator is on vacation. If on a queue, which queue? ... etc. > > You seem to imply that each individual has a ToDo list of tasks. If that > is the case, in the normal course of business, how will you handle the > situation when there are two or more moderators and one of them processes a > request. > > Richard > > On May 20, 2013, at 1:01 AM, varun sharma > wrote: > > > Hi Steve, > > I think it will be a good idea to provide an option of digests, as the > case you have mentioned may occur in a real situation. > > > > Hi Richard, > > Lets take an example of a moderator of some mailing list: > > > > ==Before going on vacaton== > > 1. If someone sends a "new user" request, the moderator will receive an > email in real time about request. > > 2. The task will be added to his and other moderators' ToDo list. > > > > ==During Vacation== > > 1. If someone sends a "new user" request, the moderator "on vacation" > will NOT receive any email about pending "add user" request. > > 2. The task will be added to his and other moderators' ToDo list. > > > > ==After Vacation== > > 1. He will receive all the emails as he was receiving before going on > vacation. > > 2. The pending tasks will show up in his ToDo queue > > 3. He will receive an email about the tasks done in his absence > > 4. He will receive email about pending tasks that were added to his ToDo > list and are still pending. > > From raj.abhilash1 at gmail.com Thu May 23 18:06:45 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Thu, 23 May 2013 21:36:45 +0530 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <51956FCF.8060506@fifthhorseman.net> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> Message-ID: <519E3E95.5050009@gmail.com> On Friday 17 May 2013 05:16 AM, Daniel Kahn Gillmor wrote: > On 05/11/2013 03:17 AM, Abhilash Raj wrote: > >> After the Barry's comment on my proposal I decided to cut down >> the proposal to implement use of OpenPGP signatures for posting >> privileges instead of both signed and encrypted list. Most of the >> infrastructure for encrypted list will be created along with this >> project so that later on it can also be implemented easily. > > I think this is the right decision. Some of the discussion below > is only relevant for the larger-scope project. but some of it is > relevant to your revised-scope project as well. I've tried to > indicate the latter concerns by flagging them with > ***SIGNED_POSTS*** > >> Sender encrypts the message to list's pub key. List's >> pub-private keypair is uploaded by the list's owner when he >> creates the list. Subscribers gets to download the list's pub-key >> when he subscribes to it. > > You're saying here that the list has a secret key (i'll call that > LK_sec) and the corresponding public key is well-known (i'll call > that LK_pub). > > in OpenPGP terms, keys have "usage flags" or "key capabilities": > > https://tools.ietf.org/html/rfc4880#section-5.2.3.21 > > It sounds like you're saying that we should mark this key as > "encryption capable", which is usually indicated with two bits set: > 0xc For the encrypted lists yes, the key will be marked as 'encryption capable'. The list owner has to upload the public-private keypair for the list. > > ***SIGNED_POSTS*** > > Might there be a reason for the list to have a keypair associated > with it even for cleartext messages? e.g. might the list send out > signed messages that users might want to verify? Yes I think this would be a good point to include but we cannot make this a default option. We ask the list owner to upload the pub-private keypair for any new list that is created. If he does not want signing of messages he might not want to deal with keys at all? > >>> what if the decryption succeeds but there is no message >>> signature inside it? >> >> In that case a notification is sent to the sender with only the >> headers of the decrypted message that the signature of the >> message does not match. If it is not sent by him he is asked to >> ignore the notification. > > you say "with only the headers" -- is there ever a time when a > bounce message might contain the message content? No. >>> what if the signature appears to be valid, but was made 3 years >>> ago (or in the future)? >> >> Is that a problem if he has not revoked his signature yet? > > ***SIGNED_POSTS*** > > Well, it could be a replay of an old message from 5 years ago from > another list member. Should it be sent to the list again? It cannot be from another list member, before posting we check that the key that signed the message belongs to the sender( the address in the "From" header and key are same). If someone tries to post his own 5yr old message then we should bounce back the message and ask him to resign the message before sending if incase he wants that old message posted. Sounds okay? >>> what if the signature appears to be valid, and recent, but is >>> the same signature that was used on a previous e-mail to the >>> list? >> >> Can there be same signatures for different messages? I think the >> digital signature is created by encrypting the message-hash, so >> if the contents of the message are changed then signature cannot >> be valid. > > ***SIGNED_POSTS*** > > it could be a replay of a recent message, which would naturally use > the same signature. But the headers could be modified. For > example, the Message-ID isn't contained in the signature. Is it feasible to check each message against previously posted messages? I mean let's say if the list is 5yrs old then can we check every incoming message against all those previous messages for matching signatures? I think we cannot check if a user picks up his own 5yrs old message and sends it after changing the headers. >>> what if the signature is cryptographically valid, but the list >>> member's key has expired? >> >> Well a expired key cannot be used to sign messages. If this >> situation happens this means it was signed in past some time ago. >> We can bounce the message and notify the user about this. > > ***SIGNED_POSTS*** > > What if the message signature has a date that precedes the key > expiry? In this case I think we can keep a threshold for posting. If a message was signed within 2 days of key expiry then it could be allowed for posting. But then the key should have expired also 2-3 days before the message was received. My doubt is that how do we actually decide what is the best policy for us to follow? One person may agree to my point, other may not, third may have a different point and so on and so forth. So how do we decide upon one point? Voting? >>> what if only part of the message is signed? >> My guess is that you are referring to inline-pgp. I read this >> article which talks about the inline-pgp as a bad messaging >> format. I think we should not support this. So if the message is >> partially signed it should probably bounce back. > > ***SIGNED_POSTS*** > > Both inline PGP and PGP/MIME can have partial message signatures. > > I happen to agree that supporting inline PGP is problematic, so > i'm willing to ignore it for now if that's the consensus of the > project. be aware that you will find some pushback here, though, > because there remain some broken MUAs that not only can't generate > PGP/MIME, but can't display a clearsigned PGP/MIME e-mail to their > users. > > When you think of PGP/MIME, you probably think of messages like > message A below: > > A???multipart/signed 3099 bytes B ???text/plain 1527 bytes C > ???application/pgp-signature attachment [signature.asc] 1027 bytes > > But consider a MIME message D of the following form > > D???multipart/mixed 7346 bytes E ???multipart/signed 3099 bytes F > ????text/plain 1527 bytes G ????application/pgp-signature > attachment [signature.asc] 1027 bytes H ???text/plain inline 424 > bytes > > the text in part F is signed by the signature in part G. So you > could argue that the subtree rooted at E is "a signed message in > some sense. > > What kind of messages look like D? where do they come from? > (hint: examine the MIME structure of this message itself) Are you referring to the quoted texts in this message? Those lines are written by me but the application/pgp-signature part only verifies that the new content is written by you. Also after mailman adds headers and footers each of your fresh posts will also look like D to each subscribers. Is this what you wanted me to see? I think can use this to filter email commands, the message of type D will not be accepted as a valid email command. About the regular posts considering quoted texts I think we have to allow the message of type D. >>>> * The messaged is moved in between queues in the encrypted >>>> form encrypted by a symmetric key algorithm which uses list's >>>> secret key to encrypt the message. >>> >>> this doesn't make sense to me. when i hear "list's secret key" >>> i tend to think people are talking about asymmetric encryption, >>> but it seems here that you're talking about symmetric >>> encryption. Maybe it would help to enumerate exactly what >>> secrets each entity holds (and maybe what public data is >>> associated with those secrets, in the case of the >>> public/private keypairs used by asymmetric crypto). If you >>> give those secrets names, you can refer to them more concisely >>> and precisely. >> >> Sorry to sound so confusing. What I actually meant was that we >> use public-private key encryption via OpenPGP so send and receive >> signed and encrypted messages. Now each list has a public-private >> keypair which the list owner uploads when he creates the list. > > I'm with you so far... > >> During processing of the message inside mailman it is decrypted >> and sometimes stored on disk as python pickles in various queues >> which is bad for security reasons. I propose that when it is >> being stored on disk it can be encrypted using a symmetric key >> encryption algorithm so that only one who has access to list's >> secret key can decrypt it. > > And here you've lst me again. the lists's secret key (LK_sec) is > by definition for use in asymmetric cryptographic schemes. why are > you saying "using a symmetric key encryption algorithm" here? Sorry for this part, actually I was of the opinion that list's secret key can be used in any other encryption also as a key, but guess I am wrong. What my intention was is to to move the message between the queues in encrypted format so as to prevent it from getting stored in the disk( in queue as pickles ) in clear text format. And I wanted to use symmetric algorithm as it is faster than asymmetric and needs only one key( no two like pub and private in asymmetric ) for encryption and decryption. The thing I did wrong was to assume we can use the private key( as it is already stored safely ) for encrypting. >> When the message is being sent to the subscribers it is encrypted >> with the user's pub-key so that only he can decrypt it. > > This hand-waves around the difficult question: how do we know what > the user's pub-key is? User uploads his pub-key when he signs up for any such list that forces encryption. >>> what happens to the original sender's signature? is it >>> stripped? or does it remain, nested within the list's >>> signature? How are list members expected to verify these >>> signatures? >> >> The original sender's signature is stripped. I guess the list >> subscribers just have to trust that the list owner. We cannot >> expect each member of the list to have every other member's >> pub-key to separately verify himself that the message is indeed >> from the sender. > > there are other options. for example, the list could *add* its > signature to the message without stripping the signature of the > original author, so that recipients could verify one or the other > or both. Yes, that would be better i guess. > ***SIGNED_POSTS*** > > This is also relevant in the reduced-scope project; is it possible > that the mailing list might want to re-sign existing signed > messages so that people who receive mails from the mailing list can > verify that they really came from the mailing list? Yes, I think it is a good point. In-case someone wants to verify if the message was indeed sent to mailman by the one mailman says it is from, he can verify the signature. >>> What happens if a user's public key is found to be expired or >>> revoked? How does mailman become aware of revocations, of >>> extensions of the expiration date, or of new keys or >>> certificates for any given user? >> >> If the user has his key uploaded to a public key server and >> wants( he will be given option of whether ot not to) mailman to >> check , mailman can periodically check for revocation and >> expiration of the key. Though i don't know how will that be >> done. > > ***SIGNED_POSTS*** > > Why would mailman *not* check the public keyservers? why should > this be an option? As a user I might not want to use the key I use everywhere to sign the message to a particular list? I guess a keyserver keeps only one key corresponding to one email id? > If you're going to be using the OpenPGP public keyservers as a > regular/possibly-heavy-duty client, i recommend asking any > questions you have about the interaction with the keyservers over > in the development list for SKS (which is currently the dominant > keyserver implementation): > > SKS development list > > The protocol used is HKP, and there is a major global pool of > gossiping keyservers that you can talk to. for more details about > the pool, see: > > https://sks-keyservers.net/ > >> New keys will be added by user only from postorius after a >> confirmation link is sent to him on the address the key >> verifies. > > ***SIGNED_POSTS*** > > Will that confirmation link be sent in the clear, or will it be > encrypted to the user's public key? Since here we are not dealing with encryption, we can send the link in clear-text message and then expect him to send a signed reply verify the key. Also the key might not be encryption enabled so we can't always encrypt using it. > if the answer is "encrypted", what if the user's key is not > encryption-capable? If the user is trying to change keys, will > the confirmation message be encrypted to the user's old key or to > their new one?s At all times there must be at-least one key associated with a user's account. If he tries to add another key he would send the confirmation through mail signed with his one of his old keys. Similarly while deleting a key he will have to reply signed confirmation from any one of the address that he owns. > Mailman has traditionally been accessible to people who do not > browse the web by making use of its e-mail interface. will there > be a way to add or adjust keys via e-mail as well? He can attach a key, sign with his existing key and add it though email commands( which will be added for key management ). It will be verified like all other email commands for signature and then processed accordingly. > ----------- > > What about the monthly "you're subscribed to this list" e-mails > mailman sends out? What about "reset your password" e-mails? A user may have joined a single list which does not have any options for signing enabled, in that case mailman cannot sign the message with any key, nor the user will be able to send signed replies. > Regards, > > --dkg I am really thankful for your questions and suggestions. I tried to answer them with some thought. Please correct me if I am wrong. > > > _______________________________________________ Mailman-Developers > mailing list Mailman-Developers at python.org > http://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: > http://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > -- Abhilash From dkg at fifthhorseman.net Thu May 23 20:26:46 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 May 2013 14:26:46 -0400 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <519E3E95.5050009@gmail.com> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> Message-ID: <519E5F66.6060503@fifthhorseman.net> On 05/23/2013 12:06 PM, Abhilash Raj wrote: > For the encrypted lists yes, the key will be marked as 'encryption > capable'. The list owner has to upload the public-private keypair for > the list. > >> [dkg wrote:] >> ***SIGNED_POSTS*** >> >> Might there be a reason for the list to have a keypair associated >> with it even for cleartext messages? e.g. might the list send out >> signed messages that users might want to verify? > > Yes I think this would be a good point to include but we cannot make > this a default option. We ask the list owner to upload the pub-private > keypair for any new list that is created. If he does not want signing > of messages he might not want to deal with keys at all? sure, but if we introduce this as an option, then we need to make sure that we've thought through all the consequences. If the list has a key for use with administrative requests (e.g. subscription, unsubscription, etc) is that the same key that it would use for message signing? or a different key? What are the advantages of each scheme? Given that the list administrative requests go to different e-mail addresses than the regular posting, how would the User ID(s) look on a single key used for both interfaces provided by the list? Is implementing this option something that would be part of the first phase of the work, or should it be part of a later phase? >> Well, it could be a replay of an old message from 5 years ago from >> another list member. Should it be sent to the list again? > > It cannot be from another list member, before posting we check that > the key that signed the message belongs to the sender( the address in > the "From" header and key are same). sure, but the From: header is forgeable, right? so if Alice knows that Bob was subscribed to list X in the past, and is subscribed to list Y today, then she could dig up his old posts in list X, and forward them (From: header intact!) directly to list Y. Should list Y publish them? > If someone tries to post his own > 5yr old message then we should bounce back the message and ask him to > resign the message before sending if incase he wants that old message > posted. Sounds okay? sounds like we agree that a message whose signature is 5 years old is "too old" -- what about 1 year old? 1 month old? 1 week? It sounds like you're proposing a cutoff somewhere; where is the cutoff? is this something that would be adjustable by the list admin? if so, what should the default be? (note also that this assumes that the clock on the server is aligned with the clock used on the machine where the messages were signed; i think this is OK, but maybe there's some scenario where it might cause trouble?) >> it could be a replay of a recent message, which would naturally use >> the same signature. But the headers could be modified. For >> example, the Message-ID isn't contained in the signature. > > Is it feasible to check each message against previously posted > messages? I mean let's say if the list is 5yrs old then can we check > every incoming message against all those previous messages for > matching signatures? With the appropriate data structures, such a check isn't infeasible (e.g. you could maintain a binary tree of the digests of all message signatures; then if you have N messages in your archive, you have to do log(N) digest comparisons when a new message comes it to be sure that it isn't a replay of an old message. Maybe the mailman devs can answer this question: does mailman already do something like this to check against message-ids that have already been delivered to prevent duplicate delivery? this sounds like a similar problem to me (just with stronger cryptographic verifiability in the OpenPGP-signed case); if such a system already exists, maybe it could be amended to address these issues in the same way. > I think we cannot check if a user picks up his own 5yrs old message > and sends it after changing the headers. remember it's not just the user re-sending their own message -- it could be *anyone* re-sending the old message. Note also that the OpenPGP signature itself has a timestamp embedded in it, which is not modifiable without invalidating the signature. I think you might be assuming that we're checking the date of the signature via the (forgeable) Date: header on the message; i think it would make more sense to use the OpenPGP signature timestamp. What if the signature timestamp and the Date: header differ by a few seconds? what if they differ by months? >> What if the message signature has a date that precedes the key >> expiry? > > In this case I think we can keep a threshold for posting. If a message > was signed within 2 days of key expiry then it could be allowed for > posting. But then the key should have expired also 2-3 days before the > message was received. where does the 2 day cutoff come from? i'm asking about a timeline like this: (if < means "is earlier than": X < Y < Z) X: message signature created (according to OpenPGP timestamp) Y: key expired Z: message received by mailman SMTP delivery can take up to 4 days, depending on network and machine failures. but my point here is not to build in a fudge factor around the actual expiration date (which is explicit and i think needs no fudge factor), but rather to point out that the "is the message signature expired" calculation has to do with several different timestamps and how they relate to each other. > My doubt is that how do we actually decide what is the best policy for > us to follow? One person may agree to my point, other may not, third > may have a different point and so on and so forth. So how do we decide > upon one point? Voting? This is a good question :) I think you should propose a reasonable approach for handling all these various corner cases, and where your approach has some arbitrary cutoffs (e.g. messages with signatures older than K days will not be accepted for delivery), you make the arbitrary cutoff tuneable by the list administrator and choose a sensible default. Then you solicit and accept patches from people who have a strong argument that your implementation isn't aligned with a reasonable policy they would like to pursue :) >> What kind of messages look like D? where do they come from? >> (hint: examine the MIME structure of this message itself) > > Are you referring to the quoted texts in this message? Those lines are > written by me but the application/pgp-signature part only verifies > that the new content is written by you. Also after mailman adds > headers and footers each of your fresh posts will also look like D to > each subscribers. Is this what you wanted me to see? yep, mailman generates messages of this form from PGP/MIME-signed messages. That said, mailman's generated messages aren't usually sent to mailman as input; maybe mailman shouldn't process these as signed messages? > I think can use this to filter email commands, the message of type D > will not be accepted as a valid email command. About the regular posts > considering quoted texts I think we have to allow the message of type D. if we allow a message of type D, then Alice could simply find a recent PGP/MIME-signed message from Bob (from somewhere else), wrap it in a multipart/mixed part, append her own footer to it (part H) containing arbitrary text, and send the message on to mailman, using a trivially-forged From: Bob header. If mailman is willing to replay that message (with alice's arbitrary H intact) to all its subscribers, that seems like an easy way around the "signed-messages-only" constraint, which seems like a failure. So what are some other options? 0) mailman could ignore all messages except those that are fully signed (this is probably the easiest) 1) mailman could strip off all outer layers until it finds an inner part that is itself fully signed, and then process that part as though it were the entire message 2) ... other ideas? >> And here you've lst me again. the lists's secret key (LK_sec) is >> by definition for use in asymmetric cryptographic schemes. why are >> you saying "using a symmetric key encryption algorithm" here? > > Sorry for this part, actually I was of the opinion that list's secret > key can be used in any other encryption also as a key, but guess I am > wrong. What my intention was is to to move the message between the > queues in encrypted format so as to prevent it from getting stored in > the disk( in queue as pickles ) in clear text format. And I wanted to > use symmetric algorithm as it is faster than asymmetric and needs only > one key( no two like pub and private in asymmetric ) for encryption > and decryption. The thing I did wrong was to assume we can use the > private key( as it is already stored safely ) for encrypting. you can use the public key for encrypting, and the secret key for decrypting. that still uses asymmetric encryption, though. anyway, this is probably a question for the larger-scope project, so we should probably drop it for now to avoid distracting from the other matters at hand. >> This hand-waves around the difficult question: how do we know what >> the user's pub-key is? > > User uploads his pub-key when he signs up for any such list that > forces encryption. so anyone can sign up for the list with any key? if the list is open for arbitrary, unmoderated subscription, then what does it say about the confidentiality of the list? setting aside confidentiality (e.g. in the ***SIGNED_POSTS*** limited-scope), what does it say about the restrictions the list is able to enforce if arbitrary keys can be signed up? If the list admin/moderator has to approve new subscriptions, are they also approving the choice of keys as well? if so, how do you expect a list moderator to tell that the key in question is the right one? What happens if a list member revokes their key, or lets it expire? can that member upload a new one? how does the list know that this key replacement is legitimate, and not being done by an adversary or an impersonator? >> Why would mailman *not* check the public keyservers? why should >> this be an option? > > As a user I might not want to use the key I use everywhere to sign the > message to a particular list? I guess a keyserver keeps only one key > corresponding to one email id? ah, this is not the case :) keyservers can store an arbitrary number of keys that are (or claim to be) associated with a single e-mail address. OpenPGP keyservers are functionally agnostic -- they don't make any claims themselves about which keys belong to which e-mail addresses (or other forms of user ID). they just publish all the keys, and expect their clients to do the verification and certification path analysis themselves, based on client-specific perspectives on whose certifications are reliable and whose should be ignored. >> Will that confirmation link be sent in the clear, or will it be >> encrypted to the user's public key? > > Since here we are not dealing with encryption, we can send the link in > clear-text message and then expect him to send a signed reply verify > the key. Also the key might not be encryption enabled so we can't > always encrypt using it. does the signed reply need to be of a given form? does it need to contain a particular arbitrary string, like the confirmation (e.g. like the string in example-confirm+8d6e100d2d168ed0837d8d2b2e6e1db2b51b8877 at lists.example.org)? how can we be sure that the confirmation verification is safe from replay attacks (from the perspective of both the subscriber and the list administrator)? For example: ---------------------- Let's say Alice wants to sign Bob up to a list X that Bob would find distasteful to be on. Alice creates a phony mailman instance with a list Y that Bob *does* want to subscribe to; Bob tries to sign up for list Y, expecting a challenge that he will sign and respond to. When the request from Bob for List Y comes in, Alice spoofs a subscription attempt "From: Bob" to list X, harvests list X's (legitimate) challenge to Bob, and has List Y replay it to Bob as the challenge for List Y. Bob signs the challenge, returns it to list Y (which is still operated secretly by Alice), and Alice in turn replays Bob's signed response to list X. List X administrators now believe that Bob has legitimately signed up. They even have "cryptographic proof" of his intent to participate in List X! ---------------------- How can such a challenge/response system be designed to protect both Bob and the List X operators from people like Alice? One other question just occurred to me: Once these features (signed-messages-only) are implemented, hould existing (non-OpenPGP-enabled) lists be able to be upgraded to use these new features? Or is this something that is decided at list creation time and never changed? If list upgrading is possible, what sort of work needs to be done on an upgrade? Should this be part of the first phase of work? Even if not, it's worth keeping the possibility of a list upgrade in mind as you're designing the data structures and UI/UX adjustments that you want to make. > I am really thankful for your questions and suggestions. I tried to > answer them with some thought. Please correct me if I am wrong. Thanks, I really appreciate your engagement with these questions. There are a lot of finicky details to keep track of, and you're coming up to speed fast on questions that most people haven't thought about at all. Keep it up! Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From stephen at xemacs.org Fri May 24 07:54:25 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 24 May 2013 14:54:25 +0900 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <519E5F66.6060503@fifthhorseman.net> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> Message-ID: <87ip28udm6.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel Kahn Gillmor writes: > Is implementing this option something that would be part of the first > phase of the work, or should it be part of a later phase? He can implement it whenever he wants :-), but if I were his GSoC mentor, he'd be getting paid for something else (ie, the pure authentication part). Barry and Wacky think similarly I believe. > Maybe the mailman devs can answer this question: does mailman already do > something like this to check against message-ids that have already been > delivered to prevent duplicate delivery? I don't recall for sure but I don't think so. I tend to think it's too much effort. We do worry about routing cycles and handle that with X-Been-Seen fields. Message-IDs themselves are not very useful; in my own experience repeated message IDs are invariably due to Post-and-Mail issues (which we deal with post-by-post by checking the NoDupes flag on any addressees who appear in the list). Duplicate originals tend to be due to "keyboard bounce" (ie, for some reason the user resends within a number of seconds) or moderation delays -- in both cases usually they end up with different Message-IDs. > Thanks, I really appreciate your engagement with these questions. There > are a lot of finicky details to keep track of, and you're coming up to > speed fast on questions that most people haven't thought about at all. > Keep it up! +1 ! Also, Abhilash, I believe it would be very helpful to you later to blog about these conversations now.[1] Your blog entries should not be fire-and-forget; you should have separate entries for different topics and go back and update entries as you learn more. It might also be helpful to keep links to the mm-dev archive posts as references in your blog. (I haven't actually practiced that last myself, but it seems plausible.) It *will* seem like too much effort at first, but (1) people forget things unbelievably fast, and (2) you'll get better at it quickly. STeve Footnotes: [1] Maybe you already have, if so, my apologies. I'll go check later. :-) From joostvb-mailman-developers at mdcc.cx Fri May 24 08:33:13 2013 From: joostvb-mailman-developers at mdcc.cx (Joost van =?utf-8?Q?Baal-Ili=C4=87?=) Date: Fri, 24 May 2013 08:33:13 +0200 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <519E5F66.6060503@fifthhorseman.net> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> Message-ID: <20130524063312.GA504@beskar.mdcc.cx> Hi! On Thu, May 23, 2013 at 02:26:46PM -0400, Daniel Kahn Gillmor wrote: > On 05/23/2013 12:06 PM, Abhilash Raj wrote: > > My doubt is that how do we actually decide what is the best policy for > > us to follow? One person may agree to my point, other may not, third > > may have a different point and so on and so forth. So how do we decide > > upon one point? Voting? > > This is a good question :) > > I think you should propose a reasonable approach for handling all these > various corner cases, and where your approach has some arbitrary cutoffs > (e.g. messages with signatures older than K days will not be accepted > for delivery), you make the arbitrary cutoff tuneable by the list > administrator and choose a sensible default. > > Then you solicit and accept patches from people who have a strong > argument that your implementation isn't aligned with a reasonable policy > they would like to pursue :) I've just typesetted http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime/audit.pdf and http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime/audit2/audit2.pdf . These document some ideas about threats for a PGP-enhanced mailman implementation. (More documentation is available in http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime .) HTH. > > I am really thankful for your questions and suggestions. I tried to > > answer them with some thought. Please correct me if I am wrong. > > Thanks, I really appreciate your engagement with these questions. There > are a lot of finicky details to keep track of, and you're coming up to > speed fast on questions that most people haven't thought about at all. > Keep it up! +1 Bye, Joost -- irc:joostvb@{OFTC,freenode} ? http://mdcc.cx/ ? http://ad1810.com/ From raj.abhilash1 at gmail.com Fri May 24 21:13:46 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sat, 25 May 2013 00:43:46 +0530 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <519E5F66.6060503@fifthhorseman.net> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> Message-ID: <519FBBEA.3060206@gmail.com> On Thursday 23 May 2013 11:56 PM, Daniel Kahn Gillmor wrote: > On 05/23/2013 12:06 PM, Abhilash Raj wrote: > >> For the encrypted lists yes, the key will be marked as >> 'encryption capable'. The list owner has to upload the >> public-private keypair for the list. >> >>> [dkg wrote:] ***SIGNED_POSTS*** >>> >>> Might there be a reason for the list to have a keypair >>> associated with it even for cleartext messages? e.g. might the >>> list send out signed messages that users might want to verify? >> >> Yes I think this would be a good point to include but we cannot >> make this a default option. We ask the list owner to upload the >> pub-private keypair for any new list that is created. If he does >> not want signing of messages he might not want to deal with keys >> at all? > > sure, but if we introduce this as an option, then we need to make > sure that we've thought through all the consequences. If the list > has a key for use with administrative requests (e.g. subscription, > unsubscription, etc) is that the same key that it would use for > message signing? or a different key? What are the advantages of > each scheme? Given that the list administrative requests go to > different e-mail addresses than the regular posting, how would the > User ID(s) look on a single key used for both interfaces provided > by the list? This part is little difficult to ponder on. Suppose a user signs up for a list. He creates a user account and subscribes to a particular list which needs his pub-key and implements signing. Now for that user his pub-key can be used for sending administrative requests. If he signs up for more than one list it might be a question which of the keys will be used for administrative request? If he signs up for a single list which does not require signing then what? There will not be any key to sign administrative requests. > Is implementing this option something that would be part of the > first phase of the work, or should it be part of a later phase? This probably would be best implemented in the later phase when the till_now_proposed architecture of only signed emails from lists is implemented and is successful. >>> Well, it could be a replay of an old message from 5 years ago >>> from another list member. Should it be sent to the list >>> again? >> >> It cannot be from another list member, before posting we check >> that the key that signed the message belongs to the sender( the >> address in the "From" header and key are same). > > sure, but the From: header is forgeable, right? so if Alice knows > that Bob was subscribed to list X in the past, and is subscribed to > list Y today, then she could dig up his old posts in list X, and > forward them (From: header intact!) directly to list Y. Should > list Y publish them? Well if somehow( 'coz have no idea how ) we can check that this message was posted anytime before in past on the same list, it would be better that we simple discard the message. >> If someone tries to post his own 5yr old message then we should >> bounce back the message and ask him to resign the message before >> sending if incase he wants that old message posted. Sounds okay? > > sounds like we agree that a message whose signature is 5 years old > is "too old" -- what about 1 year old? 1 month old? 1 week? It > sounds like you're proposing a cutoff somewhere; where is the > cutoff? is this something that would be adjustable by the list > admin? if so, what should the default be? No, I think if someone tries to send any of his previous message again we can rebound it saying that the same message was posted before. Also the time-stamp from the message signature would indicate that the message was indeed signed long time back and hence should be bounced back without checking if it was a replay of an old message. Here a 'long time' may be a cutoff set by the list owner which may default to one week considering the delay in smtp delivery( which you mentioned to be 4 days at maximum). > (note also that this assumes that the clock on the server is > aligned with the clock used on the machine where the messages were > signed; i think this is OK, but maybe there's some scenario where > it might cause trouble?) A cutoff of one week should be sufficient to include the small time( at max a day ) mismatch between the server and the system where message was signed. In-case the mismatch is more than that we can bounce the message back asking the sender to either check his clock or resign and send the message. >>> it could be a replay of a recent message, which would naturally >>> use the same signature. But the headers could be modified. >>> For example, the Message-ID isn't contained in the signature. >> >> Is it feasible to check each message against previously posted >> messages? I mean let's say if the list is 5yrs old then can we >> check every incoming message against all those previous messages >> for matching signatures? > > With the appropriate data structures, such a check isn't > infeasible (e.g. you could maintain a binary tree of the digests of > all message signatures; then if you have N messages in your > archive, you have to do log(N) digest comparisons when a new > message comes it to be sure that it isn't a replay of an old > message. > > Maybe the mailman devs can answer this question: does mailman > already do something like this to check against message-ids that > have already been delivered to prevent duplicate delivery? this > sounds like a similar problem to me (just with stronger > cryptographic verifiability in the OpenPGP-signed case); if such a > system already exists, maybe it could be amended to address these > issues in the same way. > >> I think we cannot check if a user picks up his own 5yrs old >> message and sends it after changing the headers. > > remember it's not just the user re-sending their own message -- it > could be *anyone* re-sending the old message. I think replay of message should not be allowed at all. Not by the original sender, not by anyone else, not immediately, not some time after. We can put it as an option but I can't imagine any situation where this would be used. Please tell me if you can think of any? > Note also that the OpenPGP signature itself has a timestamp > embedded in it, which is not modifiable without invalidating the > signature. I think you might be assuming that we're checking the > date of the signature via the (forgeable) Date: header on the > message; i think it would make more sense to use the OpenPGP > signature timestamp. What if the signature timestamp and the Date: > header differ by a few seconds? what if they differ by months? Is the timestamp in the OpenPGP signature not forgeable? Does it not depend on the hardware clock of the system where the message was signed? Although I agree that checking this would be good for filtering the messages signed long time ago in past and being sent now( considering that i don't plan and sign many messages by changing my hardware clock and program it to send it in future as spams. Can we assume this will not happen? ) >>> What if the message signature has a date that precedes the key >>> expiry? >> >> In this case I think we can keep a threshold for posting. If a >> message was signed within 2 days of key expiry then it could be >> allowed for posting. But then the key should have expired also >> 2-3 days before the message was received. > > where does the 2 day cutoff come from? i'm asking about a timeline > like this: > > (if < means "is earlier than": X < Y < Z) > > X: message signature created (according to OpenPGP timestamp) Y: > key expired Z: message received by mailman Again here the decision should be made by the list owner. It may depend on what values are for (Y-Z) and (Z-Y). I think we can allow a message whose signature expired a day before( and the user din't have time to change the key or extend expiration date ). But this 'one day' parameter is to be set by the list owner. > SMTP delivery can take up to 4 days, depending on network and > machine failures. but my point here is not to build in a fudge > factor around the actual expiration date (which is explicit and i > think needs no fudge factor), but rather to point out that the "is > the message signature expired" calculation has to do with several > different timestamps and how they relate to each other. > >> My doubt is that how do we actually decide what is the best >> policy for us to follow? One person may agree to my point, other >> may not, third may have a different point and so on and so forth. >> So how do we decide upon one point? Voting? > > This is a good question :) > > I think you should propose a reasonable approach for handling all > these various corner cases, and where your approach has some > arbitrary cutoffs (e.g. messages with signatures older than K days > will not be accepted for delivery), you make the arbitrary cutoff > tuneable by the list administrator and choose a sensible default. > > Then you solicit and accept patches from people who have a strong > argument that your implementation isn't aligned with a reasonable > policy they would like to pursue :) > >>> What kind of messages look like D? where do they come from? >>> (hint: examine the MIME structure of this message itself) >> >> Are you referring to the quoted texts in this message? Those >> lines are written by me but the application/pgp-signature part >> only verifies that the new content is written by you. Also after >> mailman adds headers and footers each of your fresh posts will >> also look like D to each subscribers. Is this what you wanted me >> to see? > > yep, mailman generates messages of this form from PGP/MIME-signed > messages. That said, mailman's generated messages aren't usually > sent to mailman as input; maybe mailman shouldn't process these as > signed messages? What is the structure of message with quoted text( when replying to a mail inline )? Are those signed by the user replying to it? Because such kind of message are always received by mailman. >> I think can use this to filter email commands, the message of >> type D will not be accepted as a valid email command. About the >> regular posts considering quoted texts I think we have to allow >> the message of type D. > > if we allow a message of type D, then Alice could simply find a > recent PGP/MIME-signed message from Bob (from somewhere else), wrap > it in a multipart/mixed part, append her own footer to it (part H) > containing arbitrary text, and send the message on to mailman, > using a trivially-forged From: Bob header. Just out of curiosity is the forging of headers a trivial thing? Can I send a message with some address not owned by me to say this very list easily? (I don't want to though ,just asking if I can ;-) > If mailman is willing to replay that message (with alice's > arbitrary H intact) to all its subscribers, that seems like an easy > way around the "signed-messages-only" constraint, which seems like > a failure. > > So what are some other options? > > 0) mailman could ignore all messages except those that are fully > signed (this is probably the easiest) The message that we send can be of type D but we should only accept the messages of type A? I think this the best thing to adopt. > 1) mailman could strip off all outer layers until it finds an > inner part that is itself fully signed, and then process that part > as though it were the entire message That would add some extra logic and computation for signed components in a message, maybe not much difficult to implement but more than nothing. I don't think we should do it, if we are so concerned about security we can expect the senders to follow the policy( of sending only fully signed message of kind A)? > 2) ... other ideas? > >>> And here you've lst me again. the lists's secret key (LK_sec) >>> is by definition for use in asymmetric cryptographic schemes. >>> why are you saying "using a symmetric key encryption algorithm" >>> here? >> >> Sorry for this part, actually I was of the opinion that list's >> secret key can be used in any other encryption also as a key, but >> guess I am wrong. What my intention was is to to move the message >> between the queues in encrypted format so as to prevent it from >> getting stored in the disk( in queue as pickles ) in clear text >> format. And I wanted to use symmetric algorithm as it is faster >> than asymmetric and needs only one key( no two like pub and >> private in asymmetric ) for encryption and decryption. The thing >> I did wrong was to assume we can use the private key( as it is >> already stored safely ) for encrypting. > > you can use the public key for encrypting, and the secret key for > decrypting. that still uses asymmetric encryption, though. > anyway, this is probably a question for the larger-scope project, > so we should probably drop it for now to avoid distracting from the > other matters at hand. +1 >>> This hand-waves around the difficult question: how do we know >>> what the user's pub-key is? >> >> User uploads his pub-key when he signs up for any such list that >> forces encryption. > > so anyone can sign up for the list with any key? if the list is > open for arbitrary, unmoderated subscription, then what does it say > about the confidentiality of the list? setting aside > confidentiality (e.g. in the ***SIGNED_POSTS*** limited-scope), > what does it say about the restrictions the list is able to enforce > if arbitrary keys can be signed up? If the list admin/moderator > has to approve new subscriptions, are they also approving the > choice of keys as well? if so, how do you expect a list moderator > to tell that the key in question is the right one? Yes anyone can signup but his subscription will be moderated. I don't understand here what do you mean by "choice of keys" and what is a "right" key? I am guessing by right key you mean the key indeed belongs to the owner of the address the key verifies. But already the confirmation email is sent to check that the address is indeed owned by the person before the moderators receive notification to allow the user to get subscribed. > What happens if a list member revokes their key, or lets it expire? > can that member upload a new one? how does the list know that this > key replacement is legitimate, and not being done by an adversary > or an impersonator? > >>> Why would mailman *not* check the public keyservers? why >>> should this be an option? >> >> As a user I might not want to use the key I use everywhere to >> sign the message to a particular list? I guess a keyserver keeps >> only one key corresponding to one email id? > > ah, this is not the case :) keyservers can store an arbitrary > number of keys that are (or claim to be) associated with a single > e-mail address. So in general terms if I import a key from a public keyserver, I cannot be sure that the pub-key belongs to owner of the address the key verifies? I am confused! I can change the "From" header to you email, then I can upload a key that verifies you address whose private key is with me. I sign a message and send it to mailman. If we allow the usage of keyservers how will mailman distinguish that the message was a fake? Why should we check keyservers by default? Won't it better that we ask the user to either upload his first key and later on to add another key a confirmation will be sent to both the new added address and previous default address and confirmation from both will be required? It looks messy to me though. :-/ > OpenPGP keyservers are functionally agnostic -- they don't make > any claims themselves about which keys belong to which e-mail > addresses (or other forms of user ID). they just publish all the > keys, and expect their clients to do the verification and > certification path analysis themselves, based on client-specific > perspectives on whose certifications are reliable and whose should > be ignored. > >>> Will that confirmation link be sent in the clear, or will it be >>> encrypted to the user's public key? >> >> Since here we are not dealing with encryption, we can send the >> link in clear-text message and then expect him to send a signed >> reply verify the key. Also the key might not be encryption >> enabled so we can't always encrypt using it. > > does the signed reply need to be of a given form? does it need to > contain a particular arbitrary string, like the confirmation (e.g. > like the string in > example-confirm+8d6e100d2d168ed0837d8d2b2e6e1db2b51b8877 at lists.example.org)? Yes > we can ask the user to simply resend the confirmation message signed by him? I mean this is what I can think of as the easiest. We can have anything in the mail sent to him( which will be signed by the secret key of the list he is subscribing to, so no question of fake acceptance message sent to the user) > how can we be sure that the confirmation verification is safe from > replay attacks (from the perspective of both the subscriber and the > list administrator)? For example: > > ---------------------- Let's say Alice wants to sign Bob up to a > list X that Bob would find distasteful to be on. > > Alice creates a phony mailman instance with a list Y that Bob > *does* want to subscribe to; Bob tries to sign up for list Y, > expecting a challenge that he will sign and respond to. > > When the request from Bob for List Y comes in, Alice spoofs a > subscription attempt "From: Bob" to list X, harvests list X's > (legitimate) challenge to Bob, and has List Y replay it to Bob as > the challenge for List Y. Bob signs the challenge, returns it to > list Y (which is still operated secretly by Alice), and Alice in > turn replays Bob's signed response to list X. > > List X administrators now believe that Bob has legitimately signed > up. They even have "cryptographic proof" of his intent to > participate in List X! ---------------------- > > How can such a challenge/response system be designed to protect > both Bob and the List X operators from people like Alice? The confirmation email received by Bob will be signed by the secret key of List Y which he gets to download while he was subscribing for the list. He can check it and will find the signature invalid incase Alice sends him another message which has confirmation for a list X. > One other question just occurred to me: Once these features > (signed-messages-only) are implemented, hould existing > (non-OpenPGP-enabled) lists be able to be upgraded to use these > new features? Or is this something that is decided at list > creation time and never changed? If list upgrading is possible, > what sort of work needs to be done on an upgrade? Should this be > part of the first phase of work? Even if not, it's worth keeping > the possibility of a list upgrade in mind as you're designing the > data structures and UI/UX adjustments that you want to make. Yes, the upgrade should be must have feature( in future, not in this project ). And yes I will keep this in mind while designing the system and UI that upgrading to signed lists is not much of a hassle. >> I am really thankful for your questions and suggestions. I tried >> to answer them with some thought. Please correct me if I am >> wrong. > > Thanks, I really appreciate your engagement with these questions. > There are a lot of finicky details to keep track of, and you're > coming up to speed fast on questions that most people haven't > thought about at all. Keep it up! Thanks :) > Regards, > > --dkg > -- Abhilash From raj.abhilash1 at gmail.com Fri May 24 21:16:40 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sat, 25 May 2013 00:46:40 +0530 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <87ip28udm6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> <87ip28udm6.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <519FBC98.4040407@gmail.com> On Friday 24 May 2013 11:24 AM, Stephen J. Turnbull wrote: > I don't recall for sure but I don't think so. I tend to think it's > too much effort. We do worry about routing cycles and handle that > with X-Been-Seen fields. Message-IDs themselves are not very useful; > in my own experience repeated message IDs are invariably due to > Post-and-Mail issues (which we deal with post-by-post by checking the > NoDupes flag on any addressees who appear in the list). Duplicate > originals tend to be due to "keyboard bounce" (ie, for some reason the > user resends within a number of seconds) or moderation delays -- in > both cases usually they end up with different Message-IDs. +1 > Also, Abhilash, I believe it would be very helpful to you later to > blog about these conversations now.[1] Your blog entries should not be > fire-and-forget; you should have separate entries for different topics > and go back and update entries as you learn more. It might also be > helpful to keep links to the mm-dev archive posts as references in > your blog. (I haven't actually practiced that last myself, but it > seems plausible.) > > It *will* seem like too much effort at first, but (1) people forget > things unbelievably fast, and (2) you'll get better at it quickly. Yes this was also one of my todos. And to be truthful point (1) is very highly applicable to me ;-). -- Abhilash From raj.abhilash1 at gmail.com Fri May 24 21:17:15 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sat, 25 May 2013 00:47:15 +0530 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <20130524063312.GA504@beskar.mdcc.cx> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> <20130524063312.GA504@beskar.mdcc.cx> Message-ID: <519FBCBB.1030000@gmail.com> On Friday 24 May 2013 12:03 PM, Joost van Baal-Ili? wrote: > I've just typesetted > http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime/audit.pdf > and > http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime/audit2/audit2.pdf > . These document some ideas about threats for a PGP-enhanced mailman > implementation. (More documentation is available in > http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime > .) Thanks Joost. In fact I have read these two audits before. It really helped me in deciding what would be the best for the scope of the project I am trying to do. And what are the various general problems that I would be dealing with along with a plausible solution to many of them. It is a very helpful resource. :) -- Abhilash From stephen at xemacs.org Sun May 26 18:57:49 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 27 May 2013 01:57:49 +0900 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <519FBBEA.3060206@gmail.com> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> <519FBBEA.3060206@gmail.com> Message-ID: <878v31u19u.fsf@uwakimon.sk.tsukuba.ac.jp> Abhilash Raj writes: > This part is little difficult to ponder on. Suppose a user signs up > for a list. He creates a user account and subscribes to a particular > list which needs his pub-key and implements signing. In Mailman 3, users and subscriptions are separate concepts. We should assume that users and subscriptions are both authenticated, potentially separately. I think that to start with, we can assume that the user key will be used for all user configuration (subscription, etc), and for posting. The second stage would be to allow a list to require a separate key (subkey) for posting. The third stage would be to require a separate key for administration (user configuration). > If he signs up for a single list which does not require signing > then what? There will not be any key to sign administrative > requests. For starters we'll simply require a separate installation for secure and insecure lists. The whole Mailman instance is secure and all users must have user keys. This is a proof-of-concept implementation; we think about weaker and more complex security models later. > > sure, but the From: header is forgeable, right? so if Alice knows > > that Bob was subscribed to list X in the past, and is subscribed to > > list Y today, then she could dig up his old posts in list X, and > > forward them (From: header intact!) directly to list Y. Should > > list Y publish them? Sure, but a secure list should be on a site using DKIM and this will fail the DKIM check, I think. Alternatively you can set up the list so that the whole post (originator headers included) is sent as an attachment (a signed part of a multipart message). The list can then prepend the trace headers (informational only, not authenticable) from the wrapper message when it forwards the encapsulated message. Outlook users will generally not be able to do this, so it's another proof of concept. :-) This is like a secure tunnel (eg, using SSH port forwarding). > No, I think if someone tries to send any of his previous message again > we can rebound it saying that the same message was posted before. Sure, but identifying that requires secure headers. See above. > Also the time-stamp from the message signature would indicate that the > message was indeed signed long time back and hence should be bounced > back without checking if it was a replay of an old message. Here a 'long > time' may be a cutoff set by the list owner which may default to one > week considering the delay in smtp delivery( which you mentioned to be > 4 days at maximum). SMTP doesn't really work that way; there are no time guarantees (the chain of forward can be arbitrarily long, and each one will retry for up to 4 days in normal configurations). Furthermore, I regularly see spew from Windows boxes with mail written offline. I think the *principle* of using the signature's time-stamp is OK, but the cutoff time should be determined by the list's sense of how long post content can stay "hot". > A cutoff of one week should be sufficient to include the small time( at > max a day ) I've seen many cases where timestamp skew on authentic messages was much greater than a day. Again, this is a matter for list policy. > Is the timestamp in the OpenPGP signature not forgeable? Does it not > depend on the hardware clock of the system where the message was > signed? It's forgeable, but only by the owner of the private key. The hardware clock could be deliberately skewed, but I can't see how that would create a useful attack on a list. (I guess you could imagine a scenario with a "deadman switch" controlling a message that would be sent if the creator doesn't cancel it, but that's a scenario for Mission Impossible IV, I think.) > > (if < means "is earlier than": X < Y < Z) > > > > X: message signature created (according to OpenPGP timestamp) Y: > > key expired Z: message received by mailman I don't understand the point of this scenario. X is a valid signature, and there are known to be delays in delivery. X should just be treated as an old signature. > > yep, mailman generates messages of this form from PGP/MIME-signed > > messages. That said, mailman's generated messages aren't usually > > sent to mailman as input; maybe mailman shouldn't process these as > > signed messages? Such messages can be generated in many ways; the fact that Mailman does is just a proof of concept. > What is the structure of message with quoted text( when replying to a > mail inline )? It's a flat body. It has no MIME structure unless the user deliberately creates it (well, in some cases attachments may be automatically forwarded). > Are those signed by the user replying to it? The interesting question is whether the quote is signed by the OP, and the answer it that no, it can't be. You could choose to send the original signed body (with signature) for verification of the accuracy of your quote, but the quote itself will be signed as part of the reply by the replying agent. > Just out of curiosity is the forging of headers a trivial thing? Can I > send a message with some address not owned by me to say this very list > easily? (I don't want to though ,just asking if I can ;-) Yes, all headers are easily forged unless the sending site uses DKIM. The envelope data is also easily forged. > > 0) mailman could ignore all messages except those that are fully > > signed (this is probably the easiest) I suspect that some people's legal disclaimer will fall outside the signed text. No can do. > > 1) mailman could strip off all outer layers until it finds an > > inner part that is itself fully signed, and then process that part > > as though it were the entire message I think this is the right way to handle layered messages when signatures are required. The > >>> This hand-waves around the difficult question: how do we know > >>> what the user's pub-key is? I think we can punt on this. "The same way we ever do." Ie, we use a PK certification infrastructure or a web of trust. That's up to the list owner. > > What happens if a list member revokes their key, or lets it expire? > > can that member upload a new one? Not if they needed approval in the first place. If the list is open-subscription, yes, but a confirmation mail to the subscription address and notification to list owner are required here. I'm not sure if it's possible to use a revoked or expired key in that state, but if so it might be useful to use it "just that one more time". > > how does the list know that this key replacement is legitimate, > > and not being done by an adversary or an impersonator? See above. > So in general terms if I import a key from a public keyserver, I > cannot be sure that the pub-key belongs to owner of the address the > key verifies? No, you can't. Anybody can upload such keys. You need to either rely on a certification authority, or the web of trust. Note that Daniel already answered that question, in some detail, in the post you were replying to. If you don't understand the answer the first time, reread the answer. Then try to refine your question. It's not just a matter of courtesy to someone who has spent a lot of effort in crafting clear answers; you'll also learn a *lot* faster. > > Alice creates a phony mailman instance with a list Y that Bob > > *does* want to subscribe to; Bob tries to sign up for list Y, > > expecting a challenge that he will sign and respond to. > > > > When the request from Bob for List Y comes in, Alice spoofs a > > subscription attempt "From: Bob" to list X, harvests list X's > > (legitimate) challenge to Bob, and has List Y replay it to Bob as > > the challenge for List Y. Bob signs the challenge, returns it to > > list Y (which is still operated secretly by Alice), and Alice in > > turn replays Bob's signed response to list X. Probably this requires a version of the Diffie-Hellman handshake, actually. > > One other question just occurred to me: Once these features > > (signed-messages-only) are implemented, hould existing > > (non-OpenPGP-enabled) lists be able to be upgraded to use these > > new features? As an authentication option for administrative mails, I don't see a problem. For post authentication, technically I don't see a great difficulty in switching to "everything must be authenticated" (ie, signed), but socially I think it's a mess. Creation of a new list is the right way to go. That allows birectional gatewaying (with human moderation insecure -> secure). But this is way down on the priority list. Note that Mailman 2 will never get these capabilities, at least not from the current team. From minfrin at sharp.fm Mon May 27 03:33:11 2013 From: minfrin at sharp.fm (Graham Leggett) Date: Mon, 27 May 2013 03:33:11 +0200 Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6 Message-ID: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm> Hi all, Has anyone managed to get the mailman true virtual hosting patch for 2.1 working on Redhat Enterprise 6 as described at https://wiki.koumbit.net/VirtualMailman? I have to apply the patch manually as it the patch fails in a few places, however once applied the patch doesn't seem to work as it did on RHEL5. Mails are sent, but the list ends up being called list-example.com at example.com, which will break the list for end users. Unfortunately mailman3 is out of the question as it depends on python 2.7, which is too new for RHEL6. I can tolerate a custom mailman package, I can't support parallel custom versions of entire language stacks on the same box. Regards, Graham -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4365 bytes Desc: not available URL: From mark at msapiro.net Mon May 27 04:05:27 2013 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 26 May 2013 19:05:27 -0700 Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6 In-Reply-To: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm> References: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm> Message-ID: <51A2BF67.5070506@msapiro.net> On 05/26/2013 06:33 PM, Graham Leggett wrote: > Hi all, > > Has anyone managed to get the mailman true virtual hosting patch for 2.1 working on Redhat Enterprise 6 as described at https://wiki.koumbit.net/VirtualMailman? I'm not sure how that compares to what I'm familiar with. I have a branch at based on the work of Hans Ulrich Niedermann and predecessors. (See the FAQ at and the post at .) Coincidently, this branch was just merged with the head of the 2.1 branch. I do not use this branch. My disclaimer is "Please don't ask me to fix all the problems with this branch. I don't guarantee that anything will work. I ported the patches and fixed a few reported problems as a service to those who wish to use it. I don't use it and am not enthusiastic about maintaining it. If you use this branch and encounter problems and report those problems to mailman-users at python.org, I may fix them, but only if they are easy to fix." In general, I will try to fix reported problems if the fixes are not too involved. > I have to apply the patch manually as it the patch fails in a few places, however once applied the patch doesn't seem to work as it did on RHEL5. Mails are sent, but the list ends up being called list-example.com at example.com, which will break the list for end users. This is highly reminiscent of cPanel except their list names are list_example.com at example.com and they accept mail to list at example.com for list_example.com at example.com by (in their case) teaching the Exim router about this convention. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From kip at thevertigo.com Mon May 27 04:01:40 2013 From: kip at thevertigo.com (Kip Warner) Date: Sun, 26 May 2013 19:01:40 -0700 Subject: [Mailman-Developers] Python remote urllib.request -> mailman subscription Message-ID: <1369620100.4386.118.camel@rommel> Hey list, I'd just like to preface my post with the acknowledgement that I had already posted the same query on Mailman-Users last week, but no one seemed to have an answer at the time. I figured it might be better to ask the developers. My Python 3 / PyGI / Gtk+ application, among other things, prompts a user for their name, email, and password, and then submits an http POST request to a hard coded remote GNU Mailman server. So far, the code appears to work and I'll request a peer review by anyone kind enough: One potential concern I've found is that it is difficult to machine parse the server response to reliably distinguish a successful subscription from a failure. A successful subscription returns an http code 200, but so do many failed ones (e.g. bad formatted email address is still code 200). The most reliable brute force method I could come up with was to check the message body of the returned HTML document for the substring "Your subscription request has been received". Great, except since Mailman is i18n capable, its gettext could return something semantically equivalent, but obviously worded different if the locale is changed. However, since the server I am submitting the request to will probably always use the English user interface, this probably won't be an issue, but is still inelegant and I'd like to solve it. Moreover, even if it remains in English, but perhaps the string changes anyways when Mailman is upgraded, then it is a problem again. Does anyone have any suggestions or other feedback they'd like to share or propose a better solution? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From stephen at xemacs.org Mon May 27 05:44:01 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 27 May 2013 12:44:01 +0900 Subject: [Mailman-Developers] Python remote urllib.request -> mailman subscription In-Reply-To: <1369620100.4386.118.camel@rommel> References: <1369620100.4386.118.camel@rommel> Message-ID: <87zjvhrsse.fsf@uwakimon.sk.tsukuba.ac.jp> Kip Warner writes: > Does anyone have any suggestions or other feedback they'd like to share > or propose a better solution? The better solution is Mailman 3, which provides a REST API for programmatic administration, but it not going to be considered ready for production use (at least, not unless the admin is a Mailman 3 developer) for several months. The only developer currently working on Mailman 2 at all is Mark Sapiro, who handles maintenance (ie, bug fixes and integration of "uncontroversial" minor feature patches). I think any change here is likely to be controversial, so won't make it to Mailman 2 in the near future. From kip at thevertigo.com Mon May 27 06:20:35 2013 From: kip at thevertigo.com (Kip Warner) Date: Sun, 26 May 2013 21:20:35 -0700 Subject: [Mailman-Developers] Python remote urllib.request -> mailman subscription In-Reply-To: <87zjvhrsse.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1369620100.4386.118.camel@rommel> <87zjvhrsse.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1369628435.4386.123.camel@rommel> On Mon, 2013-05-27 at 12:44 +0900, Stephen J. Turnbull wrote: > The better solution is Mailman 3, which provides a REST API for > programmatic administration, but it not going to be considered ready > for production use (at least, not unless the admin is a Mailman 3 > developer) for several months. > > The only developer currently working on Mailman 2 at all is Mark > Sapiro, who handles maintenance (ie, bug fixes and integration of > "uncontroversial" minor feature patches). I think any change here is > likely to be controversial, so won't make it to Mailman 2 in the near > future. Hey Steve. Thanks for getting back to me. Since my application will be distributed on optical media, it's impossible for me to adapt it to Mailman 3 later should the server ever be upgraded. I'd like to have it work with both interfaces, but it's impossible for me to do that right now because Mailman 3 is still experimental and I won't know how to communicate with it yet, let alone the static URL and API the server would expose whenever its is upgraded later. I think what I'll do is contact Mark, as you suggested. Thanks a lot for your help. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From minfrin at sharp.fm Mon May 27 16:57:32 2013 From: minfrin at sharp.fm (Graham Leggett) Date: Mon, 27 May 2013 16:57:32 +0200 Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6 In-Reply-To: <51A2BF67.5070506@msapiro.net> References: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm> <51A2BF67.5070506@msapiro.net> Message-ID: On 27 May 2013, at 4:05 AM, Mark Sapiro wrote: > I'm not sure how that compares to what I'm familiar with. I have a > branch at based on > the work of Hans Ulrich Niedermann and predecessors. (See the FAQ at > and the post at > .) > > Coincidently, this branch was just merged with the head of the 2.1 branch. > > I do not use this branch. My disclaimer is "Please don't ask me to fix > all the problems with this branch. I don't guarantee that anything will > work. I ported the patches and fixed a few reported problems as a > service to those who wish to use it. I don't use it and am not > enthusiastic about maintaining it. If you use this branch and encounter > problems and report those problems to mailman-users at python.org, I may > fix them, but only if they are easy to fix." In general, I will try to > fix reported problems if the fixes are not too involved. Hopefully this fix doesn't fall into the too involved category. This sanity check was failing even when the emailhost and domain were the same: --- bin/newlist-orig 2013-05-27 13:37:52.351141920 +0000 +++ bin/newlist 2013-05-27 13:38:31.080191760 +0000 @@ -163,7 +163,7 @@ urlhost = urlhost or ('lists.%s' % domain) # TODO: Not configurable yet if not emailhost: emailhost = domain - else: + elif emailhost != domain: usage(1, _('You cannot use an email host different from the domain part of the list name.')) if not mm_cfg.VIRTUAL_HOSTS.has_key(urlhost): _urlhost = repr(urlhost) Regards, Graham -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4365 bytes Desc: not available URL: From mark at msapiro.net Mon May 27 17:21:09 2013 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 27 May 2013 08:21:09 -0700 Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6 In-Reply-To: References: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm> <51A2BF67.5070506@msapiro.net> Message-ID: <51A379E5.3000802@msapiro.net> On 05/27/2013 07:57 AM, Graham Leggett wrote: > > Hopefully this fix doesn't fall into the too involved category. This sanity check was failing even when the emailhost and domain were the same: Fix accepted and committed to the branch at . Thank you. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From minfrin at sharp.fm Tue May 28 13:48:52 2013 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 28 May 2013 13:48:52 +0200 Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6 In-Reply-To: <51A379E5.3000802@msapiro.net> References: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm> <51A2BF67.5070506@msapiro.net> <51A379E5.3000802@msapiro.net> Message-ID: <042346EE-2784-40CA-BD6A-4B458D6A4CD2@sharp.fm> On 27 May 2013, at 5:21 PM, Mark Sapiro wrote: > Fix accepted and committed to the branch at > . > > Thank you. Here is another small issue, when VIRTUAL_HOST_OVERVIEW was switched off to allow all virtual lists to appear on the same host, the host_name of the list wasn't passed in the URL. The attached patch fixes this. diff -u -r mailman-2.1.12/Mailman/MailList.py mailman-2.1.12-patched/Mailman/MailList.py --- mailman-2.1.12/Mailman/MailList.py 2013-05-28 10:39:09.333154778 +0000 +++ mailman-2.1.12-patched/Mailman/MailList.py 2013-05-28 10:40:57.874209489 +0000 @@ -252,6 +252,9 @@ def GetScriptURL(self, scriptname, absolute=0): # Using "local_part" here works for both site wide lists on # the default url host and for vhost lists on the vhost url host. + if not mm_cfg.VIRTUAL_HOST_OVERVIEW: + return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \ + '/' + self.local_part + '@' + self.host_name return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \ '/' + self.local_part Only in mailman-2.1.12-patched: autom4te.cache diff -u -r mailman-2.1.12/bin/newlist mailman-2.1.12-patched/bin/newlist --- mailman-2.1.12/bin/newlist 2013-05-28 10:39:09.339158852 +0000 +++ mailman-2.1.12-patched/bin/newlist 2013-05-28 10:21:04.730131451 +0000 @@ -165,7 +165,7 @@ emailhost = domain elif emailhost != domain: usage(1, C_('You cannot use an email host different from the domain part of the list name.')) - if not mm_cfg.VIRTUAL_HOSTS.has_key(urlhost): + if mm_cfg.VIRTUAL_HOST_OVERVIEW and not mm_cfg.VIRTUAL_HOSTS.has_key(urlhost): _urlhost = repr(urlhost) _emailhost = repr(emailhost) usage(1, C_('The Mailman config file lacks a line mapping urlhost to emailhost:\n add_virtualhost(%(_urlhost)s,\n %(_emailhost)s)')) Regards, Graham -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4365 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed May 29 00:54:40 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 28 May 2013 18:54:40 -0400 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <878v31u19u.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> <519FBBEA.3060206@gmail.com> <878v31u19u.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <51A535B0.6080501@fifthhorseman.net> On 05/26/2013 12:57 PM, Stephen J. Turnbull wrote: > > > sure, but the From: header is forgeable, right? so if Alice knows > > > that Bob was subscribed to list X in the past, and is subscribed to > > > list Y today, then she could dig up his old posts in list X, and > > > forward them (From: header intact!) directly to list Y. Should > > > list Y publish them? > > Sure, but a secure list should be on a site using DKIM and this will > fail the DKIM check, I think. If i understand it correctly, DKIM allows the recipient of a message to verify that it came from the domain it claims to come from, and that the body and a select set of headers have not been tampered with while the message was in transit. Bob's e-mail could come from Bob's own domain, which isn't necessarily the domain associated with the list. The only way that a DKIM check would fail for the given attack, would be if the DKIM included the To: and Cc: headers and the list was configured to reject mail that either (a) failed or did not have a DKIM signature, or (b) did not include the list's address in either To: or Cc:. Is that what you're suggesting? > Alternatively you can set up the list so that the whole post > (originator headers included) is sent as an attachment (a signed part > of a multipart message). The list can then prepend the trace headers > (informational only, not authenticable) from the wrapper message when > it forwards the encapsulated message. Outlook users will generally > not be able to do this, so it's another proof of concept. :-) including well-vetted way to be able to cryptographically verify headers that mailman wants to rely on would be great! I'm not sure that wrap-signing a message/rfc822 part is the right way to achieve those goals, though. > > > (if < means "is earlier than": X < Y < Z) > > > > > > X: message signature created (according to OpenPGP timestamp) Y: > > > key expired Z: message received by mailman > > I don't understand the point of this scenario. X is a valid > signature, and there are known to be delays in delivery. X should > just be treated as an old signature. the point of the scenario is to think clearly about the relationship between key expiry and message/signature validity, which are distinct but associated things. doing decent key management is tricky. > > > 1) mailman could strip off all outer layers until it finds an > > > inner part that is itself fully signed, and then process that part > > > as though it were the entire message > > I think this is the right way to handle layered messages when > signatures are required. The i tend to agree with you here; but it looks like you might have gotten cut off. did you have more to say on this question? > > >>> This hand-waves around the difficult question: how do we know > > >>> what the user's pub-key is? > > I think we can punt on this. "The same way we ever do." Ie, we use a > PK certification infrastructure or a web of trust. That's up to the > list owner. I think doing proper key management is a lot trickier than that. both X.509 PKI and OpenPGP "Web of Trust"-style authentication networks have a lot of fiddly bits and ways to get the implementation wrong *and* controls that you might or might not want to expose to the end user. For example, for X.509: * how do you decide what set of CAs belongs in the trusted root authority list? * do you check CRLs in certificates? if so, how often? * do you use OCSP? * Which X.509v3 extensions do you require for message signatures from which algorithms? For example, for OpenPGP-style certification networks: * which keys do you assign full ownertrust to? * which keys do you assign marginal ownertrust to? * how do you deal with certifications from multiple marginally-trusted accounts? * how often do you check keyservers for updates? * do you honor embedded keyserver URLs? And for any key management regime: * what do you do with a message that is signed by a key that claims to belong to party X but you can't verify the key identity? * Are all kinds of key identity verification failures the same, or are some different than others? (e.g. do you handle messages signed by expired keys different from messages from messages signed by revoked keys?) There are probably more questions for each domain, and more general questions as well. how many of the these decisions do you want to expose to the list administrator? how many do you want to expose to the mailman installation operator? how do you choose good defaults for these choices? > > > What happens if a list member revokes their key, or lets it expire? > > > can that member upload a new one? > > Not if they needed approval in the first place. If the list is > open-subscription, yes, but a confirmation mail to the subscription > address and notification to list owner are required here. I'm not > sure if it's possible to use a revoked or expired key in that state, > but if so it might be useful to use it "just that one more time". What does it mean (socially) to have an open-subscription list that requires signatures from posters? > > > Alice creates a phony mailman instance with a list Y that Bob > > > *does* want to subscribe to; Bob tries to sign up for list Y, > > > expecting a challenge that he will sign and respond to. > > > > > > When the request from Bob for List Y comes in, Alice spoofs a > > > subscription attempt "From: Bob" to list X, harvests list X's > > > (legitimate) challenge to Bob, and has List Y replay it to Bob as > > > the challenge for List Y. Bob signs the challenge, returns it to > > > list Y (which is still operated secretly by Alice), and Alice in > > > turn replays Bob's signed response to list X. > > Probably this requires a version of the Diffie-Hellman handshake, > actually. i'm not convinced that DH will solve this problem without an additional identifying layer -- the problem is the anonymity of the end point itself, which DH won't solve on its own. I suspect this could be solved by requiring subscription messages and the like to have a standard format that explicitly includes the globally-unique name of the list within the signed body, so that they could not be replayed. There may be other solutions as well, though. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From mark at msapiro.net Wed May 29 01:50:04 2013 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 28 May 2013 16:50:04 -0700 Subject: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6 In-Reply-To: <042346EE-2784-40CA-BD6A-4B458D6A4CD2@sharp.fm> References: <13E81A3A-654B-4E14-915B-754FD405F080@sharp.fm> <51A2BF67.5070506@msapiro.net> <51A379E5.3000802@msapiro.net> <042346EE-2784-40CA-BD6A-4B458D6A4CD2@sharp.fm> Message-ID: <51A542AC.5060908@msapiro.net> On 05/28/2013 04:48 AM, Graham Leggett wrote: > > Here is another small issue, when VIRTUAL_HOST_OVERVIEW was switched off to allow all virtual lists to appear on the same host, the host_name of the list wasn't passed in the URL. The attached patch fixes this. > > diff -u -r mailman-2.1.12/Mailman/MailList.py mailman-2.1.12-patched/Mailman/MailList.py > --- mailman-2.1.12/Mailman/MailList.py 2013-05-28 10:39:09.333154778 +0000 > +++ mailman-2.1.12-patched/Mailman/MailList.py 2013-05-28 10:40:57.874209489 +0000 > @@ -252,6 +252,9 @@ > def GetScriptURL(self, scriptname, absolute=0): > # Using "local_part" here works for both site wide lists on > # the default url host and for vhost lists on the vhost url host. > + if not mm_cfg.VIRTUAL_HOST_OVERVIEW: > + return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \ > + '/' + self.local_part + '@' + self.host_name > return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \ > '/' + self.local_part > Actually, that patch is not what's required. The comment is wrong. @hostname is required for all vhosts lists regardless of the host name in the URL or the setting of VIRTUAL_HOST_OVERVIEW. A correct patch is attached. As for the patch below, I see what you're trying to do, but I'm nervous about untended consequences of creating lists in domains not in VIRTUAL_HOSTS. I think the patch should be OK, but as I say, I'm nervous about it. I will definitely commit the attached patch, and I'll think about the other. Do you have any motivation for it other than just not wanting to bother with adding add_virtualhost() to mm_cfg.py? > diff -u -r mailman-2.1.12/bin/newlist mailman-2.1.12-patched/bin/newlist > --- mailman-2.1.12/bin/newlist 2013-05-28 10:39:09.339158852 +0000 > +++ mailman-2.1.12-patched/bin/newlist 2013-05-28 10:21:04.730131451 +0000 > @@ -165,7 +165,7 @@ > emailhost = domain > elif emailhost != domain: > usage(1, C_('You cannot use an email host different from the domain part of the list name.')) > - if not mm_cfg.VIRTUAL_HOSTS.has_key(urlhost): > + if mm_cfg.VIRTUAL_HOST_OVERVIEW and not mm_cfg.VIRTUAL_HOSTS.has_key(urlhost): > _urlhost = repr(urlhost) > _emailhost = repr(emailhost) > usage(1, C_('The Mailman config file lacks a line mapping urlhost to emailhost:\n add_virtualhost(%(_urlhost)s,\n %(_emailhost)s)')) -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- --- ../vhost/Mailman/MailList.py 2013-05-25 16:00:50.930182026 -0700 +++ Mailman/MailList.py 2013-05-28 16:26:36.696692828 -0700 @@ -250,10 +250,10 @@ return "%s%s@%s" % (acct, self.umbrella_member_suffix, host) def GetScriptURL(self, scriptname, absolute=0): - # Using "local_part" here works for both site wide lists on - # the default url host and for vhost lists on the vhost url host. - return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \ - '/' + self.local_part + return '%s/%s' % ( + Utils.ScriptURL(scriptname, self.web_page_url, absolute), + self.internal_name() + ) def GetOptionsURL(self, user, obscure=0, absolute=0): url = self.GetScriptURL('options', absolute) From stephen at xemacs.org Wed May 29 07:51:59 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 29 May 2013 14:51:59 +0900 Subject: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project] In-Reply-To: <51A535B0.6080501@fifthhorseman.net> References: <87txmhjsod.fsf@uwakimon.sk.tsukuba.ac.jp> <87vc6vlcng.fsf@uwakimon.sk.tsukuba.ac.jp> <518B34A8.9030400@gmail.com> <518BDA11.3020504@fifthhorseman.net> <51956FCF.8060506@fifthhorseman.net> <519E3E95.5050009@gmail.com> <519E5F66.6060503@fifthhorseman.net> <519FBBEA.3060206@gmail.com> <878v31u19u.fsf@uwakimon.sk.tsukuba.ac.jp> <51A535B0.6080501@fifthhorseman.net> Message-ID: <87k3mis58g.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel Kahn Gillmor writes: > The only way that a DKIM check would fail for the given attack, would be > if the DKIM included the To: and Cc: headers and the list was configured > to reject mail that either (a) failed or did not have a DKIM signature, > or (b) did not include the list's address in either To: or Cc:. Is that > what you're suggesting? Yes. Validating anything about a given message is a PITA, as you know. I think this is the best we can do with the MTA-level headers (by MTA-level I mean they might be augmented or reordered by MTAs, so we would need a DKIM-like algorithm to sign the header in the MUA anyway). FYI: In Mailman REJECT is a technical term that implies a notification to sender. In context, I assume you meant "reject, discard, or [maybe] hold". > > I don't understand the point of this scenario. X is a valid > > signature, and there are known to be delays in delivery. X should > > just be treated as an old signature. > > the point of the scenario is to think clearly about the relationship > between key expiry and message/signature validity, which are distinct > but associated things. AFAIK key expiry is associated with signing, not with validation. Associating key expiry with validation would mean you basically can't use expirable keys with mail, and especially not with archived mail. > doing decent key management is tricky. Sure, but this particular case is well-defined AFAIK. It's out of our hands. > > > > 1) mailman could strip off all outer layers until it finds an > > > > inner part that is itself fully signed, and then process that part > > > > as though it were the entire message > > > > I think this is the right way to handle layered messages when > > signatures are required. The > > i tend to agree with you here; but it looks like you might have gotten > cut off. did you have more to say on this question? I usually do ;-) but often enough it's sufficient unimportant that I forget. I'm not sure what I intended to say. :-/ Possibly a reference to the idea of encapsulating the whole intended message (especially the "originator headers" per RFC 5322) in a signed part to avoid the whole "can we trust the headers" issue. In this format the important headers would be signed, so we trust them as much as we trust the signature. > > I think we can punt on this. "The same way we ever do." Ie, we use a > > PK certification infrastructure or a web of trust. That's up to the > > list owner. > > I think doing proper key management is a lot trickier than that. Of course it is. I'm saying it's not in scope, not for this GSoC proposal for sure, and probably not for Mailman. > both X.509 PKI and OpenPGP "Web of Trust"-style authentication > networks have a lot of fiddly bits and ways to get the > implementation wrong *and* controls that you might or might not > want to expose to the end user. I wonder why they're so fiddly? ;-) And why we should think we can do better? If you're an avatar of djb or Bruce Schneier, say so, and I'll take your word for it. I *know* I don't know enough to make recommendations here, let alone reify them in software. I'm almost certain Barry, Wacky, Terri, Florian, and Mark don't. Nor Abhilash. > And for any key management regime: > > * what do you do with a message that is signed by a key that claims to > belong to party X but you can't verify the key identity? Depends on list policy. Default: HOLD. (I'd like to say REJECT, but you don't know you're not creating backscatter in that case.) DISCARD is a more or less plausible alternative, but I haven't thought about it carefully. > * Are all kinds of key identity verification failures the same, or > are some different than others? (e.g. do you handle messages > signed by expired keys different from messages from messages > signed by revoked keys?) I would say, "not quite, not very, and no" for those two cases. I'm not sure this needs an option: both express the sender's intention that the key not be used in this way. There might be options about how to handle it (eg, I suspect that in both cases the most common reason for receiving such a message is pilot error by the sender, but it needs confirmation -- so REJECT; there are arguments for DISCARD or HOLD, though). > There are probably more questions for each domain, and more general > questions as well. how many of the these decisions do you want to > expose to the list administrator? how many do you want to expose to the > mailman installation operator? These general questions are use-case-dependent, and therefore the answer now is "none of them" for the list admin, and "all of them" for the instance admin (who in general will be the same at this point in history). As use cases arise, we can revise the design. > how do you choose good defaults for these choices? "Fail secure". > What does it mean (socially) to have an open-subscription list that > requires signatures from posters? I don't know, and personally I don't really care. I'm more interested in open-subscription lists that require signatures on admin messages. I conjecture that it could be useful on anonymized lists to prevent spoofing members who have built up trust in their nicknames over time. I guess this use case might require leaving the poster's signature in place. > I suspect this could be solved by requiring subscription messages and > the like to have a standard format that explicitly includes the > globally-unique name of the list within the signed body, so that they > could not be replayed. Didn't I suggest that? I intended to. More forgetfulness.... Steve From flo.fuchs at gmail.com Thu May 30 23:05:47 2013 From: flo.fuchs at gmail.com (Florian Fuchs) Date: Thu, 30 May 2013 23:05:47 +0200 Subject: [Mailman-Developers] Concgrats and Welcome GSoC Students Message-ID: Dear fellow Mailmaners, dear GSoC 2013 students, let's congratulate Abhilash Raj and Manish Gill for their successful Google Summer of Code 2013 applications! Abhilash's project will be the integration of OpenPGP into the mailman core. Manish will be working on a public facing, authenticated REST API. Also, thank's so much to the other students who applied for a GSoC slot this year! We really appreciate all the work you put into crafting your applications. We got a number of very good proposals, so the decision really wasn't easy. We'd be very happy to see you around contributing to the Mailman project, even if it's not as a GSoC student. So what's next for our students? Coding will officially start on June 17, so this week and the two weeks after that should be used to get to know the people you'll be working with (mentors, other Mailman coders working on parts that are relevant to your project, other students,...). The time before the coding start date should also be spent reading documentation and/or asking any still unanswered questions you might have about the existing code. It's also a good time to make yourself familiar with the tools and processes we use (version control, code reviewing etc.). Please note that we expect you to write weekly blog posts containing progress updates after June 17. So you might also want to set up a blog before that date (or - if you already have one - a separate GSoC category that can be aggregated via RSS). So, once more, congratulations -- and happy coding! Florian From barry at list.org Fri May 31 01:07:21 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 30 May 2013 19:07:21 -0400 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> Message-ID: <20130530190721.014cf538@anarchist> On May 17, 2013, at 04:58 PM, Richard Wackerbarth wrote: >Would it be easier if we just treated owners and moderators as a couple of >additional mailing lists. > >In other words, for list XXX at example.com, we also have virtual lists >@example.com and @example.com Where the list >names are accessible only from within MM. > >Thus a moderator would be subscribed to the list and that >subscription handled just as any other subscription would be handled. This is an interesting question, but let me rephrase it into MM3 terminology to see what we can coax out. MM3 has this notion of "rosters", and they are a fundamental object in the system, as described by the IRoster interface. Through a roster, you can get at the IMembers, IUsers, and IAddresses which are contained in the roster. You can also look up an IMember from a given email address; if it's in the roster then you get back the matching IMember, otherwise you get None. Mailing lists point to a bunch of rosters, and this is in fact how the subscriber information is accessed. A mailing list will have: * an owners roster * a moderators roster * an administrators roster (all owners + all moderators) * a members roster * a roster of regular delivery members * a roster of digest delivery members * a roster of subscribers (all regular + all digest) * a roster of "non-members" So, when we want to send a message of a post held for moderator approval, we send that message to every IMember in the administrators roster. Here's where it gets interesting. Rosters are not modeled as rows in a table, they are modeled as queries. This is cool because you can actually compose rosters, or pull their information from any source, including those external to the core. One of the use cases for rosters that I've always had in mind are a better way to do MM2-style umbrella lists. Let's say you have one mailing list for all of your band's New York fans, and another for all of your band's San Francisco fans. It should be very easy to compose a parent (i.e. umbrella) list which had a roster combining the New York and San Francisco rosters, and it is this roster that you would deliver to when your new tour was starting. Another use case: say a site is doing maintenance and they want to inform every subscriber on the system that it will be unavailable for a while. You could easily compose a roster that included every registered (and validated) email to every mailing list, and then you'd send a message to that roster. I think this same kind of arrangement would work for some of the things that dlists wants to do, or topics, etc. and I'm sure you can come up with a zillion other use cases. So, in this model, what is "a mailing list"? It's really all the configuration stuff *around* rosters, such as how you send a message to that roster from outside the system, what gets stuffed into Subject headers, and message footers, how do posted messages get transformed on the way to the roster membership, and who gets to send messages to them. I think this isn't far from what you're asking in your original question, and there's much to explore here. Whether the full power of this can be or should be exposed to the web ui, or the mail boundary, is much fuzzier in my mind. But I can clearly see how a determined developer could make this work pretty easily. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri May 31 01:12:25 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 30 May 2013 19:12:25 -0400 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: <20130530191225.365f91a3@anarchist> On May 19, 2013, at 11:26 AM, varun sharma wrote: >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. One thing to keep in mind is what MM2 does today. We really don't keep any kind of to-do list for a specific moderator. All we do is essentially keep a list of all the moderation actions that are pending on a mailing list, and we send this out to all the moderators every once in a while (e.g. once per day). (Note too that we can send out immediate notification about new pending requests. These don't replace the daily notifications.) In this view, if a moderator were to go on vacation, they would simply stop getting the daily reminders. Other moderators would still get them though. Once the moderator's vacation stop expires, whatever pending tasks are still outstanding will just get sent in the next daily notification. (As an aside, MM3 should do a better job of recording which of the moderators dispatches a particular pending task. We can't do that in MM2 because we don't really know - all the moderators essentially share a login. But in MM3, we can and will know, so we should record that fact in the log file, database, and original message.) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri May 31 01:14:05 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 30 May 2013 19:14:05 -0400 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> Message-ID: <20130530191405.033daba4@anarchist> On May 19, 2013, at 10:08 PM, varun sharma wrote: >2. The second thing is some moderators might be interested in knowing >the administrative changes done in their absence. So they should >receive a summary of the tasks done(eg. users added) in their absence >once they come back from vacation.This was what i was talking about in >that paragraph. This is why we would log those dispositions in the database (as well as other places probably). Then this information would be available through the REST API for Postorius to format nicely for a list's moderators. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri May 31 01:19:19 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 30 May 2013 19:19:19 -0400 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <62E713D7-3DB9-466B-A311-43E7F9996CDD@dataplex.net> Message-ID: <20130530191919.3ca82309@anarchist> On May 20, 2013, at 11:31 AM, varun sharma wrote: >So, I think the overlapping vacation may be handled in two ways: >1. Follow up the procedure as written above , i.e: If there are multiple >moderators going on vacation for same span of time, then the tasks will >remain pending in their ToDo list .During vacations, they can login to the >postorius and see their pending tasks, but there won't be any email >notifications about the pending tasks during the vacation period. But there >will be no mailing list delivery. That's okay. The requests will just pile up until some moderator comes back from vacation and chooses to process them. Really, this isn't much different from today's state of affairs :). >2. Second option as it came to my mind after you mentioned this case is >that, the last moderator(assuming all other moderators have already set >thier "on vacation" mode without digests) going on vacation will not be >allowed to completely opt-out of emails. As steve suggested, we can provide >a digest mode for notifications also. So the last moderator going on >vacation will have to choose "digest" mode for notifications as well as >mailing list mail delivery if he want to go on vacation :) I don't think we'd need to do that. It's worse if say all the moderators "unsubscribe" from their moderation roles. Then there really is no one to take care of things. But if everyone goes on vacation, the list should carry on just fine in their absence except that when their vacation stop expires, the daily notifications will start up again, and hopefully they'll take care of whatever is still pending. There's one caveat: pending requests can expire and be auto-discarded. We may want to rethink that in light of vacation stops for moderators. -Barry From barry at list.org Fri May 31 01:20:52 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 30 May 2013 19:20:52 -0400 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <1993ED1C-25E5-428C-8509-7F7951AF407F@dataplex.net> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <62E713D7-3DB9-466B-A311-43E7F9996CDD@dataplex.net> <1993ED1C-25E5-428C-8509-7F7951AF407F@dataplex.net> Message-ID: <20130530192052.66aed805@anarchist> On May 20, 2013, at 06:39 AM, Richard Wackerbarth wrote: >It is easy to say "He will receive an email about the tasks done in his >absence". However, how do you propose to compose that email? Where and how >is the information used to construct the email stored while the moderator is >on vacation. If on a queue, which queue? ... etc. > >You seem to imply that each individual has a ToDo list of tasks. If that is >the case, in the normal course of business, how will you handle the situation >when there are two or more moderators and one of them processes a request. In both MM2 and MM3 today, there is only one queue for the entire mailing list. Individual moderators don't have individual request (to-do) queues. I don't currently see a use case for changing that, and as you've observed, there are problems if we do. -Barry From rkw at dataplex.net Fri May 31 01:37:53 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Thu, 30 May 2013 18:37:53 -0500 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <20130530190721.014cf538@anarchist> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> <20130530190721.014cf538@anarchist> Message-ID: <27A1275F-B5CB-498B-AD18-4B84B1396642@dataplex.net> OK. Then a "roster" represents the distribution list for a "feed" of outgoing messages. The "mailinglist" represents the reception point(s) for the incoming messages and the directives for handling the processing of those messages. The thing that hasn't been addressed is how an individual recipient can affect the processing of messages that are processed while he is a member of a roster. In particular, how do the "user settings" come into play? Presumedly, a user can have different settings for each list to which he is subscribed. What, if any, individual settings apply to moderator feeds? Are these different from those which apply to the feed that the individual receives as a member of the list? On May 30, 2013, at 6:07 PM, Barry Warsaw wrote: > On May 17, 2013, at 04:58 PM, Richard Wackerbarth wrote: > >> Would it be easier if we just treated owners and moderators as a couple of >> additional mailing lists. >> >> In other words, for list XXX at example.com, we also have virtual lists >> @example.com and @example.com Where the list >> names are accessible only from within MM. >> >> Thus a moderator would be subscribed to the list and that >> subscription handled just as any other subscription would be handled. > > This is an interesting question, but let me rephrase it into MM3 terminology > to see what we can coax out. > > MM3 has this notion of "rosters", and they are a fundamental object in the > system, as described by the IRoster interface. Through a roster, you can get > at the IMembers, IUsers, and IAddresses which are contained in the roster. > You can also look up an IMember from a given email address; if it's in the > roster then you get back the matching IMember, otherwise you get None. > > Mailing lists point to a bunch of rosters, and this is in fact how the > subscriber information is accessed. A mailing list will have: > > * an owners roster > * a moderators roster > * an administrators roster (all owners + all moderators) > * a members roster > * a roster of regular delivery members > * a roster of digest delivery members > * a roster of subscribers (all regular + all digest) > * a roster of "non-members" > > So, when we want to send a message of a post held for moderator approval, we > send that message to every IMember in the administrators roster. > > Here's where it gets interesting. Rosters are not modeled as rows in a table, > they are modeled as queries. This is cool because you can actually compose > rosters, or pull their information from any source, including those external > to the core. > > One of the use cases for rosters that I've always had in mind are a better way > to do MM2-style umbrella lists. Let's say you have one mailing list for all > of your band's New York fans, and another for all of your band's San > Francisco fans. It should be very easy to compose a parent (i.e. umbrella) > list which had a roster combining the New York and San Francisco rosters, and > it is this roster that you would deliver to when your new tour was starting. > > Another use case: say a site is doing maintenance and they want to inform > every subscriber on the system that it will be unavailable for a while. You > could easily compose a roster that included every registered (and validated) > email to every mailing list, and then you'd send a message to that roster. > > I think this same kind of arrangement would work for some of the things that > dlists wants to do, or topics, etc. and I'm sure you can come up with a > zillion other use cases. > > So, in this model, what is "a mailing list"? It's really all the > configuration stuff *around* rosters, such as how you send a message to that > roster from outside the system, what gets stuffed into Subject headers, and > message footers, how do posted messages get transformed on the way to the > roster membership, and who gets to send messages to them. > > I think this isn't far from what you're asking in your original question, and > there's much to explore here. Whether the full power of this can be or should > be exposed to the web ui, or the mail boundary, is much fuzzier in my mind. > But I can clearly see how a determined developer could make this work pretty > easily. > > -Barry From stephen at xemacs.org Fri May 31 09:45:08 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 31 May 2013 16:45:08 +0900 Subject: [Mailman-Developers] GSOC Project Discussion In-Reply-To: <20130530190721.014cf538@anarchist> References: <87k3nbl6je.fsf@uwakimon.sk.tsukuba.ac.jp> <20130517161648.5691c17e@anarchist> <32E7DD97-E4CE-44E6-88A2-E6DEC4F5E9B6@dataplex.net> <20130530190721.014cf538@anarchist> Message-ID: <87txljbnjv.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > Here's where it gets interesting. Rosters are not modeled as rows > in a table, they are modeled as queries. [...] > > One of the use cases for rosters that I've always had in mind are a > better way to do MM2-style umbrella lists. Let's say you have one > mailing list for all of your band's New York fans, and another for > all of your band's San Francisco fans. It should be very easy to > compose a parent (i.e. umbrella) list which had a roster combining > the New York and San Francisco rosters, Meta: It would be nice if you would distinguish between the meanings of "should" in this kind of discussion. Do you mean 1. One requirement for a good admin interface it to make it easy to compose umbrella lists. or 2. This architecture is expected to make it easy for an admin interface to compose umbrella lists. or both?