From kovzol at gmail.com  Sat Jan  2 12:59:56 2010
From: kovzol at gmail.com (=?UTF-8?B?S292w6FjcyBab2x0w6Fu?=)
Date: Sat, 2 Jan 2010 12:59:56 +0100
Subject: [Mailman-Developers] adding new features for site admin (webUI)
Message-ID: <e47fa2b61001020359q110f66d2w4fe099ec35d63a3a@mail.gmail.com>

Dear Developers,

My task is to enhance the web admin interface for mailman-2.1.x, requested
by one of my customers. As a programmer, I learned that I need to add some
lines of code into Mailman/Cgi/admin.py (or listinfo.py).

I also learned that there are upcoming versions (2.2 and 3.0) which may have
a different (completely rewritten) interface. As far as I can understand the
current version (2.1.x) can be a widely used one for several years, so my
changes will be fruitful for the community for a few years or so.

I'd like to add the following new features. My customer is running 100+
different lists with 500+ users. So my customer asks me to give a web
interface for the following:

* Remove a given user from all lists. If a user to be removed is a list
admin, then a warning should come instead.
* Change the email address of a given user in all lists.

I know that these requests could be done via the command line interface, but
my customer would like to maintain these task via web.

My questions to you are:

* If my code is of quality, will it be a part of the mainstream code (from
2.1.14 or so)?
* Is admin.py the right place for such an enhancement?

Thank you for your answer in advance.

Yours,
Zoltan Kovacs
http://particio.com/english/

From kovzol at gmail.com  Sat Jan  2 16:42:28 2010
From: kovzol at gmail.com (=?UTF-8?B?S292w6FjcyBab2x0w6Fu?=)
Date: Sat, 2 Jan 2010 16:42:28 +0100
Subject: [Mailman-Developers] adding new features for site admin (webUI)
In-Reply-To: <000901ca8bc0$70f5f770$52e1e650$@org>
References: <e47fa2b61001020359q110f66d2w4fe099ec35d63a3a@mail.gmail.com>
	<000901ca8bc0$70f5f770$52e1e650$@org>
Message-ID: <e47fa2b61001020742p317eb69ds3f2fe2082c6d33fd@mail.gmail.com>

Dear Dave, thank you for this information. I guess 3.0 will not be out in a
reasonable time, and I do not think migration will be flawless from 2.1.x.
So I start to add the new features to 2.1.x and I'll make the patch
available for the public on a web page.

Yours, Zoltan

2010. janu?r 2. 16:29 David Brown ?rta, <dave at aasv.org>:

> FYI, on November 1, Barry Warsaw announced that all new functionality would
> be implemented only in 3.0; 2.1.x would be bugfixes only, and 2.2 was
> effectively dead.
>
> Dave
> --
> David Brown
> dave at aasv.org ; webmaster at aasv.org
>
> -----Original Message-----
> From: mailman-developers-bounces+dave=aasv.org at python.org
> [mailto:mailman-developers-bounces+dave<mailman-developers-bounces%2Bdave>
> =aasv.org at python.org] On Behalf Of
> Kov?cs Zolt?n
> Sent: Saturday, January 02, 2010 7:00 AM
> To: Mailman-Developers at python.org
> Subject: [Mailman-Developers] adding new features for site admin (webUI)
>
> Dear Developers,
>
> My task is to enhance the web admin interface for mailman-2.1.x, requested
> by one of my customers. As a programmer, I learned that I need to add some
> lines of code into Mailman/Cgi/admin.py (or listinfo.py).
>
> I also learned that there are upcoming versions (2.2 and 3.0) which may
> have
> a different (completely rewritten) interface. As far as I can understand
> the
> current version (2.1.x) can be a widely used one for several years, so my
> changes will be fruitful for the community for a few years or so.
>
> I'd like to add the following new features. My customer is running 100+
> different lists with 500+ users. So my customer asks me to give a web
> interface for the following:
>
> * Remove a given user from all lists. If a user to be removed is a list
> admin, then a warning should come instead.
> * Change the email address of a given user in all lists.
>
> I know that these requests could be done via the command line interface,
> but
> my customer would like to maintain these task via web.
>
> My questions to you are:
>
> * If my code is of quality, will it be a part of the mainstream code (from
> 2.1.14 or so)?
> * Is admin.py the right place for such an enhancement?
>
> Thank you for your answer in advance.
>
> Yours,
> Zoltan Kovacs
> http://particio.com/english/
> _______________________________________________
> 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/dave%40aasv.org
>
> Security Policy: http://wiki.list.org/x/QIA9
>
>

From mark at msapiro.net  Sat Jan  2 17:23:05 2010
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 02 Jan 2010 08:23:05 -0800
Subject: [Mailman-Developers] adding new features for site admin (webUI)
In-Reply-To: <e47fa2b61001020359q110f66d2w4fe099ec35d63a3a@mail.gmail.com>
References: <e47fa2b61001020359q110f66d2w4fe099ec35d63a3a@mail.gmail.com>
Message-ID: <4B3F72E9.5020600@msapiro.net>

On 1/2/2010 3:59 AM, Kov?cs Zolt?n wrote:
> 
> I'd like to add the following new features. My customer is running 100+
> different lists with 500+ users. So my customer asks me to give a web
> interface for the following:
> 
> * Remove a given user from all lists. If a user to be removed is a list
> admin, then a warning should come instead.


Note that as far as Mailman is concerned, there is no requirement that a
list owner or moderator be a member of the list.


> * Change the email address of a given user in all lists.
> 
> I know that these requests could be done via the command line interface, but
> my customer would like to maintain these task via web.
> 
> My questions to you are:
> 
> * If my code is of quality, will it be a part of the mainstream code (from
> 2.1.14 or so)?
> * Is admin.py the right place for such an enhancement?


As has been pointed out, All new feature development is now focused on
Mailman 3, so your changes won't be incorporated in 2.1.

While you could add these changes to the existing admin web interface,
it may not be really appropriate because the web admin interface is for
a given list, and in general, one list admin should not be able to
change things on other lists.

