Mailman-Developers August 2008

mailman-developers@python.org

7 participants
6 discussions

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

08 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

Enabling topics with only one topic: can't exclude topic?
by Stephen J. Turnbull 07 Sep '08

07 Sep '08

Context: The bzr developers are considering splitting their Mailman list into a -dev and a -user list, but they don't like that because they feel it would split their community in an undesirable way. So the proposal is to create a [codereview] topic which gets workflow-related posts (nitty-gritty coding style comments as well as automatically generated messages from a patch queue manager). Most users aren't going to be interested in these, but will be interested in bug reports and their resolutions, and in design discussions, which will not get an explicit topic. So many users would like to select *only* messages *without* explicit topic. The quoted post claims that appears to be impossible. Seems like a bug to me, either in the topic feature (if it *is* impossible) or in the page template documenting usage. John Arbash Meinel writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Pool wrote: > | I've set up a Mailman topic "codereview", and people can use this to > | opt out of getting review related mail. (Or, if you want, to get only > | code reviews, but that would look a bit strange.) > | > | Messages will be classified into this topic if they have either > | [merge] or [codereview] in the Subject, or in a Keywords header, or in > | a pseudoheader in the top 5 lines of the message body. > | > | I have to say that the interface through which users can configure > | this is not so obvious and people who want it may not find it. But, > | it's there and we can see how it goes. > | > | If anyone wants to try it out: go to > | <https://lists.ubuntu.com/mailman/options/bazaar>, enter your address, > | and scroll to the bottom of the resulting page. If it doesn't work as > | intended please let me know. > | > > So, I was reading through the description, and I found this: > > | If you do not select any topics of interest, you will get all the messages > | sent to the mailing list. > > And the description below that is: > | Do you want to receive messages that do not match any topic filter? > | > | This option only takes effect if you've subscribed to at least one > topic above. > > > So there is a problem. There is no way to say that don't want codereview > messages. > > You can get *only* codereview by checking the box, and then saying you > don't want unmatched messages. > > You can get all messages by either not checking codereview, or by > checking it and saying you *do* want unmatched messages. > > It seems that the only way to get what non-reviewers want, is to have > multiple topics, perhaps one as a dummy "ijustwanttodisablecodereview" > topic. > > Further, I *do* like the idea of sending merge requests directly to BB, > and having it forward the messages to the list. I think it could be an > optional feature for people who know the BB address. I suppose that I'm > a bit concerned with BB's stability if we do implement this. Because if > BB goes down, then all of our submissions get circular filed (trashed > until bounce, or whatever). > > John > =:-> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkiZrLAACgkQJdeBCYSNAAPEcgCeIpAOODfcymjQ4y9x3MAO4tyT > Y4gAoJe/WS0vmrSsZ8GGz40OyIVGegrf > =OjCX > -----END PGP SIGNATURE----- >

3 5

Demo import of bugs/patches/rfes to Launchpad
by Barry Warsaw 26 Aug '08

26 Aug '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce a demo import from SourceForge's bug tracker, patches tracker, and feature request tracker into Launchpad, and I invite you to play with the new issue tracker so that we can decide whether or not to complete this step of project hosting migration. The url is <https://bugs.demo.launchpad.net/mailman/+bugs> Things to note: This is a /demo/ import meaning that you can play with it all you want and it will not affect the eventual production import of the issues. This is a live demo though, so you should be able to try out all the features you would have access to in the main Launchpad site. Just remember that at the end of the demo, all these changes will be lost. All three SF trackers have been collapsed into one tracker on LP. With only 632 open issues, hopefully this will not be a problem, but if it is we can at least just import the bug tracker when/if we switch. If we wanted to import all three trackers but keep them separate, we'd have to figure something out. I don't have a timeframe for converting, or deciding to convert. Much depends on your feedback (and especially Mark's) and the readiness of the LP administrators to do the production import. I think if we like it, we could make the switch fairly quickly. Please send your feedback to me and I will communicate it back to the Launchpad developers working on this. My thanks go to Graham Binns and Tom Haddon. Enjoy, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkil/MwACgkQ2YZpQepbvXE0YgCdEdgPHKbXjd/JIlxenrlQmdUi fEoAn2QuaTwi/H1Ks9AYVEnFeFQLi7lZ =OHCC -----END PGP SIGNATURE-----

