From andy at insectnation.org  Fri Nov  7 11:25:56 2008
From: andy at insectnation.org (Andy Buckley)
Date: Fri, 07 Nov 2008 10:25:56 +0000
Subject: [Mailman-Developers] MM command prefix and-or single mm-admin CLI
	frontend
Message-ID: <491417B4.20909@insectnation.org>

Hi,

I've been meaning to send this mail for a long time, but for one reason
or another (mostly fear of making UI suggestions for a project whose
internals I don't really know) have repeatedly managed to put it off!

It sounds trivial, but one thing that I've always regarded as a
usability problem in MM2 is the proliferation of admin command names. As
a terminal junky, a common way to learn the functionality of a
multi-purpose set of command line tools is to type their common prefix
and press tab to see what commands are available. In MM, there is no
common prefix, so this option isn't available and memory is needed to
remember the right command name... commands like 'newlist' and
'config_list' are spread higgledy-piggledy through name-space rather
than being neatly stacked in one corner. It would be great for usability
if MM3 could use admin commands with e.g. a "mm-" prefix (with
installation of backwards compatible versions maybe as an option)

An alternative approach, used most prominently by Trac, is to have a
single admin command which can either behave like a non-interactive
process or a subcommand interpreter, depending on how it is called. I
would be happy to spend some time on a mm-admin command, using the same
Python "cmd" module as trac-admin if there is the interest. This might
also involve moving some of the intelligence out of the admin scripts
and into the API, which is also good news for people like me who have a
need/desire to hook MM into a wider system management framework.

Anyway, that's the idea --- what do you think? And apologies for being
presumptuous ;)

Best wishes,
Andy

PS. I'm also interested in taking a look at MM3 templating... is this
being actively worked on or did it stall after the GSoC effort?


From stephen at xemacs.org  Sat Nov  8 09:58:55 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 08 Nov 2008 17:58:55 +0900
Subject: [Mailman-Developers] MM command prefix and-or single mm-admin
	CLI	frontend
In-Reply-To: <491417B4.20909@insectnation.org>
References: <491417B4.20909@insectnation.org>
Message-ID: <87zlkapp9s.fsf@xemacs.org>

Andy Buckley writes:

 > In MM, there is no common prefix

Since most commands work best from the Mailman home directory, "bin/"
works fine for me.<wink>

 > is to have a single admin command which can either behave like a
 > non-interactive process or a subcommand interpreter, depending on
 > how it is called.

I would say that the big advantage is not so much the "prefix" aspect,
but rather the ability to give helpful help, such as brief
descriptions or required arguments, and also to have a "mm help <cmd>"
version for details on each command.


From barry at list.org  Sat Nov  8 19:13:52 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 8 Nov 2008 13:13:52 -0500
Subject: [Mailman-Developers] MM command prefix and-or single mm-admin
	CLI frontend
In-Reply-To: <491417B4.20909@insectnation.org>
References: <491417B4.20909@insectnation.org>
Message-ID: <816276CF-536C-4B00-A5BF-A1BC27472C4E@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 7, 2008, at 5:25 AM, Andy Buckley wrote:

> It sounds trivial, but one thing that I've always regarded as a
> usability problem in MM2 is the proliferation of admin command  
> names. As
> a terminal junky, a common way to learn the functionality of a
> multi-purpose set of command line tools is to type their common prefix
> and press tab to see what commands are available. In MM, there is no
> common prefix, so this option isn't available and memory is needed to
> remember the right command name... commands like 'newlist' and
> 'config_list' are spread higgledy-piggledy through name-space rather
> than being neatly stacked in one corner. It would be great for  
> usability
> if MM3 could use admin commands with e.g. a "mm-" prefix (with
> installation of backwards compatible versions maybe as an option)

Andy, I feel exactly the same way!  As Stephen points out, the  
tradition in Mailman has been to separate Mailman's command name space  
into its own 'bin' directory, which at least helps reduce the command  
line pollution.

> An alternative approach, used most prominently by Trac, is to have a
> single admin command which can either behave like a non-interactive
> process or a subcommand interpreter, depending on how it is called. I
> would be happy to spend some time on a mm-admin command, using the  
> same
> Python "cmd" module as trac-admin if there is the interest. This might
> also involve moving some of the intelligence out of the admin scripts
> and into the API, which is also good news for people like me who  
> have a
> need/desire to hook MM into a wider system management framework.

Mailman 3 definitely takes this approach, aided in large part by  
setuptools.  Ideally, there should be little but option parsing shim  
in the command modules, but even there, with setuptools, we're able to  
move everything into the mailman.bin package so at least it's / 
feasible/ to import it and use it.  The code in the mailman.bin  
modules are not always organized in a convenient way though.  I have a  
strong desire to change that (there should be no unique logic in a  
mailman.bin module).

