Mailman-Developers July 2011

mailman-developers@python.org

13 participants
18 discussions

wiki.list.org license has been renewed
by Barry Warsaw 29 Jul '11

29 Jul '11

I think I've managed to get our Confluence license renewed, so those of you with write privileges to wiki.list.org should be able to save pages again. If not, please let me know. I haven't heard much about the Moin conversion lately, but hopefully that will happen before the next time our license runs out. -Barry

2 2

ACL,security - how we'll implement it
by Benedict Stein 21 Jul '11

21 Jul '11

Dear Mailman Developers, we had a nice discussion this afternoon (13:00 - 15:00) UTC about this topic. I've written a small blogposts about the results which will be implemented in near future. http://benste.blogspot.com/2011/07/discussion-on-acls-using-mailman30-and.h… Key aspects: Decided to use a Proxy which: * is responsible for exposing the user roles * using it's own DB * customizable to querry others - e.g. Launchpad * needs to be authenticated at the Core using REST-API (might get https) * similar API to REST, but requiring a username to each request * each request will be handled based on username is already authenticated - e.g in a web-session * will be able to raise HTTP401 (access denied) if user is not allowed to do this action / get this option * might authenticate users based on a request(user;pswd) Python Bindings for REST will be able to use both either Proxyed REST or direct access to Rest depending on wheter the UI decides to use it with a User object. direct REST-API Calls will only be able on localhost -- Einen schönen Tag wünscht: Benedict Stein

1 0

tomorrow - discussion on how / where to implement ACL
by Benedict Stein 20 Jul '11

20 Jul '11

Hi, this IRC meeting will be about implementation of ACL which i do need for the mailmanwebUI. Everyone who is interested in this topic might be join the discussion on IRC tomorrow. https://www.google.com/calendar/event?action=TEMPLATE&tmeid=MGlzZm1tNjg5OGR… -- Einen schönen Tag wünscht: Benedict Stein

2 1

Re: [Mailman-Developers] MM3: list disabling/enabling?
by Ian Eiloart 20 Jul '11

20 Jul '11

> > I think bouncing at the MTA is slightly sub-optimal and that mailman > could generate a more informative bounce indicating how to contact the > server admin to get the list revived. Probably in the web interface > there could be a "disabled lists" category. Server admins would > probably want to be able to login to the disabled lists in the web > interface, but maybe not the list admins. Bouncing certainly is suboptimal, since it may create collateral spam. Better to reject the message at SMTP time with a 5xx response than to bounce. However, it's probably possible to do what you want by putting the list on emergency moderation, and changing the message, is it not? Or something similar? If that is possible, then what's required is simply a web interface to simplify that process. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

5 12

FW: A subscribe link
by Clayton Brown 20 Jul '11

20 Jul '11

Hello Developers at Mailman Thank you for your advice below, this solves my problem but also creates a new problem. The mobility of %(user_delivered_to)s is the issue. Is there something like an msg_body, where you can compile the html letter and insert %(user_delivered_to)s. That would obv be perfect. Right now I have the issue of the msg_footer being inserted as an attachment, but I have found a solution for that on the internet. MIMEDefang... you obv know what I am talking about. Msg_header does not work in MS office, but that won't work either because it will be at the top of the emailer. See attachment. Please let me know what you think. Thanks in advance -----Original Message----- From: Mark Sapiro [mailto:mark@msapiro.net] Sent: 15 July 2011 01:22 AM To: Clayton Brown Cc: mailman-developers(a)python.org Subject: Re: [Mailman-Developers] A subscribe link On 7/14/2011 1:18 AM, Clayton Brown wrote: > > Example: There must be a link on the cleansing email that looks like this: > <a href='www.test.com/subscribe.php?id=recipient@test.co.za'>Opt In</a> > It will be then easy for me to subscribe the recipient into a subscribe > database and just create a list afterwards. If the installation has set OWNERS_CAN_ENABLE_PERSONALIZATION = Yes in mm_cfg.py so that the 'personalize' settings appear on the list admin Non-digest options page and personalize is set to Yes, then either the replacement %(user_address)s or %(user_delivered_to)s can be used in either msg_header or msg_footer to receive either the user's lower-cased email address or case-preserved email address respectively. Those replacements work only in msg_header and msg_footer. They don't work in the message body and they don't work in digests. E.g. You could put Opt-in <www.test.com/subscribe.php?id=%(user_delivered_to)s> in msg_footer. This may or may not be rendered as an active link depending on the users MUA. You can't put an HTML tag in msg_header or msg_footer, because it will always be in a text/plain part of the message. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 4

