Mailman 3 May 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 2.1x Authentication LDAP and OpenID - SQL Member Adaptor
by Jennifer Redman 29 May '09

29 May '09

Hello, One of the Systers' Google Summer of Code Projects is abstracting Mailman authentication for use with other application frameworks via LDAP and potentially OpenID, using a SQL Member Adaptor. If anyone has a good round-up of existing code or efforts to do this in MM 2x (using a SQL Member Adaptor) or would be interested in providing some mentoring support to our GSoC student leading the project (particularly with regards to doing things the "Mailman Way"), please let me know. If you are interested in contributing to the project, with either some mentoring or code contributions -- please join our development mailing list - http://www.systers.org/mailman/listinfo/systers-dev. Thanks, Jennifer

2 1

Should Mailman provide periodic activity summaries to list owners?
by Stephen J. Turnbull 29 May '09

29 May '09

A quick search didn't find anything, so I'll do a more careful check and if there's nothing I'll add a tracker RFE and a short wiki page of the imagined feature, probably on Monday. Unfortunately, I can't volunteer to implement at this time. Details: I noticed that we've been getting a lot of posts from users who are being quite diligent about following up on their own issues, to the extent of their knowledge and accesses, but for one reason or another are not using the logs. Would it be desirable and feasible to send a periodic (options: daily, weekly, monthly, never) activity summary to list owners (similar to the tracker summaries that many trackers send to associated mailing lists)? If someone's list is having problems, then they could get access via the admin interface, which would simply wrap the text report which would be generated for mailing in an HTML PRE element, making for trivial implementation (once the report itself is implemented, of course). Something like Week of May 17-23, 2009 44 incoming messages processed (42 posts, 2 other) 1 message automatically discarded 2 messages held (1 non-member, 1 spam filter) of which 2 messages were approved 41 messages distributed to members 2 weekly digests produced (maximum size reached 1 time(s)) 20 SMTP errors occurred of which 18 posts handled normally by bounce processing 2 subscription requests (probable backscatter) Abstract of discarded messages From: hormel(a)163.com To: resident(a)whitehouse.gov Subject: We cannot transfer $1 million to you without account information Message-ID: <abc(a)fbi.cia.nsa> Abstract of held messages not configured. Abstract of SMTP errors not configured.

6 8

Mailman-2.1.9: User Interface Customization
by Alain Reguera Delgado 28 May '09

28 May '09

Hello, As part of a web redesign I've customized mailman-2.1.9 user interface. I would like to know if these changes are useful for the project somehow. http://wiki.centos.org/WebsiteVer2/WebEnvironment/Mailman Thanks for this great software. Best Regards, -- Alain Reguera Delgado areguera(a)allmail.net -- http://www.fastmail.fm - Access your email from home and the web

1 0

Re: [Mailman-Developers] Set cookies for global authentication
by Mark Sapiro 18 May '09

18 May '09

Hopkins, Justin wrote: > >I manage approx 50 discussion lists using the mailman system. The nature >of our organization is that one member is more than likely subscribed to >more than just 1 list. One issue that has come up among the membership >is the desire to authenticate only once and then be permitted to access >the private archives for all lists that they are subscribed to without >logging in again. > >I've noticed that using administrative credentials created a cookie >named 'site' whereas a normal login creates a cookie identifying the >users email address and the individual list. > >Has anyone worked on changing this functionality, or is it planned for >Mailman 3? I've scoured list archives and the internet in general and >haven't found even a hint that anyone is working on this or even feels >like it's worth complaining about. Did you look at <http://wiki.list.org/x/vgAM>? The very first paragraph says in part "Many things that people have been wanting for years will be addressed, most notably a unified user database ...". The unified user database will address this and several other issues involving user email addresses, roles, authentication, etc. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

Re: [Mailman-Developers] Set cookies for global authentication
by Barry Warsaw 18 May '09

18 May '09

On May 15, 2009, at 9:10 PM, Hopkins, Justin wrote: > Has anyone worked on changing this functionality, or is it planned for > Mailman 3? I've scoured list archives and the internet in general and > haven't found even a hint that anyone is working on this or even feels > like it's worth complaining about. This will be the case in MM3, because you'll have just one 'account' under the unified user database. -Barry

1 0

Re: [Mailman-Developers] Set cookies for global authentication
by Adam McGreggor 17 May '09

17 May '09

On Fri, May 15, 2009 at 08:10:54PM -0500, Hopkins, Justin wrote: > One issue that has come up among the membership > is the desire to authenticate only once and then be permitted to access > the private archives for all lists that they are subscribed to without > logging in again. > > Has anyone worked on changing this functionality, or is it planned for Hum, we're sort of doing something like that, at least for lists-admin. <https://secure.mysociety.org/cvstrac/rlog?f=mysociety/lists/web-admin/lists…> (<http://is.gd/AO16>) might be a starting point for you. (and also <https://secure.mysociety.org/cvstrac/dir?d=mysociety/lists/web-admin/lists/…> (<http://is.gd/AO1s>)) (In our case authentication works via Apache Basic Auth, unix groups, and password-generation scripts <https://secure.mysociety.org/cvstrac/rlog?f=mysociety/bin/htpasswd_import_u…> (<http://is.gd/AO1Z>) it should be quite trivial to implement using LDAP, too.) -- ``What lawyers call intellectual property is no more than theft from the public domain.'' (Andy Mueller-Maguhn)

1 0

Set cookies for global authentication
by Hopkins, Justin 15 May '09

15 May '09

Hey all, I manage approx 50 discussion lists using the mailman system. The nature of our organization is that one member is more than likely subscribed to more than just 1 list. One issue that has come up among the membership is the desire to authenticate only once and then be permitted to access the private archives for all lists that they are subscribed to without logging in again. I've noticed that using administrative credentials created a cookie named 'site' whereas a normal login creates a cookie identifying the users email address and the individual list. Has anyone worked on changing this functionality, or is it planned for Mailman 3? I've scoured list archives and the internet in general and haven't found even a hint that anyone is working on this or even feels like it's worth complaining about. Thoughts? Cheers, Justin J. Hopkins MOBIUS, Internet Applications Specialist hopkinsju(a)umsystem.edu

1 0

Re: [Mailman-Developers] [Mailman-Users] Deleting messages from archive....
by Barry Warsaw 15 May '09

15 May '09

On May 15, 2009, at 5:04 PM, Ralf Hildebrandt wrote: > * Mark Sapiro <mark(a)msapiro.net>: >> Charles Gregory wrote: >>> >>> Has anyone ever developed a point-n-click tool to delete >>> a message from an archive, preferably by just eliminating the >>> From/To/Subject and body, but leaving the links intact, with >>> a placeholder message that says "message content removed", etc? >> >> >> Not as far as I know. > > It would totally rule. Especially on python.org, where people regret > posting their full name because "employers tend to google them", and > then come running to us, asking "Please remove my name". > > Fucktards. > > But I like the idea of such a function. I've long thought that all archives should be vended dynamically rather than statically, of course with a cache to improve performance as necessary. This would allow you to do lots of interesting things, such as add links dynamically (e.g. "bug 12345" pointing to your bug tracker), or on-the-fly modification of archive style or anti-spam obfuscation, with the proper cache invalidation. This would also allow you to "delete" a message from the archive, by laying down a marker that causes the program to instead return a "not available" or cleansed message without affecting the underlying data. -Barry

1 0

Proposal: option for UTF-8 emails without base64 encoding
by Petr Hroudný 15 May '09

15 May '09

Hi all, due to Python defaults, mailman exhibits strange behaviour when processing UTF-8 emails. When no header/footer is configured, mailman passes UTF-8 emails in original form, i.e. 8bit. However, when either header or footer is configured in mailman, it uses Python's libraries to add them and as a side effect it converts 8bit emails into 7bit base64 encoded ones. This is highly undesirable in some cases. For instance, mailinglist might be used to distribute trouble tickets or other content which is expected to be easily parsable by automated text-based utilities. With base64, emails grow in size by 33 % and such emails are getting much higher spam scores since base64 is typically used by spammers to obfuscate the payload. There are of course much more reasons for not using base64 as the primary encoding method for UTF-8 email. The fix is quite simple and is already widely used by other projects. All that needs to be done is to redefine Python's UTF-8 charset properties, i.e. in every place where you have from email.Charset import Charset you need to add: email.Charset.add_charset('utf-8',email.Charset.SHORTEST, None, None) With such setting, mailman will keep the 8bit encoding also when it's adding header/footer and won't downconvert to 7bit+base64. So I'd like to propose the above addition, at least as a configurable option if there's any fear that enabling it by default could cause some problems. Thanks, Petr

3 3