I like the idea of a master command, and quite naturally I would  
choose 'mailman'.  I didn't know that Trac did this, but lots of other  
programs do, and I would look at the Bazaar code to see if there's  
anything we can steal there too.  If there's a Cheeseshop package we  
can just use, all the better.

Now that Python 2.6 is out, and 3.0 nearly so, I'm hoping to shift  
most of my free hacking time back to Mailman 3.  All help with the  
command reorganization would be welcome.

Another thing to think about is bringing sanity to the command line  
options.  Those are about as inconsistent as you can get too, though  
MM3 tries to bring some sanity back there.  For example, some commands  
take a -l option to specify the list name they operate on, others use  
a required positional argument.  Blech.

> PS. I'm also interested in taking a look at MM3 templating... is this
> being actively worked on or did it stall after the GSoC effort?

It's not being actively worked on, but I'd like it to be.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkkV1uAACgkQ2YZpQepbvXE19wCfVgqBWpah2Yeft9SDk9vs0qoe
p2MAnA6udvrP8mm6eak6TjZOI9Ui5Jf8
=2HOW
-----END PGP SIGNATURE-----

From dgc at uchicago.edu  Sat Nov  8 22:31:34 2008
From: dgc at uchicago.edu (David Champion)
Date: Sat, 8 Nov 2008 15:31:34 -0600
Subject: [Mailman-Developers] MM command prefix and-or single mm-admin
	CLI frontend
In-Reply-To: <816276CF-536C-4B00-A5BF-A1BC27472C4E@list.org>
References: <491417B4.20909@insectnation.org>
	<816276CF-536C-4B00-A5BF-A1BC27472C4E@list.org>
Message-ID: <20081108213134.GE16311@monkey.uchicago.edu>


> I like the idea of a master command, and quite naturally I would choose 
> 'mailman'.  I didn't know that Trac did this, but lots of other programs 
> do, and I would look at the Bazaar code to see if there's anything we can 
> steal there too.  If there's a Cheeseshop package we can just use, all 
> the better.

This interface style seems to be gaining popularity, so even if it's not
the only interface it's probably a good supplement.  I think I first
noticed it with openssl, and immediately took a liking to it.

Mercurial is another example of a Python program with a thin subcommand
driver program.  It might be more or less suitable for theft as well.
(N.B. Mercurial is GPL v2, not v3.)  Mercurial's driver calls commands
as python functions from the mercurial library, and provides a nice
extension framework for enabling users or third parties to extend the
base functionality with additional python modules.  Not sure whether bzr
or trac-admin has something similar, but it may be another reason to
look at how hg does it.

-- 
 -D.    dgc at uchicago.edu    NSIT    University of Chicago

From srf at sanger.ac.uk  Tue Nov 11 10:52:07 2008
From: srf at sanger.ac.uk (Simon Fraser)
Date: Tue, 11 Nov 2008 09:52:07 +0000
Subject: [Mailman-Developers] Feature question: mailAlternateAddress
Message-ID: <1226397127.22643.21.camel@where.dynamic.sanger.ac.uk>


Hi folks,

Asking here because I saw the note to keep 3.0 discussion off -users.  

One of the features that would be nice for my site, and I'm sure others,
would be support for alternate addresses for users.  For example, users
here have the mailAlternateAddress field in LDAP populated with all
their firstname.lastname, initial.lastname and nickname email aliases,
and sometimes set their mail clients to identify as these, causing their
posts to be held or rejected.  It would be nice if mailman could either
query a specified location for alternate identities, or accept a
generated list of them for the current membership list.

It seems problematic to wedge a list of alternate addresses into
accept_these_nonmembers, as we would never be entirely sure if someone
had unsubscribed from the list but been administratively allowed to post
to it, and I'm sure it will confuse the list administrators who have to
keep both alternate addresses and non-members in the same text box. 

I see 3.0 has support for LDAP and other forms of back-end database, so
I was wondering if support for mailAlternateAddress would be part of
that new feature-set?  If not, may I request it? 

Thanks,
Simon.







-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

From barry at list.org  Tue Nov 11 20:45:00 2008
From: barry at list.org (Barry Warsaw)
Date: Tue, 11 Nov 2008 14:45:00 -0500
Subject: [Mailman-Developers] Feature question: mailAlternateAddress
In-Reply-To: <1226397127.22643.21.camel@where.dynamic.sanger.ac.uk>
References: <1226397127.22643.21.camel@where.dynamic.sanger.ac.uk>
Message-ID: <EB603475-74D3-4E4E-8DB5-A9B59B71A902@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 11, 2008, at 4:52 AM, Simon Fraser wrote:

> I see 3.0 has support for LDAP and other forms of back-end database,  
> so
> I was wondering if support for mailAlternateAddress would be part of
> that new feature-set?  If not, may I request it?

Actually, there's no LDAP backend implemented yet (or at least,  
integrated into the core).  I'd love to see someone tackle an LDAP  
backend as a plugin.

Having said that, MM3's model fully supports multiple email addresses  
per user.  The idea is that a mailing list should be able to accept a  
message from any of a person's linked addresses, but deliver only to  
those (usually one) that they want delivery on.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkkZ4LwACgkQ2YZpQepbvXFH2QCeM4CeEaJy5X16TvdfhXsnhaSA
fmMAoIyoLPFPG5ZMw8uLKACOgnG8U57k
=oTGY
-----END PGP SIGNATURE-----

From mark at msapiro.net  Mon Nov 24 16:35:02 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 24 Nov 2008 07:35:02 -0800
Subject: [Mailman-Developers] Unicode member addresses
Message-ID: <PC187020081124073502065695ccaf52@msapiro>

Last month a user encountered a problem with Decorate throwing a
TypeError because the interpolated footer was a unicode where it was
expected to be a string. See the thread at
<http://mail.python.org/pipermail/mailman-users/2008-October/063786.html>.

It turns out that he was interpolating user_address in the footer and
some of his member addresses are unicode causing the interpolated
footer to be unicode.

I note that since 2.1.3 (before my time) bin/list_members has had a
--unicode option to list unicode members. I can't see in current
Mailman how a member address can be unicode.

Are unicode addresses expected? Under what circumstances? Was this a
bug at one time?

My main concern is I worked up a patch
<http://mail.python.org/pipermail/mailman-users/attachments/20081028/76521ff4/attachment-0001.txt>
to fix the TypeError for the user with the problem, and I wonder if it
should be committed in the current code.

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


From danm at prime.gushi.org  Tue Nov 25 18:27:01 2008
From: danm at prime.gushi.org (Dan Mahoney, System Admin)
Date: Tue, 25 Nov 2008 12:27:01 -0500 (EST)
Subject: [Mailman-Developers] Duplicate Prevention
Message-ID: <alpine.BSF.2.00.0811251214130.8233@prime.gushi.org>

Hello all,

We've recently taken on mailman to handle many large, popular lists at my 
day job, and one strangely-missing feature is the inability to avoid 
duplicates when someone cc's a list's old alias and new alias (we also 
moved the lists to a subdomain, out from under our primary).

It's suggested in the FAQs that this could be done using procmail -- but 
I'd think it (could/should) be done in mailman itself.

The list-id header is ideal for this, and it SEEMS to be not more than a 
dozen lines of code to do the same sort of per-list "lockfile" that the 
procmail recipe does (plus add a variable to make it tunable in either the 
config file, or the web-ui).  Presumably lockfiles could expire after 7 
days.  Locks could also be an entry in a .pck database.

The question is (and the reason I ask this on a developer list rather than 
-users) -- is there anyone here who could provide a patch to add this 
functionality, or who is interested in taking on such a task for some sort 
of compensation/donation?

Please contact me off (or on) list if anyone's available.

Another great feature would be to have mailman "strip" multiple cc 
recipients.  I.e. if a message is sent:

to: list
cc: list-alias(*), another-list-alias(*)

-or-

to: person
cc: list, list-alias(*)

To have these (*) stripped (and prevent the need for this).  But that's 
more work, and right now the duplicates are a major regression from what 
we had before.

-Dan

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------


From skip at pobox.com  Wed Nov 26 23:57:05 2008
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 26 Nov 2008 16:57:05 -0600
Subject: [Mailman-Developers] SpamBayes for gate_news - who can test?
Message-ID: <18733.54337.724476.962584@montanaro-dyndns-org.local>

