From anna.granudd at gmail.com Thu Jun 3 14:29:40 2010 From: anna.granudd at gmail.com (Anna Granudd) Date: Thu, 3 Jun 2010 14:29:40 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update Message-ID: 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 From adam-mailman at amyl.org.uk Thu Jun 3 17:56:37 2010 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Thu, 3 Jun 2010 16:56:37 +0100 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: <20100603155637.GD4752@amyl.org.uk> hey, On Thu, Jun 03, 2010 at 02:29:40PM +0200, Anna Granudd wrote: > 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. I think I may be missing something: "Systers". Is this something specific? > 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. Do translations/i18n aspects come under UI customizations? > 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. In "Features to be implemented first" 1. Ability for users to subscribe, manage subscriptions, unsubscribe, change emails 2. Admin ability to create/delete lists via pre-defined styles 3. Users ability to customize their subscirptions s/subscirptions/subscriptions/ 4. Moderation 5. Site admin ability to create domains, add and modify styles 6. List admin ability to customize lists I think admins being able to set-up/customize lists, is probably equally important, if not more important, then being able to (un)sub; if the lists can't easily be set-up, then what's the point in having people subscribe to them? a -- ``Freedom of the press in Britain means freedom to print such of the proprietor's prejudices as the advertisers don't object to.'' (Hannen Swaffer) From barry at list.org Thu Jun 3 20:20:25 2010 From: barry at list.org (Barry Warsaw) Date: Thu, 3 Jun 2010 14:20:25 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100603155637.GD4752@amyl.org.uk> References: <20100603155637.GD4752@amyl.org.uk> Message-ID: <20100603142025.2a38214e@heresy> On Jun 03, 2010, at 04:56 PM, Adam McGreggor wrote: >I think I may be missing something: "Systers". Is this something >specific? www.systers.org >> 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. > >Do translations/i18n aspects come under UI customizations? We do eventually need to make sure all of the web ui can be translated. Ideally, we'd be able to extract text strings into .pot files and then set up a catalog for the wui. I don't know how Django does it, but it should be part of the story. > 1. Ability for users to subscribe, manage subscriptions, > unsubscribe, change emails > 2. Admin ability to create/delete lists via pre-defined styles Note that in my current thinking, it is the site admin who can create styles. I don't know if individual list admins should be able to do that, though they should definitely be able to pick a style and do some customizations of their list. The ability of site admins to lock down styles, control customizations, and delegate style definitions can come later. > 3. Users ability to customize their subscirptions > >s/subscirptions/subscriptions/ > > 4. Moderation > 5. Site admin ability to create domains, add and modify > styles > 6. List admin ability to customize lists > >I think admins being able to set-up/customize lists, is probably >equally important, if not more important, then being able to >(un)sub; if the lists can't easily be set-up, then what's the point in >having people subscribe to them? Lists can currently be easily created on the command line, and subbing/unsubbing is a much more common task, so I think there is an argument for users being able to easily join/leave existing lists before it's easy to create lists through the web. But I don't have strong feelings either way. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From rich at richleland.com Thu Jun 3 22:37:25 2010 From: rich at richleland.com (Richard Leland) Date: Thu, 3 Jun 2010 16:37:25 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100603142025.2a38214e@heresy> References: <20100603155637.GD4752@amyl.org.uk> <20100603142025.2a38214e@heresy> Message-ID: Django's handling of i18n/l10n is well done. You could also use something like Transifex to encourage contributions in various langs. http://docs.djangoproject.com/en/1.2/topics/i18n/#topics-i18n http://www.transifex.net/ Richard Leland rich at richleland.com 240-242-7424 On Thu, Jun 3, 2010 at 2:20 PM, Barry Warsaw wrote: > On Jun 03, 2010, at 04:56 PM, Adam McGreggor wrote: > > >I think I may be missing something: "Systers". Is this something > >specific? > > www.systers.org > > >> 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. > > > >Do translations/i18n aspects come under UI customizations? > > We do eventually need to make sure all of the web ui can be translated. > Ideally, we'd be able to extract text strings into .pot files and then set > up > a catalog for the wui. I don't know how Django does it, but it should be > part > of the story. > > > 1. Ability for users to subscribe, manage subscriptions, > > unsubscribe, change emails > > 2. Admin ability to create/delete lists via pre-defined styles > > Note that in my current thinking, it is the site admin who can create > styles. > I don't know if individual list admins should be able to do that, though > they > should definitely be able to pick a style and do some customizations of > their > list. The ability of site admins to lock down styles, control > customizations, > and delegate style definitions can come later. > > > 3. Users ability to customize their subscirptions > > > >s/subscirptions/subscriptions/ > > > > 4. Moderation > > 5. Site admin ability to create domains, add and modify > > styles > > 6. List admin ability to customize lists > > > >I think admins being able to set-up/customize lists, is probably > >equally important, if not more important, then being able to > >(un)sub; if the lists can't easily be set-up, then what's the point in > >having people subscribe to them? > > Lists can currently be easily created on the command line, and > subbing/unsubbing is a much more common task, so I think there is an > argument > for users being able to easily join/leave existing lists before it's easy > to > create lists through the web. But I don't have strong feelings either way. > > -Barry > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/rich%40richleland.com > > Security Policy: http://wiki.list.org/x/QIA9 > From anna.granudd at gmail.com Fri Jun 4 10:02:30 2010 From: anna.granudd at gmail.com (Anna Granudd) Date: Fri, 4 Jun 2010 10:02:30 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: Hi, there are some mock-ups on the wiki (see http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you could help with ideas for a nice design and layout! Thanks, Anna On Fri, Jun 4, 2010 at 9:05 AM, Martin Albisetti wrote: > Hi Anna! > > It's great to see this happening. > Do you have a clear idea and/or wireframes for the layouts of the pages? > > If not, I'd be happy to help mock-up a default "skin" that looks nice > and easy to use. > > > -- > Martin > From iane at sussex.ac.uk Fri Jun 4 12:20:35 2010 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 04 Jun 2010 11:20:35 +0100 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100603142025.2a38214e@heresy> References: <20100603155637.GD4752@amyl.org.uk> <20100603142025.2a38214e@heresy> Message-ID: <07FFADBB7C082A6ABF0C63B9@lewes.staff.uscs.susx.ac.uk> --On 3 June 2010 14:20:25 -0400 Barry Warsaw wrote: >> 2. Admin ability to create/delete lists via pre-defined styles > > Note that in my current thinking, it is the site admin who can create > styles. Right, but it would be nice if Mailman came with some styles out of the box. At least, a "closed discussion list" and an "announcement list". These days, I guess that requiring approval for membership should be the default, so that should be part of any shipping style. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From argentina at gmail.com Fri Jun 4 09:05:01 2010 From: argentina at gmail.com (Martin Albisetti) Date: Fri, 4 Jun 2010 09:05:01 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: On Thu, Jun 3, 2010 at 2:29 PM, Anna Granudd wrote: > 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. Hi Anna! It's great to see this happening. Do you have a clear idea and/or wireframes for the layouts of the pages? If not, I'd be happy to help mock-up a default "skin" that looks nice and easy to use. -- Martin From barry at list.org Fri Jun 4 17:08:31 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 4 Jun 2010 11:08:31 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: <20100603155637.GD4752@amyl.org.uk> <20100603142025.2a38214e@heresy> Message-ID: <20100604110831.735d4a79@heresy> On Jun 03, 2010, at 04:37 PM, Richard Leland wrote: >Django's handling of i18n/l10n is well done. You could also use something >like Transifex to encourage contributions in various langs. > >http://docs.djangoproject.com/en/1.2/topics/i18n/#topics-i18n >http://www.transifex.net/ We'll probably end up using Launchpad since our branches and bug trackers are there, but Transifex does look nice. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Jun 4 17:10:00 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 4 Jun 2010 11:10:00 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: <20100604111000.18bc5a92@heresy> On Jun 04, 2010, at 10:02 AM, Anna Granudd wrote: >there are some mock-ups on the wiki (see >http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you >could help with ideas for a nice design and layout! Martin's a rock star, so I'm sure he'll come up with some really nice stuff. Go Beuno! :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Jun 4 17:12:04 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 4 Jun 2010 11:12:04 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <07FFADBB7C082A6ABF0C63B9@lewes.staff.uscs.susx.ac.uk> References: <20100603155637.GD4752@amyl.org.uk> <20100603142025.2a38214e@heresy> <07FFADBB7C082A6ABF0C63B9@lewes.staff.uscs.susx.ac.uk> Message-ID: <20100604111204.36e2ca3a@heresy> On Jun 04, 2010, at 11:20 AM, Ian Eiloart wrote: >>> 2. Admin ability to create/delete lists via pre-defined styles >> >> Note that in my current thinking, it is the site admin who can create >> styles. > >Right, but it would be nice if Mailman came with some styles out of the >box. At least, a "closed discussion list" and an "announcement list". Yes, Mailman will definitely come with a few built-in styles. >These days, I guess that requiring approval for membership should be the >default, so that should be part of any shipping style. Is it? Aren't most open source discussion lists generally open membership (perhaps with initial moderation)? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adam-mailman at amyl.org.uk Fri Jun 4 17:42:58 2010 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Fri, 4 Jun 2010 16:42:58 +0100 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100604111204.36e2ca3a@heresy> References: <20100603155637.GD4752@amyl.org.uk> <20100603142025.2a38214e@heresy> <07FFADBB7C082A6ABF0C63B9@lewes.staff.uscs.susx.ac.uk> <20100604111204.36e2ca3a@heresy> Message-ID: <20100604154258.GO4752@amyl.org.uk> On Fri, Jun 04, 2010 at 11:12:04AM -0400, Barry Warsaw wrote: > On Jun 04, 2010, at 11:20 AM, Ian Eiloart wrote: > >These days, I guess that requiring approval for membership should be the > >default, so that should be part of any shipping style. > > Is it? Aren't most open source discussion lists generally open membership > (perhaps with initial moderation)? Are we (as a community) forgetting who the majority of users/admins who need "more help than normal" are? I would have thought more "real-world" users of Mailman, would be the sort of things we see questions being asked about on mailman-users; newsletters, announcement lists, that sort of thing, rather than what we, as geeks are au fait with. I'm more of the mould that maybe we should make things a little easier for those who can't read source-code, who need something up and running quickly and without fuss; I'm not quite sure I go as far as Ian, in requiring approval, but certainly to require confirmation, and I might suggest, moderation bit being set, too. (most of *my* 400 odd lists are for non-geeks; a majority of them are open-subscription, without moderation, but I vaguely keep an eye on the amounts of mail going to each list; there's an element of trust, and vigorous spam-filtering going on before mail gets to Mailman). -- If we couldn't laugh at things that didn't make sense, we couldn't react to a lot of the world around us. (Calvin and Hobbes) From iane at sussex.ac.uk Fri Jun 4 18:02:42 2010 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 04 Jun 2010 17:02:42 +0100 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100604111204.36e2ca3a@heresy> References: <20100603155637.GD4752@amyl.org.uk> <20100603142025.2a38214e@heresy> <07FFADBB7C082A6ABF0C63B9@lewes.staff.uscs.susx.ac.uk> <20100604111204.36e2ca3a@heresy> Message-ID: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> --On 4 June 2010 11:12:04 -0400 Barry Warsaw wrote: > On Jun 04, 2010, at 11:20 AM, Ian Eiloart wrote: > >>>> 2. Admin ability to create/delete lists via pre-defined styles >>> >>> Note that in my current thinking, it is the site admin who can create >>> styles. >> >> Right, but it would be nice if Mailman came with some styles out of the >> box. At least, a "closed discussion list" and an "announcement list". > > Yes, Mailman will definitely come with a few built-in styles. > >> These days, I guess that requiring approval for membership should be the >> default, so that should be part of any shipping style. > > Is it? Aren't most open source discussion lists generally open membership > (perhaps with initial moderation)? Well, maybe, but I've had to switch on approval for various lists because of subscribing spammers. > -Barry > -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From mark at msapiro.net Fri Jun 4 18:58:12 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 4 Jun 2010 09:58:12 -0700 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> Message-ID: Ian Eiloart wrote: > >--On 4 June 2010 11:12:04 -0400 Barry Warsaw wrote: > >> Is it? Aren't most open source discussion lists generally open membership >> (perhaps with initial moderation)? > >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. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Fri Jun 4 19:01:11 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 4 Jun 2010 10:01:11 -0700 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100604154258.GO4752@amyl.org.uk> Message-ID: Adam McGreggor wrote: >On Fri, Jun 04, 2010 at 11:12:04AM -0400, Barry Warsaw wrote: >> >> Is it? Aren't most open source discussion lists generally open membership >> (perhaps with initial moderation)? > >I'm not quite sure I go as far as >Ian, in requiring approval, but certainly to require confirmation, and >I might suggest, moderation bit being set, too. I think that's exactly what Barry was saying. "open membership" does not imply subscription without confirmation. It only means subscription without approval. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Fri Jun 4 21:52:31 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 4 Jun 2010 15:52:31 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: <20100604154258.GO4752@amyl.org.uk> Message-ID: <20100604155231.1366beca@heresy> On Jun 04, 2010, at 10:01 AM, Mark Sapiro wrote: >Adam McGreggor wrote: > >>On Fri, Jun 04, 2010 at 11:12:04AM -0400, Barry Warsaw wrote: >>> >>> Is it? Aren't most open source discussion lists generally open membership >>> (perhaps with initial moderation)? >> >>I'm not quite sure I go as far as >>Ian, in requiring approval, but certainly to require confirmation, and >>I might suggest, moderation bit being set, too. > > >I think that's exactly what Barry was saying. "open membership" does >not imply subscription without confirmation. It only means >subscription without approval. Correct. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From vid at svaksha.com Sat Jun 5 12:36:05 2010 From: vid at svaksha.com (=?UTF-8?B?IOCkuOCljeCkteCkleCljeCktyA=?=) Date: Sat, 5 Jun 2010 16:21:05 +0545 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update Message-ID: On Fri, Jun 4, 2010 at 22:43, Mark Sapiro 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 From julian at mehnle.net Sat Jun 5 15:48:56 2010 From: julian at mehnle.net (Julian Mehnle) Date: Sat, 5 Jun 2010 13:48:56 +0000 Subject: [Mailman-Developers] spammers harvesting email ids In-Reply-To: References: Message-ID: <201006051348.56151.julian@mehnle.net> ?????? wrote: > 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). This is pointless, as you can harvest contributors' email addresses from web-based archives for most of these lists even without being a subscriber: http://lists.debian.org/debian-user/2010/06/msg00000.html -Julian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From geoff at QuiteLikely.com Sat Jun 5 18:52:48 2010 From: geoff at QuiteLikely.com (Geoff Shang) Date: Sat, 5 Jun 2010 19:52:48 +0300 (IDT) Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: On Fri, 4 Jun 2010, Anna Granudd wrote: > there are some mock-ups on the wiki (see > http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you > could help with ideas for a nice design and layout! As a blind person, I'm not able to comment on these as these are images. I can understand the desire for an overhall of the Mailman UI, but I think it's worth saying that for the most part, the 2.x UI works well for people using screen reader technology. The only area which provides some challenges is the membership management screen, as it can be difficult to associate each checkbox with the function it performs. But even this can be managed using screen reader commands for reading tables. I realise that Mailman 3.x will make it possible to create multiple UIs, as the functionality will be separated from the UI. However, it is also my experience that alternate/specialised UIs can and do go unmaintained, and as such it is my hope that the (or at least a) standard UI shipped by default with Mailman will provide the needed accessibility. So this is one of the reasons why I'm on this list, to keep an eye on developments and hopefully provide some feedback when a test server becomes available. Right now, my UI wishlist is as follows: 1. At least one UI with no *necessary* javascript. Maybe this won't be the main UI, but as a person who uses the Linux console with a text-mode browser, I like the fact that I can quickly fire up my browser to deal with a moderator request with no fuss. Given that a package like Squirrelmail can operate completely without Javascript if the user chooses, this should surely be possible. 2. Proper use of the label tag in association with form elements. This was (or seemed to be done) fairly well for the most part, with the exception of those checkboxes I mentioned, but I'd hate to see this lost. What this means in practice is that screen readers will read the appropriate label text when focusing upon a form element. There's probably other important stuff, but this is all that comes to mind right now. Other non-accessibility-related things which I think are worth considering are: 1. More useful archives with search capability. I'm sure this is on a dozen wishlists. 2. A friendlier front page per list. Surely having 3 forms on the front page (or is it 4?) is a bit intimidating to some. I've got some other feature requests based on 2.1.x functionality but I'll post that somewhere else more appropriate. Geoff. From dandrews at visi.com Sat Jun 5 23:48:47 2010 From: dandrews at visi.com (David Andrews) Date: Sat, 05 Jun 2010 16:48:47 -0500 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: At 07:29 AM 6/3/2010, Anna Granudd wrote: >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. I hope that you plan on following WCAG 2.0 standards! There are plenty of moderators and Admins who are blind or have other disabilities and still want to keep using the software! Dave From p at state-of-mind.de Sat Jun 5 23:59:31 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sat, 5 Jun 2010 23:59:31 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: <20100605215931.GA1986@state-of-mind.de> Geoff, I am really happy to find out you, as a blind person, are on this list and that you want to get involved into MM3 development, because creating a user interface that works well for most visually impaired people is one of our/my major goals in the MM3 WUI (web user interface) overhaul. This said: I believe the current interface is too complicated even for those who don't need to meet any perceptional or motional challenges: - It doesn't enforce reasonable grouping of related functions - It exposes an immense number of configuration options to the user but doesn't seem to prioritize how often they are required - It has a high signal noise ratio i.e. it's crowed with text (help messages) which makes it hard to focus on the configuration options themselves. - HTML is not used in a semantic way. You already mentioned there's no association between option names and their fields aka 'labels'. If I remember correctly structure i.e. headings and reasonable use of list are also missing. The list is totally uncomplete, but I guess you get the idea. This and more should go and be replaced by better solutions AND the interface should be modern, nice to look at and provide a set of comfortable JavaScript functions. But JavaScript et al. must not be a basic requirement. We want progressive enhancement and, to answer one of your questions in your message, our goal is to ship a default user interface that provides the needed accessibility. You mentioned "some other feature requests based on 2.1.x functionality". I'd be curious to learn what they are and even more than that I would like to invite you to help us create a user interface that works for as many as possible. p at rick * Geoff Shang : > On Fri, 4 Jun 2010, Anna Granudd wrote: > > >there are some mock-ups on the wiki (see > >http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you > >could help with ideas for a nice design and layout! > > As a blind person, I'm not able to comment on these as these are images. > > I can understand the desire for an overhall of the Mailman UI, but I > think it's worth saying that for the most part, the 2.x UI works > well for people using screen reader technology. The only area which > provides some challenges is the membership management screen, as it > can be difficult to associate each checkbox with the function it > performs. But even this can be managed using screen reader commands > for reading tables. > > I realise that Mailman 3.x will make it possible to create multiple > UIs, as the functionality will be separated from the UI. However, > it is also my experience that alternate/specialised UIs can and do > go unmaintained, and as such it is my hope that the (or at least a) > standard UI shipped by default with Mailman will provide the needed > accessibility. > > So this is one of the reasons why I'm on this list, to keep an eye > on developments and hopefully provide some feedback when a test > server becomes available. > > Right now, my UI wishlist is as follows: > > 1. At least one UI with no *necessary* javascript. Maybe this won't > be the main UI, but as a person who uses the Linux console with a > text-mode browser, I like the fact that I can quickly fire up my > browser to deal with a moderator request with no fuss. Given that a > package like Squirrelmail can operate completely without Javascript > if the user chooses, this should surely be possible. > > 2. Proper use of the label tag in association with form elements. > This was (or seemed to be done) fairly well for the most part, with > the exception of those checkboxes I mentioned, but I'd hate to see > this lost. What this means in practice is that screen readers will > read the appropriate label text when focusing upon a form element. > > There's probably other important stuff, but this is all that comes > to mind right now. > > Other non-accessibility-related things which I think are worth > considering are: > > 1. More useful archives with search capability. I'm sure this is > on a dozen wishlists. > > 2. A friendlier front page per list. Surely having 3 forms on the > front page (or is it 4?) is a bit intimidating to some. > > I've got some other feature requests based on 2.1.x functionality > but I'll post that somewhere else more appropriate. > > Geoff. > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind.de > > Security Policy: http://wiki.list.org/x/QIA9 -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From chris at schoeppi.net Sun Jun 6 15:28:45 2010 From: chris at schoeppi.net (Christian Schoepplein) Date: Sun, 6 Jun 2010 15:28:45 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100605215931.GA1986@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> Message-ID: <20100606132845.GB2521@athlon.schoeppi.net> Hi P at trick, On Sat, Jun 05, 2010 at 11:59:31PM +0200, Patrick Ben Koetter wrote: >Geoff, > >I am really happy to find out you, as a blind person, are on this list and >that you want to get involved into MM3 development, because creating a user >interface that works well for most visually impaired people is one of our/my >major goals in the MM3 WUI (web user interface) overhaul. That sounds very good. I also got in contact with Anna and asked about the accessibility in the new WUI, that should be an important point IMHO and should be not forgotten. Very nice that other people, who are more involved in the development of mailman, are keeping this point in mind too :). As allready said to Anna, just let me / us know, if there is anything to test. I'd be happy to support the development of the new WUI as good as possible regarding the accessibility for blind or visual impared users. Regards from Munic, Schoepp -- Christian Schoepplein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From geoff at QuiteLikely.com Sun Jun 6 21:16:23 2010 From: geoff at QuiteLikely.com (Geoff Shang) Date: Sun, 6 Jun 2010 22:16:23 +0300 (IDT) Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100605215931.GA1986@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> Message-ID: On Sat, 5 Jun 2010, Patrick Ben Koetter wrote: > I am really happy to find out you, as a blind person, are on this list and > that you want to get involved into MM3 development, because creating a user > interface that works well for most visually impaired people is one of our/my > major goals in the MM3 WUI (web user interface) overhaul. Glad to hear it. I've been using Mm successfully in varius capacities for 10 years, so I have some experience of using it. I've only recently taken on site admin tasks with it, which is when I decided to jump on the mailing lists. > This said: I believe the current interface is too complicated even for those > who don't need to meet any perceptional or motional challenges: Oh I can see the issues. I think its served us nurdy types reasonably well for some time, but as you say, it's not very logical in the way it does things. I was mainly wanting to highlight my accessibility concerns, particularly since I couldn't see the mock-ups, but I agree with all your points. > But JavaScript et al. must not be a basic requirement. We want progressive > enhancement and, to > answer one of your questions in your message, our goal is to ship a default > user interface that provides the needed accessibility. I'm glad to hear it, and I'm sure others will be also. > You mentioned "some other feature requests based on 2.1.x functionality". I'd > be curious to learn what they are and even more than that I would like to > invite you to help us create a user interface that works for as many as > possible. Most of my other feature requests are functionality-related, rather than UI as such. Some may already be in the wishlist(s) on the Wiki (or wherever I saw it). I'm happy to post them here in a separate thread if people think it's relevant. They're just things I've jotted down when using Mm that I've thought should be changed/fixed. As for UI development, I'm fairly rusty at Python and I've never actually used Django (though I like the look of it), but I'd be happy to get my hands dirty if it's a matter of tweeking what someone else has started. Geoff. From p at state-of-mind.de Sun Jun 6 21:50:56 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sun, 6 Jun 2010 21:50:56 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: <20100605215931.GA1986@state-of-mind.de> Message-ID: <20100606195056.GC1995@state-of-mind.de> * Geoff Shang : > I was mainly wanting to highlight my accessibility concerns, > particularly since I couldn't see the mock-ups, but I agree with all > your points. Great. I can see and I need to use my imagination to figure what a _real good_ interface for visually imapaired people looks like. Better to have people who really know from first hand experience what to look out for. This said I think the interface should also be better accessible for deaf people. I've learned deaf people experience problems with complex sentences. We should consider that too and other aspects. > >You mentioned "some other feature requests based on 2.1.x functionality". I'd > >be curious to learn what they are and even more than that I would like to > >invite you to help us create a user interface that works for as many as > >possible. > > Most of my other feature requests are functionality-related, rather > than UI as such. Some may already be in the wishlist(s) on the Wiki > (or wherever I saw it). I'm happy to post them here in a separate > thread if people think it's relevant. They're just things I've > jotted down when using Mm that I've thought should be changed/fixed. Please post your feature requests even if we find out they are duplicates. > As for UI development, I'm fairly rusty at Python and I've never > actually used Django (though I like the look of it), but I'd be > happy to get my hands dirty if it's a matter of tweeking what > someone else has started. You are more than welcome to help. As far as I know MM3 development has taken place mostly in sprints at Pycons in 2009 and 2010 (I don't recall everybodys name right now) and after these events almost solely by Barry and Florian. For this summer (of code) Anna has joined the team and I believe if Barry manages to do more work on the REST server and IMAP backend - *HINT* *HINT* - we will soon be able to present an early version of MM3 to test and play with while we bring it to a stable state. p at rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From p at state-of-mind.de Sun Jun 6 22:02:33 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sun, 6 Jun 2010 22:02:33 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606132845.GB2521@athlon.schoeppi.net> References: <20100605215931.GA1986@state-of-mind.de> <20100606132845.GB2521@athlon.schoeppi.net> Message-ID: <20100606200233.GD1995@state-of-mind.de> * Christian Schoepplein : > >I am really happy to find out you, as a blind person, are on this list and > >that you want to get involved into MM3 development, because creating a user > >interface that works well for most visually impaired people is one of our/my > >major goals in the MM3 WUI (web user interface) overhaul. > > That sounds very good. I also got in contact with Anna and asked about > the accessibility in the new WUI, that should be an important point > IMHO and should be not forgotten. Very nice that other people, who are > more involved in the development of mailman, are keeping this point in > mind too :). > > As allready said to Anna, just let me / us know, if there is anything to > test. I'd be happy to support the development of the new WUI as good as > possible regarding the accessibility for blind or visual impared users. Great. I live near Munich. Maybe we can meet and you can give me some first some Sendmail bashing... ;) p at rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: Digital signature URL: From cmpalmer at garp.metalab.unc.edu Sun Jun 6 22:29:14 2010 From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Sun, 6 Jun 2010 16:29:14 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> Message-ID: <20100606202914.GC7286@garp.metalab.unc.edu> On Fri, Jun 04, 2010 at 09:58:12AM -0700, Mark Sapiro wrote: > > As Barry suggests, setting moderation of new members as the default can > also thwart the subscribing spammers. The ability to use reCAPTCHA or other CAPTCHA systems as part of the web signup would also significantly reduce spammy signups, so if we could have MM3 ship with a CAPTCHA system and/or support for a class of CAPTCHA systems in the default web UI, that would be super. Is there a good place in the wiki for me to stick this suggestion, or will somebody who knows where it should go do that? Cheers, -- Crist?bal Palmer ibiblio.org metalab.unc.edu From p at state-of-mind.de Sun Jun 6 22:37:29 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sun, 6 Jun 2010 22:37:29 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606200233.GD1995@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606132845.GB2521@athlon.schoeppi.net> <20100606200233.GD1995@state-of-mind.de> Message-ID: <20100606203729.GE1995@state-of-mind.de> * Patrick Ben Koetter