I think a more appropriate place to do this may be on the user options
page. You could add a 'globally' check box to the unsubscribe request
(there already is one for the address change), and you could accept
these from the site admin without confirmations.

Otherwise you could consider a totally separate site admin GUI.

As far as contributing your changes to the community is concerned, the
best way is to create a Bazaar branch at
https://code.launchpad.net/mailman and make your changes there.

But, I would encourage you to get involved with MM 3. It may not be as
far off as you think.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From me at earlruby.org  Wed Jan  6 20:22:29 2010
From: me at earlruby.org (Earl Ruby)
Date: Wed, 6 Jan 2010 11:22:29 -0800
Subject: [Mailman-Developers] Reply-To munging considered *carefully*
In-Reply-To: <1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org>
References: <1255119636.9074.22.camel@zest.trausch.us>
	<1255475702.16706.33.camel@zest.trausch.us>
	<878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255498516.13356.69.camel@zest.trausch.us>
	<20091014063026.GK14800@benfinney.id.au>
	<1255508359.13356.170.camel@zest.trausch.us>
	<87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255621047.4358.20.camel@zest.trausch.us>
	<871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org>
Message-ID: <e679484e1001061122ta674a16ka68adec15a128ff9@mail.gmail.com>

I've read back through this thread, and forgive me if this has been
discussed before, but have you considered giving subscribers the
option of deciding for themselves whether their replies should go to
the list or to the poster?

In other words, add the option:

Where are replies to list messages directed? (*) Poster  ( ) This list

... to the subscriber's settings, let the list administrator set the
default behavior, and add the option:

Allow subscribers to chose where their replies to list messages are
directed? (*) Yes  ( ) No

... to the list administrator's settings. It seems like whatever the
default behavior is set to it always irks 5% of any list's
subscribers. This would allow that 5% to fix the problem for
themselves, leaving only 2% to continue to grumble that there's really
only one correct way to do things and everyone should be doing it that
way.

-- 
Earl Ruby
http://earlruby.org/

From stephen at xemacs.org  Thu Jan  7 07:56:50 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 07 Jan 2010 15:56:50 +0900
Subject: [Mailman-Developers] Reply-To munging considered *carefully*
In-Reply-To: <e679484e1001061122ta674a16ka68adec15a128ff9@mail.gmail.com>
References: <1255119636.9074.22.camel@zest.trausch.us>
	<1255475702.16706.33.camel@zest.trausch.us>
	<878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255498516.13356.69.camel@zest.trausch.us>
	<20091014063026.GK14800@benfinney.id.au>
	<1255508359.13356.170.camel@zest.trausch.us>
	<87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255621047.4358.20.camel@zest.trausch.us>
	<871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org>
	<e679484e1001061122ta674a16ka68adec15a128ff9@mail.gmail.com>
Message-ID: <871vi2l7wt.fsf@uwakimon.sk.tsukuba.ac.jp>

Earl Ruby writes:

 > I've read back through this thread, and forgive me if this has been
 > discussed before, but have you considered giving subscribers the
 > option of deciding for themselves whether their replies should go to
 > the list or to the poster?

No, I hadn't considered it, and upon consideration I would add it to
the RFC only with a gun to my head (or equivalents such as demands
from multiple list management software developers).

The functionality you propose is *already available* to posters by
setting Reply-To, and that method should be encouraged for posters who
care because the poster already has the *per-message* knowledge of
what is appropriate.

I'm aware that many posters are in love with their Message-User-Agent-
That-Sucks[tm] and don't have that functionality available to them by
default.  That is not a problem I can solve, and I'm not going to try
to solve it in the RFC.  A better way to solve it is to help Michael
Trausch develop his all-things-to-all-men-and-even-women-and-children
mail-cum-news-cum-webforum thingy, and hope it takes over the world.

My advice, obviously, is that I don't think it will work as well as
the existing software, but it wouldn't be the first time I've been
very wrong, and I hope to live long enough to make many more
mistakes. :-)  If he's right, it would be a good thing to have, and I
think that's the place to look before adding more functionality to the
RFC.

Mailman could in theory offer it anyway, but I suspect that without an
RFC sanction Barry and Mark would shy away from it.


From adam-mailman at amyl.org.uk  Thu Jan  7 14:02:18 2010
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Thu, 7 Jan 2010 13:02:18 +0000
Subject: [Mailman-Developers] Reply-To munging considered *carefully*
In-Reply-To: <871vi2l7wt.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255498516.13356.69.camel@zest.trausch.us>
	<20091014063026.GK14800@benfinney.id.au>
	<1255508359.13356.170.camel@zest.trausch.us>
	<87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255621047.4358.20.camel@zest.trausch.us>
	<871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org>
	<e679484e1001061122ta674a16ka68adec15a128ff9@mail.gmail.com>
	<871vi2l7wt.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20100107130218.GO3079@amyl.org.uk>

On Thu, Jan 07, 2010 at 03:56:50PM +0900, Stephen J. Turnbull wrote:
> Earl Ruby writes:
> 
>  > I've read back through this thread, and forgive me if this has been
>  > discussed before, but have you considered giving subscribers the
>  > option of deciding for themselves whether their replies should go to
>  > the list or to the poster?
> 
> No, I hadn't considered it, and upon consideration I would add it to
> the RFC only with a gun to my head (or equivalents such as demands
> from multiple list management software developers).
> 
> The functionality you propose is *already available* to posters by
> setting Reply-To, and that method should be encouraged for posters who
> care because the poster already has the *per-message* knowledge of
> what is appropriate.

+1.

Or, indeed, setting (reply) hooks (or equivalents) in the
mail-directory for lists mails -- where clients support that -- if
people are so inclined. 

(I remember making Thunderbird or Outlook do that when I used one, or
both of them, in $DAYJOB-x, so that sort of behaviour *is* possible.)

I'm of the view that if mail's good enough to go to the list, the
reply ought to go there, too, with the exception of annoucement-only
type lists.

-- 
``Government incompetence [is] one of the UK's
  most important safeguards against totalitarianism.''
    (John Lettice)

