Mailman 3 April 2009 - 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

mailman 3: webinterface: prototype (PDF)
by Patrick Ben Koetter 08 May '09

08 May '09

Greetings, following our discussions at the Pycon 2009 Mailman sprint I've come up with first draft of a/the future mailman 3 web interface. The interface has changed a lot. Changes follow these principles: * Simplify interface * Focus on tasks * Order and sort by task recurrance * Reduce information overflow e.g. by hiding help messages * Show help messages as bubbles when selected by user * Remove instructions on using a web from * Use default button texts e.g. "Save" instead of "Submit your changes" See also: <http://wiki.list.org/display/DEV/Rest+client> I've come up with a paper prototype, which you can download in an annotated PDF by clicking at "Mailman webinterface draft" at the following location: <http://wiki.list.org/display/DEV/Information+Architecture> Important The version you can download is _not a design_. It's a grid that creates a structure, puts elements we need on a (HTML) page, orders and groups them following the principles I've outlined above. Please feel free to comment on it and ask questions. I've spent the last 5 days clicking the old interface, thinking and sitting before my current proposal - I just might be blind to my own stupidity or brain dead by now. ;) My goal is to agree on an information architecture, so we can go on and create a design that combines functional requirements and aesthetics. Once we've agreed on a design, we will create HTML templates and then we will put them together with the upcoming REST client. p@rick -- state of mind Agentur für Kommunikation, Design und Softwareentwicklung http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563

3 9

MM 2.1.12(rc2) backport for Ubuntu Hardy?
by Adam McGreggor 26 Apr '09

26 Apr '09

Just a quick query really (and possibly being slightly cheeky asking here...), but have any of you guys backported Mailman 2.1.12 from the Ubuntu Jaunty (or Debian 5) repos -> Ubuntu Hardy? I can't seem to find anything with an internet search, and I'd rather not repeat the efforts, if someone's already done it (as it's been quite some time since I last backported something) TIA. a -- ``Foot-and-mouth believed to be first virus unable to spread through Microsoft Outlook'' (spoof headline)

5 5

Re: [Mailman-Developers] Mailman and Extend.py
by Chris Nulk 17 Apr '09

17 Apr '09

Mark Sapiro wrote: > C Nulk wrote: >> Thank you for responding. A quick question, will MM3 also support the >> @list funtionality, both for the 4 *_these_nonmembers options and the >> owner, moderator, and the ban_list options? > > > I have a few remarks about this. The @listname feature was implemented > in Mailman 2.1/2.2 after they diverged from 3.0 so it's not in 3.0 at > this moment. It probably will be if it makes sense to do so. Thank you for the info Mark. > > However, for your situation, the whole notion of a member adaptor per > se goes away in 3.0 and is replaced by the backend database interface, > so this may not be that significant. Okay. I understand. > > Regarding owner and moderator, my understanding (Barry will correct me) > is that these roles are defined in the back-end rather than being list > attributes per se so I think your question becomes moot at least for > owner and moderator. > Don't have a problem with a backend database for deriving/managing the members of a list, whether it be MySQL, Postgresql, LDAP, or anything else. Clearly makes sense to me. It was just for the other "list of email addresses" options I was curious about. If they are defined by a backend database, am I restricted to the same backend database as I am using for members list? Or, can I use a different backend for each of the "list of email addresses" options whether it be LDAP, MySQL, Postgresql, etc. or any combination of the mix? Now, about an LDAP interface to MM3 (or possibly making the MM2 more complete), is anyone interested in what ideas I have thought about? If so, a new thread should probably be started. Thanks, Chris

3 2

Mailman and Extend.py
by C Nulk 17 Apr '09

17 Apr '09

Hello, I have recently implemented the LDAPMembership adapter. It provides some good functionality in creating the list membership. However, the concept is there to provide access to one or more lists of email addresses (list membership is essentially a list of email addresses). I would like to use the LDAP functionality in other areas which require or use a list of email addresses (e.g. accept_these_nonmembers, hold_these_nonmembers, etc). I have looked at the F.A.Q. on custom handlers and read the MailList.py file (under __init__) to see the 'extend.py' file being loaded. Can someone better explain how loading the 'extend.py' file incorporates the files code and how the 'def extend' function is called? If I can understand how it works, perhaps, a solution to adding multiple LDAP search queries can be added to the extend.py file and used in other places in Mailman. Thanks, Chris P.S. When explaining, please realize I am moving from knowing absolutely nothing about Python to knowing next to nothing. :):)

4 14

Patch for Bug 266263 (NNTP gatewaying trashes Message-IDs)
by phaidros 17 Apr '09