2 2

Re: [Mailman-Developers] [Mailman-Users] Subscribers suddenly "disappear"
by Max Lanfranconi 26 Aug '08

26 Aug '08

I tried the "sleep" approach as well. But then I thought that it was not viable. I am setting a relatively high number of mailing list that will receive asynchronous "subscribe" requests via web and/or shell API. It would be simply not possible to prevent bug this from happening as the chance of two "subscribe" being processsed almost simultaneously are not that small... I also vote for some kind of timing/lock issue. Max Barry Finkel wrote: > Max Lanfranconi <Max.Lanfranconi(a)Sun.COM> wrote: > > >> Mailman 2.1.11 >> Python 2.4.4 >> OS Solaris 2.11 >> >> >> Hi, >> >> I have been able to reproduce this bug consistently by running the >> replicate_bug script: >> >> >> replicate _bug is the following: >> >> #!/bin/sh >> /usr/local/mailman/bin/rmlist testlist1 >> /usr/local/mailman/bin/rmlist testlist2 >> /usr/local/mailman/bin/rmlist testlist3 >> /usr/local/mailman/bin/rmlist testlist4 >> /usr/local/mailman/bin/rmlist testlist5 >> /usr/local/mailman/bin/rmlist testlist6 >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist1 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist2 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist3 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist4 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist5 >> list-admin(a)domain.com testpwd >> /usr/local/mailman/bin/newlist -q -e url.domain.com testlist6 >> list-admin(a)domain.com testpwd >> >> >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist1 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist2 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist3 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist4 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist5 >> echo "foo(a)bar.com" | /usr/local/mailman/bin/add_members -r - testlist6 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist1 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist2 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist3 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist4 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist5 >> echo "boo(a)foo.com" | /usr/local/mailman/bin/add_members -r - testlist6 >> >> After a short wait the following output is received: >> >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: foo(a)bar.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> Subscribed: boo(a)foo.com >> >> foo(a)bar.com receives 6 confirmation emails, as boo(a)foo.com does. S >> o far so >> good. >> >> At this point testlist1-6 each should contain 2 subscribers: foo(a)bar.com >> and boo(a)foo.com >> >> BUT >> >> /usr/local/mailman/bin/list_members testlist1 >> /usr/local/mailman/bin/list_members testlist2 >> /usr/local/mailman/bin/list_members testlist3 >> /usr/local/mailman/bin/list_members testlist4 >> /usr/local/mailman/bin/list_members testlist5 >> /usr/local/mailman/bin/list_members testlist6 >> >> invariably produce some random combination in which one or more of the >> subscribers are missing: >> for example: >> boo(a)foo.com >> foo(a)bar.com >> foo(a)bar.com >> boo(a)foo.com >> foo(a)bar.com >> foo(a)bar.com >> foo(a)bar.com >> boo(a)foo.com >> foo(a)bar.com >> >> in which three instances of boo(a)foo.com are missing... >> >> No Errors in any Mailman log. >> >> >> Thanks in advance for your help. Please let me know if you need additional >> details. >> Regards, >> Max >> > > I ran the script (after some minor modifications) on > > Ubuntu Dapper > Mailman 2.1.11 (self-built package) > Python 2.4.3 (#2, Oct 6 2006, 07:49:22) > > and I get similar results: > > Script started on Tue 05 Aug 2008 09:45:31 AM CDT > # set prompt="mailman11-test# " > mailman11-test# ./replicate_bug.exec > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist1 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist2 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist3 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist4 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist5 > Remove the components of a mailing list with impunity - beware! > > This removes (almost) all traces of a mailing list. By default, the lists > archives are not removed, which is very handy for retiring old lists. > > Usage: > rmlist [-a] [-h] listname > > Where: > --archives > -a > Remove the list's archives too, or if the list has already been > deleted, remove any residual archives. > > --help > -h > Print this help message and exit. > > > No such list (or list already deleted): testlist6 > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > boo(a)foo.com > foo(a)bar.com > 2 > boo(a)foo.com > foo(a)bar.com > 3 > boo(a)foo.com > foo(a)bar.com > 4 > boo(a)foo.com > foo(a)bar.com > 5 > foo(a)bar.com > 6 > foo(a)bar.com > mailman11-test# ======================================================= > mailman11-test# ./replicate_bug.exec > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > boo(a)foo.com > foo(a)bar.com > 2 > boo(a)foo.com > foo(a)bar.com > 3 > foo(a)bar.com > 4 > foo(a)bar.com > 5 > foo(a)bar.com > 6 > foo(a)bar.com > mailman11-test# ======================================================= > mailman11-test# ./replicate_bug.exec > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Not removing archives. Reinvoke with -a to remove them. > Removing list info > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: foo(a)bar.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > Subscribed: boo(a)foo.com > mailman11-test# foreach list (1 2 3 4 5 6) > ? echo $list > ? list_members testlist$list > ? end > 1 > foo(a)bar.com > 2 > boo(a)foo.com > foo(a)bar.com > 3 > foo(a)bar.com > 4 > foo(a)bar.com > 5 > foo(a)bar.com > 6 > foo(a)bar.com > mailman11-test# exit > > Script done on Tue 05 Aug 2008 09:50:48 AM CDT > > I then added > > sleep 5 > > after each "add_members" line, and the output looked fine. > I changed the sleep interval from 5 down to 1 in successive > runs, and each output looks fine; each list has the proper two > subscribers. Is there a timing issue here? > ---------------------------------------------------------------------- > Barry S. Finkel > Computing and Information Systems Division > Argonne National Laboratory Phone: +1 (630) 252-7277 > 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 > Building 222, Room D209 Internet: BSFinkel(a)anl.gov > Argonne, IL 60439-4828 IBMMAIL: I1004994 > > ------------------------------------------------------ > Mailman-Users mailing list > Mailman-Users(a)python.org > http://mail.python.org/mailman/listinfo/mailman-users > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-users/max.lanfranconi%40sun.… > > Security Policy: http://wiki.list.org/x/QIA9 >