From barry at list.org  Sat Jan  9 04:55:43 2010
From: barry at list.org (Barry Warsaw)
Date: Fri, 8 Jan 2010 22:55:43 -0500
Subject: [Mailman-Developers] Reply-To munging considered *carefully*
In-Reply-To: <871vi2l7wt.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1255119636.9074.22.camel@zest.trausch.us>
	<1255475702.16706.33.camel@zest.trausch.us>
	<878wfehbn8.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255498516.13356.69.camel@zest.trausch.us>
	<20091014063026.GK14800@benfinney.id.au>
	<1255508359.13356.170.camel@zest.trausch.us>
	<87ljjdg6ky.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1255621047.4358.20.camel@zest.trausch.us>
	<871vl4f48r.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1A31B838-B1C5-4697-9ACC-022A65E0A759@python.org>
	<e679484e1001061122ta674a16ka68adec15a128ff9@mail.gmail.com>
	<871vi2l7wt.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20100108225543.6ba56489@freewill>

On Jan 07, 2010, at 03:56 PM, Stephen J. Turnbull wrote:

>My advice, obviously, is that I don't think it will work as well as
>the existing software, but it wouldn't be the first time I've been
>very wrong, and I hope to live long enough to make many more
>mistakes. :-)  If he's right, it would be a good thing to have, and I
>think that's the place to look before adding more functionality to the
>RFC.
>
>Mailman could in theory offer it anyway, but I suspect that without an
>RFC sanction Barry and Mark would shy away from it.

Indeed.  TBH, I don't think adding more knobs to Mailman here is going to make
life any better for users.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100108/fe76c05a/attachment.pgp>

From barry at list.org  Fri Jan 15 16:07:11 2010
From: barry at list.org (Barry Warsaw)
Date: Fri, 15 Jan 2010 10:07:11 -0500
Subject: [Mailman-Developers] New Logo Contest for 2010
Message-ID: <20100115100711.5e690a0a@freewill>

Hello everybody!

Our current GNU Mailman logos were designed by the Dragon De Monsyne many
years ago.  They have served us exceedingly well, but with the coming of
Mailman 3, we've decided it's time our logos got a face lift.  So we're
opening up a new logo contest to the Mailman and GNU communities.  We invite
your creative and inspiring designs!

Details of the contest and submission guidelines are available here:

http://wiki.list.org/display/DEV/NewLogo

Submissions will be open until February 28, 2010, and is open to everyone, so
feel free to forward this announcement.  Please contact the Mailman Steering
Committee at mailman-cabal at python.org with any questions.

Enjoy,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100115/5c666462/attachment.pgp>

From barry at list.org  Tue Jan 19 13:46:57 2010
From: barry at list.org (Barry Warsaw)
Date: Tue, 19 Jan 2010 07:46:57 -0500
Subject: [Mailman-Developers] RELEASED GNU Mailman 3.0 alpha 5 (Distant
	Early Warning)
Message-ID: <20100119074657.5f8c59a9@freewill>

Hello everyone, welcome to 2010 and another Mailman 3 alpha release.

I'm happy to announce Mailman 3.0 alpha 5.  New in this release are additional
REST API methods for subscribing and unsubscribing email addresses to mailing
lists, and for listing all members of all mailing lists.  Mailman also
properly handles the -join, -leave, and -confirm email commands and
sub-addresses (-subscribe and -unsubscribe are aliases for -join and -leave).

A few more command line scripts have been renamed, a 'devmode' setting has
been added, and Mailman now searches for its configuration file using this
search order:

   -C config command line argument
   $MAILMAN_CONFIG_FILE environment variable
   ./mailman.cfg
   ~/.mailman.cfg
   /etc/mailman.cfg

As always, you can download the tarball from the Cheeseshop or Launchpad:

http://pypi.python.org/pypi/mailman
https://launchpad.net/mailman

Documentation is available here:

http://packages.python.org/mailman

Enjoy,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100119/ee545366/attachment.pgp>

From barry at list.org  Tue Jan 19 16:58:17 2010
From: barry at list.org (Barry Warsaw)
Date: Tue, 19 Jan 2010 10:58:17 -0500
Subject: [Mailman-Developers] [Mailman-i18n] RELEASED GNU Mailman 3.0
 alpha 5 (Distant Early Warning)
In-Reply-To: <e63cb1001001190717g530a3693u1fa88942ddf3ae0f@mail.gmail.com>
References: <20100119074657.5f8c59a9@freewill>
	<e63cb1001001190717g530a3693u1fa88942ddf3ae0f@mail.gmail.com>
Message-ID: <20100119105817.2fd69a4b@freewill>

On Jan 19, 2010, at 04:17 PM, Marcos wrote:

>Must be the Asturian language in the version 3? :)
>Can you confirm if is it an error, please?
>Thanks very much!

There is currently only English in Mailman 3.  We'll begin to do translations
on Launchpad, but I haven't hooked all that up yet.  It's on my list. ;)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100119/fe234dda/attachment.pgp>

From mmenezes at gmail.com  Wed Jan 20 00:42:13 2010
From: mmenezes at gmail.com (Marlon Menezes)
Date: Tue, 19 Jan 2010 17:42:13 -0600
Subject: [Mailman-Developers] Advanced user reputation/moderation features
Message-ID: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>

Let me state that I am not a IT person, so some of my questions/comments may
not be the most appropriate lingo that is used by you folks. It is also very
likely that my issues/ideas have been raised before, though I have not been
able to find it in the archives. I have been moderating non-commercial
mailing lists (initially majordomo and then mailman) since the mid 1990s.

One of the biggest issues has been in the moderation of posts on these
discussion lists. Usually, we have had a set of volunteer moderators who
review the posts for spam, obscenity, personal attacks etc before they get
approved for distribution. While stuff like spam, obscenity etc are for the
most part obvious and can be auto filtered  using various options, the
problem remains that the issue of more mundane posts are still subject to
the moderator's bias.  Besides being subjective, it can be many, many hours
before a post gets approved, which  hampers the continuity and spontaneity
of the posts.

