Mailman-Developers March 2008

mailman-developers@python.org

33 participants
22 discussions

by Satoshi Tanabe

Hello, Currently I'm creating an unofficial site of GNU Mailman. It's not done yet, but the goal is to make the current official site more accessible and usable. The content is almost the same. The unofficial site (since Google Page Creator doesn't support folders, images are not shown and linked docs are not available): http://gnu.mailman.googlepages.com/index.html You can download the source tarball here (with linked docs): Source Tarball (size: 1.1mb) http://gnu.mailman.googlepages.com/Mailman-Site-Redesign.tar.gz This site tries to solve the problems that I listed in the following document: What's wrong with the current Mailman official site? http://gnu.mailman.googlepages.com/wrong.txt I'd love to have your feedback. Also, I listed several questions in the document above, so I'd appreciate if any of you could answer or comment on them (Some questions are not about the official site per se). Best, - Satoshi

12 years, 11 months

Mailman 2.1.10b4 Released

by Mark Sapiro

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am happy to announce the next beta release of Mailman 2.1.10. This is a security and bug fix release and it is highly recommended that all sites upgrade to this version. Mailman 2.1.10 also adds support for three new language translations, Galician, Hebrew and Slovak and a few new features. Mailman is free software for managing email mailing lists and e- newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, including download links, please see: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman Special thanks are due to Barry Warsaw and Tokio Kikuchi for much coding and support, Moritz Naumann for help with security issues and Jim Tittsler for a significant patch. Here's a list of the major changes. Security - - The 2.1.9 fixes for CVE-2006-3636 were not complete. In particular, some potential cross-site scripting attacks were not detected in editing templates and updating the list's info attribute via the web admin interface. This has been assigned CVE-2008-0564 and has been fixed. Thanks again to Moritz Naumann for assistance with this. New Features - - Changed cmd_who.py to list all members if authorization is with the list's admin or moderator password and to accept the password if the roster is public. Also changed the web roster to show hidden members when authorization is by site or list's admin or moderator password (1587651). - - Added the ability to put a list name in accept_these_nonmembers to accept posts from members of that list (1220144). - - Added a new 'sibling list' feature to exclude members of another list from receiving a post from this list if the other list is in the To: or Cc: of the post or to include members of the other list if that list is not in the To: or Cc: of the post (Patch ID 1347962). - - Added the admin_member_chunksize attribute to the admin General Options interface (Bug 1072002, Partial RFE 782436). Internationalization - - Added the Hebrew translation from Dov Zamir. This includes addition of a direction ('ltr', 'rtl') to the LC_DESCRIPTIONS table. The add_language() function defaults direction to 'ltr' to not break existing mm_cfg.py files. - - Added the Slovak translation from Martin Matuska. - - Added the Galician translation from Frco. Javier Rial Rodríguez. Changes since 2.1.10b3 include the Galician translation and updates to the French translation (Vietnamese and Danish translations were updated in 2.1.10b3). Other changes since 2.1.10b3 include: - - In 2.1.9, queue runner processing was made ~ more robust by making backups of queue entries when they were dequeued ~ so they could be recovered in the event of a system failure. This ~ opened the possibility that if a message itself caused a runner to ~ crash, a loop could result that would endlessly reprocess the message. ~ This has now been fixed by adding a dequeue count to the entry and ~ moving the entry aside and logging the fact after the third dequeue of ~ the same entry. - - Fixed the command line scripts add_members, sync_members and ~ clone_member to properly handle banned addresses (1904737). - - Fixed bin/newlist to add the list's preferred language to the list's ~ available_languages if it is other than the server's default language ~ (1906368). - - Changed the first URL in the RFC 2369 List-Unsubscribe: header to go ~ to the options login page instead of the listinfo page. - - Changed the options login page to not issue the "No address given" ~ error when coming from the List-Unsubscribe and other direct links. ~ Also changed to remember the user's language selection when ~ redisplaying the page following an error. /Mark Sapiro - -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH2eJuVVuXXpU7hpMRAihOAJ4zIREWCWCQt7YDDHp3frDHjzwkCQCfdh7J W3UKWsTTfStBE4z64oqa36c= =ZedT -----END PGP SIGNATURE-----

13 years, 2 months

before next release: disable backscatter in default installation

by Jo Rhett

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

13 years, 2 months

Google Summer of Code - Spam Defense

by Timo Wingender

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I like to participate in Google Summer of Code this year. One possible Project for me is to implement some Spam Defense in Mailman. I think development for Mailman should be possible through Python Software Foundation. Am I right with this? I administrate a Mailman installation with about 100 lists and thousands of users and I moderate most of the Lists. I think the biggest Problem of Mailman is the lack in spam defense. Discard messages from nonmembers is no option on most lists. Some time ago I began some modification of Mailman. But I never finished it. The first action is to integrate support for SpamAssassin in Mailman. Therefor I wrote a python class spamc which connects to spamd. This gives the possibility to scan all incoming Mail. Further ideas for spam defense are: - - Add the possibility to scan all messages form nonmembers half an hour later again before mark them as hold. This is because most of the mails which are not recognized as spam are to new. The servers are not in any blacklist at time of incoming. - - Train the bayes filter from Mailman. Forward all accepted Messages to SpamAssassin to learn them as ham. The autolearn feature of SA doesn't work for me. It learns to much false negatives. This are my ideas so far. Is this welcome in Mailman and is it enough for an GSoC Project? Where would it be best? 2.1.11? 2.2.0? 3.0.0? Best Wishes Timo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH67yiakDbqHKnrh8RAhxoAKDYWguLeFxuSAy18sSCXdwWONmdiwCg2YwO W60FvGTr79tAAXZEndPSFSk= =iutB -----END PGP SIGNATURE-----

13 years, 2 months

Done.

by Jo Rhett

I've been incredibly tolerant of being abused on this issue for 3 weeks now, but the now-constant flood of people coming forward to say that I'm not respecting the mailman community is too funny. It breaks the bounds of reality. *I* did one thing. I pointed out an issue that *EVERYONE* knows about, even the non-technical news media. I asked that something be done soon. I wrote my post clearly and politely. http://mail.python.org/pipermail/mailman-developers/2008-March/019804.html Did I receive a respectful response addressing these issues from anyone who writes code for the project? Yes: Mark Sapiro wrote me a respectful reply on March 5. http://mail.python.org/pipermail/mailman-developers/2008-March/019807.html But that reply only negated my suggestions, with no solutions proposed. I attempted to respond to the insults and derision I received in most of the replies with honest, straightforward answers. Even when the questions were hopelessly supercilious and rude. At this time there has been more effort spent writing me back saying that I'm not respecting the community than it would have taken to write patches to fix the problem. I've certainly wasted more time here than I did writing my patches and testing them in the first place. I respected the community by coming here and trying to address the issue, rather than simply blacklisting Mailman sites. I respected the community by replying to everyone who replied to me, rather than ignoring the posts filled with derision or technical nonsense. Perhaps that was a mistake. I had a nice dinner with a number of people last night on this topic, and not a single person (all of whom witnessed this thread) felt that trying to address this issue here was producing any results. So I am done. Keep your derision to yourself, and keep wasting time telling people how they should respect you rather than solve the problem. I am right now updating our AUP documentation to mention that Mailman is explicitly banned unless the person provides documentation of the configuration/patches they have applied to prevent backscatter. I am notifying the known mailman sites within our network. We are done with this issue. -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness

13 years, 2 months

Has Mailman lost its way?

by David Lee

First there was Majordomo... Once upon a time, Majordomo version one was the leader in its field. So good was it, that ambitious plans were laid for a succeeding generation: version two. And at that point it went off the rails and ended up in a ditch. 'Domo V1 got stuck, because the development went into 'Domo V2. But V2 got stuck because it never got released and never got used. And so the once glorious Majordomo sadly faded into the night-time of obscurity. Move forward a few years... In another place, at a later time, Mailman v2.1 became the leader in its field. So good was it, that ambitious plans were laid, not just for one, but for two, succeeding generations: v2.2 and v3. And at that point... ... well what has happened? Nearly two years ago, the July 5 2006 "What I did on my summer vacation" email and wiki entry (http://wiki.list.org/x/vg) outlined a massive amount of potential progress. But, in reality, what actually have we (the subset of real-world end-users who could assist development) been able to do? Has Mailman lost its way? Could it be drifting to the same obscurity and oblivion as the entire majordomo project? Could I suggest that serious consideration be given to: 1. Freeze 2.1 now. No new features. The only exception would be security bug-fixes. Nothing else. 2. Freeze "new idea" development now. Concentrate solely on bugfixing the already implemented ideas. 3. Decide whether 2.2 or 3.0 is the way of the near future. The reality is that neither of these has delivered anything to the real-world end-user during two or more years. Choose only one. Freeze the other for the time being, until the "chosen one" has been properly post-beta released. 4. Whichever of the above is chosen, aim to start delivering betas fast. Get something out there that you (the main developers) and we (some real-world end-users who can help bug-hunt) can get to work on, knowing that our work will be productive in a foreseeable timescale. Set the goal. Drive towards it, ignoring distractions. 5. For a few months, change the mindset away from development (yes, I know we coders love it) and towards a firm, decisively-directed "release management" (to use ITIL-speak). Mailman used to be a leading product. But it is slipping behind. We, the end-users, need some of that new code that's being lying dormant, and (to an end-user) unuseable, during the last two years or so. Many of us, the enthusiastic real-world end-users, cannot realistically commit to developing something for which there is no clear strategy. Give us a strategy, a roadmap with real, near-future dates on it, then we can at least make local business cases to our local managements for our taking part in beta trials. Let's get some new code out now as beta. There may be a sizeable "TODO"; there may be a sizeable "Known Problems". But let's start releasing betas soon, and concentrate all our limited efforts on that one common task. Otherwise, are we not in danger of following Majordomo into oblivion? (Oh, and #1 on my own list is proper "virtual domains": the Jul/2005 paper mentioned that the code substantially existed. But sadly it's never come anywhere near a release schedule. If we have a realistic beta-release schedule, then I can locally justify actively investing in bug-hunting.) Sorry if that sounds harsh. It is meant to be constructive. (Honest!) Best wishes. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

13 years, 2 months

Re: [Mailman-Developers] Google Summer of Code - Spam Defense

by Cristóbal Palmer

On Sat, Mar 29, 2008 at 01:12:59PM -0500, Robby Griffin wrote: >> How/where do I stop that? > > How is that backscatter? Looks like plain old spam to me (addressed > to a -owner address, which forwarded to postmaster But it shouldn't go to postmaster! /usr/local/mailman/bin/list_owners cc-co shows me three addresses, all of which are @gmail.com addresses. > , which forwarded to you), postmaster does forward to me, yes. > and your (three!) SpamAssassins two. One on malecky (the list machine), and one on garp. The third machine doesn't come into play here. > let it through. Though one > of them did score it high enough to be marked as spam, you don't > seem to have anything between the world and your inbox that actually > blocks spam... Not true. Mail to lists (but apparently not owners) now gets discarded if it has been tagged as spam. Furthermore, I have procmail rules in place in two places that drop mail above a certain threshold and quarantine a middle batch. > If it helps, I have one setup where I have to discard high-scoring > spam with procmail on its way into my inbox, and another where I > modified SA to add a user-configurable threshold for tagging > "extreme" spam so I could discard it within the MTA. I don't discard anything at the MTA, but otherwise you've got close to what I've got. What I'm missing here is the step where the mail went from going to one of the three list admins (again, all at gmail) to going to me. Where was the forgery? How did mailman (or was it postfix?) get duped? Cheers, -- Cristóbal Palmer ibiblio.org systems administrator

13 years, 2 months

Re: [Mailman-Developers] Done.

by Mark Sapiro

Jo Rhett wrote: >Mark Sapiro wrote: >> Are you aware that not once in the "before next release:" thread is >> there any mention that you have patches? Perhaps this has been >> mentioned before, and I missed it, but I would be interested in seeing >> them. > >I'm not on the mailing list any more. But not only did I say this >multiple times, but I said this directly in a reply to you: > >http://mail.python.org/pipermail/mailman-developers/2008-March/019809.html What you said in that reply was "I disabled all the backscatter aliases 4 years ago, and haven't heard a single complaint." You also acknowledged in a subsequent post that "obviously you also have to patch the headers added to list e-mail to not reference these names" This is to me at least, not the same thing as saying you have actual patches. Close perhaps, but not the same. >The patches I did were brute-force patches for 2.1.4 or maybe even >earlier. Any competent programmer could do the same patches in about 15 >minutes. Maybe so, and maybe even I could, but even a checklist such as the following, presumably tested, list is of interest. >* Create only a single alias per list (remove 11-12 lines from the output) > >* Change the default to D_DISCARD in two places > >* Remove the option to reject message (leave accept/discard) in moderation > >* Change the headers to give only http addresses for subscribe/unsubscribe. > >I kid you not, it's less text than this message. It's also very >brute-force and I can understand why people would want something >supported by the Mailman developers. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

13 years, 2 months

Per-user subject prefix setting

by Kenneth Porter

A frequent request on mailing lists without a subject prefix is to add one. This often leads to long debate threads about the utility of the prefix. There seems to be two different styles of processing mail that leads to this conflict. One style (which I use) is to filter mail into many folders, one per list. No tag is needed in this case. The other style is to dump all mail into one or a small number of folders, and in this style one needs to tag to know which list a message belongs to. This has been captured in this feature request: <https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1104433&group_…> There seems to be limited code for customizing messages per-user, but this setting may want to be treated as some kind of user "class" setting so that messages can still be batched for the no-prefix class and the add-prefix class. Perhaps this could be implemented as two distinct queues, similar to the way digests are treated as a distinct queue.

13 years, 3 months

Question about specific place of source code

by Lars Reimann

Hi all, i am using mailman 2.1.9. I am making some customizations, and i have a questions about MIME Content-Type. (I have crawled through the archives...) If I add a message header (msg_header and msg_footer) mailman sets the > Content-Type: text/plain; charset="us-ascii" My Question is, if anyone can please point me to the line of code, where this is added to a message. I already looked in Decorate.py but my alterations (e.g. comment out the header addition) did not make any difference. So the place where i looked might not be correct. I want to see how these are constructed and maybe alter to fit my customization. Any urgent help would be greatly appreciated. Thanks so far, L.R.

13 years, 3 months

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