: > * Christian Schoepplein : > > >I am really happy to find out you, as a blind person, are on this list and > > >that you want to get involved into MM3 development, because creating a user > > >interface that works well for most visually impaired people is one of our/my > > >major goals in the MM3 WUI (web user interface) overhaul. > > > > That sounds very good. I also got in contact with Anna and asked about > > the accessibility in the new WUI, that should be an important point > > IMHO and should be not forgotten. Very nice that other people, who are > > more involved in the development of mailman, are keeping this point in > > mind too :). > > > > As allready said to Anna, just let me / us know, if there is anything to > > test. I'd be happy to support the development of the new WUI as good as > > possible regarding the accessibility for blind or visual impared users. > > Great. I live near Munich. Maybe we can meet and you can give me some first > some Sendmail bashing... ;) That's what you get when you delete the wrong lines... :-D I wanted to say: "Great. I live near Munich. Maybe we can meet and you can give me some first hand experience using MM3 as a blind person." And I was going to say something about the two of us using Postfix and we could do some Sendmail bashing... ;) p at rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: Digital signature URL: From geoff at QuiteLikely.com Sun Jun 6 22:46:20 2010 From: geoff at QuiteLikely.com (Geoff Shang) Date: Sun, 6 Jun 2010 23:46:20 +0300 (IDT) Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606202914.GC7286@garp.metalab.unc.edu> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> Message-ID: On Sun, 6 Jun 2010, Crist?bal Palmer wrote: > The ability to use reCAPTCHA or other CAPTCHA systems as part of the > web signup would also significantly reduce spammy signups, so if we > could have MM3 ship with a CAPTCHA system and/or support for a class > of CAPTCHA systems in the default web UI, that would be super. I would think that having some way of plugging this in would be better than hard-coding it, as new solutions come along all the time. Recaptcha is good as far as traditional captchas go, but while we're voting, I'll vote for Text Captcha (www.textcaptcha.com) for obvious reasons. Though one available in multiple languages would be a good idea of course. And it goes without saying that this only would make a difference for web-based subscription, it wouldn't make any difference for Email subscription requests unless you wanted to plug something like Text Captcha into the confirmation process, which would be rather novel at least. Geoff. From geoff at QuiteLikely.com Sun Jun 6 23:00:36 2010 From: geoff at QuiteLikely.com (Geoff Shang) Date: Mon, 7 Jun 2010 00:00:36 +0300 (IDT) Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606195056.GC1995@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> Message-ID: On Sun, 6 Jun 2010, Patrick Ben Koetter wrote: > Great. I can see and I need to use my imagination to figure what a _real > good_ interface for visually imapaired people looks like. Better to have > people who really know from first hand experience what to look out for. Note that people who use magnification (i.e. who have low vision) are going to have differing requirements from those who use speech or Braille output via screen readers. Ideally the UI would work well for both groups but I'm not qualified to talk about the former, only the latter. > This said I think the interface should also be better accessible for deaf > people. I've learned deaf people experience problems with complex sentences. > We should consider that too and other aspects. Huh? This makes no sense to me. People who only have hearing impairments shouldn't have any more problems with comprehention or reading than people with only vision impairments. By all means make allowances for people with reading/learning/cognitive disabilities, but please don't atribute the need for this to something unrelated. Disclaimer: I am not deaf. A deaf person should be consulted about the requirements that deaf people may have. >> Most of my other feature requests are functionality-related, rather >> than UI as such. Some may already be in the wishlist(s) on the Wiki >> (or wherever I saw it). I'm happy to post them here in a separate >> thread if people think it's relevant. They're just things I've >> jotted down when using Mm that I've thought should be changed/fixed. > > Please post your feature requests even if we find out they are duplicates. Ok, will do. Geoff. From p at state-of-mind.de Sun Jun 6 23:44:07 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Sun, 6 Jun 2010 23:44:07 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> Message-ID: <20100606214406.GB3276@state-of-mind.de> * Geoff Shang : > Note that people who use magnification (i.e. who have low vision) > are going to have differing requirements from those who use speech > or Braille output via screen readers. Ideally the UI would work > well for both groups but I'm not qualified to talk about the former, > only the latter. Yes, thank you. I was aware of that and I have to admit I don't know yet what qualities exactly will be required to create an interface that works equally well for both groups. Unless someone has a better idea I guess we will just have to do 'a best guess', then measure and improve in an iterative manner. > >This said I think the interface should also be better accessible for deaf > >people. I've learned deaf people experience problems with complex > >sentences. We should consider that too and other aspects. > > Huh? This makes no sense to me. People who only have hearing > impairments shouldn't have any more problems with comprehention or It didn't make sense to me either until I listened to a Chaos Computer Club (CCC) Podcast about accessibility with the two guys who started/participated in the Web Standards Project . Too bad the Podcasts are German only. I recommend them to anybody interested in technics, society and culture. Anyway, their story went like this: If you are deaf you learn sign language to communicate with others. Sign language is the first (mother) language for deaf people. Any other (written) language is foreign and that introduces all the problems people usually have with foreign languages. > reading than people with only vision impairments. By all means make > allowances for people with reading/learning/cognitive disabilities, > but please don't atribute the need for this to something unrelated. Do I seem overeager? Don't worry I am not a do-gooder trying to create an interface that attempts to work for _everybody_ on this planet. I simply want to create an interface that accounts for accessibility and that includes deaf people too. If the relation "deaf - reading problems" stands then I'd like to find a way that works for deaf people too. Maybe (!) that's not a problem at all with an application interface as we are going to create, but only with websites that contain lots of text. > Disclaimer: I am not deaf. A deaf person should be consulted about > the requirements that deaf people may have. Yes, good idea. Are there any deaf people on this list who might be able to shed some light on this? p at rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From stephen at xemacs.org Mon Jun 7 05:44:30 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 07 Jun 2010 12:44:30 +0900 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100604110831.735d4a79@heresy> References: <20100603155637.GD4752@amyl.org.uk> <20100603142025.2a38214e@heresy> <20100604110831.735d4a79@heresy> Message-ID: <87typf8q1t.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > We'll probably end up using Launchpad since our branches and bug trackers are > there, but Transifex does look nice. File an RFE on Launchpad! Then go twist some arms at the next Ubuntu summit, or better yet, lull them into submission with slow sexy bass line. Maybe you can get Slowhand as the front man! From stephen at xemacs.org Mon Jun 7 05:47:42 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 07 Jun 2010 12:47:42 +0900 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100605215931.GA1986@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> Message-ID: <87sk4z8pwh.fsf@uwakimon.sk.tsukuba.ac.jp> Patrick Ben Koetter writes: > Geoff, > > I am really happy to find out you, as a blind person, Yeah, a big +1 on that. Good to hear that we can get first person feedback. Interesting to hear that Mailman 2 has a reasonably usable interface, as AFAIK that wasn't a design consideration. From chris at schoeppi.net Mon Jun 7 09:11:10 2010 From: chris at schoeppi.net (Christian Schoepplein) Date: Mon, 7 Jun 2010 09:11:10 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606214406.GB3276@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> <20100606214406.GB3276@state-of-mind.de> Message-ID: <20100607071109.GA6041@mx.cs-x.de> On Sun, Jun 06, 2010 at 11:44:07PM +0200, Patrick Ben Koetter wrote: >* Geoff Shang : >> Note that people who use magnification (i.e. who have low vision) >> are going to have differing requirements from those who use speech >> or Braille output via screen readers. Ideally the UI would work >> well for both groups but I'm not qualified to talk about the former, >> only the latter. > >Yes, thank you. I was aware of that and I have to admit I don't know yet what >qualities exactly will be required to create an interface that works equally >well for both groups. Unless someone has a better idea I guess we will just >have to do 'a best guess', then measure and improve in an iterative manner. I know some people that use magnification. I can ask them to test also the new MM WUI or ask them for their needs regarding a new user interface. >> Disclaimer: I am not deaf. A deaf person should be consulted about >> the requirements that deaf people may have. > >Yes, good idea. Are there any deaf people on this list who might be able to >shed some light on this? I also can help out on this point maybe, because I also have friends that are deaf or work for a big German organization for deaf people. @P at trick: Maybe I can also arrange a meeting with these people, they also live in Munich. Regards, Schoepp -- Christian Schoepplein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From p at state-of-mind.de Mon Jun 7 09:16:58 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 7 Jun 2010 09:16:58 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100607071109.GA6041@mx.cs-x.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> <20100606214406.GB3276@state-of-mind.de> <20100607071109.GA6041@mx.cs-x.de> Message-ID: <20100607071658.GB22167@state-of-mind.de> * Christian Schoepplein : > >* Geoff Shang : > >> Note that people who use magnification (i.e. who have low vision) > >> are going to have differing requirements from those who use speech > >> or Braille output via screen readers. Ideally the UI would work > >> well for both groups but I'm not qualified to talk about the former, > >> only the latter. > > > >Yes, thank you. I was aware of that and I have to admit I don't know yet what > >qualities exactly will be required to create an interface that works equally > >well for both groups. Unless someone has a better idea I guess we will just > >have to do 'a best guess', then measure and improve in an iterative manner. > > I know some people that use magnification. I can ask them to test also the > new MM WUI or ask them for their needs regarding a new user interface. Great. > >> Disclaimer: I am not deaf. A deaf person should be consulted about > >> the requirements that deaf people may have. > > > >Yes, good idea. Are there any deaf people on this list who might be able to > >shed some light on this? > > I also can help out on this point maybe, because I also have friends > that are deaf or work for a big German organization for deaf people. Even better. > @P at trick: Maybe I can also arrange a meeting with these people, they also > live in Munich. 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? p at rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From chris at schoeppi.net Mon Jun 7 11:45:31 2010 From: chris at schoeppi.net (Christian Schoepplein) Date: Mon, 7 Jun 2010 11:45:31 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100607071658.GB22167@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> <20100606214406.GB3276@state-of-mind.de> <20100607071109.GA6041@mx.cs-x.de> <20100607071658.GB22167@state-of-mind.de> Message-ID: <20100607094531.GA6011@mx.cs-x.de> On Mon, Jun 07, 2010 at 09:16:58AM +0200, Patrick Ben Koetter wrote: >* Christian Schoepplein : >> >* Geoff Shang : >> >> Note that people who use magnification (i.e. who have low vision) >> >> are going to have differing requirements from those who use speech >> >> or Braille output via screen readers. Ideally the UI would work >> >> well for both groups but I'm not qualified to talk about the former, >> >> only the latter. >> > >> >Yes, thank you. I was aware of that and I have to admit I don't know yet what >> >qualities exactly will be required to create an interface that works equally >> >well for both groups. Unless someone has a better idea I guess we will just >> >have to do 'a best guess', then measure and improve in an iterative manner. >> >> I know some people that use magnification. I can ask them to test also the >> new MM WUI or ask them for their needs regarding a new user interface. > >Great. > >> >> Disclaimer: I am not deaf. A deaf person should be consulted about >> >> the requirements that deaf people may have. >> > >> >Yes, good idea. Are there any deaf people on this list who might be able to >> >shed some light on this? >> >> I also can help out on this point maybe, because I also have friends >> that are deaf or work for a big German organization for deaf people. > >Even better. > >> @P at trick: Maybe I can also arrange a meeting with these people, they also >> live in Munich. > >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. Regards, Schoepp -- Christian Schoepplein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From anna.granudd at gmail.com Mon Jun 7 12:32:49 2010 From: anna.granudd at gmail.com (Anna Granudd) Date: Mon, 7 Jun 2010 12:32:49 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update Message-ID: On Mon, Jun 7, 2010 at 12:00 PM, 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 From barry at list.org Mon Jun 7 20:28:22 2010 From: barry at list.org (Barry Warsaw) Date: Mon, 7 Jun 2010 14:28:22 -0400 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: <20100607142822.2bddb0e6@heresy> On Jun 05, 2010, at 04:21 PM, ?????? wrote: >On Fri, Jun 4, 2010 at 22:43, Mark Sapiro 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. At the very least, we want to make it has hard as possible for spammers to spam people *through* a mailing list. >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. We can try to make it more difficult to harvest email address from mailing list archives and posts, but some of that is fairly difficult without disrupting the usability of the mailing list. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Mon Jun 7 20:41:06 2010 From: barry at list.org (Barry Warsaw) Date: Mon, 7 Jun 2010 14:41:06 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606202914.GC7286@garp.metalab.unc.edu> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> Message-ID: <20100607144106.64c47649@heresy> On Jun 06, 2010, at 04:29 PM, Crist?bal Palmer wrote: >On Fri, Jun 04, 2010 at 09:58:12AM -0700, Mark Sapiro wrote: >> >> As Barry suggests, setting moderation of new members as the default can >> also thwart the subscribing spammers. > >The ability to use reCAPTCHA or other CAPTCHA systems as part of the >web signup would also significantly reduce spammy signups, so if we >could have MM3 ship with a CAPTCHA system and/or support for a class >of CAPTCHA systems in the default web UI, that would be super. I personally hate captcha systems because I think they all have horrible usability issues. But I understand the appeal so I think I would vote against enabling such things by default, but would support allowing it to be added fairly easily. >Is there a good place in the wiki for me to stick this suggestion, or >will somebody who knows where it should go do that? Probably start here: http://wiki.list.org/display/DEV/Web+Interface but I think with the ramp up of work on the wui, these pages could use some gardening and reorganization. Any volunteers? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Mon Jun 7 20:46:34 2010 From: barry at list.org (Barry Warsaw) Date: Mon, 7 Jun 2010 14:46:34 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: Message-ID: <20100607144634.747c9984@heresy> On Jun 05, 2010, at 07:52 PM, Geoff Shang wrote: >I realise that Mailman 3.x will make it possible to create multiple UIs, >as the functionality will be separated from the UI. However, it is also >my experience that alternate/specialised UIs can and do go unmaintained, >and as such it is my hope that the (or at least a) standard UI shipped by >default with Mailman will provide the needed accessibility. > >So this is one of the reasons why I'm on this list, to keep an eye on >developments and hopefully provide some feedback when a test server >becomes available. That's great Geoff, we appreciate all your help in understanding the issues and driving toward a ui that's at least as usable as the MM 2.1 interface is. I have a general question though: given that Mailman 3 will be scriptable, is that a better long term solution than screen scraping? We still need to work out the security model for public access (i.e. OAuth, a proxy to the internal admin interface, etc), but I think it'll be very cool to write the scripts you want and actually interact with Mailman without using a wui. >1. At least one UI with no *necessary* javascript. Maybe this won't be >the main UI, but as a person who uses the Linux console with a text-mode >browser, I like the fact that I can quickly fire up my browser to deal >with a moderator request with no fuss. Given that a package like >Squirrelmail can operate completely without Javascript if the user >chooses, this should surely be possible. +1. We want links/lynx users to be able to use the site. >2. Proper use of the label tag in association with form elements. This >was (or seemed to be done) fairly well for the most part, with the >exception of those checkboxes I mentioned, but I'd hate to see this lost. >What this means in practice is that screen readers will read the >appropriate label text when focusing upon a form element. > >There's probably other important stuff, but this is all that comes to mind >right now. > >Other non-accessibility-related things which I think are worth considering >are: > >1. More useful archives with search capability. I'm sure this is on a >dozen wishlists. Indeed. :) You know that song by the Bare Naked Ladies? Well, if *I* had a million dollars, I'd write a killer new open source mail archiver. :) >2. A friendlier front page per list. Surely having 3 forms on the front >page (or is it 4?) is a bit intimidating to some. Definitely. >I've got some other feature requests based on 2.1.x functionality but I'll >post that somewhere else more appropriate. Looking forward to it! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Mon Jun 7 20:48:42 2010 From: barry at list.org (Barry Warsaw) Date: Mon, 7 Jun 2010 14:48:42 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606195056.GC1995@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> Message-ID: <20100607144842.51610758@heresy> On Jun 06, 2010, at 09:50 PM, Patrick Ben Koetter wrote: >For this summer (of code) Anna has joined the team and I believe if Barry >manages to do more work on the REST server and IMAP backend - *HINT* *HINT* - >we will soon be able to present an early version of MM3 to test and play with >while we bring it to a stable state. Hint taken. :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From anna.granudd at gmail.com Mon Jun 7 20:50:52 2010 From: anna.granudd at gmail.com (Anna Granudd) Date: Mon, 7 Jun 2010 20:50:52 +0200 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100607144106.64c47649@heresy> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100607144106.64c47649@heresy> Message-ID: I could look into reorganizing the pages since I'll be working with the UI anyways but I'm not sure how to "gard" them (might be that I don't have the rights to do so though)? Anyone else willing to help out is of course welcome to do so. Anna On Mon, Jun 7, 2010 at 8:41 PM, Barry Warsaw wrote: > ... > Probably start here: > > http://wiki.list.org/display/DEV/Web+Interface > > but I think with the ramp up of work on the wui, these pages could use some > gardening and reorganization. Any volunteers? > > -Barry > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/anna.granudd%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > From barry at list.org Mon Jun 7 20:51:51 2010 From: barry at list.org (Barry Warsaw) Date: Mon, 7 Jun 2010 14:51:51 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100607071658.GB22167@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> <20100606214406.GB3276@state-of-mind.de> <20100607071109.GA6041@mx.cs-x.de> <20100607071658.GB22167@state-of-mind.de> Message-ID: <20100607145151.76274404@heresy> On Jun 07, 2010, at 09:16 AM, Patrick Ben Koetter 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? Although I wouldn't be able to make that in person, please do use the bug tracker to request any new features of the REST interface. You can always tag them with 'mailman3' to get my attention. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adam-mailman at amyl.org.uk Tue Jun 8 14:55:13 2010 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Tue, 8 Jun 2010 13:55:13 +0100 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: <20100607142822.2bddb0e6@heresy> References: <20100607142822.2bddb0e6@heresy> Message-ID: <20100608125513.GU4752@amyl.org.uk> On Mon, Jun 07, 2010 at 02:28:22PM -0400, Barry Warsaw wrote: > At the very least, we want to make it has hard as possible for spammers to > spam people *through* a mailing list. With that in mind, I've been reminded about posting a mail I've been meaning to write ;) It's quite common, in my set-ups, at least, for me to allow a ^[^@]+@(.*\.)?example\.org$ wildcard for allowing posting by non-members -- from "our" domain(s). Recently, I changed the regexp over to ^[^@]+ at example\.org$ as I've noticed the horrible trend for spammers to post from various addresses purporting to be from the lists.example.org subdomain. The current "problem", is the order in which MM2 handles its non-members filters; and I guess what I'd welcome is an ability to finely control the order in which given rules are processed; I think that would help immensely. So, perhaps, something like: -->>- ex 1 ->>-- Posting Settings for List X on lists.example.org: .-----------------------------+---------+--------+----------+-------------+---------. | email-address | allow | hold | reject | blackhole | order | +-----------------------------+---------+--------+----------+-------------+---------+ | list-x at list.example.org | | | | X | 1 | | foo at list.example.org | | | | X | 2 | | ^[^@]+@(.*\.)?example\.org$ | X | | | | last | '-----------------------------+---------+--------+----------+-------------+---------' --<<- ex 1 -<<-- where the order setting ('n', 'first', 'last') has effect on how the rules are processed. (so in this example, the 'global' wildcard for the entire DNS-space example.org is processed as the last rule -- after all others have run -- i.e., postings from end up being blackholed, but those posts from get through to the list.) I suppose the modern way of setting processing order (at least for the person using the web-interface) is not to define "numbers" in the interface, but to allow the user/admin/moderator to move things up and down with arrows (so replace '2' with '?' and '?', and something "appropriate" for 'top' and 'bottom' of the list), and perhaps enabling mouse click-and-drag? Was that in the pipeline? -- ``Another sport which wastes unlimited time is Comma-hunting.'' (Francis Cornford, Microcosmographia Academica) From terri at zone12.com Tue Jun 8 18:27:54 2010 From: terri at zone12.com (Terri Oda) Date: Tue, 08 Jun 2010 12:27:54 -0400 Subject: [Mailman-Developers] Archives work (was Re: UI for Mailman 3.0 update) In-Reply-To: References: Message-ID: <4C0E6F8A.9010401@zone12.com> Geoff Shang wrote: > 1. More useful archives with search capability. I'm sure this is on a > dozen wishlists. Oh! If you're not on mailman-users (or just missed the posts) you may not be aware, but we've got 3 GSoC students (again from Systers) working on archives this summer, including search. If you'd like to help them develop better use-cases before the coding starts in earnest, there's still time to fill out the survey we're using to gather data on how people actually use their Mailman archives right now: http://spreadsheets.google.com/viewform?formkey=dF9XcGRsYUpsOUtxYjBWRUdnVXN4X1E6MQ Terri From geoff at QuiteLikely.com Tue Jun 8 19:07:38 2010 From: geoff at QuiteLikely.com (Geoff Shang) Date: Tue, 8 Jun 2010 20:07:38 +0300 (IDT) Subject: [Mailman-Developers] Archives work (was Re: UI for Mailman 3.0 update) In-Reply-To: <4C0E6F8A.9010401@zone12.com> References: <4C0E6F8A.9010401@zone12.com> Message-ID: On Tue, 8 Jun 2010, Terri Oda wrote: > Oh! If you're not on mailman-users (or just missed the posts) you may not be > aware, but we've got 3 GSoC students (again from Systers) working on archives > this summer, including search. Odd. I *am* on Mailman-users and haven't seen this. > If you'd like to help them develop better use-cases before the coding starts > in earnest, there's still time to fill out the survey we're using to gather > data on how people actually use their Mailman archives right now: > > http://spreadsheets.google.com/viewform?formkey=dF9XcGRsYUpsOUtxYjBWRUdnVXN4X1E6MQ I expect there are others who have thought this out more than I, but I'll fill out the survey gladly. Geoff. From dandrews at visi.com Tue Jun 8 19:07:15 2010 From: dandrews at visi.com (David Andrews) Date: Tue, 08 Jun 2010 12:07:15 -0500 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606195056.GC1995@state-of-mind.de> References: <20100605215931.GA1986@state-of-mind.de> <20100606195056.GC1995@state-of-mind.de> Message-ID: At 02:50 PM 6/6/2010, Patrick Ben Koetter wrote: >Great. I can see and I need to use my imagination to figure what a _real >good_ interface for visually imapaired people looks like. Better to have >people who really know from first hand experience what to look out for. > >This said I think the interface should also be better accessible for deaf >people. I've learned deaf people experience problems with complex sentences. >We should consider that too and other aspects. Well, you probably wouldn't like the look or feel of an interface I would design for myself as a blind person. No danger of having to suffer through it anyway, as I am not a developer. I think I started this thread a couple days ago, and my point was, and is, that if WCAG 2.0 guidelines are followed, the UI can look however you guys want, but still meet the needs of blind and other disabled users -- including the deaf. I am not a developer -- but run a bunch of lists and have a little experience at web site accessibility testing and would be pleased to help out in that area in any way I can. Dave David Andrews: dandrews at visi.com Follow me on Twitter: http://www.twitter.com/dandrews920 From vid at svaksha.com Tue Jun 8 19:30:33 2010 From: vid at svaksha.com (=?UTF-8?B?IOCkuOCljeCkteCkleCljeCktyA=?=) Date: Tue, 8 Jun 2010 23:15:33 +0545 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: <20100607142822.2bddb0e6@heresy> References: <20100607142822.2bddb0e6@heresy> Message-ID: On Tue, Jun 8, 2010 at 00:13, Barry Warsaw wrote: > > We can try to make it more difficult to harvest email address from mailing > list archives and posts, but some of that is fairly difficult without > disrupting the usability of the mailing list. I had two suggestions or should I say, feature requests(?) : 0. Obfuscate the *-owner address on the listinfo page :: Allow the admin to edit the MM-footer in such a way that a spammer cannot use bots to click and spam the *-owner address. ATM, this customization is possible only if you have access to the MM installation--most admins dont. Currently, MM allows me to edit the "General list information page" and remove the MM-footer but in a Floss project, folks need to know who the list admins inorder to get in touch with them (I can put the list admin names on the listinfo page but how many people will read it?) and then, there is the possibility of assuming "cabal". 1. Obfuscate/trim Email-id's in the archives:: Currently an email-id is archived as "YourName at gmail.com" by MM. It would be nicer if it was obfuscated to ""Your..... at gmail.com" like google groups does: http://groups.google.com/groups/profile?hl=en&enc_user=Fvdg4xEAAAD4rsRkC93N5ixKcUO4kQ32kdEasx1kiYTQavV7mdW13Q and , http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/0351b1bce764cfc6?hl=en Thanks, -- thanks and regards, vid || http://svaksha.com From mark at msapiro.net Tue Jun 8 20:10:32 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 08 Jun 2010 11:10:32 -0700 Subject: [Mailman-Developers] Archives work (was Re: UI for Mailman 3.0 update) In-Reply-To: References: <4C0E6F8A.9010401@zone12.com> Message-ID: <4C0E8798.80500@msapiro.net> On 6/8/2010 10:07 AM, Geoff Shang wrote: > On Tue, 8 Jun 2010, Terri Oda wrote: > >> Oh! If you're not on mailman-users (or just missed the posts) you >> may not be aware, but we've got 3 GSoC students (again from >> Systers) working on archives this summer, including search. > > Odd. I *am* on Mailman-users and haven't seen this. there are others who haven't also as I expect it to be a hot topic> The post is at . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Tue Jun 8 22:12:25 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 08 Jun 2010 13:12:25 -0700 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: References: <20100607142822.2bddb0e6@heresy> Message-ID: <4C0EA429.5020908@msapiro.net> On 6/8/2010 10:30 AM, ?????? wrote: > Currently, MM allows me to edit the > "General list information page" and remove the MM-footer but in a > Floss project, folks need to know who the list admins inorder to get > in touch with them (I can put the list admin names on the listinfo > page but how many people will read it?) and then, there is the > possibility of assuming "cabal". Or you can create your own replacement footer and add its HTML to the page. Granted, this is a maintenance problem if you actually want to use the 'owner' addresses and they change, but you could just direct the mailto: to the -owner address. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From rsk at gsp.org Wed Jun 9 04:22:03 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 8 Jun 2010 22:22:03 -0400 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: <20100607142822.2bddb0e6@heresy> References: <20100607142822.2bddb0e6@heresy> Message-ID: <20100609022203.GB3963@gsp.org> On Mon, Jun 07, 2010 at 02:28:22PM -0400, Barry Warsaw wrote: > We can try to make it more difficult to harvest email address from mailing > list archives and posts, but some of that is fairly difficult without > disrupting the usability of the mailing list. Agreed, and as I pointed out last year, it's useless. Spammers have such an embarrassment of riches when it comes to harvesting addresses that they really don't need to bother with mailing list mechanisms. And since I wrote that lengthy explanation, they've come up with a few more, including one that's really quite clever since it uses social engineering to convince users to give up not just addresses, but information on the relationships between them. So there is not only zero value in trying to obfuscate addresses, there is *negative* value since the only people who will actually be impaired in the least by this are those actually trying to communicate, e.g., those coming across a message in an archive and trying to write to the author. Spammers are already so far past this that it's disappeared from their rear view mirrors. ---Rsk From rsk at gsp.org Wed Jun 9 04:12:18 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 8 Jun 2010 22:12:18 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100606202914.GC7286@garp.metalab.unc.edu> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> Message-ID: <20100609021217.GA3963@gsp.org> On Sun, Jun 06, 2010 at 04:29:14PM -0400, Crist?bal Palmer wrote: > The ability to use reCAPTCHA or other CAPTCHA systems as part of the > web signup would also significantly reduce spammy signups, so if we > could have MM3 ship with a CAPTCHA system and/or support for a class > of CAPTCHA systems in the default web UI, that would be super. No, it won't. Spammers have quite thoroughly defeated these, years ago, via an assortment of techniques. Yes, some deployments don't see this: they're not considered important enough to attack. But as Yahoo most recently found (and they're only the most recent entry in a long parade) when spammers or other abusers decide it's time, they can rapidly solve them by the tens of thousands. Moreover, there's really no need for spammers to trouble themselves with this approach. If the goal is address-harvesting, then there are far more efficient ways that yield much better results. If the goal is to spam the list, then it's much easier to hijack an already-subscribed account -- particularly if it's located at one of the many freemail providers whose security is weak, but alternatively by via the subscriber's own system. There does not exist a truly effective defense against these attack vectors for lists of substantial size. (Very small lists can be defended by limiting membership, mail account location and operating system but these are clearly special cases and these tactics don't scale.) This isn't surprising, nor is it Mailman's fault: when the adversary owns so much infrastructure, it's just not going to be possible to craft defenses that work other than temporarily and accidentally. One mitigation step -- and it's not a terribly good one, but at least it's one with minimal impact -- is to employ the policy that list subscribers posting from freemail providers are always moderated. Of course this only intercepts one vector and of course it requires manual intervention -- which is why I *said* it's not terribly good. But experiments I've run indicate that at least for the moment, it deals with the most likely attack vector, and it has the virtue of using an existing mechanism. But, captchas? Pre-defeated. ---Rsk From barry at list.org Wed Jun 9 21:45:14 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 9 Jun 2010 15:45:14 -0400 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: <20100608125513.GU4752@amyl.org.uk> References: <20100607142822.2bddb0e6@heresy> <20100608125513.GU4752@amyl.org.uk> Message-ID: <20100609154514.480bf73d@heresy> On Jun 08, 2010, at 01:55 PM, Adam McGreggor wrote: >The current "problem", is the order in which MM2 handles its >non-members filters; and I guess what I'd welcome is an ability to >finely control the order in which given rules are processed; I think >that would help immensely. Here's how Mailman 3 works. First, where MM2 had 'handlers' which conflated rule checking with message processing, MM3 separates these. This means that the processing handlers are called during a separate phase of message delivery, and not until the message has been approved for delivery. Rule checking itself happens by way of configurable 'chains'. There are a number of built-in chains, but you can always add new ones and you can configure mailing lists, or the entire MM3 system to use your custom defined chains. Each chain consists of a series of 'links' where each link is essentially a triplet of (rule, action, argument). Rules are just the name of the rule, so custom rules must have unique names, but they can be more or less arbitrary strings (similarly with chain names). Rules are looked up globally by name. Link actions are one of the following: * jump - stop processing this chain and start processing from the beginning of the named chain; takes a chain name as argument * stop - stop processing through this chain * defer - make no decision (i.e. continue processing through the current chain) * run - the argument will be a callable, so call it with the standard argument triple of (mailing list, message, message metadata dictionary) * detour - this is like 'jump' except that processing returns to the next link in the original chain when the detour chain is finished; takes a chain name as argument (chain processing loop is in mailman/core/chains.py) From here on I'll talk about what happens by default... The incoming queue runner is now very simple. It asks the mailing list for its 'start chain' and then processes the message through that chain. By default, this is the 'built-in' chain. (built-in chain is defined in mailman/chains/builtin.py) The built-in chain starts by running a few immediate actions: * is the message pre-approved? if so, jump to the 'accept' chain * is the mailing list in emergency hold? if so, jump to the 'hold' chain * are we in a mailing list loop? if so, jump to the 'discard' chain After this, some of the general checking rules get processed, but they all defer action. These are rules like the administrivia check, no-subject check, member moderation rule, and so on. Each of these rules marks the message metadata with a 'hit' or 'miss' tag. After these run, the 'any' rule runs and it just looks to see if there were any rule hits. If so, we jump to the 'hold' chain. If a message makes it through this gauntlet, it then detours through a dynamically created 'header-match' chain. This chain is created the configuration file, so it works globally. This means you can define your global header matches and decide which will be accepted, held, rejected, or discarded, say to handle known spammers. While not currently implemented, a similar technique will be used to do per-list web-configured header matching. It should be fairly straight-forward to implement your request using the above raw materials, and we should definitely do that. Just to finish the story, the final action in the built-in chain is to accept the message unconditionally. I.e. it's made it through all the known checks, so it should be good to go. As you've seen above, there are other default chains, such as discard, reject, hold, and accept. Most of these are fairly simple, e.g. the discard chain just logs the Message-ID, fires an event, and then does nothing, which basically throws the message away. The accept chain sets up a couple of headers, logs the Message-ID, fires an event, and drops the message in the 'accept' queue - which is where the processing queue runner does all the other message preparation tasks you're familiar with from MM2. The hold chain is of course the most complex one; for more details UTSL. I've probably given you way too much detail, and this should definitely go into a system architecture document, but hopefully it gives you an idea of the power and flexibility of MM3. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Wed Jun 9 21:47:14 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 9 Jun 2010 15:47:14 -0400 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: <20100609022203.GB3963@gsp.org> References: <20100607142822.2bddb0e6@heresy> <20100609022203.GB3963@gsp.org> Message-ID: <20100609154714.7847ccee@heresy> On Jun 08, 2010, at 10:22 PM, Rich Kulawiec wrote: >On Mon, Jun 07, 2010 at 02:28:22PM -0400, Barry Warsaw wrote: >> We can try to make it more difficult to harvest email address from mailing >> list archives and posts, but some of that is fairly difficult without >> disrupting the usability of the mailing list. > >Agreed, and as I pointed out last year, it's useless. Spammers have such >an embarrassment of riches when it comes to harvesting addresses that they >really don't need to bother with mailing list mechanisms. And since >I wrote that lengthy explanation, they've come up with a few more, >including one that's really quite clever since it uses social engineering >to convince users to give up not just addresses, but information on >the relationships between them. > >So there is not only zero value in trying to obfuscate addresses, there is >*negative* value since the only people who will actually be impaired in >the least by this are those actually trying to communicate, e.g., those >coming across a message in an archive and trying to write to the author. >Spammers are already so far past this that it's disappeared from their >rear view mirrors. Agreed. The least we can do is make mailing lists and their archives so much more valuable that it's worth the cost of doing business. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Wed Jun 9 21:50:50 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 9 Jun 2010 15:50:50 -0400 Subject: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update In-Reply-To: References: <20100607142822.2bddb0e6@heresy> Message-ID: <20100609155050.662409a5@heresy> On Jun 08, 2010, at 11:15 PM, ?????? wrote: >0. Obfuscate the *-owner address on the listinfo page I think we should do something about this in MM3. Instead of displaying the individual owner addresses, we should advertise the -owner address and send the message through the normal Mailman processing. That way, if anti-spam defenses were implemented in the toolchain (either in the MTA or as an add-on to Mailman), you'd at least have a hope of catching them. >1. Obfuscate/trim Email-id's in the archives:: Currently an email-id >is archived as "YourName at gmail.com" by MM. It would be nicer if it >was obfuscated to ""Your..... at gmail.com" like google groups does: >http://groups.google.com/groups/profile?hl=en&enc_user=Fvdg4xEAAAD4rsRkC93N5ixKcUO4kQ32kdEasx1kiYTQavV7mdW13Q >and , >http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/0351b1bce764cfc6?hl=en Interesting that you can get the full email address after a captcha dance. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From fil at rezo.net Sun Jun 13 21:42:51 2010 From: fil at rezo.net (Fil) Date: Sun, 13 Jun 2010 21:42:51 +0200 Subject: [Mailman-Developers] REST API docs? Message-ID: 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 From cmpalmer at garp.metalab.unc.edu Sun Jun 13 23:16:56 2010 From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Sun, 13 Jun 2010 17:16:56 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100609021217.GA3963@gsp.org> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> Message-ID: <20100613211656.GH11196@garp.metalab.unc.edu> On Tue, Jun 08, 2010 at 10:12:18PM -0400, Rich Kulawiec wrote: > > could have MM3 ship with a CAPTCHA system and/or support for a class > > of CAPTCHA systems in the default web UI, that would be super. I'd like to re-emphasize the fact that what I would like is some sort of plugin support. Want this kind of CAPTCHA? Take these simple steps.... > But, captchas? Pre-defeated. With all due respect to your experience, I don't think CAPTCHAs as a class have been defeated, in the sense that the goal is not to completely defeat all spam, but rather the goal is to mitigate at relatively low cost to ourselves and at high cost to the spammers, and from personal experience I can say that reCAPTCHA has served that purpose well when I have deployed it. If there's some other non-CAPTCHA approach (or set of approaches) that we could use to help reduce spammy signups, then I'm all for it. I guess my hope is that we'd have something in place that reduces the signups themselves rather than imposing work or workflow changes on moderators or list members after they've joined. If that's necessary, fine, but let's try things that happen at the signup step, too, yes? Even something as simple as requiring a hidden form field NONCE and conservative rate limits on public signups, neither of which require javascript or images.... Cheers, -- Crist?bal Palmer ibiblio.org metalab.unc.edu From Eric.Bloch at marklogic.com Mon Jun 14 04:15:16 2010 From: Eric.Bloch at marklogic.com (Eric Bloch) Date: Sun, 13 Jun 2010 19:15:16 -0700 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100613211656.GH11196@garp.metalab.unc.edu> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org>, <20100613211656.GH11196@garp.metalab.unc.edu> Message-ID: I am a lurker here and can concur with Crist?bal's sentiments wrt captchas . I run http://markmail.org where we provide a search index for thousands of public mailman lists (and google groups and other mailing lists as well). The captchas we use (for a variety of purposes) aren't perfect, but they get rid of a lot of junk. -Eric ________________________________________ > But, captchas? Pre-defeated. With all due respect to your experience, I don't think CAPTCHAs as a class have been defeated, in the sense that the goal is not to completely defeat all spam, but rather the goal is to mitigate at relatively low cost to ourselves and at high cost to the spammers, and from personal experience I can say that reCAPTCHA has served that purpose well when I have deployed it. From f at state-of-mind.de Mon Jun 14 19:21:04 2010 From: f at state-of-mind.de (Florian Fuchs) Date: Mon, 14 Jun 2010 19:21:04 +0200 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server Message-ID: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> 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 From barry at list.org Mon Jun 14 19:51:13 2010 From: barry at list.org (Barry Warsaw) Date: Mon, 14 Jun 2010 13:51:13 -0400 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server In-Reply-To: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> References: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> Message-ID: <20100614135113.5e74214b@heresy> On Jun 14, 2010, at 07:21 PM, Florian Fuchs wrote: >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 Yay! Thanks Florian and Patrick. Can we get access to the IMAP folder? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From p at state-of-mind.de Mon Jun 14 21:14:24 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Mon, 14 Jun 2010 21:14:24 +0200 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server In-Reply-To: <20100614135113.5e74214b@heresy> References: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> <20100614135113.5e74214b@heresy> Message-ID: <20100614191424.GB2033@state-of-mind.de> * Barry Warsaw : > On Jun 14, 2010, at 07:21 PM, Florian Fuchs wrote: > > >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 > > Yay! Thanks Florian and Patrick. > > Can we get access to the IMAP folder? host: mailman.state-of-mind.de user: mailman at mailman.state-of-mind.de pass: hemispheres And, please (!), don't use it to trade files... p at rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: Digital signature URL: From barry at list.org Mon Jun 14 21:51:46 2010 From: barry at list.org (Barry Warsaw) Date: Mon, 14 Jun 2010 15:51:46 -0400 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server In-Reply-To: <20100614191424.GB2033@state-of-mind.de> References: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> <20100614135113.5e74214b@heresy> <20100614191424.GB2033@state-of-mind.de> Message-ID: <20100614155146.2b83b462@heresy> On Jun 14, 2010, at 09:14 PM, Patrick Ben Koetter wrote: >> Can we get access to the IMAP folder? > >host: mailman.state-of-mind.de >user: mailman at mailman.state-of-mind.de >pass: hemispheres > >And, please (!), don't use it to trade files... Nice! I'm in. -B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Tue Jun 15 04:11:33 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 15 Jun 2010 11:11:33 +0900 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> Message-ID: <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> Eric Bloch writes: > I am a lurker here and can concur with Crist?bal's sentiments wrt > captchas . I run http://markmail.org where we provide a search > index for thousands of public mailman lists (and google groups and > other mailing lists as well). The captchas we use (for a variety > of purposes) aren't perfect, but they get rid of a lot of junk. How do you know? "Post hoc ergo propter hoc" is a fallacy. In my (limited and often second-hand) experience, *any* change to a form reduces "junk" dramatically. Simply using obfuscated names for signup fields (such as swapping the email address variable name and the full name variable name) often reduces signups (presumably the difference is 'bots) significantly. I've heard one report that switching from a homebrew CMS to Drupal (IIRC) was followed by a dramatic increase in signups ... most of the increase being bogus. Nothing against Drupal, just that it apparently provides standard forms for certain purposes, and 'bots take advantage. Any standard and common system (eg, Mailman) which recruits members would face the same problem. Do cosmetic changes work as well as captcha? I don't know. I do know that about 2 years ago I downloaded one of the gocr-based captcha breakers and watched it get 5% to 40% success rates against a star-studded cast (don't recall exactly, but the likes of Google and Yahoo were in there). 95% "correct" answers may sound good to a college student taking a final exam, but what that means in the case of captchas is bogus signups at a maximum rate of about 3/min. Oops. My conclusion (lacking other data) is that the cost of annoying my users is far greater than the potential benefit. I don't intend to even try to collect real data on captcha efficacy. ;-) From Eric.Bloch at marklogic.com Tue Jun 15 04:56:17 2010 From: Eric.Bloch at marklogic.com (Eric Bloch) Date: Mon, 14 Jun 2010 19:56:17 -0700 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> , <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: My experience is not limited nor second hand. We get scanned by plenty of bots every day. We also see captchas broken every day by some bots. Not all bots break the captchas. Not all are trying to, either of course. But without the captchas, the ones that weren't even trying would be getting to things we don't want them to get at. It's that simple. Not a solution, just a screen door in the way - one that I don't mind asking my users to open up by hand as they come in. -Eric ________________________________________ From: Stephen J. Turnbull [stephen at xemacs.org] Sent: Monday, June 14, 2010 7:11 PM To: Eric Bloch Cc: Crist?bal Palmer; mailman-developers at python.org Subject: Re: [Mailman-Developers] UI for Mailman 3.0 update Eric Bloch writes: > I am a lurker here and can concur with Crist?bal's sentiments wrt > captchas . I run http://markmail.org where we provide a search > index for thousands of public mailman lists (and google groups and > other mailing lists as well). The captchas we use (for a variety > of purposes) aren't perfect, but they get rid of a lot of junk. How do you know? "Post hoc ergo propter hoc" is a fallacy. In my (limited and often second-hand) experience, *any* change to a form reduces "junk" dramatically. Simply using obfuscated names for signup fields (such as swapping the email address variable name and the full name variable name) often reduces signups (presumably the difference is 'bots) significantly. I've heard one report that switching from a homebrew CMS to Drupal (IIRC) was followed by a dramatic increase in signups ... most of the increase being bogus. Nothing against Drupal, just that it apparently provides standard forms for certain purposes, and 'bots take advantage. Any standard and common system (eg, Mailman) which recruits members would face the same problem. Do cosmetic changes work as well as captcha? I don't know. I do know that about 2 years ago I downloaded one of the gocr-based captcha breakers and watched it get 5% to 40% success rates against a star-studded cast (don't recall exactly, but the likes of Google and Yahoo were in there). 95% "correct" answers may sound good to a college student taking a final exam, but what that means in the case of captchas is bogus signups at a maximum rate of about 3/min. Oops. My conclusion (lacking other data) is that the cost of annoying my users is far greater than the potential benefit. I don't intend to even try to collect real data on captcha efficacy. ;-) From stephen at xemacs.org Tue Jun 15 06:15:47 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 15 Jun 2010 13:15:47 +0900 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> Eric Bloch writes: > My experience is not limited nor second hand. We get scanned by > plenty of bots every day. Heck, I can beat that: some of my sites get scanned by more bots than they have actual users. The question of "limited" is "how many different sites/kinds of sites do you have experience (eg, log access) on?" In my case, it's a half dozen or so, plus the talk I hear from other admins in the LUGs etc I hang out with. You can surely beat that, but does your experience generalize to a large fraction of Mailman lists, so that it should be a standard option provided by Mailman? "Not every three-line patch needs to be a standard feature." Or 300-line patch, for that matter. But some do. Are captchas a feature that ordinary Mailman users need? Or are they something that "if you know enough to know why you need them, you know enough to code an appropriate Handler"? (Or snaffle one from the CheeseShop, for that matter.) I have my opinion ;-), but I'm willing to be corrected. :-| > We also see captchas broken every day by some bots. Not all bots > break the captchas. Not all are trying to, either of course. This is the post hoc part. Of course, you see this, I was assuming you do. > But without the captchas, the ones that weren't even trying would > be getting to things we don't want them to get at. It's that > simple. This is the propter hoc part. It's not that simple. Captcha-using pages are *different* from non-captcha pages. What is it in your experience that shows that the captcha has any additional effect compared to *other* differences that are less annoying to bona fide users? I subscribe to a *lot* of Mailman lists. I would be mildly annoyed if uninformed list owners started using captchas just because they're easy to configure and because a lot of big names use them. At this point, I don't see a good reason to make it easy to annoy millions of subscribers that way. Or lose them, for that matter; I'm an Anonymous Coward on more than one site because I couldn't be bothered to use my "neural network" to break the captchas. Especially in open source development, the "frivolous" contributions (eg, one-off bug reports) add up --- we really don't want to encourage "features" of known cost to the individual subscriber and dubious benefit to the list community. Not to mention that this is an "arms race game": the more captchas are used, the more 'bots will be programmed to recognize *and break* them. You admit that you already see successful break-ins "every day", and the rate will only increase. They're really mostly suitable for well- informed admins who understand concepts like "defense in depth". (But again, those folks can typically cons up a patch pretty quickly. These parts of Mailman are not that hard to modify, especially in Mailman 3.) I guess my bottom line is that if a captcha feature is provided standard in Mailman 3, I believe that (1) it should be configurable per list (and off by default); (2) it should need to be enabled by the site admin (and off by default); The rationale for this is not just to make it harder to use the feature, but that the site admin is likely to be more expert in general to understand the limitations of the feature, and also some of the benefits and costs accrue to the site rather to the list community, so the site admin should have some input. (3) both configuration tools should have documentation indicating that captchas do not provide security; what they do is chase off the frivolous (both bona fide users and would-be abusers). This is a genuine benefit in several ways for many lists; it's just not real security because serious abusers will get through. From iane at sussex.ac.uk Tue Jun 15 17:31:30 2010 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 15 Jun 2010 16:31:30 +0100 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server In-Reply-To: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> References: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> Message-ID: <38F7B756A3E582AB30553000@lewes.staff.uscs.susx.ac.uk> --On 14 June 2010 19:21:04 +0200 Florian Fuchs wrote: > 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 That's so much nicer than Mailman2! A couple of small issues with list creation: 1. The checkboxes should be closer to the text in the languages list. It's hard to see which box applies to which text. 2. Mailman 3 supports multiple domains, right? So the list creation page should, perhaps, let me pick a domain from a drop down list. 3. Given that the list of lists is created from the list creation page, perhaps there should be an opportunity to fill in the "List information" field on the list creation page. > 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 > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a > c.uk > > Security Policy: http://wiki.list.org/x/QIA9 -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From cmpalmer at garp.metalab.unc.edu Tue Jun 15 19:21:27 2010 From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Tue, 15 Jun 2010 13:21:27 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20100615172127.GN11196@garp.metalab.unc.edu> Before getting into this (long) reply, I want to re-emphasize that what I want is (1) the ability to plug in existing CAPTCHA systems (notably reCAPTCHA) quickly and easily, and change simple config settings to enable those CAPTCHAs for parts of the interface that have been tested and confirmed to make sense. And (2) I want other (non-CAPTCHA, probably transparent to most users) changes to some points (eg. new user signup, moderator login) in the default MM interface that are designed to reduce abuse. I want (1) merely to the extent that it helps with (2). With that, more reply below. On Tue, Jun 15, 2010 at 01:15:47PM +0900, Stephen J. Turnbull wrote: > "Not every three-line patch needs to be a standard feature." Or > 300-line patch, for that matter. But some do. Are captchas a feature > that ordinary Mailman users need? Or are they something that "if you > know enough to know why you need them, you know enough to code an > appropriate Handler"? (Or snaffle one from the CheeseShop, for that > matter.) I have my opinion ;-), but I'm willing to be corrected. :-| While I could in theory maintain a patch, I have a lot of machines to herd, and I am unlikely to customize anything unless I must do so in order to meet a requirement. I very much want upstream to maintain anything that is reasonable and I will configure within the parameters set by them. This is not an issue of my expertise. This is an issue of maintainability and good use of admin time. > I subscribe to a *lot* of Mailman lists. So do I, but neither of us can claim (as individuals) to be representative of mailman users (subscribers, moderators, list owners, etc.), and in this case our claims seem to clash, so we need to look elsewhere. > I would be mildly annoyed if > uninformed list owners started using captchas just because they're > easy to configure and because a lot of big names use them. At this > point, I don't see a good reason to make it easy to annoy millions of > subscribers that way. While I share your distaste for bad implementations of... anything, really, CAPTCHAs do not annoy me unless they are poorly implemented, and they do not have to be poorly implemented. If you're going to say that millions of subscribers are going to be annoyed, please cite some studies. Here, I'll start: (As an aside, please contact me off-list if you're not able to access the full text for one or more of the papers cited below, and I will arrange for you to have access.) (1) Yan, J. and El Ahmad, A. S. 2008. Usability of CAPTCHAs or usability issues in CAPTCHA design. In Proceedings of the 4th Symposium on Usable Privacy and Security (Pittsburgh, Pennsylvania, July 23 - 25, 2008). SOUPS '08, vol. 337. ACM, New York, NY, 44-52. DOI= http://doi.acm.org/10.1145/1408664.1408671 ABSTRACT CAPTCHA is now almost a standard security technology, and has found widespread application in commercial websites. Usability and robustness are two fundamental issues with CAPTCHA, and they often interconnect with each other. This paper discusses usability issues that should be considered and addressed in the design of CAPTCHAs. Some of these issues are intuitive, but some others have subtle implications for robustness (or security). A simple but novel framework for examining CAPTCHA usability is also proposed. (2) Bigham, J. P. and Cavender, A. C. 2009. Evaluating existing audio CAPTCHAs and an interface optimized for non-visual use. In Proceedings of the 27th international Conference on Human Factors in Computing Systems (Boston, MA, USA, April 04 - 09, 2009). CHI '09. ACM, New York, NY, 1829-1838. DOI= http://doi.acm.org/10.1145/1518701.1518983 ABSTRACT Audio CAPTCHAs were introduced as an accessible alternative for those unable to use the more common visual CAPTCHAs, but anecdotal accounts have suggested that they may be more difficult to solve. This paper demonstrates in a large study of more than 150 participants that existing audio CAPTCHAs are clearly more difficult and time-consuming to complete as compared to visual CAPTCHAs for both blind and sighted users. In order to address this concern, we developed and evaluated a new interface for solving CAPTCHAs optimized for non-visual use that can be added in-place to existing audio CAPTCHAs. In a subsequent study, the optimized interface increased the success rate of blind participants by 59% on audio CAPTCHAs, illustrating a broadly applicable principle of accessible design: the most usable audio interfaces are often not direct translations of existing visual interfaces. And finally, my favorite: (3) M Motoyama, K Levchenko, C Kanich, D McCoy, GM. Re: CAPTCHAs?Understanding CAPTCHA-Solving Services in an Economic Context. Proceedings of the USENIX Security Symposium, Washington, D.C., August 2010. http://cseweb.ucsd.edu/~savage/papers/UsenixSec10.pdf ABSTRACT Reverse Turing tests, or CAPTCHAs, have become an ubiquitous defense used to protect open Web resources from being exploited at scale. An effective CAPTCHA resists existing mechanistic software solving, yet can be solved with high probability by a human being. In response, a robust solving ecosystem has emerged, reselling both automated solving technology and real-time human labor to bypass these protections. Thus, CAPTCHAs can increasingly be understood and evaluated in purely economic terms; the market price of a solution vs the monetizable value of the asset being protected. We examine the market-side of this question in depth, analyzing the behavior and dynamics of CAPTCHA-solving service providers, their price performance, and the underlying labor markets driving this economy. So I'm going to disagree with your premise that CAPTCHAs are necessarily annoying to most people unless you give more than anecdotal evidence that that is the case, and I'm going to disagree that they are always or even usually useless for protecting parts of WUIs. > (1) it should be configurable per list (and off by default); Agreed. > (2) it should need to be enabled by the site admin (and off by > default); Agreed, but only to the extent that having it available by default would add a dependency, which is too much of a burden on the MM team. > The rationale for this is not just to make it harder to use the > feature, but that the site admin is likely to be more expert in > general to understand the limitations of the feature, and also > some of the benefits and costs accrue to the site rather to the > list community, so the site admin should have some input. Definitely agreed. > (3) both configuration tools should have documentation indicating that > captchas do not provide security; what they do is chase off the > frivolous (both bona fide users and would-be abusers). This is a > genuine benefit in several ways for many lists; it's just not real > security because serious abusers will get through. Disagree. This is like saying that putting a $30 (USD) cable lock on my bike is not security because serious thieves could defeat it with a large pair of bolt cutters. Mind you, I use a ~$100 (USD) chain lock on my bikes, but that doesn't mean the $30 (USD) cable lock is useless, especially if the replacement cost of your bike is $150 (USD). You seem to think that only $100 (USD) chain locks are worth the effort, and that I'm insisting people use cheap locks. That is not the case. Furthermore, I think we may be in part talking past each other because you have seen lots and lots of poorly-done CAPTCHAs, and the entire concept has been spoiled for you by those bad implementations, and you picture us wanting one of those bad implementations on by default in mailman. That is not the case at all; it is also a straw man. CAPTCHA systems (and services such as reCAPTCHA) have improved a lot in the past three years, and nobody wants even the best of these to be used in a silly way within the default MM3 WUI. What I want is the ability to flip a switch and have CAPTCHAs available to me, and then have switches in one or more places (eg. moderator login, user signup) for those CAPTCHAs to be used every time or after the Nth attempt, for example. As I said before, there are several non-CAPTCHA approaches that I'd like to see used by default, too. For example, forcing signups to include a NONCE, rate limiting signups, etc. I don't want to get too hung up on CAPTCHAs in particular, but I also don't want us to completely reject them, since they are in fact useful and good if used properly. I'm very sorry you dislike them so much and have had bad experiences with them, but please let's have a more scientific discussion of the merits of CAPTCHAs. Cheers, -- Crist?bal Palmer ibiblio.org metalab.unc.edu From cmpalmer at garp.metalab.unc.edu Tue Jun 15 19:46:39 2010 From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Tue, 15 Jun 2010 13:46:39 -0400 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server In-Reply-To: <38F7B756A3E582AB30553000@lewes.staff.uscs.susx.ac.uk> References: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> <38F7B756A3E582AB30553000@lewes.staff.uscs.susx.ac.uk> Message-ID: <20100615174639.GQ11196@garp.metalab.unc.edu> On Tue, Jun 15, 2010 at 04:31:30PM +0100, Ian Eiloart wrote: > > >The server's address is http://mailman.state-of-mind.de > > That's so much nicer than Mailman2! Agreed! An earlier reply containing an ascii mockup got rejected, so here is an image of what I was trying to convey: http://dl.dropbox.com/u/2226600/two-column-mm3-mockup.png Basically I want to make sure that the "subscribe" box always shows up above the fold on the listinfo page. I get a fair number of tickets because things are not above the fold. Please let me know what you think of this idea. Cheers, -- Crist?bal Palmer ibiblio.org metalab.unc.edu From p at state-of-mind.de Tue Jun 15 21:08:20 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Tue, 15 Jun 2010 21:08:20 +0200 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server In-Reply-To: <38F7B756A3E582AB30553000@lewes.staff.uscs.susx.ac.uk> References: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> <38F7B756A3E582AB30553000@lewes.staff.uscs.susx.ac.uk> Message-ID: <20100615190819.GA2002@state-of-mind.de> * Ian Eiloart : > > > --On 14 June 2010 19:21:04 +0200 Florian Fuchs wrote: > > >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 > > That's so much nicer than Mailman2! That was hard... ;) > A couple of small issues with list creation: > > 1. The checkboxes should be closer to the text in the languages > list. It's hard to see which box applies to which text. Agreed. > 2. Mailman 3 supports multiple domains, right? So the list creation > page should, perhaps, let me pick a domain from a drop down list. There will be a way to choose among the domains a user (role) has access to, when MM3 and the REST server will provide such functionality. What you see at the moment is about all the REST server can provide at the moment. > 3. Given that the list of lists is created from the list creation > page, perhaps there should be an opportunity to fill in the "List > information" field on the list creation page. Yep. Do you have a wiki account? If not, you should get one and write down the constraints here: p at rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From terri at zone12.com Tue Jun 15 22:16:39 2010 From: terri at zone12.com (Terri Oda) Date: Tue, 15 Jun 2010 16:16:39 -0400 Subject: [Mailman-Developers] Mailman 3.0 UI Test Server In-Reply-To: <20100615174639.GQ11196@garp.metalab.unc.edu> References: <3D946E48-DD50-4AF0-BC45-97EBD3ECA89B@state-of-mind.de> <38F7B756A3E582AB30553000@lewes.staff.uscs.susx.ac.uk> <20100615174639.GQ11196@garp.metalab.unc.edu> Message-ID: <4C17DFA7.3050603@zone12.com> Crist?bal Palmer wrote: > Basically I want to make sure that the "subscribe" box always shows up > above the fold on the listinfo page. I get a fair number of tickets > because things are not above the fold. I like the idea in principle, but I don't think it'll work because there's a *lot* of stuff we want visible at first glance: - subscribe - unsubscribe - archives - list description - user options etc. We might want to consider having a set of links across the top to smaller pages (or anchors within one page) rather than trying to jam all these needs across the top of one page. From barry at list.org Wed Jun 16 04:44:03 2010 From: barry at list.org (Barry Warsaw) Date: Tue, 15 Jun 2010 22:44:03 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100613211656.GH11196@garp.metalab.unc.edu> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> Message-ID: <20100615224403.50b0eb20@heresy> On Jun 13, 2010, at 05:16 PM, Crist?bal Palmer wrote: >If there's some other non-CAPTCHA approach (or set of approaches) that >we could use to help reduce spammy signups, then I'm all for it. I >guess my hope is that we'd have something in place that reduces the >signups themselves rather than imposing work or workflow changes on >moderators or list members after they've joined. If that's necessary, >fine, but let's try things that happen at the signup step, too, yes? > >Even something as simple as requiring a hidden form field NONCE and >conservative rate limits on public signups, neither of which require >javascript or images.... Given that all signups require an email validation step, and that we'll rate-limit that to prevent using signups as a spam vector, what additional protection does captcha provide? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Wed Jun 16 05:02:56 2010 From: barry at list.org (Barry Warsaw) Date: Tue, 15 Jun 2010 23:02:56 -0400 Subject: [Mailman-Developers] REST API docs? In-Reply-To: References: Message-ID: <20100615230256.50e4b4df@heresy> On Jun 13, 2010, at 09:42 PM, Fil wrote: >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. The documentation on http://packages.python.org/mailman is out of date, but ultimately, that will be the best place to look. For now, the current bzr head is the best place to start: http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mailman/rest/docs/ This is unformatted, but should be easy to read. I should also mention that if you have requirements for additional REST APIs, the best thing to do is to file bugs in the tracker: https://bugs.edge.launchpad.net/mailman Please add the tags 'rest-api' and 'mailman3' so the bugs are easy to find. Tracking requests via bugs will help me prioritize the work. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Wed Jun 16 06:03:20 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 16 Jun 2010 13:03:20 +0900 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100615172127.GN11196@garp.metalab.unc.edu> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> <20100615172127.GN11196@garp.metalab.unc.edu> Message-ID: <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> Crist?bal Palmer writes: > While I could in theory maintain a patch, I have a lot of machines to > herd, and I am unlikely to customize anything unless I must do so in > order to meet a requirement. This is a straw man in the context of the Mailman pipelined architecture and the CheeseShop. > While I share your distaste for bad implementations of... anything, > really, CAPTCHAs do not annoy me unless they are poorly implemented, > and they do not have to be poorly implemented. Show me some well-implemented CAPTCHAs. Maybe I don't have to avoid them any more. However, the ones I have seen recently are no better than the ones I was seeing 3 or 4 years ago, and they still involve extra clicks, extra typing, and eyestrain. For blog comments, a CAPTCHA invariably means I'll move on. I'd also like to see evidence that CAPTCHAs work better than other efforts at confusing the attacker. -------------- next part -------------- > M Motoyama, K Levchenko, C Kanich, D McCoy, GM. Re: > CAPTCHAs~Understanding CAPTCHA-Solving Services in an Economic > Context. Proceedings of the USENIX Security Symposium, Washington, > D.C., August 2010. http://cseweb.ucsd.edu/~savage/papers/UsenixSec10.pdf > > ABSTRACT > > Reverse Turing tests, or CAPTCHAs, have become an ubiquitous defense > used to protect open Web resources from being exploited at scale. An > effective CAPTCHA resists existing mechanistic software solving, yet > can be solved with high probability by a human being. In response, a > robust solving ecosystem has emerged, reselling both automated solving > technology and real-time human labor to bypass these > protections. Thus, CAPTCHAs can increasingly be understood and > evaluated in purely economic terms; the market price of a solution vs > the monetizable value of the asset being protected. We examine the > market-side of this question in depth, analyzing the behavior and > dynamics of CAPTCHA-solving service providers, their price > performance, and the underlying labor markets driving this economy. Heck, I could have written that paper. > So I'm going to disagree with your premise that CAPTCHAs are > necessarily annoying to most people unless you give more than > anecdotal evidence that that is the case, There are plenty of studies showing that every extra click is costly. What I mean by "annoying" is "increases the probability of an exit click vs. staying on this site". > and I'm going to disagree that they are always or even usually > useless for protecting parts of WUIs. The question is "what are they protecting?" My claim is that if you're protecting economic resources (bandwidth, accurate counts of real users) they may be more or less useful. If it's a security issue -- including ways of harvesting email addresses that involve subscribing -- though, you're busted. > > (2) it should need to be enabled by the site admin (and off by > > default); > > Agreed, but only to the extent that having it available by default > would add a dependency, which is too much of a burden on the MM team. Mailman should clearly not provide any CAPTCHA implementation itself, given your claims of rapid progress in the field. > > (3) both configuration tools should have documentation indicating that > > captchas do not provide security; what they do is chase off the > > frivolous (both bona fide users and would-be abusers). This is a > > genuine benefit in several ways for many lists; it's just not real > > security because serious abusers will get through. > > Disagree. This is like saying that putting a $30 (USD) cable lock on > my bike is not security because serious thieves could defeat it with a > large pair of bolt cutters. Yes, exactly. My point is that you and I understand defense in depth and the economic aspects of security; most people think in terms of privacy leaks or hacking the financial system, which is far more severe than the loss of a bicycle. > Mind you, I use a ~$100 (USD) chain lock on my bikes, but that > doesn't mean the $30 (USD) cable lock is useless, It is where I live. My $25 USD (1982 prices) Kryptonite lock is still in service, and I have never lost a bike when using it. I did lose a $150 bike with a 4000 yen (1993 prices, ~$30) chain lock on it, in less than 4 months, though. > You seem to think that only $100 (USD) chain locks are worth the > effort, In fact, for the bike lock, I do. A good bike lock lasts forever (unless the thieves take the whole bike rack, nothing's perfect ;-). Unless you know your bike-riding life will last less than a year, there's no real point in buying less than than best bike lock available. Note how much knowledge and planning is required to make a good decision here! Computers are even harder.... This is not true for computer network services, however, where the stakes are higher and defense in depth is necessary. > and that I'm insisting people use cheap locks. No, that's not my claim. My claim is that it is unethical to make weak locks available for free, without explaining to people their correct use. > What I want is the ability to flip a switch and have CAPTCHAs > available to me, and then have switches in one or more places > (eg. moderator login, user signup) for those CAPTCHAs to be used every > time or after the Nth attempt, for example. > > As I said before, there are several non-CAPTCHA approaches that I'd > like to see used by default, too. For example, forcing signups to > include a NONCE, rate limiting signups, etc. I don't want to get too > hung up on CAPTCHAs in particular, but I also don't want us to > completely reject them, since they are in fact useful and good if used > properly. I'm very sorry you dislike them so much and have had bad > experiences with them, but please let's have a more scientific > discussion of the merits of CAPTCHAs. The first thing I want to see, then, is documentation that CAPTCHAs are more effective than other methods of confusing the dumb 'bots. From cmpalmer at garp.metalab.unc.edu Wed Jun 16 06:33:51 2010 From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Wed, 16 Jun 2010 00:33:51 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100615224403.50b0eb20@heresy> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <20100615224403.50b0eb20@heresy> Message-ID: <20100616043351.GT11196@garp.metalab.unc.edu> On Tue, Jun 15, 2010 at 10:44:03PM -0400, Barry Warsaw wrote: > > Given that all signups require an email validation step, and that we'll > rate-limit that to prevent using signups as a spam vector, what additional > protection does captcha provide? Are you saying that no scripts/bots can automatically sign up for mailman lists? I get plenty of signups like "qneu456na at nanke62w.net" that suggest otherwise. I should take the time to log those and send them to you, perhaps? After my masters paper... Most of these numbers are educated guess numbers; if you want real, validated numbers they'll have to wait, again, until I turn in my masters paper. With that... Let's say I have a large list that receives 16 signups a day, and of those two are actually humans and not scripts. The list owner, having had trouble with spammy signups in the past, has set the list to require moderator approval before users can post. What are the human costs? We'll say that the two human signups took 40s each (80s), and the moderator also took 40 seconds per signup (640s), for a total of 720s = 12 minutes. Now let's assume the reCAPTCHA adds 13s[0] to real human signups and cuts down spammy signups to 4 per day and re-run our math. The two people now spend 106s and the moderator spends 160s, or 4.43 minutes. Yes, we've shifted some costs to our subscribers, but they do that once, and the moderator gets back time daily. What's more, we've increased their burden by just over a quarter and almost divided the moderators burden by three. And we haven't even mentioned the increased cost to the spammer, or (in the case of reCAPTCHA) the benefit to society the CAPTCHA solving work. That's the real point of all this: drive up the cost to spammers as much as possible while imposing as little burden as is reasonable on list owners, moderators, subscribers, site admins, etc. We can't exactly follow the metafilter model[0] here, and I think this is as good an idea as I have seen, but I'd love for others to propose something else that imposes less of a burden on subscribers and we know will drive up costs to spammers over a longer-term basis. Again, I don't even propose we turn this on by default. I would just like to see this as a documented, tested option that can be enabled by site admins and cleanly upgraded without extra work. Okay... now that I've put all this energy into this explanation, I'll admit: spam to list owners, especially of the "Dear $LISTNAME owner, we at $SITENAME security need you to reset your password. Please find instructions in the attached .zip file..." were a much bigger problem a couple of years ago (surprisingly even after implementing SA) until I decided to block .zip and several other mime types at the MTA level. So if y'all have no interest in doing any reCAPTCHA integration, I'll just spend that much more time making anti-spam tweaks at the MTA level, and I'll field one or two more "I'm a moderator and I'm dealing with a lot of spam here" tickets every now and then. That's another point, come to think of it: I've had plenty of time and experience running a couple of decently-sized mailman installs, but what about the many, many people who have less experience running mailman? The easier we make it for them to make it hard on spammers, the better. A final note: are there any published user studies on mailman? I see your ATEC '03 and LISA '98 presentations in the ACM portal, and I see http://www.gnu.org/software/mailman/otherstuff.html ... but nothing else turns up in google scholar. Please point me to other research on mailman and its user base if it exists. If it doesn't, maybe I need to make that happen.... Thanks so much for all the work all of you do. It really is a pleasure and a privilege to be involved. Cheers, -- Crist?bal Palmer ibiblio.org metalab.unc.edu [0] http://www.sciencemag.org/cgi/content/full/321/5895/1465 "reCAPTCHA: Human-Based Character Recognition via Web Security Measures." Originally published in Science Express on 14 August 2008 Science 12 September 2008: Vol. 321. no. 5895, pp. 1465 - 1468 DOI: 10.1126/science.1160379 Quoting: User testing on our site (http://captcha.net) showed that it took 13.51 s on average (SD = 6.37) for 1000 randomly chosen users to solve a seven-letter conventional CAPTCHA (25th percentile was 8.28 s, median was 12.62 s, and 75th percentile was 17.12 s), whereas it took 13.06 s on average (SD = 7.67) for a different set of 1000 randomly chosen users (also from http://captcha.net) to solve a reCAPTCHA (25th percentile was 5.79 s, median was 12.64 s, and 75th percentile was 18.91 s). [1] Charge five US dollars (paypal) for an account. From cmpalmer at garp.metalab.unc.edu Wed Jun 16 06:57:59 2010 From: cmpalmer at garp.metalab.unc.edu (=?iso-8859-1?Q?Crist=F3bal?= Palmer) Date: Wed, 16 Jun 2010 00:57:59 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> <20100615172127.GN11196@garp.metalab.unc.edu> <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20100616045759.GU11196@garp.metalab.unc.edu> On Wed, Jun 16, 2010 at 01:03:20PM +0900, Stephen J. Turnbull wrote: > > The question is "what are they protecting?" My claim is that if > you're protecting economic resources (bandwidth, accurate counts of > real users) they may be more or less useful. If it's a security issue > -- including ways of harvesting email addresses that involve > subscribing -- though, you're busted. To my mind the main resources we're protecting are moderator time and site owner time, and we're admittedly cost shifting onto subscribers for lists where CAPTCHAs are enabled. > Mailman should clearly not provide any CAPTCHA implementation itself, > given your claims of rapid progress in the field. Not my claim. Others in the literature. I can do more digging if you don't believe me or don't have institutional access. Regardless, we're in agreement that it should not be the job of the MLM to provide the CAPTCHA. I'd just like a tested, approved way to plug in reCAPTCHA at the moment. I'll do it myself without any help from y'all (after my masters paper), but I think this would benefit the community. > > and that I'm insisting people use cheap locks. > > No, that's not my claim. My claim is that it is unethical to make > weak locks available for free, without explaining to people their > correct use. Ahhh. Very much agree. Also, sorry about your stolen bike. :( > The first thing I want to see, then, is documentation that CAPTCHAs > are more effective than other methods of confusing the dumb 'bots. http://www.sciencemag.org/cgi/content/full/321/5895/1465 Originally published in Science Express on 14 August 2008 Science 12 September 2008: Vol. 321. no. 5895, pp. 1465 - 1468 DOI: 10.1126/science.1160379 http://recaptcha.net/faq.html Good a place as any.... take it up with the authors. But think of it this way: if what mailman does is provide a plugin spot for something external to do CAPTCHA or CAPTCHA-like work, then some non-CAPTCHA method could be inserted that doesn't impose user load. For example, people could use a plugin that adds a junk form field that is hidden by CSS, or a simple 1 + 2 math problem, or any number of other things. The point is that we're doing the equivalent of adding braze-ons to the seat stays of a bicycle frame: whether the user adds a sturdy rack, a cheap one, or none at all is up to them. While I'm digging around and thinking of other anti-spam tools, maybe it's worth digging around in here for ideas, since this seems rather popular with WordPress: http://www.bad-behavior.ioerror.us/documentation/ Cheers, -- Crist?bal Palmer ibiblio.org metalab.unc.edu From adam-mailman at amyl.org.uk Wed Jun 16 10:59:07 2010 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Wed, 16 Jun 2010 09:59:07 +0100 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100616045759.GU11196@garp.metalab.unc.edu> References: <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> <20100615172127.GN11196@garp.metalab.unc.edu> <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> <20100616045759.GU11196@garp.metalab.unc.edu> Message-ID: <20100616085907.GV4752@amyl.org.uk> On Wed, Jun 16, 2010 at 12:57:59AM -0400, Crist?bal Palmer wrote: > While I'm digging around and thinking of other anti-spam tools, maybe > it's worth digging around in here for ideas, since this seems rather > popular with WordPress: > http://www.bad-behavior.ioerror.us/documentation/ Another one to look at (I'm not exactly a 'fan' of bad-behavior), is http://mollom.com/features (and http://mollom.com/benefits) -- it's quite a popular (aiui) plugin/module for Drupal-based/powered sites to use. (apparently, there's a Python library available at http://github.com/itkovian/PyMollom) -- "A traitor may betray himself and do good that he does not intend" -- J. R. R. Tolkien From adam-mailman at amyl.org.uk Wed Jun 16 14:10:17 2010 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Wed, 16 Jun 2010 13:10:17 +0100 Subject: [Mailman-Developers] Wiki Editing? Message-ID: <20100616121017.GA4752@amyl.org.uk> 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 (and the second parag of that mail) in , 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 From barry at list.org Wed Jun 16 14:38:24 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 16 Jun 2010 08:38:24 -0400 Subject: [Mailman-Developers] Wiki Editing? In-Reply-To: <20100616121017.GA4752@amyl.org.uk> References: <20100616121017.GA4752@amyl.org.uk> Message-ID: <20100616083824.3e14e640@heresy> On Jun 16, 2010, at 01:10 PM, Adam McGreggor wrote: >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 > >(and the second parag of that mail) in , >please?) You should now have write permission. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Wed Jun 16 14:44:56 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 16 Jun 2010 21:44:56 +0900 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100616045759.GU11196@garp.metalab.unc.edu> References: <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> <20100615172127.GN11196@garp.metalab.unc.edu> <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> <20100616045759.GU11196@garp.metalab.unc.edu> Message-ID: <87iq5jkuyf.fsf@uwakimon.sk.tsukuba.ac.jp> Crist?bal Palmer writes: > On Wed, Jun 16, 2010 at 01:03:20PM +0900, Stephen J. Turnbull wrote: > > > > The question is "what are they protecting?" My claim is that if > > you're protecting economic resources (bandwidth, accurate counts of > > real users) they may be more or less useful. If it's a security issue > > -- including ways of harvesting email addresses that involve > > subscribing -- though, you're busted. > > To my mind the main resources we're protecting are moderator time and > site owner time, and we're admittedly cost shifting onto subscribers > for lists where CAPTCHAs are enabled. I consider that a valid tradeoff, with the breakeven point to be determined by the moderators/list owners/site owners. OK, I'm happy again, no crazy people here. :-) > But think of it this way: if what mailman does is provide a plugin > spot for something external to do CAPTCHA or CAPTCHA-like work, then > some non-CAPTCHA method could be inserted that doesn't impose user > load. But IMO the pipeline architecture already does that. I haven't looked closely at the Mailman 3 webserver, but my understanding is that it gets a pipeline too. It seems to me that once you have that (and IMHO that is extremely desirable just by analogy to the list processing pipeline, which I have written several Handlers for), the rest is going to be pretty CAPTCHA-specific, and quite possibly specific to the particular CAPTCHA implementation. It might be worth recommending a third-party implementation of a best-of-breed (reCAPTCHA?) plugin or even providing one ourselves, but I plan to leave that decision to Barry, as long as the documentation for any such feature points out the limitations of the technology. > Also, sorry about your stolen bike. :( Don't be. It was a $150 bike, and the Minister of Finance in my house approved purchase of a $670 replacement. :-) All I really lost was a junk lock and about $50 resale value. From barry at list.org Wed Jun 16 21:26:40 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 16 Jun 2010 15:26:40 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100616043351.GT11196@garp.metalab.unc.edu> References: <5780E11428BE17C29814FF47@lewes.staff.uscs.susx.ac.uk> <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <20100615224403.50b0eb20@heresy> <20100616043351.GT11196@garp.metalab.unc.edu> Message-ID: <20100616152640.2bb5938e@heresy> On Jun 16, 2010, at 12:33 AM, Crist?bal Palmer wrote: >Are you saying that no scripts/bots can automatically sign up for >mailman lists? I get plenty of signups like "qneu456na at nanke62w.net" >that suggest otherwise. I should take the time to log those and send >them to you, perhaps? After my masters paper... Only if I can send you all the bounces and unsubs I get every month on Mailman day. :) >Okay... now that I've put all this energy into this explanation, I'll >admit: spam to list owners, especially of the "Dear $LISTNAME owner, >we at $SITENAME security need you to reset your password. Please find >instructions in the attached .zip file..." were a much bigger problem >a couple of years ago (surprisingly even after implementing SA) until >I decided to block .zip and several other mime types at the MTA >level. So if y'all have no interest in doing any reCAPTCHA >integration, I'll just spend that much more time making anti-spam >tweaks at the MTA level, and I'll field one or two more "I'm a >moderator and I'm dealing with a lot of spam here" tickets every now >and then. Two points: antispam defenses are always going to be better done in the MTA upstream of Mailman. We may provide some hooks to allow integration with SA/spambayes/clam/etc. but just seeing the cpu these take up on my measly server I do not think I want such a check running on everything teh intarwebs can throw at your lists domain. Second, I intend to pass -owner email through a pipeline the way posted messages go through, so you will at least have the opportunity to do some content and other checks on the message before they're forwarded to the owners. >That's another point, come to think of it: I've had plenty of time and >experience running a couple of decently-sized mailman installs, but >what about the many, many people who have less experience running >mailman? The easier we make it for them to make it hard on spammers, >the better. Yes, we should be opinionated and make reasonable defaults so that it's easy to install and run a working system, with good tradeoffs between usability, functionality and security. These are not always easy tradeoffs to make. >A final note: are there any published user studies on mailman? I see >your ATEC '03 and LISA '98 presentations in the ACM portal, and I see >http://www.gnu.org/software/mailman/otherstuff.html ... but nothing >else turns up in google scholar. Please point me to other research on >mailman and its user base if it exists. If it doesn't, maybe I need to >make that happen.... Terri was talking at one point of contracting such research, and I think some is being done as part of the GSoC work. None exists that I know of. If you're offering, I'm sure we would love to have some additional solid usability studies, especially focused on helping to guide Mailman 3 design. >Thanks so much for all the work all of you do. It really is a pleasure >and a privilege to be involved. Thanks to you and everyone who contributes to Mailman development. It truly is a great community. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From fil at rezo.net Wed Jun 16 21:31:05 2010 From: fil at rezo.net (Fil) Date: Wed, 16 Jun 2010 21:31:05 +0200 Subject: [Mailman-Developers] REST API docs? In-Reply-To: <20100615230256.50e4b4df@heresy> References: <20100615230256.50e4b4df@heresy> Message-ID: >?For now, the current bzr > head is the best place to start: > http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files/head:/src/mailman/rest/docs/ > > This is unformatted, but should be easy to read. yes that's perfect, thanks a lot. I see no mention of access control. Will we use OAuth or something? -- Fil From barry at list.org Wed Jun 16 21:34:38 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 16 Jun 2010 15:34:38 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <87iq5jkuyf.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> <20100615172127.GN11196@garp.metalab.unc.edu> <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> <20100616045759.GU11196@garp.metalab.unc.edu> <87iq5jkuyf.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20100616153438.0a2ab392@heresy> On Jun 16, 2010, at 09:44 PM, Stephen J. Turnbull wrote: >But IMO the pipeline architecture already does that. I haven't looked >closely at the Mailman 3 webserver, but my understanding is that it >gets a pipeline too. It seems to me that once you have that (and IMHO >that is extremely desirable just by analogy to the list processing >pipeline, which I have written several Handlers for), the rest is >going to be pretty CAPTCHA-specific, and quite possibly specific to >the particular CAPTCHA implementation. It's an interesting idea, but I'm not quite sure how a webserver pipeline would work. The way the list server pipeline works now is by treating messages as jobs that flow through the system. A web request is kind of a different beast. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Wed Jun 16 21:41:41 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 16 Jun 2010 15:41:41 -0400 Subject: [Mailman-Developers] REST API docs? In-Reply-To: References: <20100615230256.50e4b4df@heresy> Message-ID: <20100616154141.0b0a85db@heresy> On Jun 16, 2010, at 09:31 PM, Fil wrote: >I see no mention of access control. Will we use OAuth or something? Well, this is an interesting question . The way I've been thinking about it has been that the REST interface currently in the core engine is essentially an unprotected administrative interface. We would only ever expose it by default on localhost. For a publicly accessible REST front-end, we'd use OAuth and lock down permission based on privilege, but this would be a separate process and interface from the core. I know that's somewhat controversial but given the nightmarish complexity of lazr.restful and Zope's publisher, it was IMO an entirely justified architecture. With the switch to restish, it may be feasible to put security in the core. The tricky thing is doing this for end-user scripting while still allowing something like the webui to have unlimited, essentially root access. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From fil at rezo.net Wed Jun 16 21:56:58 2010 From: fil at rezo.net (Fil) Date: Wed, 16 Jun 2010 21:56:58 +0200 Subject: [Mailman-Developers] REST API docs? In-Reply-To: <20100616154141.0b0a85db@heresy> References: <20100615230256.50e4b4df@heresy> <20100616154141.0b0a85db@heresy> Message-ID: > The way I've been thinking about it has been that the REST interface currently > in the core engine is essentially an unprotected administrative interface. I see... Another (interesting?) question is how do you encode data esp. if an email address or username contains a slash (/) character. -- Fil From barry at list.org Wed Jun 16 22:28:51 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 16 Jun 2010 16:28:51 -0400 Subject: [Mailman-Developers] REST API docs? In-Reply-To: References: <20100615230256.50e4b4df@heresy> <20100616154141.0b0a85db@heresy> Message-ID: <20100616162851.17aae106@heresy> On Jun 16, 2010, at 09:56 PM, Fil wrote: >> The way I've been thinking about it has been that the REST interface currently >> in the core engine is essentially an unprotected administrative interface. > >I see... > >Another (interesting?) question is how do you encode data esp. if an >email address or username contains a slash (/) character. AFAIK, if it's encoded properly by the client (e.g. Python's httplib2), then the restish library should properly decode it. It's worth a test... going-off-to-hack-ly y'rs, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From fil at rezo.net Thu Jun 17 00:03:22 2010 From: fil at rezo.net (Fil) Date: Thu, 17 Jun 2010 00:03:22 +0200 Subject: [Mailman-Developers] REST API docs? In-Reply-To: <20100616162851.17aae106@heresy> References: <20100615230256.50e4b4df@heresy> <20100616154141.0b0a85db@heresy> <20100616162851.17aae106@heresy> Message-ID: How would I query members of list A? GET 'http://localhost:8001/3.0/members' + A ? If my mailing-list has thousands of members, how would I paginate the results? 'http://localhost:8001/3.0/members' + A + page=x ? -- Fil From stephen at xemacs.org Fri Jun 18 06:46:51 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 18 Jun 2010 13:46:51 +0900 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <20100616153438.0a2ab392@heresy> References: <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> <20100615172127.GN11196@garp.metalab.unc.edu> <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> <20100616045759.GU11196@garp.metalab.unc.edu> <87iq5jkuyf.fsf@uwakimon.sk.tsukuba.ac.jp> <20100616153438.0a2ab392@heresy> Message-ID: <87eig5kkw4.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > It's an interesting idea, but I'm not quite sure how a webserver pipeline > would work. The way the list server pipeline works now is by treating > messages as jobs that flow through the system. A web request is kind of a > different beast. Why? Abstractly, both web requests and mail messages are packages of data divided into metadata and payload. You line up a sequence of Handlers, each one looks at the metadata and decides whether it wants a crack at the package or not. If no, back to the pipeline. If yes, it may process metadata or payload (possibly modifying them), then decide to (a) do something final (reject/discard it or send something back out to the outside world), or (b) punt it back to the pipeline for further processing. You can also keep state across requests. If it's request-specific the nature of HTTP and email both require cookies (aka one-time keys). So, what's so different? It seems to me that it might also make communication between the webserver and the mail server(s) easier to organize (eg, when the user sends email to list-subcribe, then confirms by clicking on the web URL in the response) if these "jobs" had a unified format. It's possible that having a thousand handlers all looking at everything would be horribly inefficient, then you could divide things up into subpipelines (in the Linux kernel firewall they're called chains), with master Handlers in the toplevel pipeline dispatching to lower level subpipelines. I thought that was how Mailman 3 was organized. I know that Mailman 2's mail pipeline has inspired a lot of my thoughts about how Roundup's internal implementation could be improved. (Roundup "auditors" and "reactors" look a lot like Handlers.) I guess I'd better go look more closely at Mailman 3. From barry at list.org Sat Jun 19 01:34:05 2010 From: barry at list.org (Barry Warsaw) Date: Fri, 18 Jun 2010 19:34:05 -0400 Subject: [Mailman-Developers] REST API docs? In-Reply-To: References: <20100615230256.50e4b4df@heresy> <20100616154141.0b0a85db@heresy> <20100616162851.17aae106@heresy> Message-ID: <20100618193405.0741999a@heresy> On Jun 17, 2010, at 12:03 AM, Fil wrote: >How would I query members of list A? >GET 'http://localhost:8001/3.0/members' + A ? In the Bazaar trunk, r6914 , for mailing list alpha at example.com, if you want all the subscribed members, you would request: http://localhost:8001/3.0/lists/alpha at example.com/roster/members If you want the owners of the list: http://localhost:8001/3.0/lists/alpha at example.com/roster/owners and if you want the moderators: http://localhost:8001/3.0/lists/alpha at example.com/roster/moderators >If my mailing-list has thousands of members, how would I paginate the results? >'http://localhost:8001/3.0/members' + A + page=x ? Pagination is not yet supported. One of the deficiencies of restish as opposed to lazr.restful is that the former does not support collections out of the box. I have a CollectionMixin class to handle those, but it doesn't yet know about batching. Contributions are welcome! (The plus side of restish of course is that it only took me about two hours to add support for rosters, and most of that time was refactoring, writing the tests, and fixing a regression with the zope.testrunner integration. Read: easy peasy!) Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Sat Jun 19 23:31:34 2010 From: barry at list.org (Barry Warsaw) Date: Sat, 19 Jun 2010 17:31:34 -0400 Subject: [Mailman-Developers] UI for Mailman 3.0 update In-Reply-To: <87eig5kkw4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20100606202914.GC7286@garp.metalab.unc.edu> <20100609021217.GA3963@gsp.org> <20100613211656.GH11196@garp.metalab.unc.edu> <87sk4p2gfe.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxux2aoc.fsf@uwakimon.sk.tsukuba.ac.jp> <20100615172127.GN11196@garp.metalab.unc.edu> <87pqzrlj3r.fsf@uwakimon.sk.tsukuba.ac.jp> <20100616045759.GU11196@garp.metalab.unc.edu> <87iq5jkuyf.fsf@uwakimon.sk.tsukuba.ac.jp> <20100616153438.0a2ab392@heresy> <87eig5kkw4.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20100619173134.10a4a8ef@heresy> On Jun 18, 2010, at 01:46 PM, Stephen J. Turnbull wrote: >Barry Warsaw writes: > > > It's an interesting idea, but I'm not quite sure how a webserver pipeline > > would work. The way the list server pipeline works now is by treating > > messages as jobs that flow through the system. A web request is kind of a > > different beast. > >Why? Abstractly, both web requests and mail messages are packages of >data divided into metadata and payload. You line up a sequence of >Handlers, each one looks at the metadata and decides whether it wants >a crack at the package or not. If no, back to the pipeline. If yes, >it may process metadata or payload (possibly modifying them), then >decide to (a) do something final (reject/discard it or send something >back out to the outside world), or (b) punt it back to the pipeline >for further processing. The primary difference is that with email jobs, we can handle the asynchronously and there's little demand on handling them quickly. Web requests are synchronous and must be handle immediately, or the browser will time out. It's certainly possible to turn a web request into an asynchronous job, but it's much more complicated, and we don't often have the same access to the underlying jobs. With the email pipeline the MTA hands us a message and that (plus an accompanying metadata dictionary) *is* the job. Usually with a web request we don't have quite the same thing, even in a WSGI environment. >You can also keep state across requests. If it's request-specific the >nature of HTTP and email both require cookies (aka one-time keys). >So, what's so different? I'm not sure I follow about email requiring cookies. >It seems to me that it might also make communication between the >webserver and the mail server(s) easier to organize (eg, when the user >sends email to list-subcribe, then confirms by clicking on the web URL >in the response) if these "jobs" had a unified format. I don't quite see how that follows. >It's possible that having a thousand handlers all looking at >everything would be horribly inefficient, then you could divide things >up into subpipelines (in the Linux kernel firewall they're called >chains), with master Handlers in the toplevel pipeline dispatching to >lower level subpipelines. > >I thought that was how Mailman 3 was organized. I know that Mailman >2's mail pipeline has inspired a lot of my thoughts about how >Roundup's internal implementation could be improved. (Roundup >"auditors" and "reactors" look a lot like Handlers.) I guess I'd >better go look more closely at Mailman 3. Mailman 3 has the same basic architecture, except that the rule-checking handlers live in a different pipeline and have a slightly different semantic and interface. Please do take a look! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From c at state-of-mind.de Thu Jun 24 16:23:21 2010 From: c at state-of-mind.de (Claudia Fleiner) Date: Thu, 24 Jun 2010 16:23:21 +0200 Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3841 bytes Desc: not available URL: From barry at list.org Thu Jun 24 17:24:36 2010 From: barry at list.org (Barry Warsaw) Date: Thu, 24 Jun 2010 11:24:36 -0400 Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation In-Reply-To: References: Message-ID: <20100624112436.010bbcbe@heresy> On Jun 24, 2010, at 04:23 PM, Claudia Fleiner wrote: >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 panelfor 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 newuser >interface. Please don?t hesitate to send us your feedback. Very nice. I like it a lot. While I think we could use some re-evaluations of the categories, presenting them in this way works well I think. I think we won't have such a deep or wide hierarchy that displaying them all will be too confusing. The thing I really like about this is that I can figure out exactly what's going on in one quick glance, and can probably find my way to the section I care about very easily (certainly much more easy than today). I wonder, would it be possible to put tooltips on those menu items? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From terri at zone12.com Thu Jun 24 17:37:48 2010 From: terri at zone12.com (Terri Oda) Date: Thu, 24 Jun 2010 11:37:48 -0400 Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation In-Reply-To: <20100624112436.010bbcbe@heresy> References: <20100624112436.010bbcbe@heresy> Message-ID: <4C237BCC.5000605@zone12.com> Barry Warsaw wrote: > While I think we could use some re-evaluations of the categories, presenting > them in this way works well I think. I think we won't have such a deep or > wide hierarchy that displaying them all will be too confusing. The thing I > really like about this is that I can figure out exactly what's going on in one > quick glance, and can probably find my way to the section I care about very > easily (certainly much more easy than today). Agreed, both in that it looks lovely and that we need to redesign those categories badly. I also reiterate that we need a search option for finding admin options. There's just too many for average list administrators (who probably use this part of the interface once a month or less) to remember the hierarchy. Most people nowadays seem to be heavily reliant upon search. Terri From barry at list.org Thu Jun 24 18:09:04 2010 From: barry at list.org (Barry Warsaw) Date: Thu, 24 Jun 2010 12:09:04 -0400 Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation In-Reply-To: <4C237BCC.5000605@zone12.com> References: <20100624112436.010bbcbe@heresy> <4C237BCC.5000605@zone12.com> Message-ID: <20100624120904.0ae9d89c@heresy> On Jun 24, 2010, at 11:37 AM, Terri Oda wrote: >I also reiterate that we need a search option for finding admin options. >There's just too many for average list administrators (who probably use this >part of the interface once a month or less) to remember the hierarchy. Most >people nowadays seem to be heavily reliant upon search. +1 Searching on variable name and description at the least (which we should probably improve too ;). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From geoff at QuiteLikely.com Thu Jun 24 18:18:22 2010 From: geoff at QuiteLikely.com (Geoff Shang) Date: Thu, 24 Jun 2010 19:18:22 +0300 (IDT) Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation In-Reply-To: References: Message-ID: On Thu, 24 Jun 2010, Claudia Fleiner wrote: > 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 Can anyone explain this a bit for those of us who can't see this image? Or better still, point us at a coded example? Geoff. From tanstaafl at libertytrek.org Thu Jun 24 18:54:02 2010 From: tanstaafl at libertytrek.org (Tanstaafl) Date: Thu, 24 Jun 2010 12:54:02 -0400 Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation In-Reply-To: <20100624120904.0ae9d89c@heresy> References: <20100624112436.010bbcbe@heresy> <4C237BCC.5000605@zone12.com> <20100624120904.0ae9d89c@heresy> Message-ID: <4C238DAA.7020401@libertytrek.org> On 2010-06-24 12:09 PM, Barry Warsaw wrote: > On Jun 24, 2010, at 11:37 AM, Terri Oda wrote: > >> I also reiterate that we need a search option for finding admin options. >> There's just too many for average list administrators (who probably use this >> part of the interface once a month or less) to remember the hierarchy. Most >> people nowadays seem to be heavily reliant upon search. > +1 > > Searching on variable name and description at the least (which we should > probably improve too ;). How about also including a checkbox option (unchecked by default) to 'include online Knowledgebase/FAQ in seach results' (separated from hits in the Admin intrfce itself)? Or would that be overkill? From p at state-of-mind.de Thu Jun 24 20:38:18 2010 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Thu, 24 Jun 2010 20:38:18 +0200 Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation In-Reply-To: References: Message-ID: <20100624183818.GC1972@state-of-mind.de> * Geoff Shang : > On Thu, 24 Jun 2010, Claudia Fleiner wrote: > > >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 > > Can anyone explain this a bit for those of us who can't see this > image? Or better still, point us at a coded example? The overall style is light. Lot's of whitespace creates room to distinguish object from each other. The compositional focus is on the content area. Logo and navigation stand back to let users concentrate on the task they need to accomplish. The page is white. The navigation color scheme used is dark blue for typo and light blue as background color. There's a broad border around the navigation pane. It is semi-transparent. When opened, i.e. when level 2 and 3 are visible, the navigation layers over the content drawing users attention to the navigation only. The navigation is horizontal to make way for applications that take place beneath; applications usually require more place than text/images pages. You can see navigation level 1. The navigation differs from traditional navigations in a few ways: - When you hover the mouse or focus a menu entry using keyboard navigation you get to see both, level 2 and 3, at once. A large rectangle (wider than higher) creates the canvas for for both levels. - A topic specific icon prepends evey level 2 item. - Level 2 items are aligned to the left and in bold text. - Level 3 items, if there are any, follow right hand to their correspondent level 2 entry on the same line. They are displayed in regular font weight. - If there were so many level 3 items that they needed to wrap to the next line, they would indent starting at the same left margin where the first level 3 item started. -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From iane at sussex.ac.uk Fri Jun 25 12:25:43 2010 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 25 Jun 2010 11:25:43 +0100 Subject: [Mailman-Developers] Mailman user interface: draft of a mega drop-down navigation In-Reply-To: References: Message-ID: <388E58D5485326B866CC5A3E@lewes.staff.uscs.susx.ac.uk> --On 24 June 2010 19:18:22 +0300 Geoff Shang wrote: > On Thu, 24 Jun 2010, Claudia Fleiner wrote: > >> 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 > > Can anyone explain this a bit for those of us who can't see this image? > Or better still, point us at a coded example? > The page is a Mailman page that looks like it's for list administrators, but that's not made clear anywhere. Top left is a nice new Mailman logo, but if you can't see it, that doesn't help! Maybe the logo should be implemented in HTML5 such that the text ("Mailman GNU" is machine readable). Below the logo is a horizonal set of tabs with text labels: "Maintenance", "Options", "Subscriptions", "Statistics", "Plugins". I'm not sure that "maintenance" and "options" are good labels. If maintenance relates to pending moderation requests, perhaps it should be labelled "requests", or "queues". I'd prefer "configuration" for options, given that there are options (by definition) in every menu. Below are some paragraphs of Ipsum Lorem text. As a result of a mouseover on the "options tab", a vertical menu of options has popped up: "General, Non-Digest/Digest, Filter, Bounces, Archive, Gateways, Auto-responder, Plugins". Two of these options have submenus - fully visible and aligned horizontally: "General - Subscription Rules, Language", and "Filter - Sender, Recipient, Spam, Message, Topics". There are icons adjacent to each of the options. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ From mein at cs.umn.edu Fri Jun 25 22:54:32 2010 From: mein at cs.umn.edu (Kent Mein) Date: Fri, 25 Jun 2010 15:54:32 -0500 Subject: [Mailman-Developers] small suggestion Message-ID: <20100625205432.GB15954@cs.umn.edu> 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 at cs.umn.edu http://www.cs.umn.edu/~mein From mark at msapiro.net Sat Jun 26 01:25:28 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 25 Jun 2010 16:25:28 -0700 Subject: [Mailman-Developers] small suggestion In-Reply-To: <20100625205432.GB15954@cs.umn.edu> References: <20100625205432.GB15954@cs.umn.edu> Message-ID: <4C253AE8.9030008@msapiro.net> On 6/25/2010 1:54 PM, Kent Mein wrote: > 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) If your VIRTUAL_HOSTS dictionary (add_virtualhost() directives) is properly configured, hostname in the above code is the email host corresponding to the current web host, not the web host itself. Thus, the address has (or should have) an appropriate email domain. There is still an issue in that the address exposed for the site list on the admin and listinfo overview pages has the email domain for the current virtual host rather than DEFAULT_EMAIL_HOST, and this may require an additional virtual mapping in the MTA in order to work, but changing the domain is not the answer as some service provider type sites would not want to expose DEFAULT_EMAIL_HOST to someone visiting the listinfo overview for a virtual domain. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mss at apache.org Tue Jun 29 22:49:18 2010 From: mss at apache.org (Malte S. Stretz) Date: Tue, 29 Jun 2010 22:49:18 +0200 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header Message-ID: <201006292249.25934.mss@apache.org> 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From barry at list.org Wed Jun 30 03:15:33 2010 From: barry at list.org (Barry Warsaw) Date: Tue, 29 Jun 2010 21:15:33 -0400 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <201006292249.25934.mss@apache.org> References: <201006292249.25934.mss@apache.org> Message-ID: <20100629211533.1f8e0507@heresy> On Jun 29, 2010, at 10:49 PM, Malte S. Stretz wrote: >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.) It may just be time to ditch the Sender rewriting in Mailman 3. I don't think a reading of RFC 5322 can justify it, and I'm pretty sure getting bounce processing right with modern MTAs no longer requires it. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mark at msapiro.net Wed Jun 30 03:19:01 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 29 Jun 2010 18:19:01 -0700 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <20100629211533.1f8e0507@heresy> References: <201006292249.25934.mss@apache.org> <20100629211533.1f8e0507@heresy> Message-ID: <4C2A9B85.3040905@msapiro.net> On 6/29/2010 6:15 PM, Barry Warsaw wrote: > > It may just be time to ditch the Sender rewriting in Mailman 3. I don't think > a reading of RFC 5322 can justify it, and I'm pretty sure getting bounce > processing right with modern MTAs no longer requires it. +1 -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Wed Jun 30 04:15:46 2010 From: barry at list.org (Barry Warsaw) Date: Tue, 29 Jun 2010 22:15:46 -0400 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <4C2A9B85.3040905@msapiro.net> References: <201006292249.25934.mss@apache.org> <20100629211533.1f8e0507@heresy> <4C2A9B85.3040905@msapiro.net> Message-ID: <20100629221546.74f77b69@heresy> On Jun 29, 2010, at 06:19 PM, Mark Sapiro wrote: >On 6/29/2010 6:15 PM, Barry Warsaw wrote: >> >> It may just be time to ditch the Sender rewriting in Mailman 3. I don't think >> a reading of RFC 5322 can justify it, and I'm pretty sure getting bounce >> processing right with modern MTAs no longer requires it. > >+1 Done in r6915. I also removed the setting of the Errors-To header. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mss at apache.org Wed Jun 30 16:07:01 2010 From: mss at apache.org (Malte S. Stretz) Date: Wed, 30 Jun 2010 16:07:01 +0200 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <20100629221546.74f77b69@heresy> References: <201006292249.25934.mss@apache.org> <4C2A9B85.3040905@msapiro.net> <20100629221546.74f77b69@heresy> Message-ID: <201006301607.01912.mss@apache.org> On Wednesday 30 June 2010 04:15:46 Barry Warsaw wrote: > On Jun 29, 2010, at 06:19 PM, Mark Sapiro wrote: > >On 6/29/2010 6:15 PM, Barry Warsaw wrote: > >> It may just be time to ditch the Sender rewriting in Mailman 3. I > >> don't think a reading of RFC 5322 can justify it, and I'm pretty > >> sure getting bounce processing right with modern MTAs no longer > >> requires it. > > > >+1 > > Done in r6915. I also removed the setting of the Errors-To header. Cool. I set the status of bug 266824 to Fix Committed. Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask because I have to take care of some mailing lists on a shared server and I doubt that the admin will upgrade to 3.0 any time soon but I might convince him to go for the next 2.1 release once/if it is out and packaged :) Cheers, Malte From barry at list.org Wed Jun 30 16:24:07 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 30 Jun 2010 10:24:07 -0400 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <201006301607.01912.mss@apache.org> References: <201006292249.25934.mss@apache.org> <4C2A9B85.3040905@msapiro.net> <20100629221546.74f77b69@heresy> <201006301607.01912.mss@apache.org> Message-ID: <20100630102407.6d1c655c@heresy> On Jun 30, 2010, at 04:07 PM, Malte S. Stretz wrote: >Cool. I set the status of bug 266824 to Fix Committed. Thanks. I've targeted that to 3.0a6. >Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask because I >have to take care of some mailing lists on a shared server and I doubt >that the admin will upgrade to 3.0 any time soon but I might convince him >to go for the next 2.1 release once/if it is out and packaged :) It's Mark's decision, but I would be hesitant about applying it to 2.1. It's a new feature and as such shouldn't (IMO) go into a maintenance release. OTOH, I understand that it's the only version practically available to folks. Maybe you could create a branch on Launchpad. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mss at apache.org Wed Jun 30 16:38:39 2010 From: mss at apache.org (Malte S. Stretz) Date: Wed, 30 Jun 2010 16:38:39 +0200 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <20100630102407.6d1c655c@heresy> References: <201006292249.25934.mss@apache.org> <201006301607.01912.mss@apache.org> <20100630102407.6d1c655c@heresy> Message-ID: <201006301638.40297.mss@apache.org> On Wednesday 30 June 2010 16:24:07 Barry Warsaw wrote: > On Jun 30, 2010, at 04:07 PM, Malte S. Stretz wrote: > >Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask > >because I have to take care of some mailing lists on a shared server > >and I doubt that the admin will upgrade to 3.0 any time soon but I > >might convince him to go for the next 2.1 release once/if it is out > >and packaged :) > > It's Mark's decision, but I would be hesitant about applying it to 2.1. > It's a new feature and as such shouldn't (IMO) go into a maintenance > release. OTOH, I understand that it's the only version practically > available to folks. That I understand. But my patch is more or less a beefed up version of the patches some people use for ages. Not sure if I did something wrong in the GUI integration though. > Maybe you could create a branch on Launchpad. Here is a branch for 2.1: https://code.launchpad.net/~mss/mailman/2.1-sender-header And here for 2.2: https://code.launchpad.net/~mss/mailman/2.2-sender-header Not sure how to proceed from here, shall I try a merge proposal? Thanks, Malte From barry at list.org Wed Jun 30 16:45:39 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 30 Jun 2010 10:45:39 -0400 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <201006301638.40297.mss@apache.org> References: <201006292249.25934.mss@apache.org> <201006301607.01912.mss@apache.org> <20100630102407.6d1c655c@heresy> <201006301638.40297.mss@apache.org> Message-ID: <20100630104539.66cab03a@heresy> On Jun 30, 2010, at 04:38 PM, Malte S. Stretz wrote: >On Wednesday 30 June 2010 16:24:07 Barry Warsaw wrote: >> On Jun 30, 2010, at 04:07 PM, Malte S. Stretz wrote: >> >Any chance to have my patch applied to 2.1 (and/or 2.2)? I ask >> >because I have to take care of some mailing lists on a shared server >> >and I doubt that the admin will upgrade to 3.0 any time soon but I >> >might convince him to go for the next 2.1 release once/if it is out >> >and packaged :) >> >> It's Mark's decision, but I would be hesitant about applying it to 2.1. >> It's a new feature and as such shouldn't (IMO) go into a maintenance >> release. OTOH, I understand that it's the only version practically >> available to folks. > >That I understand. But my patch is more or less a beefed up version of >the patches some people use for ages. Not sure if I did something wrong >in the GUI integration though. > >> Maybe you could create a branch on Launchpad. > >Here is a branch for 2.1: > https://code.launchpad.net/~mss/mailman/2.1-sender-header >And here for 2.2: > https://code.launchpad.net/~mss/mailman/2.2-sender-header > >Not sure how to proceed from here, shall I try a merge proposal? That would be great. It would allow folks to comment on specifics of the implementation. It would then be up to Mark to decide whether and when to merge it into the 2.1 branch. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mark at msapiro.net Wed Jun 30 16:55:38 2010 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 30 Jun 2010 07:55:38 -0700 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <201006301638.40297.mss@apache.org> Message-ID: Malte S. Stretzwrote: > >Here is a branch for 2.1: > https://code.launchpad.net/~mss/mailman/2.1-sender-header >And here for 2.2: > https://code.launchpad.net/~mss/mailman/2.2-sender-header > >Not sure how to proceed from here, shall I try a merge proposal? I looked at your patch yesterday. It seems good, but it's missing a critical piece. It has to increment DATA_FILE_VERSION in Mailman/Version.py. Otherwise, the code in Mailman/versions.py to add the include_sender_header attribute to existing lists will not be called. See the CheckVersion() method in Mailman/MailList.py. I don't have a problem with including the patch in 2.1, except for the Defaults.py.in ALLOW_SENDER_OVERRIDES = Yes If it were no, the feature would be entirely transparent to those who didn't want it, essentially preserving the current situation for those who took no action. The problem with that is all those cPanel and service provider list owners who would then not have access to the feature even if they were aware and wanted it, so I think the default needs to be Yes which is somewhat disruptive, but probably not excessively so considering the potential benefit. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mss at apache.org Wed Jun 30 17:14:23 2010 From: mss at apache.org (Malte S. Stretz) Date: Wed, 30 Jun 2010 17:14:23 +0200 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: References: Message-ID: <201006301714.23820.mss@apache.org> On Wednesday 30 June 2010 16:55:38 Mark Sapiro wrote: > I looked at your patch yesterday. It seems good, but it's missing a > critical piece. It has to increment DATA_FILE_VERSION in > Mailman/Version.py. Otherwise, the code in Mailman/versions.py to add > the include_sender_header attribute to existing lists will not be > called. See the CheckVersion() method in Mailman/MailList.py. Ah, sorry, seems like I was too quick with my merge proposal. Gnn, now I have to grok how to supersede it on lp. I'll go and fix it. > I don't have a problem with including the patch in 2.1, except for the > Defaults.py.in > > ALLOW_SENDER_OVERRIDES = Yes > > If it were no, the feature would be entirely transparent to those who > didn't want it, essentially preserving the current situation for those > who took no action. Hmm. The change is still fairly transparent I think, after an upgrade there will just pop up an additional option for the list admins, defaulting to the old value. In the worst case it (theoretically) allows the list admin to shoot himself or his users in the foot. But nothing the superadmin should be worried about (IMHO). > The problem with that is all those cPanel and service provider list > owners who would then not have access to the feature even if they were > aware and wanted it, so I think the default needs to be Yes which is > somewhat disruptive, but probably not excessively so considering the > potential benefit. As I am one of those cPanel users, trying to push this change down my sysadmins throat the long way round, I'm in favor for Yes :) Cheers, Malte From adam-mailman at amyl.org.uk Wed Jun 30 17:02:38 2010 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Wed, 30 Jun 2010 16:02:38 +0100 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: References: <201006301638.40297.mss@apache.org> Message-ID: <20100630150238.GN25409@hendricks.amyl.org.uk> On Wed, Jun 30, 2010 at 07:55:38AM -0700, Mark Sapiro wrote: > I don't have a problem with including the patch in 2.1, except for the > Defaults.py.in > > ALLOW_SENDER_OVERRIDES = Yes > > If it were no, the feature would be entirely transparent to those who > didn't want it, essentially preserving the current situation for those > who took no action. Tricky, isn't it? > The problem with that is all those cPanel and service provider list > owners who would then not have access to the feature even if they were > aware and wanted it, so I think the default needs to be Yes which is > somewhat disruptive, but probably not excessively so considering the > potential benefit. I'd have thought given their mods anyhow, an extra one -- particularly one with clearly marked emails -- shouldn't be too difficult for them to maintain/include. -- ``Another sport which wastes unlimited time is Comma-hunting.'' (Francis Cornford, Microcosmographia Academica) From barry at list.org Wed Jun 30 17:27:47 2010 From: barry at list.org (Barry Warsaw) Date: Wed, 30 Jun 2010 11:27:47 -0400 Subject: [Mailman-Developers] [PATCH] for the notorious Sender header In-Reply-To: <201006301714.23820.mss@apache.org> References: <201006301714.23820.mss@apache.org> Message-ID: <20100630112747.42886463@heresy> On Jun 30, 2010, at 05:14 PM, Malte S. Stretz wrote: >Ah, sorry, seems like I was too quick with my merge proposal. Gnn, now I >have to grok how to supersede it on lp. I'll go and fix it. Just push an update to your existing branch. I believe LP will rescan your branch and update the merge proposal appropriately. >> I don't have a problem with including the patch in 2.1, except for the >> Defaults.py.in >> >> ALLOW_SENDER_OVERRIDES = Yes >> >> If it were no, the feature would be entirely transparent to those who >> didn't want it, essentially preserving the current situation for those >> who took no action. > >Hmm. The change is still fairly transparent I think, after an upgrade >there will just pop up an additional option for the list admins, >defaulting to the old value. In the worst case it (theoretically) allows >the list admin to shoot himself or his users in the foot. But nothing the >superadmin should be worried about (IMHO). If it does get applied to 2.1.x, be sure this new option (both the Defaults.py.in setting and the list admin option it enables) is clearly discussed in the release notes. I wonder if cPanel folks would ever read that and enable it for their own users? >> The problem with that is all those cPanel and service provider list >> owners who would then not have access to the feature even if they were >> aware and wanted it, so I think the default needs to be Yes which is >> somewhat disruptive, but probably not excessively so considering the >> potential benefit. > >As I am one of those cPanel users, trying to push this change down my >sysadmins throat the long way round, I'm in favor for Yes :) :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: