Mailman 3 April 2014 - Mailman-Developers

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
by Stephen J. Turnbull April 28, 2014

April 28, 2014

Rajeev S writes: > You do a *heroku login *from your shell and you can run commands on > the remote server of your application from your shell.This would be > an interesting project and would hugely benefit usability of the > current project. Sure, under the hood this is just an ssh login, most likely. However, I wouldn't bet on it being "hugely useful", as these days most Mailman list owners share a Mailman site using cPanel or similar, and don't have shell access at all. *Very* useful in beta test, though. > That seems like a funny GMail bug. All I did was to reorder the terms of > the phrase which was in boldface, using cut and paste. Anyway, I will > remember not to do this again. Aargh. HTML mail is a tool of the devil. It is not a hacker's friend, it makes life annoying for filtering and automatic mail processing. When you get ~250 wanted mails (many of them list, of course) and ~1000 spams (that get past the 6-sigma "if this filter thinks it's spam, throw it away!" filter) a day, automatic processing is really important. Unfortunately I don't have a copy of your original, but what may be happening is not at GMail, but rather that the mailing list tries pretty hard to avoid HTML mail, throwing away the text/html part if there's a text/plain alternative, and otherwise running it through an HTML-to-text converter (probably Lynx with output to a file). It could also just be my local MUA, which I have set up to try to minimize the HTML mail that I see. Mark can probably say with some confidence.

3 3

Deploying postorius and mailman-bundle
by Abhilash Raj April 27, 2014

April 27, 2014

Hi All, I was trying to setup mailman-bundler as demo for new mailman suite that we just launched. We have a wsgi script for deployment in postorius_standalone and mailman_bundler as well. While I was trying to deploy using nginx and uwsgi/gunicorn I found that they expect the script to have .py extension and not .wsgi. All new django versions currently create a wsgi.py file along with the project itself. So I was thinking we should change that in our code too. Thoughts? thanks, Abhilash

1 0

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
by Stephen J. Turnbull April 27, 2014

April 27, 2014

Rajeev S writes: > Hi Abhilash, Please don't top-post. It's very helpful to readers to keep the "subthreads" about particular issues separate, while at the same time bundling them together for ease of mail-handling. > I did not quite get the user role part.A command line utility runs on the > server on which a software instance runs, just like a MySQL command line > utility.You will need physical access to the system or atleast the shell.I > believe you cannot expect every moderator of the list to have that kind of > access. From my point of view, the tool will be used by the list owner or > the server admin, just like the MySQL shell,which can be used only if you > have access to system shell.However, User/Role management can be imposed by > including a login for the shell,if necessary.Again,that's not possible for > the command tools. Why not? The CLI tools will have access to the user database, so in theory you could authenticate. In *practice*, this may be outside of the scope of your project because there's no provision for authentication in the current RESTful interface; you end up restricting to connections from localhost. But by the same token, past projects have decided to connect to Postorius rather than Mailman itself precisely because Postorious *does* maintain roles and credentials for users. Again, probably beyond the scope of your project, but for precisely this reason it has been proposed a few times that the authn/authz part of Postorius be broken out into a separate module. > And Yes.Users will be a part of this. I prefer to build the other two > first.Many methods that can come under User class is better suited under > the other two.For eg, for adding a moderator to the list, you can do, *list > --addmoderator user_id , *which should be under the List class*. *But the > same from user point of view, would be a complicated and less intuitive > command, *user **user_id **--addmoderator **--list list_id *. So, after the > list and domain functions are built, It will be more clear what the user > class must do. I agree with your logic here. But I find the text very difficult to read. There should be at least one space after a sentence-ending period ("Yes.Users" looks like a class attribute!) And I have no idea what the semantics of "*" is intended to be. > About optparse, I actually meant argparse,sorry about that :). And thanks > for the style guide tip. Despite the current thread on python-dev<wink target="Barry"/>, I strongly recommend the pep8.py tool (available on PyPI as well as upstream: https://github.com/jcrocholl/pep8/). pyflakes, pylint, and pychecker are also good tools, but their orientation is a bit different, and you may or may not find them useful (and in particular you may find after a while that you *never* get warnings from them).

2 1

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
by Abhilash Raj April 26, 2014

April 26, 2014

Hi Rajeev, On Sat, Apr 26, 2014 at 1:27 PM, Rajeev S <rajeevs1992(a)gmail.com> wrote: > Hi Abhilash, > > I did not quite get the user role part.A command line utility runs on the > server on which a software instance runs, just like a MySQL command line > utility.You will need physical access to the system or atleast the shell.I > believe you cannot expect every moderator of the list to have that kind of > access. From my point of view, the tool will be used by the list owner or > the server admin, just like the MySQL shell,which can be used only if you > have access to system shell.However, User/Role management can be imposed by > including a login for the shell,if necessary.Again,that's not possible for > the command tools. > The working of mysql client and this project are very different. As Steve pointed a lot of things might be out of scope for your project but it would be nice if you could discuss about the complete working of it and at-least document it so that if not you, someone else can leverage this discussion and help improve your project after you are done with it. There is usually never a physical access to a server so that is out of question but still applications do exist with user roles, don't they? Even in mysql you have users. What if on a host I run mailman as 'maxking' and on the same host 'rajeev' and 'steve' are two other users whom I have granted owner roles(as an admin) to two different lists do whatever the CLI will do. Who said only one person can have access to a host?

1 0

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
by Rajeev S April 26, 2014

April 26, 2014

Hi Abhilash, I did not quite get the user role part.A command line utility runs on the server on which a software instance runs, just like a MySQL command line utility.You will need physical access to the system or atleast the shell.I believe you cannot expect every moderator of the list to have that kind of access. From my point of view, the tool will be used by the list owner or the server admin, just like the MySQL shell,which can be used only if you have access to system shell.However, User/Role management can be imposed by including a login for the shell,if necessary.Again,that's not possible for the command tools. And Yes.Users will be a part of this. I prefer to build the other two first.Many methods that can come under User class is better suited under the other two.For eg, for adding a moderator to the list, you can do, *list --addmoderator user_id , *which should be under the List class*. *But the same from user point of view, would be a complicated and less intuitive command, *user **user_id **--addmoderator **--list list_id *. So, after the list and domain functions are built, It will be more clear what the user class must do. About optparse, I actually meant argparse,sorry about that :). And thanks for the style guide tip. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk <http://rajeevs.tk>* On Sat, Apr 26, 2014 at 10:42 AM, Abhilash Raj <raj.abhilash1(a)gmail.com>wrote: > On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S <rajeevs1992(a)gmail.com> wrote: > >> Hi Stephen, >> >> The CLI project would be a sub module for the mailman.client project. >> > >> Since bzr does not have the submodule feature, I must be doing it either >> by using a new repository or as a new branch to mailman.client .The latter >> would be better as it would be easier to integrate the code into the >> mailman.client project when this project is completed. >> > > Why do you want it to be a submodule in the first place? If you want to > extend > mailman.client they why not simply branch it? > >> >> Now about the implementation part.As described in the project timeline, >> the first phase would be to build the command tools. I would be building >> two classes List and Domain, and identify the various methods that are to >> be given to them. Many of the methods are identified in my GSoC proposal. >> The command parsing would be handled by the python Optparse library. >> > Are users not going to be a part of this? Or you have thought of something > else > for managing users? > > Also in your proposal I don't find any mention of user roles. How will you > manage > user roles? Is the command line tool that you want to build will only be > accessible > by the supersuser/admin? Or moderators and assigned list owners can also > use it > to do whatever it does? Also if you allow moderators and owners then you > probably > have to think of something about permissions to restrict everyone to use > the features > only specific to there role. > > From my point of view this project would (someday) be an command line > alternative to postorius for admin roles. Not that you have to do > everything in this summer, but it > should be kept in mind while you work on it. > > Also may I suggest you to use argparse instead of optparse -- it is now > depricated > since py2.7. > >> >> > I would like to start building the Version 0, but not to throw away, but >> will be refining it further as per the feedback. If all this is OK I would >> start building the version and push it to the mailman.client project. >> >> > You probably should figure out everything before you jump on to coding. > The time till > 19th May is allotted for community bonding and there is a reason for that. > Try to > understand how new features are discussed in here(mailman community) before > becoming python statements. > > I don't know if you already have, but try to read the source code and > understand the > coding style Barry prefers. There is a style guide for mailman, find it > out. > > And forget about the git vs bzr part. I am OK with using bzr :). >> >> Great. > > thanks, > Abhilash Raj >

1 0

Mailman 2.1.18 release
by Mark Sapiro April 26, 2014

April 26, 2014

I am pleased to announce the first release candidate for Mailman 2.1.18. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has new features to help with mitigation of the impacts of DMARC on mailing lists. There is also a new dependency associated with these features. Namely, the new Privacy options -> Sender filters -> dmarc_moderation_action feature requires that the dnspython <http://www.dnspython.org/> package be available in Python. There are also bug fixes. See the attached README for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.18rc1 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 3

Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
by Abhilash Raj April 26, 2014

April 26, 2014

On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S <rajeevs1992(a)gmail.com> wrote: > Hi Stephen, > > The CLI project would be a sub module for the mailman.client project. > > Since bzr does not have the submodule feature, I must be doing it either > by using a new repository or as a new branch to mailman.client .The latter > would be better as it would be easier to integrate the code into the > mailman.client project when this project is completed. > Why do you want it to be a submodule in the first place? If you want to extend mailman.client they why not simply branch it? > > Now about the implementation part.As described in the project timeline, > the first phase would be to build the command tools. I would be building > two classes List and Domain, and identify the various methods that are to > be given to them. Many of the methods are identified in my GSoC proposal. > The command parsing would be handled by the python Optparse library. > Are users not going to be a part of this? Or you have thought of something else for managing users? Also in your proposal I don't find any mention of user roles. How will you manage user roles? Is the command line tool that you want to build will only be accessible by the supersuser/admin? Or moderators and assigned list owners can also use it to do whatever it does? Also if you allow moderators and owners then you probably have to think of something about permissions to restrict everyone to use the features only specific to there role. >From my point of view this project would (someday) be an command line alternative to postorius for admin roles. Not that you have to do everything in this summer, but it should be kept in mind while you work on it. Also may I suggest you to use argparse instead of optparse -- it is now depricated since py2.7. > > I would like to start building the Version 0, but not to throw away, but > will be refining it further as per the feedback. If all this is OK I would > start building the version and push it to the mailman.client project. > > You probably should figure out everything before you jump on to coding. The time till 19th May is allotted for community bonding and there is a reason for that. Try to understand how new features are discussed in here(mailman community) before becoming python statements. I don't know if you already have, but try to read the source code and understand the coding style Barry prefers. There is a style guide for mailman, find it out. And forget about the git vs bzr part. I am OK with using bzr :). > > Great. thanks, Abhilash Raj

1 0

Re: [Mailman-Developers] Mailman3: creating a user from an existing address
by Barry Warsaw April 25, 2014

April 25, 2014

On Apr 25, 2014, at 06:31 PM, Aurelien Bompard wrote: >Interesting. I'll look into that at some point, but I have a few more >urgent things to do, so if someone wants to beat me to it feel free... >;-) Can you open a bug? -Barry

2 1

Re: [Mailman-Developers] Mailman3: creating a user from an existing address
by Barry Warsaw April 25, 2014

April 25, 2014

On Apr 25, 2014, at 04:55 PM, Aurelien Bompard wrote: >I'm trying to create a User in Mailman 3 from an existing Address. If I were >using the Python interface, that would be very easy: just create the user >with no address and then link the existing address to it. So the address is currently unlinked? And you don't want to link it to an existing user, but to a new user you're about to create? >However, I'm using the REST interface. In >mailman.rest.users.AllUser.create(), there's a try/except block which >explicitely looks for this case and raises an HTTP 400 error. Looking at the >test_existing_user_error() test case, it's apparently to prevent creating a >user twice, which is not my use case. Are you OK if I hack the code to >automatically link to an existing address while still erroring-out if the >user already exist? Or would it be better to allow linking to an existing >address from the REST API? The other way to think about it is that you might want to create the user and link to it from the existing address resource, i.e. the AnAddress class. Right now, you cannot get directly from the address to its linked user, if it has one. Look at _AddressBase._resource_as_dict() in addresses.py. Sketching out an approach: - The address resource would gain a `user` key if there is a linked user. This would be a url to the user resource. If the address is unlinked, then there would be no such key. - AnAddress would gain a /user sub-resource which would either 404 if the address is unlinked or return the linked user's JSON data. - POSTing to /addresses/<email>/user would create a new user and link the address to it, but only if the address is not yet linked. If it's already linked, you'd get a 409 Conflict error. If the new user is created, you'd get 201 Created response. Additional use cases to consider: Q. What if the address is already linked and you want to unlink it? A. DELETE on the /addresses/<email>/user resource Q. What if you want to change the user the address is linked to? A. Currently, it's two operations: DELETE the existing link as above, then see below. The other option is to allow a PUT on the /addresses/<email>/user resource. Q. What if you want to link the unlinked address to an existing user? A. Maybe allow this in the POST to /addresses/<email>/user, i.e. the user would only be created if it doesn't yet exist. If it gets created, you'd get a 201 Created, but if it's just a link operation to an existing user, you'd get a 200 Success response. It's possibly you'd want to include POST boolean that specifies whether creating a new user is okay or not, with the appropriate response codes in the false case. -Barry