7 15

Web Interface to Mailman using Zope
by Daniel Harris 12 Aug '08

12 Aug '08

Hi, I have put together a proof-of-concept UI to Mailman using Zope. It currently implements two functions: viewing a list of lists and creating a new list. I am announcing this to the developers' list: o to see if there is interest in using Zope / Plone as the basis for a user interface o to enquire about how I might best continue this work. I created the prototype to start exploring whether Plone and Mailman could be integrated to support a community organisation I'm working with. In particular, I wanted participants to be able to: o manage their mailing list subscriptions through Plone o view mailing list messages through Plone, email or RSS o send messages to mailing lists by email or Plone. The implementation comprises a Zope product, a bridge, and a server that provides access to Mailman functions. I'm currently using Corba for the bridge as I'm not familiar with REST - but I am planning to transfer to the REST interface as its implementation develops. The interface (around five entries) provides access to Mailman functions to list mailing lists, create a mailing list and list available languages. Additional functions are defined to check the arguments used to create a new list - these functions are used by the ZPT page to display errors needing correction to the end user. Your advice and comments are requested. I have read through previous discussions and documents about the web interface in the mailing lists and on the developers' wiki. Regards, Daniel.

1 0

Scheduled downtime for wiki.list.org
by Barry Warsaw 04 Aug '08

04 Aug '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody, Just a quick note that Contegix, our hosting provider for the wiki, will be performing a requested upgrade of the server at 0200 EDT on Tuesday, August 5. There is a 2 hour planned downtime for the upgrade. No other Mailman services will be affected. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkiXAGQACgkQ2YZpQepbvXGqmQCcCMBn0D5lDTm2e/p066PjMwBN NFIAoJ7B/gzfWGqcNEe0lZOP1o8UbA29 =HCPy -----END PGP SIGNATURE-----

1 0

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 August 2008