Mailman-Developers October 2012

mailman-developers@python.org

8 participants
7 discussions

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

Listadmin and other alternate interfaces for Mailman
by Terri Oda 07 Nov '12

07 Nov '12

Since I now treat every gathering of hackers as an excuse to get people to tell me things about Mailman, I was chatting with folk at the GSoC mentor summit and my friend V was telling me that she really likes Listadmin as a nicer interface to Mailman: http://freecode.com/projects/listadmin Seems like something I might have to look at and learn some lessons from before we're done with postorius dev. Anyhow, it got me thinking: does anyone here use any other add-ons that they think I should know about? :) I used to have a set of greasemonkey scripts for my own lists, and I'll bet I'm not the only one. Terri

4 5

Re: [Mailman-Developers] [Merge] lp:~sophron/postorius/create_users into lp:postorius
by Richard Wackerbarth 25 Oct '12

25 Oct '12

Isn't the visibility of the list members a per_list policy setting? In any case, we will need to have list administrators (who are not the superuser) be able to see the membership on their list. I think that Postorius will require a better model for roles. Richard On Oct 25, 2012, at 3:19 AM, Florian Fuchs <flo.fuchs(a)gmail.com> wrote: > Review: Approve > > Hi George, > > thank you for your changes (and the bug reports)! I have just merged them to the trunk. I only made some very small changes and additions (adjusted the docstring in MailmanUserView, added the user icon, some PEP8 fixes...). I also made the user list and details only available to superusers (I don't think every user should be able to see who else is there...).

1 0

add_members and nomail
by Scot Hacker 23 Oct '12

23 Oct '12

Back in 2005, while working at an OS X Server-based organization, I wrote a bash + python script pair that extracted students/staff/faculty from a database to populate mailman lists, where many members were subscribed to various lists in nomail mode, using add_member's "-e" flag. The system worked very well. Later, we dropped OS X Server and moved to Linux, and I was surprised to find that my script no longer worked. Only then did I realize that "-e" for "nomail" was an Apple customization that never found its way into the standard Mailman distribution. I solved the problem by copying the Apple-provided add_members to my Linux systems and changing the python shebang at the top. These days, I find myself still doing the same thing on the cPanel-based systems I run, which means my systems break each time cPanel updates Mailman, and that I now run a very old version of add_members. Every organization I've worked for has had this need to batch-add people in nomail mode, which makes it really surprising to me that the standard distribution still doesn't support the option (I can't possibly be the only admin with this need!) Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included? Thanks, Scot

4 8

Logging automatic rejects of incoming posts.
by Mark Sapiro 20 Oct '12

20 Oct '12

When a handler raises Errors.RejectMessage to reject an incoming post, nothing is logged. I have filed <https://bugs.launchpad.net/mailman/+bug/1068837> in preparation for addressing this. My question is what to log. Currently, IncomingRunner logs automatic discards with the message 'Message discarded, msgid: %s'. This is a bit cryptic. I think it would be good to have the list name in this message, but I have never changed it as that could be disruptive. It would also be possible to log which handler raised the exception, but again, that could be disruptive. With a new message for rejects, disruption is not much of an issue as existing log analyzers would presumably not recognize the message and skip it, which is no different from no message, or report the raw message. The question is whether it is a good thing to log the error message that accompanies the exception. This can be quite verbose as the error message can be the list's member_moderation_notice or nonmember_rejection_notice, but if only the handler name is logged, it doesn't distinguish between a non-member reject and a moderated member reject. Does anyone have an opinion on this? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

Manipulate mailman in / out queue (from mailman-users)
by Barry Warsaw 19 Oct '12

19 Oct '12

[Redirecting part of this discussion from mailman-users to mailman-developers. Mark does a great job of explaining the gory details of the queue runners.] On Oct 16, 2012, at 09:23 PM, Mark Sapiro wrote: >First of all, The actual physical size of the queue directory impacts >processing. Every time an entry is added to the queue, and every time >a .pck file is renamed to .bak, the entire physical directory must be >searched to ensure this isn't a duplicate name. Depending on OS >settings, cache sizes and the physical directory size, this may >actually involve multiple disk reads each time. Thus, if the >qfiles/out/ directory has grown large because 8000+ messages were >added to the queue when the runner couldn't handle them (and there may >have been more in the retry/ queue because of SMTP failures), it would >benefit from shrinking. This is accomplished by moving (mv) or >renaming the queue directory itself aside, not just its contents and >then letting the runner recreate it when it starts. Then, if >necessary, move messages back a few at a time so the directory doesn't >grow large again. I'd like to begin to explore ways to make this automatically more manageable, so that when problems occur (e.g. upstream SMTPd not responding or slow), Mailman can recognize and response more efficiently to the problem. The first question to ask is whether this mostly affects the outgoing queue, or whether other queues *in practice* can suffer the same overloading? I suspect that the incoming queue could get filled quickly if Mailman is slow to handling an onslaught of new messages. My sense is that in general, it's the outgoing queue that gives people the most problems though. The switchboard in Mailman 3 is largely the same as in Mailman 2 (modulo updating the code to more modern Pythons). Before describing my own thoughts, I'd like to open it up and get a sense of your experiences, and strategies you think might help manage big queues. Cheers, -Barry

2 1

GHC 12 Open Source Day was amazing!
by Terri Oda 08 Oct '12

08 Oct '12

A very quick report: We had our post-GHC12 hackathon today and I think we were wildly successful. I didn't sit down and count, but we had around 15 women, most new contributors, hacking on Postorius/Mailman today. We stomped on a bunch of the specially-marked bugs, and just as vitally, we had a bunch of folk go through decent first-pass usability testing of the Postorius interface with Robin (who is an experienced UI person from Google) and file bugs for the missing bits that seem most essential for the Postorius release. Sometimes we also filed fixes for the bugs that were tractable in the time we had! Because we were on limited time, I've just got a pile of contributions tarballed up on our dev vm (and backed up elsewhere), and I got everyone who fixed a bug to comment on it on Launchpad so we can send out the appropriate copyright forms. I'll be marking those bugs as fixed once I get home (I need to pack and sleep now) and sometime thereafter (probably next weekend) I'll separate out the code to merge requests and triage the rest of the new bugs so we can start work on those. I think people had a lot of fun seeing their code go live on our test server and watching their bugs get fixed, and I think we've got a few contributors who'll be interested in doing more (and maybe, once I wrangle the travel funds, coming to pycon!). I'm so very excited! :) Terri

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 October 2012