17 Apr '09

Hi, we have thought a while about it and needed a solution badly. We are having several Mail2News mailing lists, which all come up with broken threading, when cross posted messages appear. The same issues as stated in the bug here: https://bugs.launchpad.net/mailman/+bug/266263 I have just added a patch and a description for the patch at launchpad. This is a request for considering this patch as improvement and merging it. A lot of mail and news administrators would be thankful for less headaches :) kind regards, kloschi -- With or without religion, we would have good people doing good things and evil people doing evil things. But for good people to do evil things, that takes religion." -- Steve Weinberg

1 0

Systers Custom Mailman Extensions and GSoC projects
by Jennifer Redman 13 Apr '09

13 Apr '09

Hello! So I posted many months ago about Systers (http://systers.org) and our implementation of dynamic sublists for Mailman. We finally managed to get everything into source control: http://launchpad.net/systers and ported to Mailman 2.1.10. (I apologize for our Launchpad organization -- it's on my list to straighten things out a bit including a new patch set and a better versioning scheme.) To implement the dlist options, we needed to add on a separate database -- we are currently using Postgresql, unfortunately at this time the code contains raw sql calls. The good news is that Systers was accepted into the GSoC and one of our projects is building out the ORM layer for the dlist functionality. We received an overwhelming number of applications and are just now reaching the final stages of ranking students and proposals. You can see our idea's page here: http://systers.org/systers-soc One of our requirements for the ORM project is compatibility with MM3 (we originally recommended using SQL Alchemy, but are now asking for STORM since it appears that is what MM3 is using.) With that in mind, and since our projects all have a Mailman focus are there any active developers who would be willing to join our dev list and/or potentially act as "armchair-mentors" -- just being available to answer any specific questions about Mailman and perhaps help introduce our students to the Mailman development community in a kind and gentle manner? If so would you please email me off-list (jenred(a)gmail.com) and tell me a little bit about your background -- (if you are interested in being an informal mentor)? Features that are included in our MM customizations: 1) Dynamic sublists (the ability to unsubscribe from individual discussion threads) 2) Alternate email address - users can enter in multiple email addresses (as opposed to being done at the admin level) 3) Essay requirement for mailing list application and approval At this point our documentation is part of a larger set of complete system installation, we will make better installation directions available over the next week or so if anyone is interested in using some of the above features (in tandem with the Launchpad re-org, and patch making). Features hopefully coming soon: 1) Using an ORM for Database Abstraction (for dlist functionality) 2) Storing application essays for future review 3) Using the MM user data for 3rd party application authentication (potentially OpenID and OpenLDAP) One of our priorities is to make sure we are doing things in ways that are compatible with MM3 and MM upstream in general, so any suggestions are welcome. Thanks, Jen

1 0

Inserting users names as signature of message
by Capt Bruce Gregory 13 Apr '09

13 Apr '09

I hope this is on topic and hopefully not a question that has been hashed and rehashed but: I need a way to append the full name box string of each user to the end of each message they post. Is this something that is easily attainable? Thank You, Bruce Gregory, neophyte list administrator

2 2

Detailed Flowchart
by vince＠wlcr.net 11 Apr '09

11 Apr '09

Where can I get a detailed flowchart of the mailman system? Thanks!

1 0

Mailman+SpamBayes for Mailman 2.2
by skip＠pobox.com 08 Apr '09

08 Apr '09

Sorry about the rather broad distribution. A few people have inquired recently about this code. I *think* I successfully migrated my cron/gate_news changes to the mailman 2.2 branch. The modified mailman2.2 branch is available here: bzr+ssh://smontanaro@bazaar.launchpad.net/%7Esmontanaro/mailman/SpamBayes/ (I have no idea how these strange URLs work. You'll probably need to snip out the "smontanaro@" bit. What you might replace it with I have no clue or if the protocol needs to be changed.) The cron/gate_news file has been changed to run incoming Usenet messages through the SpamBayes classifier. There is also a spambayes.ini file to use as a template. This simple change worked wonders on the python-list(a)python.org mailing list. I still see complaints about spam from time-to-time. I think, "what spam?". When I investigate I always find it's a user on the Usenet side of the bridge who is complaining. There is still absolutely no training support. You will have to wrangle that somehow else. Either the mboxtrain or tte scripts which come with the SpamBayes distribution should do the trick if you have some collected ham and spam. If you need some help, contact me offline or send email to spambayes(a)python.org. Cheers, -- Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/ "XML sucks, dictionaries rock" - Dave Beazley

2 1