Re: [Mailman-Developers] MM3: list disabling/enabling?
by Barry Warsaw 15 Jul '11

15 Jul '11

On Jul 13, 2011, at 04:51 PM, Paul Wise wrote: >By bounce I meant SMTP-time rejection, sounds like the LMTP stuff >provides that (and mailman 2 doesn't use that IIRC). Correct. >Temporarily failing lists were not an objective. Cool, I think we're agreed on that. >The design of list objects seems to be heavily similar to how the UI >is in mailman 2, I think it should be much more generic. > >For example: > >In the web UI turning on emergency moderation should set the first >item in the receive pipeline to a hold() function. > >Disabling a list would set the first item in the receive pipeline to >reject_disabled, set the first item in the subscription pipeline to >reject_disabled, set the first item in the settings pipeline to >admin_read_only etc. This isn't exactly how MM3 works. In MM3, the incoming queue sends the message through a chain, where each link has a rule and an action. An action can be something like "jump to the `hold` chain", which is in fact exactly what happens in the default built-in chain: src/mailman/chains/builtin.py: _link_descriptions = ( ('approved', LinkAction.jump, 'accept'), ('emergency', LinkAction.jump, 'hold'), ... There really aren't "subscription" or "settings" pipelines, and I'm not sure they're the right way to implement what you have in mind. >List objects should be flexible to support different kinds of lists, >but the UI should hide most of that behind simple labels like "retired >list", "public list", "private list" and the "emergency moderation" >button. MM3 has list styles, which are composeable and extensible. A style is only applied at list creation time though. >PS: Is there a Mailman UI yet? The link on the Mailman branches wiki >page points to one with only one commit in it and no working code. I think we're still waiting for Florian and the GSoC students to propose branch merges into lp:mailmanweb. >PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm >thinking configuration filenames, data directories etc should be named >mailman3 instead of mailman. Maybe. I'd really like to not do that if it can be avoided. For example, the configuration system is so different I can't see how there would be much collision. The data directories, possibly, but I also think there are enough knobs to allow site admins or vendor packagers to set things up with the proper defaults. I don't think there will be any collisions on command line program names. Cheers, -Barry

1 0

A subscribe link
by Clayton Brown 15 Jul '11

15 Jul '11

Good Morning Mailman Developers I would like to know the following: I want to send out an cleansing email to a list that I have, on the cleansing email there must be a subscribe link. When a recipient clicks on the subscribe link the recipient will automatically be transferred into a new list called subscriptions. Afterwards I have a subscriptions list and the old list which will be deleted. Alternatively is there some way Mailman can put the recipient's email address in a variable in the email the recipient is receiving. Example: There must be a link on the cleansing email that looks like this: <a href='www.test.com/subscribe.php?id=recipient@test.co.za'>Opt In</a> It will be then easy for me to subscribe the recipient into a subscribe database and just create a list afterwards. The main point here is, that when the recipient clicks on the 'Opt-in' link their email address must automatically be captured, thus removing a step where they will be navigated to a page where they must first fill in their email address to be subscribed. I am in inexperience php developer, if there is a way that you know off where I can capture the email's headers please let me know. Please remember the way Mailman works in regards to posting an email. Does it allow for php in the code or only HTML? Thank You in advance Clayton Brown

2 1

Re: [Mailman-Developers] MM3: list disabling/enabling?
by Benedict Stein 13 Jul '11

13 Jul '11

HI Paul, or all others who want to get involved into mm3 WebUI development. I'm closly listening your dicsussion. The WebUI is work in progress and there is nothing stable yet. However if you're interested taking a look at the dev snippets take a look at the following branches: https://code.edge.launchpad.net/mailmanwebgsoc2011 Feel free to contact Flo or me on IRC (#benste) PS: Little tutorial on how to get it running: http://wiki.list.org/pages/viewpage.action?pageId=11960560 Please really keep in mind th Am Mittwoch, den 13.07.2011, 16:51 +0200 schrieb Paul Wise: > On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote: > > > It sounds like a lot, but I'd think it's only a day or two of work, and I'm > > happy to answer questions, review code, etc. > > I would like to get the design right first, after reading the full > thread a couple of times, some thoughts: > > By bounce I meant SMTP-time rejection, sounds like the LMTP stuff > provides that (and mailman 2 doesn't use that IIRC). > > Temporarily failing lists were not an objective. > > The design of list objects seems to be heavily similar to how the UI > is in mailman 2, I think it should be much more generic. > > For example: > > In the web UI turning on emergency moderation should set the first > item in the receive pipeline to a hold() function. > > Disabling a list would set the first item in the receive pipeline to > reject_disabled, set the first item in the subscription pipeline to > reject_disabled, set the first item in the settings pipeline to > admin_read_only etc. > > List objects should be flexible to support different kinds of lists, > but the UI should hide most of that behind simple labels like "retired > list", "public list", "private list" and the "emergency moderation" > button. > > PS: Is there a Mailman UI yet? The link on the Mailman branches wiki > page points to one with only one commit in it and no working code. > > PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm > thinking configuration filenames, data directories etc should be named > mailman3 instead of mailman. > -- Einen schönen Tag wünscht: Benedict Stein

1 0

Re: [Mailman-Developers] MM3: list disabling/enabling?
by Benedict Stein 13 Jul '11

13 Jul '11

HI Paul, or all others who want to get involved into mm3 WebUI development. I'm closly listening your dicsussion. The WebUI is work in progress and there is nothing stable yet. However if you're interested taking a look at the dev snippets take a look at the following branches: https://code.edge.launchpad.net/mailmanwebgsoc2011 Feel free to contact Flo or me on IRC (#benste) PS: Little tutorial on how to get it running: http://wiki.list.org/pages/viewpage.action?pageId=11960560 Please really keep in mind these are only suggested peaces of work which don't even cover all basic functionallity. Am Mittwoch, den 13.07.2011, 16:51 +0200 schrieb Paul Wise: > On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote: > > > It sounds like a lot, but I'd think it's only a day or two of work, and I'm > > happy to answer questions, review code, etc. > > I would like to get the design right first, after reading the full > thread a couple of times, some thoughts: > > By bounce I meant SMTP-time rejection, sounds like the LMTP stuff > provides that (and mailman 2 doesn't use that IIRC). > > Temporarily failing lists were not an objective. > > The design of list objects seems to be heavily similar to how the UI > is in mailman 2, I think it should be much more generic. > > For example: > > In the web UI turning on emergency moderation should set the first > item in the receive pipeline to a hold() function. > > Disabling a list would set the first item in the receive pipeline to > reject_disabled, set the first item in the subscription pipeline to > reject_disabled, set the first item in the settings pipeline to > admin_read_only etc. > > List objects should be flexible to support different kinds of lists, > but the UI should hide most of that behind simple labels like "retired > list", "public list", "private list" and the "emergency moderation" > button. > > PS: Is there a Mailman UI yet? The link on the Mailman branches wiki > page points to one with only one commit in it and no working code. > > PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm > thinking configuration filenames, data directories etc should be named > mailman3 instead of mailman. > -- Einen schönen Tag wünscht: Benedict Stein

1 0

Re: [Mailman-Developers] MM3: list disabling/enabling?
by Barry Warsaw 13 Jul '11

13 Jul '11

On Jul 11, 2011, at 12:22 AM, Paul Wise wrote: >For the Indymedia Mailman 2 install, we have a patch that allowed list >disabling (and later re-enabling). Disabled lists had their >settings/archives saved, did not accept mail and were listed on a >separate page to listinfo. For a long-lived large mailman server >serving local groups in many locations, management of the complete >list life cycle was and still is essential for us. > >AFAICT Mailman 3 doesn't yet support such a concept, is that the case? I've thought about this on and off over the years and still think it's a good idea. No, MM3 does not have such a thing yet. >If not, would it be acceptable to add that? Yep, but I'd like to understand the semantics first. Do messages to the list get bounced, and if so, by Mailman or the MTA? Currently, deleting a list does remove its configuration, but (by default) retains its archives, which can be deleted later. A disabled list would always have its archives available I think. >Any pointers if I were to try and add that? I think the core feature would not be too hard to implement, but some specifics would depend on answering the main question above. Here's an outline of what you'd probably need to touch: - IMailingList interface to add a `enabled` flag, along with (possibly) methods to disable and re-enable a list. It's possible that the flag would be a property and just setting `mlist.enabled = False` would be enough. - mailman.sql to add that flag to the schema. - MailingList model to plumb the flag through and implement the switching logic. - Add a new command class, probably in cli_lists.py to expose disable/enable to `bin/mailman`. Perhaps implement this as options on the existing `remove` command. - Plumb this through to the REST API, either by extended the AList class in src/mailman/rest/lists.py, or by exposing the flag in the ListConfiguration class in src/mailman/rest/configuration.py. - Tests and documentation! It sounds like a lot, but I'd think it's only a day or two of work, and I'm happy to answer questions, review code, etc. -Barry

3 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers July 2011