I pushed a Mailman branch to Launchpad which hooks the gate_news cron job
into SpamBayes.  On python.org we do a fair amount of early reject/filter
stuff at the SMTP step.  One of those things is to run incoming mail through
SpamBayes (if it doesn't get rejected by an earlier step).

Unfortunately, messages coming from the comp.lang.python newsgroup destined
for python-list at python.org just waltz right in as pretty as you please
without so much as a sniff from our spam-trapping tools.  It seemed to me
that the correct place to sniff is in gate_news, so I implemented the
necessary bits there to run incoming mail through SpamBayes and hold any
messages which look like they are or might be spam.

I am, however, neither a Mailman developer nor a Usenet user.  Setting up
the necessary scaffolding (Mailman instance, Usenet news connection, etc)
would be much harder for me than the work I've done so far stitching
SpamBayes into gate_news.  I thought about adding a --dry-run flag to
gate_news then testing my version out in parallel with the active version
already running on mail.python.org but it seems that would be difficult to
do as well since it's pretty hard to completely disconnect it from the list
data.

So I come, hat in hand, looking for some brave Mailman developer who is
willing to test out my modified version of gate_news.  You can grab the
latest version from Launchpad:

    bzr pull lp:~smontanaro/mailman/SpamBayes

There is an associated doc repo with a few instructions for setting up the
SpamBayes stuff:

    bzr pull lp:~smontanaro/mailman-administrivia/SpamBayes

A sample spambayes.ini file lives in the cron directory alongside gate_news.
It's basically what I would use on mail.python.org if I had the necessary
savvy to do this myself.

If you have any questions I'd be happy to answer them.  I can help you get
SpamBayes installed if you've never done that before.  (It's quite
straightforward if you're familiar with the normal Python setup.py thing or
use setuptools.)  I can also provide ham and spam training sets from
mail.python.org so you can construct a useful database for SpamBayes to
score messages against.  (You could run with an empty training database but
that would just cause all messages to score as "unsure" and be held as
possible spam.)

-- 
Skip Montanaro - skip at pobox.com - http://smontanaro.dyndns.org/

From mark at msapiro.net  Sat Nov 29 20:09:02 2008
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 29 Nov 2008 11:09:02 -0800
Subject: [Mailman-Developers] SpamBayes for gate_news - who can test?
In-Reply-To: <18733.54337.724476.962584@montanaro-dyndns-org.local>
Message-ID: <PC18702008112911090202037f25a8cd@msapiro>

skip at pobox.com wrote:
>
>So I come, hat in hand, looking for some brave Mailman developer who is
>willing to test out my modified version of gate_news.  You can grab the
>latest version from Launchpad:
>
>    bzr pull lp:~smontanaro/mailman/SpamBayes
>
>There is an associated doc repo with a few instructions for setting up the
>SpamBayes stuff:
>
>    bzr pull lp:~smontanaro/mailman-administrivia/SpamBayes
>
>A sample spambayes.ini file lives in the cron directory alongside gate_news.
>It's basically what I would use on mail.python.org if I had the necessary
>savvy to do this myself.
>
>If you have any questions I'd be happy to answer them.  I can help you get
>SpamBayes installed if you've never done that before.  (It's quite
>straightforward if you're familiar with the normal Python setup.py thing or
>use setuptools.)  I can also provide ham and spam training sets from
>mail.python.org so you can construct a useful database for SpamBayes to
>score messages against.  (You could run with an empty training database but
>that would just cause all messages to score as "unsure" and be held as
>possible spam.)


Skip,

I have installed SpamBayes and am running your modified gate_news. The
test list is <http://www.msapiro.net/mailman/listinfo/python> and it
is gating comp.lang.python from news.bu.edu.

Currently I have

#BAYESCUSTOMIZE=/usr/local/mailman/cron/spambayes.ini

in mailman's crontab. I.e. it is commented out so SpamBayes is not
actually being invoked.

I could use the training sets and some advice on how to proceed.
Presumably the files

lookup_ip_cache:/usr/local/spambayes-corpus/dnscache.pck
crack_image_cache:/usr/local/spambayes-corpus/imagecache.pck
persistent_storage_file:/etc/spambayes/wordprobs.cdb

referenced in your spambayes.ini get created when the training sets are
processed, but I'm unclear on that part of the process.

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


From barry at list.org  Sun Nov 30 00:57:04 2008
From: barry at list.org (Barry Warsaw)
Date: Sat, 29 Nov 2008 18:57:04 -0500
Subject: [Mailman-Developers] Python 2.6 compatibility
Message-ID: <26DB58D1-5A84-403D-B3E0-2B7C219C7608@list.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mark,

My branch to fix Python 2.6 compatibility for Mailman 2.1 is ready to  
be reviewed.  You should have gotten a "merge proposal" message in  
your inbox about it.  For reference the proposal is here:

https://code.launchpad.net/~barry/mailman/py26/+merge/1998

Basically, this is asking you to review the code changes, which you  
should be able to do by email or web.  Let me know if you have any  
questions about how to interact with this part of Launchpad.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkkx1tAACgkQ2YZpQepbvXEnYwCcDArq9XcU1Q/rj/DIeTZkMxfG
KpEAniKrwP6tSzVLejBXBxH2sLN+2edo
=WQBU
-----END PGP SIGNATURE-----