Mailman 3 July 2011 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 07 Nov '22

07 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

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

28 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 19 Jul '11

19 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 14 Jul '11

14 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