Mailman 3 June 2010 - 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

[PATCH] for the notorious Sender header
by Malte S. Stretz 30 Jun '10

30 Jun '10

Hi folks, every now and then the Sender header added by Mailman is discussed on this list. Patches float through the net. The old FAQ is gone but for some reason I remember that it was point 2.3. Guess I read it too often. Because every now and then I get bitten by the header breaking somebody's beloved Outlook. Well, breaking as in "Hey, I got this mail inline forwarded from a list and don't have the original sender's address because all Outlook adds is 'From: Full Name (on behalf of list- owner(a)example.com'". Today I got pissed enough to actually tackle the issue. Instead of the old just-get-rid-of-it patches arriving here, I implemented yet another option on the General page, just below the RFC 2369 options. It defaults to On to keep backwards compatibility. You can find the patch against the 2.1 codebase in this [1] branch. It also applies with a little fuzz against 2.2. The patch is quite simple but I'm not an expert of the codebase and couldn't really test it because I currently don't have the time to set up a local mailman. But the test suite doesn't throw any errors... well, it does throw a bunch of errors and fails but did this already before I applied my patch. I guess it shouldn't be too hard to whip up a patch for 3.0 as well. I just wanted to make sure (and start the old discussion again :) if it should default to On or Off. If I interpret this [2] post from 2006 it isn't really needed. (Hm, almost forgot: I took some of the comments from James Ralston's patch from 2006 and added it to mine.) Cheers, Malte [1]https://code.launchpad.net/~mss/mailman/2.1-sender-header [2]http://mail.python.org/pipermail/mailman-developers/2006- July/019040.html

4 11

small suggestion
by Kent Mein 25 Jun '10

25 Jun '10

Hi I just have a small suggestion/patch. In Mailman/Utils.py in the function get_site_email I think it makes more sense to change these two lines: return '%s@%s' % (mm_cfg.MAILMAN_SITE_LIST, hostname) return '%s-%s@%s' % (mm_cfg.MAILMAN_SITE_LIST, extra, hostname) to this: return '%s@%s' % (mm_cfg.MAILMAN_SITE_LIST, mm_cfg.DEFAULT_EMAIL_HOST) return '%s-%s@%s' % (mm_cfg.MAILMAN_SITE_LIST, extra, mm_cfg.DEFAULT_EMAIL_HOST) chances are more likely you have the MAILMAN_SITE_LIST setup on your emailserver not on your webhost. (We've had to tweak it here so things work) Anyway thanks for the great work you all do. We have been using mailman here at the University of Minnesota for quite awhile and its great. Kent Mein -- mein(a)cs.umn.edu http://www.cs.umn.edu/~mein

2 1

Mailman user interface: draft of a mega drop-down navigation
by Claudia Fleiner 25 Jun '10

25 Jun '10

Hi, I´m Claudia Fleiner and I work together with Patrick Koetter and Florian Fuchs. Here I will present you our idea of a mega drop-down navigation panel for the new Mailman user interface: http://wiki.list.org/display/DEV/Web+UI+Mockups As the draft shows, a mega drop-down has the following characteristics: 1. The big panel is divided into groups of navigation options 2. Navigation choices is structured through layout, typography and icons 3. Eliminate scrolling: everything is visible at once As shown in the draft, I put as navigation structure an example of the "admin navigation options". This structure will be revised into the right form later. The icons I used in the draft are just placeholders. Nice Icons well adapted for the new navigation structure will be designed in the next steps. I hope you´ll like our idea of using drop-down navigations for the new user interface. Please don´t hesitate to send us your feedback. Kind regards, Claudia ----- 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 Am Südhang 3 Telefon +49 6131 6223149 55127 Mainz Amtsgericht München Partnerschaftsregister PR 563e

7 7

UI for Mailman 3.0 update
by Anna Granudd 19 Jun '10

19 Jun '10

Hi, my name is Anna and I'm participating in GSoC for Systers where my project this summer is to develop a new UI for Mailman 3.0 as well as a UI extension for Systers who are running a customized version of Mailman. The UI will be written as an app in Django. Together with my mentor Florian we've discussed some general matters regarding the UI and the most recent concern adding a database for it. We figured it might be good to use the core db only for the "standard" UI with which we'll communicate through the rest-client and for organizations wishing to customize the UI, such as Systers, we'll let them add a UI db. Other things we've discussed was the number of apps for the UI, if we should use only one or if we should separate it into, for instance, one app for the user UI's and one for the admin UI, or possibly split it up even more. We've gathered all our thoughts on http://wiki.list.org/display/DEV/Web+Interface+Status and now we'd like to get some feedback from you people as well as to find out if you have other opinions or ideas for us. I/we would really appreciate your help on this. Thanks, Anna

16 56

REST API docs?
by Fil 18 Jun '10

18 Jun '10

Hi all, I've been looking around for a description of the REST API in Mailman3. Fact is I couldn't wait more and started a REST API for Mailman2. So, I would like it to be as close as possible to the final stuff. -- Fil

2 7

Wiki Editing?
by Adam McGreggor 16 Jun '10

16 Jun '10

I've forgotten who it is who can grant write-access to the wiki, but I don't appear to have an edit button anywhere (apart from labels). Can I have write-perms, please (same email address)? (Or would someone put a link to <http://www.mail-archive.com/mailman-developers@python.org/msg11808.html> (and the second parag of that mail) in <http://wiki.list.org/x/BIGj>, please?) a -- "If more of us valued food and cheer and song above hoarded gold, it would be a merrier world" -- J. R. R. Tolkien

2 1

Mailman 3.0 UI Test Server
by Florian Fuchs 15 Jun '10

15 Jun '10

Hi all, we have set up a test server for the development of the Mailman 3.0 UI. As coding on the UI progresses we will update it regularly so everybody can see what's being done. For now it contains a simple, experimental Django app I've written to test list creation and subscription through Mailman's new REST API. You can add mailing lists and subscribe to them. Mails sent to those lists will not be delivered to subscribers but be kept in a separate IMAP folder so nobody gets spammed (thanks Patrick!). This app will be replaced as soon as there's a working code base for the "real" UI. The server's address is http://mailman.state-of-mind.de Cheers Florian -- 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 Heckmannufer 2 Telefon +49 30 3013 6756 10997 Berlin Mobil +49 176 2064 0812 Amtsgericht München Partnerschaftsregister PR 563e

6 7

spammers harvesting email'ids [was] UI for Mailman 3.0 update
by स्वक्ष 09 Jun '10

09 Jun '10

On Fri, Jun 4, 2010 at 22:43, Mark Sapiro <mark(a)msapiro.net> wrote: > Ian Eiloart wrote: >> >>Well, maybe, but I've had to switch on approval for various lists because >>of subscribing spammers. > > > As Barry suggests, setting moderation of new members as the default can > also thwart the subscribing spammers. A smart spammer would hardly post to the mailing list --atleast on linux lists its asking to be moderated or kicked out, depending on the admins. I've checked out spammers who mass subscribe to the lists at Debian, Ubuntu, Fedora and RH, to access the email id's of all the subscribers (if this is set as available only to the list members). If the settings are "membership list is available only to the *-owner", the spammer can still subscribe, and lurk on the list to silently harvest the email id's of all the folks who post mails to any list they lurk on. The latter can be identified by checking their TLD when they sub to the list but if they use *-free-email-provider like a gmail or yahoo address to sub and lurk, its hard to tell. -- thanks and regards, vid || http://svaksha.com

6 9

Re: [Mailman-Developers] UI for Mailman 3.0 update
by Anna Granudd 07 Jun '10

07 Jun '10

On Mon, Jun 7, 2010 at 12:00 PM, <mailman-developers-request(a)python.org>wrote: > ... >That would be perfect. Should we all meet before we start working on the > new >WUI so we can take the input into consideration right from the start? > IMHO it is easier to talk / discuss about real things than about things > that should be done theoreticaly :). So I'd suggest to meet if a early > draft of the new WUI is available. > Please keep the rest of us, or at least myself and Florian, posted about your discussions when meeting IRL. I believe you Patrick work together with Florian so I guess that should be easy enough. :) In German or English doesn't really matter unless you want to post it to this list... Thanks, Anna

1 0