An alternate approach to moderation could be via a "user reputation score"
as is often found in many web based discussion forums. A person with a
higher user reputation score could have fewer restrictions posed on him, in
terms of the number of posts (say per unit of time) without moderation,
before he gets flagged for manual moderation. At this stage, it is not my
intent to propose an a specific mathematical algorithm, but rather to bring
out general concepts.

The issue of course is how would a "user reputation score" be determined? I
would think it would be composed of a variety of components such as: (in no
particular order)

1) Feedback scores as determined by the general mailing list population. The
feature could be embedded into an email to allow collective input from the
reader base.  This will automatically provide a feedback loop to poor
quality posters to either reign in their posts or suffer a demotion in their
posting rights via the pre-defined algorithm. Furthermore, it will be based
on the fopinions of the collective masses, rather than that of the
moderator.

2) Verified identity/open ID: I understand that open ID is one of the
features being considered for a future release of mailman. Individuals with
larger networks on sites such as facebook etc could be given a higher
starting reputation score as opposed to a ID that has little or no prior
history or network to back that person's identity. This will help reduce the
possibility of fraudulent posts under freshly created IDs.

I would appreciate some feedback on whether something like this is possible.
Since I am not a programmer, I would not be able to provide technical
support for the development of this code.  However, I may be able to get
some funding from a non-profit foundation to get this done.

Regards,
Marlon

From adam-mailman at amyl.org.uk  Wed Jan 20 01:41:19 2010
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Wed, 20 Jan 2010 00:41:19 +0000
Subject: [Mailman-Developers] Advanced user reputation/moderation
	features
In-Reply-To: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
References: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
Message-ID: <20100120004118.GD3079@amyl.org.uk>

On Tue, Jan 19, 2010 at 05:42:13PM -0600, Marlon Menezes wrote:
> Individuals with larger networks on sites such as facebook etc could be given a higher
> starting reputation score as opposed to a ID that has little or no prior
> history or network to back that person's identity. This will help reduce the
> possibility of fraudulent posts under freshly created IDs.

The "numbers game" concerns me slightly; I don't believe a large
amount of "friends" necessarily equates to a greater level of trust.

Perhaps this may best be highlighted with 'spammers' on Twitter, for
example (those following a large amount of people, compared with a
representatively small amount of followers); or, indeed, the myspace
"get as many 'friends' as you can" game.

Not much help, more of a dampener on things.

On the reverse, if one were to use (G|P)GP keys, and the amounts of
verifications/web-of-trust there: a lot of us are really quite lazy
when it comes to key-signing.

About the only site with a trustworthy reputation, I would suggest,
would have been LinkedIn, although, I'm not too sure I'd even stand-by
that these days, as it's changed rather a lot since when *I* signed
up to that.

Were there to be a scheme, I think *I* would tend to go with something
operating per-list, in the stack-overflow approach you're suggesting;
were something that complex to be introduced; I'm lazy, and think if
someone's wrong, they'll be shouted down; when people can 'prove'
they're not barking mad, they're set as unmoderated.

That said, for a majority of the lists I listmaster, it's a "you can
post to the list, once you join, until you annoy the list(master)".

And annoying the listmaster usually means spamming/posting
out-of-office messages to the list, or being *exceptionally* 
out of tune with the rest of the list.

(With MM3, I could see, perhaps, this maybe being useful as an optional
plugin, mind.)

-- 
``Of course we are not patronising women. We are just going to explain to
  them, in words of one syllable, what it is all about.'' (Olga Maitland)

From mmenezes at gmail.com  Wed Jan 20 21:21:03 2010
From: mmenezes at gmail.com (Marlon Menezes)
Date: Wed, 20 Jan 2010 14:21:03 -0600
Subject: [Mailman-Developers] Advanced user reputation/moderation
	features
In-Reply-To: <20100120004118.GD3079@amyl.org.uk>
References: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
	<20100120004118.GD3079@amyl.org.uk>
Message-ID: <113fdcdd1001201221q77cc8bd3m8d951a82d677254@mail.gmail.com>

On Tue, Jan 19, 2010 at 6:41 PM, Adam McGreggor <adam-mailman at amyl.org.uk>wrote:

> On Tue, Jan 19, 2010 at 05:42:13PM -0600, Marlon Menezes wrote:
> > Individuals with larger networks on sites such as facebook etc could be
> given a higher
> > starting reputation score as opposed to a ID that has little or no prior
> > history or network to back that person's identity. This will help reduce
> the
> > possibility of fraudulent posts under freshly created IDs.
>
> The "numbers game" concerns me slightly; I don't believe a large
> amount of "friends" necessarily equates to a greater level of trust.
>
> Perhaps this may best be highlighted with 'spammers' on Twitter, for
> example (those following a large amount of people, compared with a
> representatively small amount of followers); or, indeed, the myspace
> "get as many 'friends' as you can" game.
>
>  I think one way to get around this would be to give higher value to
friends who are already on the mailing list. The real issue I am trying to
address here is not identity verification, but rather, reducing the chance
of a potential abuser who has been put in the moderated list,  then tries to
get in un-moderated under a new ID.  With such a set up, it will require a
lot of effort on the part of that user to generate a new friends list etc.


> That said, for a majority of the lists I listmaster, it's a "you can
> post to the list, once you join, until you annoy the list(master)".
>
> This approach, while being suitable for a low volume technical group such
as this, does not work for a highly active community/social forum in which
what defines what is annoying the list master is subject to interpretation.

Regards,
Marlon

From barry at list.org  Wed Jan 20 23:51:32 2010
From: barry at list.org (Barry Warsaw)
Date: Wed, 20 Jan 2010 17:51:32 -0500
Subject: [Mailman-Developers] Advanced user reputation/moderation
 features
In-Reply-To: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
References: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
Message-ID: <20100120175132.69419f47@freewill>

On Jan 19, 2010, at 05:42 PM, Marlon Menezes wrote:

