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@richleland.com 240-242-7424

On Thu, Jun 3, 2010 at 2:20 PM, Barry Warsaw <barry@list.org> 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@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....

Security Policy: http://wiki.list.org/x/QIA9

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!

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

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 <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

--On 4 June 2010 11:12:04 -0400 Barry Warsaw <barry@list.org> 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/

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

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

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

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.

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@xemacs.org] Sent: Monday, June 14, 2010 7:11 PM To: Eric Bloch Cc: Cristóbal Palmer; mailman-developers@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. ;-)

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

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

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.

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.

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

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@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

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 <argentina@gmail.com>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

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.

Hi P@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 <chris at schoeppi.net>

• Patrick Ben Koetter <p@state-of-mind.de>:

• Christian Schoepplein <chris@schoeppi.net>:

...

...

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@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

• Geoff Shang <geoff@QuiteLikely.com>:

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@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

• Geoff Shang <geoff@QuiteLikely.com>:

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 <http://www.webstandards.org/>. 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@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

• Christian Schoepplein <chris@schoeppi.net>:

...

• Geoff Shang <geoff@QuiteLikely.com>:

...

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@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@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

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

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@visi.com

Follow me on Twitter: http://www.twitter.com/dandrews920

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

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. <wonders if there are others who haven't also as I expect it to be a hot topic>

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=dF9XcGRsYUpsOUtxYjBWRUdnVXN4...

I expect there are others who have thought this out more than I, but I'll fill out the survey gladly.

Geoff.