2 1

Re: [Mailman-Developers] [Mailman-Users] handler to auto detach attachment and link it to a website keeping html
by Sylvain Viart April 25, 2014

April 25, 2014

Coding question. A bit of context: Goal is to develop a custom handler to perform: * detach all attachments * post detached content somewhere available on http * modify the content of the original email, keeping original html, adding an html link to the moved document * adding a small clip image as an attachment symbol as an embed object Le 16/04/2014 16:01, Mark Sapiro a écrit : > <https://docs.python.org/2/library/email.mime.html> to create new > sub-parts and use the Message.attach() method to attach them. How can I replace the part which contain the html part, by a new one which will become : >> Content-Type: multipart/related >>>>Content-Type: text/html; >>>> Content-Type: image/png; name="clip-24.png" The text/html is the old one. Adding a part is ok, but replacing it with a new one which embed the previous one… I dont see. part of the code I've produced: if msg.is_multipart(): syslog('debug', 'multipart message rewriting') related = None for part in msg.walk(): ctype = part.get_content_type() if ctype == 'text/plain' and not part['X-Mailman-Part']: new_footer = txt_attacht_replace + footer_attach part.set_payload(part.get_payload() + new_footer) continue elif ctype == 'text/html': related = MIMEMultipart('related') clip = MIMEText(attach_clip) clip.add_header('Content-Disposition', 'inline') clip.add_header('Content-ID', '<part1.%d>' % 123412) clip['Content-Transfer-Encoding'] = 'base64' del clip['Content-type'] del clip['Content-transfer-encoding'] clip['Content-type'] = 'image/png; name="attachment-24.png"' clip['Content-transfer-encoding'] = 'base64' html_footer = html_attachment_holder % {'html_attachment_clip_tpl': html_footer_attach} html_footer += '</body>' old_content = part.get_payload() new_content = re.sub(r'</body>', html_footer, old_content) part.set_payload(new_content) related.attach(part) related.attach(clip) # WRONG del part msg.attach(related) continue

2 10