>An alternate approach to moderation could be via a "user reputation score"
>as is often found in many web based discussion forums. A person with a
>higher user reputation score could have fewer restrictions posed on him, in
>terms of the number of posts (say per unit of time) without moderation,
>before he gets flagged for manual moderation. At this stage, it is not my
>intent to propose an a specific mathematical algorithm, but rather to bring
>out general concepts.

First I'm going to explain how we do something similar in Launchpad[1], then I
can talk about how we might go about this in Mailman 3.

In Launchpad, we do several things to reduce the moderation burden while not
opening up lists to too much spam.  One advantage we have in Launchpad is that
we accept no email from unregistered or unvalidated email addresses.  Now,
this is site-wide so once you've registered and validated your email address
to Launchpad, then you can potentially email any mailing list, even ones you
are not a member of.  Before that, we summarily reject your message.  The
validation step is of course important, because once you're registered with
Launchpad you can add more email addresses, but you can't really use them
until they've been validated via mail-back confirmation.

Okay, that's the first step, and it can do a pretty good job of reducing
crap.  Next, if you are a member of the mailing list, we allow your message to
go through.  Because list moderators have tools at their disposal to punish
abusers we think this is generally a fine trade-off.  I'm less concerned about
allowing one bad message if you can boot the offender off your list or ban
them permanently if they persist.  IOW, I'd rather punish the rare bad apple
than impose additional burdens on the vast majority of good ones.

Let's say you post to a mailing list that you are not a member of, what
happens?  Well, the first time you post to it, your message gets held for
moderator approval.  This is very similar to what happens in Mailman today.
The difference is that if the moderator approves your post, you then your
subsequent messages to that mailing list are not moderated.  The numbers can
be tweaked, but the idea is the same: if you prove yourself by posting some
good messages a few times, we don't need to moderate you any more.

Taking this concept further, if you post to three different mailing lists that
you are not a member of, and your held message gets approved each time with no
rejections, we think you're probably okay in general and will let you post to
any mailing list without moderation, regardless of whether you're a member or
not.  See, your reputation is improving so you get more privileges.

Each user in Launchpad also has a concept of "standing", which the admins can
set but users cannot see or influence.  There are essentially four levels of
standing: excellent, good, unknown, and poor.  If your standing is poor, we
summarily discard your messages.  If your standing is good or better, then
your posts go through without moderation.  So one of the tools we have to
punish abusers is to set their standing to "poor" and wave goodbye.

Now, even though Launchpad is backed by Mailman 2, most of the data for this
is in Launchpad, so stock Mailman 2 can't really do this.  The main reason is
that Mailman 2 doesn't have any global concept of a user.  It's a complete
silo per mailing list.  Mailman 3 fixes this architectural limitation so we
could potentially record the same standing data and posting history in Mailman
3 and use very similar posting rules.  I think this would help sites that run
many mailing lists (e.g. python.org).

I could even see other moderation rules implemented as plugins.  Mailman 3 has
a more robust architecture, with separate pipelines for moderation and
modification of messages.  The rule chains that handle moderation could easily
be extended to look for any of the above criteria, as well as any other
user reputation scores you can dream up.

This all works great in theory, with of course the fundamental problem of
email: without digital signatures, it's completely spoofable.  Every byte of
data that Mailman can possibly look at can be forged, so it could make a
completely reasonable decision based on false data, and then you're pretty
much SoL.  In practice, this doesn't seem to be a big problem, but really
paranoid sites with knowledgeable users could require that all messages be
digitally signed in order to even be considered for acceptance.  Personally,
I'd love to see that become the normal across the board, but I'm not holding
my breath. ;)

I hope that helps in understanding where my current thinking on the subject
is.  While the framework for implementing the above exists and works in the
current Mailman 3 alphas, the actual reputation code isn't there.  That's
something that focused (and funded?) development work could push forward.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100120/67ab89bc/attachment.pgp>

From vince at wlcr.net  Thu Jan 21 17:14:52 2010
From: vince at wlcr.net (vince at wlcr.net)
Date: Thu, 21 Jan 2010 11:14:52 -0500
Subject: [Mailman-Developers] Advanced user reputation/moderation
	features
References: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
	<20100120175132.69419f47@freewill>
Message-ID: <D984BBB2F23A47858598E68841BF2EE1@L520>

Hi Barry,
Keep up the good work!   In response to your last email:

With the "global user" concept, would the individual list moderators
be able to assign a "poor" status for one list only?
Or will all the lists be stuck with the status assigned on a global basis?

vince heuser

From barry at list.org  Fri Jan 22 15:50:04 2010
From: barry at list.org (Barry Warsaw)
Date: Fri, 22 Jan 2010 09:50:04 -0500
Subject: [Mailman-Developers] [SPAM] Re: Advanced user
 reputation/moderation features
In-Reply-To: <D984BBB2F23A47858598E68841BF2EE1@L520>
References: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
	<20100120175132.69419f47@freewill>
	<D984BBB2F23A47858598E68841BF2EE1@L520>
Message-ID: <20100122095004.5a699bf6@freewill>

On Jan 21, 2010, at 11:14 AM, vince at wlcr.net wrote:

>Hi Barry,
>Keep up the good work!   In response to your last email:

Thanks!

>With the "global user" concept, would the individual list moderators
>be able to assign a "poor" status for one list only?
>Or will all the lists be stuck with the status assigned on a global basis?

In Launchpad, standing is an attribute of the user, so it is global across all
mailing lists.  I think that makes the most sense, since I don't think a user
in poor standing on list A is going to be much better on list B.  However list
admins do have other means to control who can post to their list, so they'll
have other ways to manage that on a per-list basis.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100122/d2a681f8/attachment.pgp>

From barry at list.org  Fri Jan 22 16:07:59 2010
From: barry at list.org (Barry Warsaw)
Date: Fri, 22 Jan 2010 10:07:59 -0500
Subject: [Mailman-Developers] Pycon 2010 sprint
Message-ID: <20100122100759.79b5210f@freewill>

I would like to conduct another sprint at the 2010 Python conference in
Atlanta this year.  The focus should be on building the new web user interface
for Mailman 3.  We'll be doing things like reviewing and choosing
technologies, doing the information layout, building the framework, and
fleshing out the REST API.

