Re: [Mailman-Developers] Mailman 2.1.18 release
I'm pleased to announce the third candidate release for Mailman 2.1.18. This fixes a few bugs since discovered since the second release candidate. Python 2.4 is the minimum supported, but Python 2.7 is recommended. Please submit any i18n updates before May 1 to get them in the final release. 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 m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.18rc3 (25-Apr-2014) Bug fixes and other patches - The Reply-To: munging options weren't honored if there was no from_is_list action. (LP: #1313010) - Changed from_is_list actions to insert the list address in Cc: if the list is fully personalized. Otherwise, the list address is only in From: and Reply-To: overrides it. (LP: #1312970) - Fixed the Munge From action to only Munge the From: and/or Reply-To: in the outgoing message and not in archives, digests and messages sent via the usenet gateway. (LP: #1311431) 2.1.18rc2 (19-Apr-2014) Bug fixes and other patches - The new Utils.IsDMARCProhibited() used collections.defaultdict which requires Python 2.5. Changed to use a dict and setdefault. 2.1.18rc1 (18-Apr-2014) Dependencies - There is a new dependency associated with the new Privacy options - Sender filters - dmarc_moderation_action feature discussed below. This requires that the dnspython http://www.dnspython.org/ package be available in Python. This package can be downloaded from the above site or from the CheeseShop https://pypi.python.org/pypi/dnspython/ or installed with pip. New Features - The from_is_list feature introduced in 2.1.16 is now unconditionally available to list owners. There is also, a new Privacy options - Sender filters - dmarc_moderation_action feature which applies to list messages where the From: address is in a domain which publishes a DMARC policy of reject or possibly quarantine. This is a list setting with values of Accept, Wrap Message, Munge From, Reject or Discard. There is a new DEFAULT_DMARC_MODERATION_ACTION configuration setting to set the default for this, and the list admin UI is not able to set an action which is 'less' than the default. The prior ALLOW_FROM_IS_LIST setting has been removed and is effectively always Yes. There is a new DMARC_QUARANTINE_MODERATION_ACTION configuration setting which defaults to Yes but can be set to No to exclude domains with DMARC policy of quarantine from dmarc_moderation_action. dmarc_moderation_action and from_is_list interact in the following way. If the message is From: a domain to which dmarc_moderation_action applies and if dmarc_moderation_action is other than Accept, dmarc_moderation_action applies to that message. Otherwise the from_is_list action applies. i18n - Added missing mm-digest-question-start tag to French listinfo template. (LP: #1275964) Bug Fixes and other patches - Fixed a long standing issue in which a notice sent to a user whose language is other than that of the list can cause subsequent things which should be in the list's language to be in the user's language instead. (LP: #1308655) - Fixed the admin Membership List so a search string if any is not lost when visiting subsequent fragments of a chunked list. (LP: #1307454) - For from_is_list feature, use email address from original From: if original From: has no display name and strip domain part from resultant names that look like email addresses. (LP: #1304511) - Added the list name to the vette log held message approved entry. (LP: 1295875) - Added the CGI module name to various No such list error log entries. (LP: 1295875) - Modified contrib/mmdsr to report module name if present in No such list error log entries. - Fixed a NameError exception in cron/nightly_gzip when it tries to print the usage message. (LP: #1291038) - Fixed a bug
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
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.abhila...@gmail.comwrote: On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S rajeevs1...@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 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi Rajeev, On Sat, Apr 26, 2014 at 1:27 PM, Rajeev S rajeevs1...@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? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