Please sign up on this page if you plan on attending.

http://wiki.list.org/display/DEV/PyCon+Sprint+2010

(You can also sign up there if you're only able to participate virtually.)

Hope to see you there,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100122/400856bf/attachment.pgp>

From mmenezes at gmail.com  Fri Jan 22 20:06:46 2010
From: mmenezes at gmail.com (Marlon Menezes)
Date: Fri, 22 Jan 2010 13:06:46 -0600
Subject: [Mailman-Developers] Advanced user reputation/moderation
	features
In-Reply-To: <20100120175132.69419f47@freewill>
References: <113fdcdd1001191542p3261e0d0wf7712f8d875102f@mail.gmail.com>
	<20100120175132.69419f47@freewill>
Message-ID: <113fdcdd1001221106k290200fftaafc72d58b48a023@mail.gmail.com>

On Wed, Jan 20, 2010 at 4:51 PM, Barry Warsaw <barry at list.org> wrote:

>
> Taking this concept further, if you post to three different mailing lists
> that
> you are not a member of, and your held message gets approved each time with
> no
> rejections, we think you're probably okay in general and will let you post
> to
> any mailing list without moderation, regardless of whether you're a member
> or
> not.  See, your reputation is improving so you get more privileges.
>
> Each user in Launchpad also has a concept of "standing", which the admins
> can
> set but users cannot see or influence.  There are essentially four levels
> of
> standing: excellent, good, unknown, and poor.  If your standing is poor, we
> summarily discard your messages.  If your standing is good or better, then
> your posts go through without moderation.  So one of the tools we have to
> punish abusers is to set their standing to "poor" and wave goodbye.
>
> Barry,

Thanks for your detailed explanation. The concept of "standing" is in line
with my thinking, but I would like to extend it even further. As of now,
one's standing is completely in the hands of the list administrator, which
again, may be fine for a low volume technical mailing list. Why not
democratize it by allowing for input/feedback from the list members? Right
now, one of the biggest issues we are facing is that in very high volume
community/opinion discussion lists, the list administrators need to scan
hundreds of posts per day from legitimate members. Discussions often get
heated and discussion threads can go on endlessly. Sometimes,
administrators, may take actions that may not be appropriate, given their
inability to keep up with the discussions.  If the quality scores of posts
and discussion threads could be farmed out to the general list, it would
drastically reduce the burden on the administrators.

The issue of identify verification, spoofing etc are valid, but those
instances are exactly the occasions where the list admins should have time
to focus on.

Regards,
Marlon

From barry at list.org  Fri Jan 22 23:19:39 2010
From: barry at list.org (Barry Warsaw)
Date: Fri, 22 Jan 2010 17:19:39 -0500
Subject: [Mailman-Developers] Mailman web user interface kick-off
Message-ID: <20100122171939.6311b93c@freewill.wooz.org>

Hello folks,

I'd like to officially kickoff the Mailman 3 web user interface project.  I
want to invite all interested developers and designers to join in on helping
to produce an awesome, modern user interface for the next version of Mailman.

I believe we have enough infrastructure in the core Mailman 3 engine to
support at least initial work on the WUI.  The architecture we've laid out is
solid I believe.  The Mailman 3 engine provides a REST HTTP server exposing a
full-access administrative interface.  The WUI will be a separate optional
process that sites can run, which communicates over REST to manage security
and provide external HTTP/HTML access to Mailman functionality for users, list
administrators, and site administrators.

All discussions about the WUI can be conducted on the mailman-developers
mailing list.  The wiki can be used to collect artifacts such as design notes,
decisions, and progress:

http://wiki.list.org/display/DEV/Web+Interface

(Contact me or mailman-cabal at python.org off-line if you need write access.
The wiki is fairly locked down due to spam.)

The Launchpad project for the Mailman WUI is here:

https://launchpad.net/mailmanweb

but there is currently very little there at the moment.  Remember too that we
are trying to gather critical mass to sprint on the WUI at Pycon 2010:

http://wiki.list.org/display/DEV/PyCon+Sprint+2010

Enjoy,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20100122/13f59b83/attachment.pgp>

From johnf at net2000.com.au  Sun Jan 24 05:56:10 2010
From: johnf at net2000.com.au (John Fitzsimons)
Date: Sun, 24 Jan 2010 15:56:10 +1100
Subject: [Mailman-Developers] Mailman web user interface kick-off
In-Reply-To: <4B5BBF84.2060005@value.net>
References: <20100122171939.6311b93c@freewill.wooz.org>
	<4bdnl5l5hll3hin9ef30e73uop81rqami6@4ax.com>
	<4B5BBF84.2060005@value.net>
Message-ID: <dmjnl5tsmctfvriil0cdsmnhs7vshqissf@4ax.com>

On Sat, 23 Jan 2010 19:33:24 -0800, Mark Sapiro wrote:
 
>On 11:59 AM, John Fitzsimons wrote:

< snip >

>> Sounds good. Is this instead of the news server integration ? Being
>> done prior to that ? Or are they being developed concurrently ?
 
>> Is this meant to be a Mailman "alternative" to CPanel ? Or are you
>> thinking of adding such things as posting to an email list via a
>> Mailman web page ? In other words an (optional ?) Mailman 
>> created web forum.

< snip >

>And no, this is independent of any possible NNTP support and is probably
>happening first

Okay, though I expect that if a news server option were offered it
might include a "common" database for email/news/web posts.

> (although in open source, you never know what might
>happen), and no it is not a "Mailman "alternative" to CPanel" whatever
>that might be. 

As a windows user the CPanel interface is all that I am familiar with.

>It is a redesign of the existing MM 2.1 web interface

Okay, I haven't seen that.

>(most of which is virtually unchanged by cPanel). I.e. all of the
>existing list admin, admindb, options, etc. web interface that you see
>in your cPanel installation is virtually unchanged from standard Mailman
>2.1. This is a redesign of that interface for MM 3.

Sounds good. Particularly if one has a "Delete (or hide ?) archive"
option.  :-)

>The ability to post from a web page could be part of this if there is
>enough interest.

Though I don't like web forums many people do. I am sure that a lot 
of people would like a web forum interface if it were offered as an
"option".

For many people "Web Mail" is a handy way to check what is in their
"home" mailbox when on the road, or at work.

The current web access to Mailman archives is very close already to a
web forum IMO. All that needs to be added is a "reply" button and a
"new post" button.

IF that page were offered, as a html page that administrators could
alter, it would enable them to make things "prettier".

Regards, John.

From f at state-of-mind.de  Sun Jan 24 13:33:28 2010
From: f at state-of-mind.de (Florian Fuchs)
Date: Sun, 24 Jan 2010 13:33:28 +0100
Subject: [Mailman-Developers] Mailman web user interface kick-off
In-Reply-To: <20100122171939.6311b93c@freewill.wooz.org>
References: <20100122171939.6311b93c@freewill.wooz.org>
Message-ID: <B0CE96A7-9D59-42CF-A7F8-6F68D32AB346@state-of-mind.de>

Hi there, 

I'm Florian, a web developer from Berlin. I have been subscribed to the mailing list for a year now, but haven't posted anything so far. So first things first: Hi to you all!

I was, however, present at last year's Pycon MM-sprint (and will be this year), so here's what I recall, along with some thoughts: 

I guess the framework would be one of the first things to decide about. At last year's sprint, we talked about using Pylons and genshi as a template engine. On the other hand: Pylons' standard template engine, Mako, seems to be a lot faster while having a similar set of features (i18n, ...). Being relatively new to Python I personally don't have a preferred framework (Pylons seemed fine, though...). But I am a fan of the MVC pattern because of the separation of logic and layout. So using something like Pylons or Django seems like a good idea to me.

On the Javascript side, I would recommend jQuery because of its performance, small size, tons of plugins and general awesomeness.

Best,
Florian Fuchs



Am 22.01.2010 um 23:19 schrieb Barry Warsaw:

> All discussions about the WUI can be conducted on the mailman-developers
> mailing list.  The wiki can be used to collect artifacts such as design notes,
> decisions, and progress:


From nahuel at ahtna.org  Mon Jan 25 13:27:51 2010
From: nahuel at ahtna.org (Nahuel ANGELINETTI)
Date: Mon, 25 Jan 2010 13:27:51 +0100
Subject: [Mailman-Developers] Mailman web user interface kick-off
In-Reply-To: <bfc33ad71001250200t366e8fcdw2d017c168e074557@mail.gmail.com>
References: <20100122171939.6311b93c@freewill.wooz.org>	
	<B0CE96A7-9D59-42CF-A7F8-6F68D32AB346@state-of-mind.de>
	<bfc33ad71001250200t366e8fcdw2d017c168e074557@mail.gmail.com>
Message-ID: <4B5D8E47.5020805@ahtna.org>

Hi,

> Hi there,
>
> I'm Florian, a web developer from Berlin. I have been subscribed to
> the mailing list for a year now, but haven't posted anything so far.
> So first things first: Hi to you all!
>
> I was, however, present at last year's Pycon MM-sprint (and will be
> this year), so here's what I recall, along with some thoughts:
>
> I guess the framework would be one of the first things to decide
> about. At last year's sprint, we talked about using Pylons and genshi
> as a template engine. On the other hand: Pylons' standard template
> engine, Mako, seems to be a lot faster while having a similar set of
> features (i18n, ...). Being relatively new to Python I personally
> don't have a preferred framework (Pylons seemed fine, though...). But
> I am a fan of the MVC pattern because of the separation of logic and
> layout. So using something like Pylons or Django seems like a good
> idea to me.
>
> On the Javascript side, I would recommend jQuery because of its
> performance, small size, tons of plugins and general awesomeness.
>    
I already did a lot of work using django, jquery, and some python 
libraries. All is accessible on :
http://dev.arbrows.org
We already put it in beta production at : http://archives.rezo.net.
The main goal of this project, is to have a "generic" webapp for all 
mailing list managers(mailman, sympa, ...), and it should be a good idea 
to create an open REST API.
We have a lot of ideas for arbrows futur, but well I have not really 
time atm to work full time on this project, i'm walking slowly.

If you're interested to help me/us, please contact me, it'll be a pleasure.

Bests,

-- 
Nahuel ANGELINETTI


From kovzol at particio.com  Fri Jan 29 11:26:49 2010
From: kovzol at particio.com (=?UTF-8?B?S292w6FjcyBab2x0w6Fu?=)
Date: Fri, 29 Jan 2010 11:26:49 +0100
Subject: [Mailman-Developers] adding new features for site admin (webUI)
In-Reply-To: <4B3F72E9.5020600@msapiro.net>
References: <e47fa2b61001020359q110f66d2w4fe099ec35d63a3a@mail.gmail.com>
	<4B3F72E9.5020600@msapiro.net>
Message-ID: <e47fa2b61001290226g74183d81wc3c609c705a8e3ad@mail.gmail.com>

Dear All,

Thank you for the worthy answers! In the meanwhile I started to write a
subsystem which is about to be introduced for production use. It is not
fully functional yet, e.g. administrator email changes are missing yet, but
the software is already usable. I uploaded it to
http://particio.com/downloads/mmsawt-0.6.tar.gz.


2010. janu?r 2. 17:23 Mark Sapiro ?rta, <mark at msapiro.net>:

> On 1/2/2010 3:59 AM, Kov?cs Zolt?n wrote:
> >
> > I'd like to add the following new features. My customer is running 100+
> > different lists with 500+ users. So my customer asks me to give a web
> > interface for the following:
> >
> > * Remove a given user from all lists. If a user to be removed is a list
> > admin, then a warning should come instead.
>
>
> Note that as far as Mailman is concerned, there is no requirement that a
> list owner or moderator be a member of the list.
>

Thanks for pointing out this!


>
>
> > * Change the email address of a given user in all lists.
> >
> > I know that these requests could be done via the command line interface,
> but
> > my customer would like to maintain these task via web.
> >
> > My questions to you are:
> >
> > * If my code is of quality, will it be a part of the mainstream code
> (from
> > 2.1.14 or so)?
> > * Is admin.py the right place for such an enhancement?
>
>
> As has been pointed out, All new feature development is now focused on
> Mailman 3, so your changes won't be incorporated in 2.1.
>
> While you could add these changes to the existing admin web interface,
> it may not be really appropriate because the web admin interface is for
> a given list, and in general, one list admin should not be able to
> change things on other lists.
>
> I think a more appropriate place to do this may be on the user options
> page. You could add a 'globally' check box to the unsubscribe request
> (there already is one for the address change), and you could accept
> these from the site admin without confirmations.
>
> Otherwise you could consider a totally separate site admin GUI.
>

This is what I chose.


>
> As far as contributing your changes to the community is concerned, the
> best way is to create a Bazaar branch at
> https://code.launchpad.net/mailman and make your changes there.
>

OK, I'll do that, but I should learn Bazaar first. I guess it should be
quite straightforward. If you find my contribution useful, I'll happily
learn Bazaar and upload my scripts. Of course, the current package I
uploaded to particio.com is also available for the community.


>
> But, I would encourage you to get involved with MM 3. It may not be as
> far off as you think.
>

:-) Yes, I read the news that you are working hard on MM 3. I hope I'll have
some time to try it soon!

Yours, Zoltan

From hedges at scriptdolphin.com  Fri Jan 29 22:55:35 2010
From: hedges at scriptdolphin.com (Mark Hedges)
Date: Fri, 29 Jan 2010 13:55:35 -0800 (PST)
Subject: [Mailman-Developers] return 401 for bad password?
Message-ID: <alpine.DEB.1.10.1001291354180.10659@li16-163.members.linode.com>


Hi... is there any possibility a post with a bad password
could return 401 instead of 200... that way fail2ban would
automatically block bots that try to hack list manager
passwords.

Mark

From mark at msapiro.net  Sat Jan 30 02:02:47 2010
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 29 Jan 2010 17:02:47 -0800
Subject: [Mailman-Developers] return 401 for bad password?
In-Reply-To: <alpine.DEB.1.10.1001291354180.10659@li16-163.members.linode.com>
Message-ID: <PC195201001291702470375957a6766@msapiro>

Mark Hedges wrote:
>
>Hi... is there any possibility a post with a bad password
>could return 401 instead of 200... that way fail2ban would
>automatically block bots that try to hack list manager
>passwords.


In Mailman/Cgi/Auth.py in the definition of loginpage find

    if msg:
        msg = FontAttr(msg, color='#ff0000', size='+1').Format()

and append

        print '401 Unauthorized\n'

to make it

    if msg:
        msg = FontAttr(msg, color='#ff0000', size='+1').Format()
        print '401 Unauthorized\n'

This is entirely untested, but should work for both failed admin and
admindb logins.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Sat Jan 30 03:22:42 2010
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 29 Jan 2010 18:22:42 -0800
Subject: [Mailman-Developers] return 401 for bad password?
In-Reply-To: <PC195201001291702470375957a6766@msapiro>
References: <PC195201001291702470375957a6766@msapiro>
Message-ID: <4B6397F2.2000508@msapiro.net>

Mark Sapiro wrote:


> and append
> 
>         print '401 Unauthorized\n'
> 
> to make it
> 
>     if msg:
>         msg = FontAttr(msg, color='#ff0000', size='+1').Format()
>         print '401 Unauthorized\n'


Actually, that's wrong on two counts. It should be 'Status: 401
Unauthorized' and there should be no newline as print provides one, so
make it

    if msg:
        msg = FontAttr(msg, color='#ff0000', size='+1').Format()
        print 'Status: 401 Unauthorized'


> This is entirely untested, but should work for both failed admin and
> admindb logins.


And it's still untested.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From benjamin.rahn at gmail.com  Sat Jan 30 03:47:39 2010
From: benjamin.rahn at gmail.com (Benjamin Rahn)
Date: Fri, 29 Jan 2010 21:47:39 -0500
Subject: [Mailman-Developers] batch editing of users' topic subscriptions
	(feature request)
Message-ID: <7F68339C-363C-4454-8B49-BAAA2615F634@gmail.com>

Hi Mailman devs,

As a list admin I would find it hugely helpful if I could batch-edit  
users' topic subscriptions.

========
Context

I use mailman to administer mailing lists for a 400-member community  
of a college dorm (including students and staff).  Many of the  
announcements aren't applicable to the entire community, but instead  
to particular subgroups (e.g. sophomores, students living on the  
third floor, students enrolled in a math class).

Our current approach is to set up multiple lists -- one main list to  
which everyone is subscribed ('announce') and then another list for  
each subgroup (e.g. 'announce-sophomores', 'announce-third-floor',  
'announce-math').  This is, of course, inelegant at best and more  
typically a major hassle for all involved.

I'd like to be able to use topics to filter messages to the  
appropriate set of users, but as far as I can tell this would require  
adjusting each user's topics by hand.  (It's not realistic to ask  
members to set up their own topic subscriptions.)   If there was a  
batch mechanism for adjusting users' topic subscriptions this would  
be much easier.

========
Potential Solution

I'm not particularly fussy about how the batch editing would be  
accomplished, but here's what I came up with that would seem to  
require little modification of mailman's current interface (I'm using  
2.1.9):

On the mass-subscribe page (mailman/admin/foo/members/add), permit  
input to the 'subscribees' textarea with lines of the form

   'address at domain.com topic1 topic2'

which would subscribe the address to the list if it wasn't already,  
and further subscribe the address to the listed topics.

Similarly, the mass unsubscribe page (mailman/admin/foo/members/ 
remove), this input would unsubscribe the address from _only_ the  
listed topics, but not from the list as a whole.

=========

Would love to get others' thoughts on this feature.

Thanks for your consideration!

Best regards,
Ben

PS I'm new to the list -- apologies if this has been covered before  
and my archive search wasn't sufficiently thorough.