From jag at fsf.org  Wed Nov  2 00:12:09 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Tue, 01 Nov 2005 18:12:09 -0500
Subject: [Mailman-Developers] XMLRPC Patch
In-Reply-To: <1129335154.32365.56.camel@geddy.wooz.org>
References: <1129307125.6026.10.camel@localhost.localdomain>
	<1129335154.32365.56.camel@geddy.wooz.org>
Message-ID: <1130886730.30605.70.camel@localhost.localdomain>

Barry et al. --

Here is the unified patch that Joseph and I have agreed upon. Given it's
a little over 1000 lines total, if you'd like us to discuss some of the
design decisions that went into the patch, we'd be happy to. Both he and
I agree that the end result of our efforts is better than either of our
individual contributions -- hope you agree.

-jag

On Fri, 2005-10-14 at 20:12 -0400, Barry Warsaw wrote:
> On Fri, 2005-10-14 at 12:25, Joshua Ginsberg wrote:
> > I'm developing a patch to add an XMLRPC-based management interface to
> > Mailman. Would this be something that you would be interested in trying
> > to incorporate in the 2.1.x branch? Thanks!
> 
> Josh, thanks very much for this patch (and thanks for Joseph's previous
> patch).  Now that Tokio has whipped the trunk into shape, I think this
> is something that should be slated for Mailman 2.2 instead of 2.1.x.
> 
> Since there is more than one XMLRPC patch out there, I'd like for there
> to be some convergence before we apply the patches.  Would you and/or
> Joseph be able to review the patches and lead an effort to provide a
> single patch against the trunk?  It would also be great if you could add
> documentation to the existing texinfo files.
> 
> If anybody else is interested in XMLRPC interface to Mailman, this is
> the place to discuss it!  I may not pay strict attention to the thread
> until there's consensus in the community about what you'd like to see. 
> But I'll try to answer any questions that come up.
> 
> Cheers,
> -Barry
> 
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mailman-xmlrpc-20051101.patch
Type: text/x-patch
Size: 41385 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051101/d3f92355/mailman-xmlrpc-20051101-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051101/d3f92355/attachment-0001.pgp

From fil at rezo.net  Thu Nov  3 01:59:02 2005
From: fil at rezo.net (Fil)
Date: Thu, 3 Nov 2005 01:59:02 +0100
Subject: [Mailman-Developers] Another take at MysqlMemberAdaptor + a
	migration utility
Message-ID: <20051103005902.GX7918@rezo.net>


Dear mailman-developers,


here are a few patches and contributions for our dear Mailman, that I made
in order to have it "scale" a bit more. I had hit the usability limit (on my
server) of the Web UI, on a list with a bit more than 100 000 subscribers.
(Its config.pck file had grown to 25Mb, and simply to load the list costs
about 30 seconds.)


Summary
-------

* a comprehensive rewrite of MysqlMemberAdaptor.py
* a revision of the /admin/members/ page
* a migration utility
* a trick to easily test on your production server w/o too many risks


MysqlMemberAdaptor.py
---------------------

My first step was to try switching to MySQL for backend. I started with Kev
Green's MysqlMemberAdaptor.py (that has been discussed recently on this
list).

I had decided, for some reason, to use its 'flat' mode of operation, but
realised, first, that it was not working on my site, and then that this code
could not be maintained as it was, and had to be 'reunited'. (I also wanted
the 'flat' table to be called something else than `mailman_mysql`, which I
can't type fast enough :-)

Anyway, it has now shrunk a lot in size, as many functions have been
simplified. And it has grown a little set of features:

* in mm_cfg.py you can now optionally set:
    # in 'flat' mode, the name of the table
    MYSQL_MEMBER_TABLE_NAME = 'mailman'
    # auto-creating the table becomes an option
    MYSQL_MEMBER_CREATE_TABLE = True
    # the 'verbose' option now logs all mysql queries to logs/mysql.log
    MYSQL_MEMBER_DB_VERBOSE = True

* two new methods have been introduced, in order to get around bottlenecks
  in speed in the admin/members/ page

    def getMembersMatching(self, regexp):
        """Get all the members who match regexp"""
    def getMembersCount(self, reason):
        """Get the count of all members (reason=Y for digest, N for regular)"""

getMembersMatching(regexp) is for the "search" feature on the members page.
Instead of reading into memory the full list of subscribers, then applying
the regexp to each one of them, we ask MySQL to carry out the search for us,
and process the small set of results.

I tried to test every method with several combinations of accents and weird
chars (like '%') in the names and email addresses, and it seems fine for
iso-8859-1, but will certainly fail (or rather, give weird results) for
other charsets. There's room for improvement here.

I *think* that the file is almost ready for being a generic
DBAPIMemberAdaptor, but I can't prove it as I have absolutely no knowledge
of SQLite or postgres. But there is nothing specific to MySQL in it, except
for the quotes escaping function. This could be an important new feature.



Mailman/Cgi/admin.py
--------------------

This file had already become **really slow** with OldStyleMemberships, for
several reasons; switching to MySQLMemberAdaptor made things even worse:
most methods were called once per member, which in the (older)
MysqlMemberAdaptor translated into hundreds of thousands of queries on the
DB. I rewrote the parts that were slow, especially the "buckets" thing. The
result is visually a bit different (more condensed), but retains about the
same functionality. The speed is dramatically better, the time to render the
members page for my big list going down from... 4 minutes (!) to 30 seconds
(in OldStyle...), and to 12 seconds with my version of MysqlMemberAdaptor.

While I was at it, I also removed the unusable/unused buttons and menus in
this members page: no more language menu when there's only one language to
choose, and no more digest/plain button when the list is not digestable.


bin/migrate_to_mysql
--------------------

This new CLI utility copies all the members of a mailing list to a new
MemberAdaptor. It is written in a purely generic manner: it opens two
instances of the list, one with each MemberAdaptor, and reads all data from
the "source" memberadaptor, writing it back with the "dest" memberadaptor.

Its name does not reflect its genericity, because you have to edit it if you
want to change the source and dest MemberAdaptors, e.g. to go back to
OldStyleMemberships. This could be improved.

Also, this utility does not remove the members from the older memberadaptor;
to do so you have to carefully check that you have set the list to the older
adapator, then use
        bin/remove_members --all -n -N listname
(In my example, after using migrate..., the config.pck file is left
untouched and still weighs 25Mb; after using remove_members it's back to a
few kb)



Small patches
-------------

In Mailman/MemberAdaptor.py I have added the wo new methods
@@ -63,6 +63,14 @@ class MemberAdaptor:
+    def getMembersMatching(self, regexp):
+        """Get all the members who match regexp"""
+        raise NotImplementedError
+    
+    def getMembersCount(self, reason):
+        """Get the count of all members (reason=Y for digest, N for
regular)"""
+        raise NotImplementedError

I'm not sure if this is the way to go -- i.e. admin.py can do without those
methods being implemented, so it's more a design decision to be made by
Barry
and al.


For some reason, I was biten by a weird bug that could only be solved by
adding in Mailman/MailList.py the following line:
@@ -385,6 +385,7 @@ class MailList(HTMLFormatter, Deliverer,
+        self.nonmember_rejection_notice = ''
this might be due to the fact that I'm based on 2.1.6b and not the final
version, or that I made an error during my hacking nights :) Anyway it might
be worth a check.



A trick
-------

The best (and only?) way to test this on a production server is to use the
extend.py mechanism. In your test list directory (~mailman/lists/test/),
just drop this file named extend.py:

"""
# import the MySQL stuff
from Mailman.MysqlMemberships import MysqlMemberships

# override the default for this list
def extend(mlist):
    mlist._memberadaptor = MysqlMemberships(mlist)
"""

It's also immensely useful if you want to switch back and forth, for
instance to use the migrate_to_mysql script, check the results, then go back
to oldstyle to remove the oldstyle subscriptions.



Finally
-------

I'd love to see this integrated in Mailman's standard distribution. I think
Barry or Tokio must check all the changes, and discuss which ones might not
be acceptable, and resolve copyright issues. I don't know why Kev Green's
patch was left as is on SourceForge for a long while, as it's a common
requirement to have a MySQL backend for Mailman. I hope this work will
contribute to this issue. 

There was also a discussion lately on the list, about Kev's
MysqlMemberAdaptor and bounces handling. The issues that were raised might
continue (or not) to apply to my version of this Adaptor, and might call for
a few more changes. Please read it, try it, and tell me.

As everyone knows the SF site is not really easy to use for contributors as
well as for readers; so I'm temporarily uploading the files on my SVN
server; if someone wants to join and contribute I'll be happy to open write
access.

Everything is at:
    svn co svn://trac.rezo.net/rezo/Mailman/
and the web interface:
    http://trac.rezo.net/trac/rezo/browser/Mailman/

Enjoy!

-- Fil


From tkikuchi at is.kochi-u.ac.jp  Fri Nov  4 07:45:45 2005
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri, 04 Nov 2005 15:45:45 +0900
Subject: [Mailman-Developers] Sibling list
Message-ID: <436B0399.7010109@is.kochi-u.ac.jp>

Hi Developers,

I've just uploaded a new patch to enable 'sibling list' feature in
mailman non-digest delivery.  I'd like to get feedback from develpers on
this feature, particularly on the naming ... sibling.  ;-)

https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1347962&group_id=103

Here are excerpts from the patch tracker.

- Sibling lists are other mailing lists on this site
whose members are excluded from regular delivery if
those list addresses appear in To: or Cc: header.

- The list addresses should be witten in full mail
address format (e.g. mailman at example.com).  Do not
specify the list address mutually in the sibling list
configuration page or those doubled members won't get
message.

TBD:

- Is the terminology 'sibling' appropriate?

- Need more comments in the processing code
(CalcRecips.py).

-- 
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/



From kyrian-list at ore.org  Sat Nov  5 01:05:30 2005
From: kyrian-list at ore.org (Kyrian (list))
Date: Sat, 05 Nov 2005 00:05:30 +0000
Subject: [Mailman-Developers] Another take at MysqlMemberAdaptor + a
	migration utility
In-Reply-To: <mailman.43.1131015610.19170.mailman-developers@python.org>
References: <mailman.43.1131015610.19170.mailman-developers@python.org>
Message-ID: <436BF74A.7080604@ore.org>

Folks,

Well, after a gargantuan cull of my inbox, it's down from 9,000+ to more
like 9, and as mentioned, I would work on MysqlMemberships.py at that point.

I have, I believe incorporated everyone's non-destructive patches and
comments so far into the distribution (I have erred on the side of
caution with incorporating stuff in, so please don't take offence if I
have not included your contributions), crediting where appropriate, and
pending some testing (as I now have a development environment built in
which to do so) before I send a sourceforge announcement, etc. If anyone
else feels like testing it, I have fairly silently uploaded the latest
version (1.69) of it to the oRe Net Opensource pages, although that has
only been tested to the point of a python syntax check pass.

Considerable thanks go to Adrian Wells for his repeated contributions,
Fil for his large-scale suggestions, and everyone else, I didn't think
for an instant that my very first piece of Python coding would generate
such interest.

In any case, before I go any further with regards to development, since
Mailman appears to be undergoing internal changes that may cause future
issues, and I already have a large TODO list, I'd like the input of the
development team and others on both the progress of Mailman and future
plans, and its relation to my (slightly amended) TODO list for the MySQL
Member Adaptor stands as follows...

Firstly, those items in it which I need help with, or to discuss with folks:

* Figure out how to make passwords work. Currently using "!" as the default
  password, so that things don't barf, but that is probably not the right
  way to go about it. What is the Mailman equivalent of "No password", etc?

* Ensure that what the patch is doing ties up with Barry's input wrt.
what it
  should be doing.

* Check up on whether Adrian Wells is correct with regards to the user flags
  ('hide', 'noemail', 'ack', 'not_metoo', and 'plain'), and hence columns
  in the adaptor's database tables are fully deprecated from Mailman, in
  favour of the user_options flag/column if so, make changes to the adaptor
  accordingly.

* Adrian Wells Bouncer.py patch. Discuss with Mailman team. Is it the
right way
  to go. Moving this patch deeper into the guts of mailman seems to be a
little
  anathema to the whole idea of Member Adaptors in the first place, not to
  mention that it scares me a little ;-)

* Await responses to fil (at) rezo.net's ideas. I would not mind at all
incorporating a migration ultility into the
   MysqlMemberships.py tarball I'm sending out, and I certainly see the
merit of the other suggestions, but some of it
   strikes me as a little premature, or perhaps overkill given various
factors.

And of course the obvious ones, which I shouldn't have much of a problem
with.

* PRIORITY: Database escaping, need to work out how to to this with the
Python
  MYSQLdb module, after all it would only take a well-crafted email to raise
  merry hell as things are at the moment.

* MYSQL_MEMBER_DB_WHERE so you can specify a "WHERE x = y" on all the
queries
  in the database. ???

* MYSQL_MEMBER_DB_SOCKET, to support a local socket connection to the MySQL
  server. This should be easy using the "unix_socket" attribute of MySQLdb's
  connect call.

I guess if anyone would care to add anything to the above or make
suggestions that would be cool, but please try and keep them short, I
don't want 9,000 emails in my inbox again any time in the next six
months or so, please.

K.

From stephen at xemacs.org  Sat Nov  5 07:53:58 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 05 Nov 2005 15:53:58 +0900
Subject: [Mailman-Developers] Sibling list
In-Reply-To: <436B0399.7010109@is.kochi-u.ac.jp> (Tokio Kikuchi's message of
	"Fri, 04 Nov 2005 15:45:45 +0900")
References: <436B0399.7010109@is.kochi-u.ac.jp>
Message-ID: <87mzkj60vt.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Tokio" == Tokio Kikuchi <tkikuchi at is.kochi-u.ac.jp> writes:

    Tokio> - Is the terminology 'sibling' appropriate?

I hesistate to give it a +1 because I know I think differently from
most people, but FWIW I *did* guess what it does from that name.



-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From fil at rezo.net  Sat Nov  5 11:43:54 2005
From: fil at rezo.net (Fil)
Date: Sat, 5 Nov 2005 11:43:54 +0100
Subject: [Mailman-Developers] Another take at MysqlMemberAdaptor + a
	migration utility
In-Reply-To: <436BF74A.7080604@ore.org>
References: <mailman.43.1131015610.19170.mailman-developers@python.org>
	<436BF74A.7080604@ore.org>
Message-ID: <20051105104354.GE14531@rezo.net>

> else feels like testing it, I have fairly silently uploaded the latest
> version (1.69) of it to the oRe Net Opensource pages, although that has
> only been tested to the point of a python syntax check pass.

Thanks! I have upgraded my version (which is still very different from
yours, as you notice), with those patches @
http://trac.rezo.net/trac/rezo/changeset/17


> * Figure out how to make passwords work. Currently using "!" as the default
>   password, so that things don't barf, but that is probably not the right
>   way to go about it. What is the Mailman equivalent of "No password", etc?

I guess you have to add a new random password. That is, something like
        self.setMemberPassword(user, Utils.MakeRandomPassword())


> * PRIORITY: Database escaping, need to work out how to to this with the
>   Python MYSQLdb module, after all it would only take a well-crafted email
>   to raise merry hell as things are at the moment.

I'm not sure what your're referring to. The MemberAdaptor is only called
when the list exists, isn't it? So the only way to hack into the database
would be to have weird chars in either the address (which is properly
escaped, from what I saw), or the bi_cookie (which isn't, but I guess
Mailman is crafting this one, isn't it?)

> * MYSQL_MEMBER_DB_WHERE so you can specify a "WHERE x = y" on all the
>   queries in the database. ???

Like in "WHERE home_made_delivery_status = 'enabled'"? It could be useful in
some situations, but probably on a list-per-list basis, not a global setting
like this (well of course you can always set MYSQL_MEMBER_DB_WHERE from
extend.py)

There was another suggestion recently (on irc) to allow for lists of
subscribers taken on the fly from a SQL query on any table; but then no
subscriptions, no bounce processing and so on... This would add a lot of
complexity.

-- Fil


From lists05 at equinephotoart.com  Sat Nov  5 16:01:57 2005
From: lists05 at equinephotoart.com (JC Dill)
Date: Sat, 05 Nov 2005 07:01:57 -0800
Subject: [Mailman-Developers] Sibling list
In-Reply-To: <87mzkj60vt.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <436B0399.7010109@is.kochi-u.ac.jp>
	<87mzkj60vt.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <436CC965.9020907@equinephotoart.com>

Stephen J. Turnbull wrote:
>>>>>>"Tokio" == Tokio Kikuchi <tkikuchi at is.kochi-u.ac.jp> writes:
> 
> 
>     Tokio> - Is the terminology 'sibling' appropriate?
> 
> I hesistate to give it a +1 because I know I think differently from
> most people, but FWIW I *did* guess what it does from that name.

Ditto.

jc


From msapiro at value.net  Sat Nov  5 18:49:22 2005
From: msapiro at value.net (Mark Sapiro)
Date: Sat, 5 Nov 2005 09:49:22 -0800
Subject: [Mailman-Developers] Scrubber mungs Quoted Printable
Message-ID: <PC17402005110509492200467b8e29e4@msapiro>

A couple of posts on the mailman-users list
(<http://mail.python.org/pipermail/mailman-users/2005-September/046400.html>
and
<http://mail.python.org/pipermail/mailman-users/2005-October/047367.html>)
have pointed out that there is a problem with Scrubber.py.

The basic issue is that under some circumstances, the scrubbed message
is quoted-printable encoded, but Scrubber unconditionally adds a
'Content-Transfer-Encoding: 8bit' header resulting in garbled content
when the message is viewed.

The addition of the header was a small part of the patch at
<http://sourceforge.net/tracker/index.php?func=detail&aid=655214&group_id=103&atid=300103>
and the associated comment is

  - Fixes a bug in the scrubber, where a
    content-transfer-encoding might have survived
    flattening of the message.

I think the fix for the current problem is the following patch -

--- mailman-2.1.6/Mailman/Handlers/Scrubber.py
+++ mailman-mas/Mailman/Handlers/Scrubber.py
@@ -376,9 +376,8 @@
         # Now join the text and set the payload
         sep = _('-------------- next part --------------\n')
         del msg['content-type']
-        msg.set_payload(sep.join(text), charset)
         del msg['content-transfer-encoding']
-        msg.add_header('Content-Transfer-Encoding', '8bit')
+        msg.set_payload(sep.join(text), charset)
     return msg

I have checked this with Tokio, and he agrees, but I don't have any
message that would have triggered the original bug to test against nor
do I know what the characteristics of such a message would be or if
subsequent changes in the Python email library have taken care of it.

Thus, before committing this patch, I'd like to see it get a bit more
exposure/testing and/or get feedback from someone who knows something
about the original bug.

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


From tkikuchi at is.kochi-u.ac.jp  Sun Nov  6 13:34:32 2005
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun, 06 Nov 2005 21:34:32 +0900
Subject: [Mailman-Developers] Sibling list
In-Reply-To: <436CC965.9020907@equinephotoart.com>
References: <436B0399.7010109@is.kochi-u.ac.jp>	<87mzkj60vt.fsf@tleepslib.sk.tsukuba.ac.jp>
	<436CC965.9020907@equinephotoart.com>
Message-ID: <436DF858.6090205@is.kochi-u.ac.jp>

JC Dill wrote:

> Stephen J. Turnbull wrote:
> 
>>>>>>>"Tokio" == Tokio Kikuchi <tkikuchi at is.kochi-u.ac.jp> writes:
>>
>>
>>    Tokio> - Is the terminology 'sibling' appropriate?
>>
>>I hesistate to give it a +1 because I know I think differently from
>>most people, but FWIW I *did* guess what it does from that name.
> 
> 
> Ditto.
> 

Just to add a note.  I picked up this word from Squid Web Proxy server's 
configuration.
http://squid.visolve.com/squid/squid24s1/glossary.htm#sibling

-- 
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/


From adrian at whatifnet.com  Mon Nov  7 16:04:33 2005
From: adrian at whatifnet.com (Adrian Wells)
Date: Mon, 07 Nov 2005 11:04:33 -0400
Subject: [Mailman-Developers] Another take at MysqlMemberAdaptor + a
	migration util
In-Reply-To: <436BF74A.7080604@ore.org>
References: <mailman.43.1131015610.19170.mailman-developers@python.org> <,>
	<436BF74A.7080604@ore.org>
Message-ID: <fc.001d0211006f76713b9aca0098df82fb.6f78f0@whatifnet.com>

"Kyrian (list)" <kyrian-list at ore.org> on Friday, November 04, 2005 at 7:05
PM wrote:
>If anyone else feels like testing it, I have fairly silently uploaded the
>latest
>version (1.69) of it to the oRe Net Opensource pages, although that has
>only been tested to the point of a python syntax check pass.


Thank you for releasing this version.  There is a change in this version
which caught my attention but I do not understand - that is the size of
the varchar address column when creating table for the 'wide' format:

@@ -118,7 +118,7 @@
 ) TYPE=MyISAM""" )
                else:
                        self.cursor.execute ("""CREATE TABLE IF NOT EXISTS
%s (
-  address varchar(255) NOT NULL,
+  address varchar(100) NOT NULL,
   hide enum('Y','N') NOT NULL default 'N',
   nomail enum('Y','N') NOT NULL default 'N',
   ack enum('Y','N') NOT NULL default 'Y',


I do not believe that this column length should be reduced to 100. 
Although it appears this might have been a typo when reducing the size of
the varchar listname column from 255 to 100 for the 'flat' format.


>* Figure out how to make passwords work. Currently using "!" as the
>default
>  password, so that things don't barf, but that is probably not the right
>  way to go about it. What is the Mailman equivalent of "No password",
>etc?


As it is now, passwords seem to work... at least one can login via the web
browser based interface using a member password to change member options
(including successfully changing a member password).  Is this comment
specific to "No password" conditions?  If that is the case, then I agree
with Fli's suggestion (which I understand as simply assigning a random
password instead of "!" as the default password).  A member can receive
this randomly generated password if it is needed.

>
>* Ensure that what the patch is doing ties up with Barry's input wrt.
>  what it should be doing.


Is there more background on this?  It seems like something was discussed
off-list, perhaps?  Or I simply missed a discussion.


>* Check up on whether Adrian Wells is correct with regards to the user
>flags
>  ('hide', 'noemail', 'ack', 'not_metoo', and 'plain'), and hence columns
>  in the adaptor's database tables are fully deprecated from Mailman, in
>  favour of the user_options flag/column if so, make changes to the
>adaptor
>  accordingly.


Minor correction:  'noemail' should be 'nomail'.  These findings were
originally based on the fact that version 1.61 of this adaptor did not
insert or update any of these columns.  Additionally, some time was spent
determining how the 'user_options' column stored various settings by
making changes and observing results (not the most efficient method).  The
following is a list of how things appear to break down:  'user_options'
column is a sum of the following options:

NO OPTIONS selected = 0
not metoo = 2
ack = 4
plain = 8
hide = 16
mod = 128
no dupes = 256

>
>* Adrian Wells Bouncer.py patch. Discuss with Mailman team. Is it the
>right way
>  to go. Moving this patch deeper into the guts of mailman seems to be a
>little
>  anathema to the whole idea of Member Adaptors in the first place, not to
>  mention that it scares me a little ;-)


To be more accurate, Mark Sapiro helped to refine this patch, and he
provided valuable insight and suggestions about this: 
<http://mail.python.org/pipermail/mailman-developers/2005-October/018271.html>.

Barry Warsaw also recommend to "pickle the BounceInfo object on the way
into the database, and unpickle it on the way out": 
<http://mail.python.org/pipermail/mailman-developers/2003-November/016036.html>.
>
>
>* PRIORITY: Database escaping, need to work out how to to this with the
>Python
>  MYSQLdb module, after all it would only take a well-crafted email to
>raise
>  merry hell as things are at the moment.


Not that I'm looking for a proof of concept here, but I'm interested in
knowing how this is an issue.  Like Fil, I don't see an issue but I may be
overlooking something obvious.  Maybe this would be best
answered/discussed after the issue was resolved.

-Adrian


From jag at fsf.org  Tue Nov  8 22:23:55 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Tue, 08 Nov 2005 16:23:55 -0500
Subject: [Mailman-Developers] XMLRPC Patch
In-Reply-To: <1130886730.30605.70.camel@localhost.localdomain>
References: <1129307125.6026.10.camel@localhost.localdomain>
	<1129335154.32365.56.camel@geddy.wooz.org>
	<1130886730.30605.70.camel@localhost.localdomain>
Message-ID: <1131485036.7487.25.camel@localhost.localdomain>

Barry et al. --

Does anybody have any feedback on this patch? Is it something that can
be committed? Thanks!

-jag

On Tue, 2005-11-01 at 18:12 -0500, Joshua Ginsberg wrote:
> Barry et al. --
> 
> Here is the unified patch that Joseph and I have agreed upon. Given it's
> a little over 1000 lines total, if you'd like us to discuss some of the
> design decisions that went into the patch, we'd be happy to. Both he and
> I agree that the end result of our efforts is better than either of our
> individual contributions -- hope you agree.
> 
> -jag
> 
> On Fri, 2005-10-14 at 20:12 -0400, Barry Warsaw wrote:
> > On Fri, 2005-10-14 at 12:25, Joshua Ginsberg wrote:
> > > I'm developing a patch to add an XMLRPC-based management interface to
> > > Mailman. Would this be something that you would be interested in trying
> > > to incorporate in the 2.1.x branch? Thanks!
> > 
> > Josh, thanks very much for this patch (and thanks for Joseph's previous
> > patch).  Now that Tokio has whipped the trunk into shape, I think this
> > is something that should be slated for Mailman 2.2 instead of 2.1.x.
> > 
> > Since there is more than one XMLRPC patch out there, I'd like for there
> > to be some convergence before we apply the patches.  Would you and/or
> > Joseph be able to review the patches and lead an effort to provide a
> > single patch against the trunk?  It would also be great if you could add
> > documentation to the existing texinfo files.
> > 
> > If anybody else is interested in XMLRPC interface to Mailman, this is
> > the place to discuss it!  I may not pay strict attention to the thread
> > until there's consensus in the community about what you'd like to see. 
> > But I'll try to answer any questions that come up.
> > 
> > Cheers,
> > -Barry
> > 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jag%40fsf.org
> 
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051108/a6b311fd/attachment.pgp

From barry at python.org  Tue Nov  8 23:24:50 2005
From: barry at python.org (Barry Warsaw)
Date: Tue, 08 Nov 2005 17:24:50 -0500
Subject: [Mailman-Developers] XMLRPC Patch
In-Reply-To: <1131485036.7487.25.camel@localhost.localdomain>
References: <1129307125.6026.10.camel@localhost.localdomain>
	<1129335154.32365.56.camel@geddy.wooz.org>
	<1130886730.30605.70.camel@localhost.localdomain>
	<1131485036.7487.25.camel@localhost.localdomain>
Message-ID: <1131488690.20278.23.camel@geddy.wooz.org>

On Tue, 2005-11-08 at 16:23, Joshua Ginsberg wrote:

> Does anybody have any feedback on this patch? Is it something that can
> be committed? Thanks!

I'd really like to look at this in more detail, but because of work
constraints, I won't be able to spend any time on it until later in this
month.  Thanksgiving is Mailman time! :)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051108/ca76dad7/attachment.pgp

From jag at fsf.org  Wed Nov  9 00:04:27 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Tue, 08 Nov 2005 18:04:27 -0500
Subject: [Mailman-Developers] XMLRPC Patch
In-Reply-To: <1131488690.20278.23.camel@geddy.wooz.org>
References: <1129307125.6026.10.camel@localhost.localdomain>
	<1129335154.32365.56.camel@geddy.wooz.org>
	<1130886730.30605.70.camel@localhost.localdomain>
	<1131485036.7487.25.camel@localhost.localdomain>
	<1131488690.20278.23.camel@geddy.wooz.org>
Message-ID: <1131491067.27773.2.camel@localhost.localdomain>

Of course -- thanks, BAW. I look forward to hearing your thoughts.

-jag

On Tue, 2005-11-08 at 17:24 -0500, Barry Warsaw wrote:
> On Tue, 2005-11-08 at 16:23, Joshua Ginsberg wrote:
> 
> > Does anybody have any feedback on this patch? Is it something that can
> > be committed? Thanks!
> 
> I'd really like to look at this in more detail, but because of work
> constraints, I won't be able to spend any time on it until later in this
> month.  Thanksgiving is Mailman time! :)
> 
> -Barry
> 
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051108/79c99c83/attachment.pgp

From tkikuchi at is.kochi-u.ac.jp  Wed Nov  9 00:43:33 2005
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Wed, 09 Nov 2005 08:43:33 +0900
Subject: [Mailman-Developers] XMLRPC Patch
In-Reply-To: <1131485036.7487.25.camel@localhost.localdomain>
References: <1129307125.6026.10.camel@localhost.localdomain>	<1129335154.32365.56.camel@geddy.wooz.org>	<1130886730.30605.70.camel@localhost.localdomain>
	<1131485036.7487.25.camel@localhost.localdomain>
Message-ID: <43713825.2080702@is.kochi-u.ac.jp>

Hi,

Joshua Ginsberg wrote:

> Barry et al. --
> 
> Does anybody have any feedback on this patch? Is it something that can
> be committed? Thanks!

Will you please upload the patch to the SF tracker?  Then, much more
people can test the XMLRPC feature before commiting in the CVS.  As the
past discussions on this list suggest, there will be no more new feature
in 2.1.x series but bug fixes, This should be integrated in 2.2 or 3.0.

BTW, I had Sun RPC cracked, then vulnerable Windows RPC.  So, I'm rather
skeptical about RPC things.  Yeah, I know it's different but ... :-(

-- 
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/


From jag at fsf.org  Wed Nov  9 16:48:11 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Wed, 09 Nov 2005 10:48:11 -0500
Subject: [Mailman-Developers] XMLRPC Patch
In-Reply-To: <43713825.2080702@is.kochi-u.ac.jp>
References: <1129307125.6026.10.camel@localhost.localdomain>
	<1129335154.32365.56.camel@geddy.wooz.org>
	<1130886730.30605.70.camel@localhost.localdomain>
	<1131485036.7487.25.camel@localhost.localdomain>
	<43713825.2080702@is.kochi-u.ac.jp>
Message-ID: <1131551291.27773.4.camel@localhost.localdomain>

Gladly -- doing that now.

-jag

On Wed, 2005-11-09 at 08:43 +0900, Tokio Kikuchi wrote:
> Hi,
> 
> Joshua Ginsberg wrote:
> 
> > Barry et al. --
> > 
> > Does anybody have any feedback on this patch? Is it something that can
> > be committed? Thanks!
> 
> Will you please upload the patch to the SF tracker?  Then, much more
> people can test the XMLRPC feature before commiting in the CVS.  As the
> past discussions on this list suggest, there will be no more new feature
> in 2.1.x series but bug fixes, This should be integrated in 2.2 or 3.0.
> 
> BTW, I had Sun RPC cracked, then vulnerable Windows RPC.  So, I'm rather
> skeptical about RPC things.  Yeah, I know it's different but ... :-(
> 
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051109/ec2588e5/attachment.pgp

From adrian at whatifnet.com  Fri Nov 11 19:11:12 2005
From: adrian at whatifnet.com (Adrian Wells)
Date: Fri, 11 Nov 2005 14:11:12 -0400
Subject: [Mailman-Developers] Bouncer.py syslog differences
Message-ID: <fc.001d0211006fc303001d0211006fc303.6fc6a7@whatifnet.com>

Hello.  The following is portion of an exchange of ideas between Mark
Sapiro and myself (initial comments) which occurred not too long ago on
this list:

>>>>>

>>>>As a minor side note, I noticed the bounce log receives two different
>>>>formatted messages for the first bounce and subsequent bounces.  An
>>>>example:
>>>>...
>>>>Oct 25 10:50:51 2005 (2687) samplelist: falseaddresstest at somedomain.net
>>>>bounce score: 1.0
>>>>Oct 25 11:06:54 2005 (2687) falseaddresstest at somedomain.net: samplelist
>>>>current bounce score: 2.0
>>>>...
>>>>This is not a major issue but it is inconsistent and it not clear why
>it
>>>>should be this way.  Is there reason is should be different?
>>>
>>>
>>>I don't think so. All the other log messages from Bouncer are "list:
>>>member". I don't see any reason why this one shouldn't also be that
>>>way.
>>
>>
>>OK.  Should this be entered as a bug on SF?
>
>
Yes, I think so, but I'd be inclined to wait a bit and see if there are
more comments from the list.


>>>>>


It does not appear that more comments have been made on this issue.  I am
trying to work with the output of the Mailman logs (Brad Knowles has a
great script
<http://sourceforge.net/tracker/index.php?func=detail&aid=1123383&group_id=103&atid=300103>
for this but, it would be preferred to store more information in a
database for reporting- not sure the best way to do this yet) and this
minor difference is slightly annoying.  Additionally, as Mark noted, no
reason has been given to explain difference from other "current bounce
score" messages.  Here is a patch that should correct this difference:


--- Bouncer.py.10.25.2005.original      2005-10-25 12:21:57.000000000 -0400
+++ Bouncer.py.log.patch        2005-11-11 11:27:08.000000000 -0500
@@ -145,7 +145,7 @@
                 info.score += weight
                 info.date = day
                 syslog('bounce', '%s: %s current bounce score: %s',
-                       member, self.internal_name(), info.score)
+                       self.internal_name(), member, info.score)
             # Continue to the check phase below
         #
         # Now that we've adjusted the bounce score for this bounce, let's


Unless there is a case against filing this as a bug on SourceForge, I'm
willing to file one within the next  couple weeks.

-Adrian


From tealev at yahoo.com  Fri Nov 11 18:09:55 2005
From: tealev at yahoo.com (Levente Torok)
Date: Fri, 11 Nov 2005 09:09:55 -0800 (PST)
Subject: [Mailman-Developers] Listserv Migration Toolkit
Message-ID: <20051111170955.73398.qmail@web60319.mail.yahoo.com>

Dead Developers,

Currently we have come through a project that 
was aiming to convert 100 of lists with about 12000
users from Listserv to Mailman.
And we succeeded.
It was and extreme burden in the near past.

The reason of my posting is that.
Up to know, I have no information if anyone has
done this before automatically.
We have made a package that helps to achieve this.
I hope it serves many users purpose in the future.
Since it is not a big file, I post it the list 
(published under GPL3)
We will set up a site for this purpose in the near
future
but we also want to receive some feedback 
from you guys.

Best regards,

Levente Torok


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ls_mm_migration_toolkit.tar.gz
Type: application/gzip
Size: 22007 bytes
Desc: 3382784324-ls_mm_migration_toolkit.tar.gz
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051111/78efec7d/ls_mm_migration_toolkit.tar-0001.bin

From tealev at yahoo.com  Mon Nov 14 11:16:19 2005
From: tealev at yahoo.com (Levente Torok)
Date: Mon, 14 Nov 2005 02:16:19 -0800 (PST)
Subject: [Mailman-Developers] Mailman-Developers Digest, Vol 199,
	Issue 11
In-Reply-To: <mailman.1417.1131736690.18700.mailman-developers@python.org>
Message-ID: <20051114101619.72000.qmail@web60314.mail.yahoo.com>

Hi All,

I have put the Listserv-to-Mailman migration toolkit
in on the web.
It can be downloaded from:

http://www.sztaki.hu/~lev/miscellaneous.html

or 

http://www.sztaki.hu/~lev/ls_mm/ls_mm_migration_toolkit-0.1.tar.gz

Best regards,

Levente Torok


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

From adrian at whatifnet.com  Wed Nov 16 18:12:30 2005
From: adrian at whatifnet.com (Adrian Wells)
Date: Wed, 16 Nov 2005 13:12:30 -0400
Subject: [Mailman-Developers] PHP Wrappers?
Message-ID: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>

Hello.  How might one configure Mailman (version 2.1.6) list settings
using PHP scripts?  The goal is to configure Mailman list settings such as
domain name of list, non-digest footer, set welcome/goodbye messages, etc.
 An approach that comes to mind is to use bin/config_list.  This would
require writing/reading files and using bin/config_list to process them. 
Is there another recommended or preferred way to accomplish this?

There was a post about "PHP Wrappers" which suggested, "...just use a
setuid mailman wrapper script that does caller-checking to see if it's
called correctly, by the right user, and with 'safe' values"
<http://mail.python.org/pipermail/mailman-developers/2001-March/008421.html>.
 This was recommended over simply adding the www user to the mailman group.

I do not completely understand how one creates a setuid mailman wrapper
script.  Is this a matter of creating something similar to mail-wrapper.c?

If someone has written a wrapper script or has some good resources further
explaining this to share and is willing to do so, I would appreciate it. 
Thank you,
-Adrian


From slave at codegrunt.com  Wed Nov 16 20:01:01 2005
From: slave at codegrunt.com (slave@codegrunt.com)
Date: Wed, 16 Nov 2005 11:01:01 -0800
Subject: [Mailman-Developers] PHP Wrappers?
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
Message-ID: <437b81ed-f30b@Islandnet.com>

> Hello.  How might one configure Mailman (version 2.1.6) list settings
> using PHP scripts?  

The quick answer would be to not bother and wait until version 3 of Mailman which will use a MySQL backend and instead manipulate that directly (if I have been reading past discussions correctly).  Calling the existing Python code via PHP exec() calls is plain out yuck.

=)

Cheers

http://industrial.org




From Dale at Newfield.org  Wed Nov 16 20:40:16 2005
From: Dale at Newfield.org (Dale Newfield)
Date: Wed, 16 Nov 2005 14:40:16 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437b81ed-f30b@Islandnet.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com>
Message-ID: <437B8B20.9090708@Newfield.org>

slave at codegrunt.com wrote:
 > The quick answer would be to not bother and wait until version 3 of
 > Mailman

That would be the easy answer, but since there is currently no ETA (as 
far as I know) for MM3, that certainly wouldn't be the quick answer.

-Dale Newfield
  Dale at Newfield.org

From jag at fsf.org  Wed Nov 16 21:01:57 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Wed, 16 Nov 2005 15:01:57 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
Message-ID: <1132171318.15630.22.camel@localhost.localdomain>

This would be something that could take advantage of the XMLRPC patch
under review:

http://www.lnk4.com/?437B8F9B45D7

See also:

http://www.lnk4.com/?437B900345F7
http://www.lnk4.com/?437B901745F9

-jag

On Wed, 2005-11-16 at 13:12 -0400, Adrian Wells wrote:
> Hello.  How might one configure Mailman (version 2.1.6) list settings
> using PHP scripts?  The goal is to configure Mailman list settings such as
> domain name of list, non-digest footer, set welcome/goodbye messages, etc.
>  An approach that comes to mind is to use bin/config_list.  This would
> require writing/reading files and using bin/config_list to process them. 
> Is there another recommended or preferred way to accomplish this?
> 
> There was a post about "PHP Wrappers" which suggested, "...just use a
> setuid mailman wrapper script that does caller-checking to see if it's
> called correctly, by the right user, and with 'safe' values"
> <http://mail.python.org/pipermail/mailman-developers/2001-March/008421.html>.
>  This was recommended over simply adding the www user to the mailman group.
> 
> I do not completely understand how one creates a setuid mailman wrapper
> script.  Is this a matter of creating something similar to mail-wrapper.c?
> 
> If someone has written a wrapper script or has some good resources further
> explaining this to share and is willing to do so, I would appreciate it. 
> Thank you,
> -Adrian
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jag%40fsf.org
> 
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
> 
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051116/710d44ff/attachment.pgp

From peterjh at mennonot.net  Wed Nov 16 22:48:10 2005
From: peterjh at mennonot.net (Peter John Hartman)
Date: Wed, 16 Nov 2005 16:48:10 -0500 (EST)
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437b81ed-f30b@Islandnet.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com>
Message-ID: <Pine.LNX.4.63.0511161645150.17743@mennonot.mennonite.net>

I'm finishing up a drupal module (in PHP) that wraps the CLI of mailman.
Everything works EXCEPT getting at the moderation bit.  And there is a bit
of duplication with the userbase, since the pickle file is a bit inaccessible
to anything outside Python.

There is an option in the script to use the MYSQL patch of fil and Kev Green,
which is quite a nice patch and hopefully will be in the next mailman release.
If you use this option, then full mailman functionality is available.

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/mlist/#dirlist

Peter

On Wed, 16 Nov 2005, slave at codegrunt.com wrote:

>> Hello.  How might one configure Mailman (version 2.1.6) list settings
>> using PHP scripts?
>
> The quick answer would be to not bother and wait until version 3 of Mailman which will use a MySQL backend and instead manipulate that directly (if I have been reading past discussions correctly).  Calling the existing Python code via PHP exec() calls is plain out yuck.
>
> =)
>
> Cheers
>
> http://industrial.org
>
>
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/peterjh%40mennonot.net
>
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp
>

From kmccann at cruciverb.com  Wed Nov 16 22:30:39 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Wed, 16 Nov 2005 16:30:39 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437b81ed-f30b@Islandnet.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com>
Message-ID: <437BA4FF.6090003@cruciverb.com>

slave at codegrunt.com wrote:

>>Hello.  How might one configure Mailman (version 2.1.6) list settings
>>using PHP scripts?  
>>    
>>
>
>The quick answer would be to not bother and wait until version 3 of Mailman which will use a MySQL backend and instead manipulate that directly (if I have been reading past discussions correctly). 
>

I don't mean to be a pessimist, but I don't think this will ever happen. 
There are a few realities when it comes to Mailman 3.0 / Mailman 
Integration issues:

-  Barry is considered to be the lead MM developer but he's a very busy 
guy. This is not a criticism at all, just a point of fact.

-  The Mailman project is not as open as it could be. There is too much 
control over who can contribute code, how they can do it, when they can 
do it. I understand wanting to maintain quality and stability, but 
effort and goodwill are going to waste.

-  Not everyone sees the need for a highly integratable MLM, despite the 
fact that people have been begging for it for half a decade. They beg 
for it on the Mailman list. They beg for it on the Sympa list. But MLM 
developers apparently do not work with organizations or people who see 
the need to integrate MLM's with other collaborative tools. MLM 
developers do not buy into the concept of making the three main data 
stores available in SQL (those being list config, member and message 
archives) so that one can easily get and update this data from within a 
Drupal, Mambo or Xaraya CMS. "Why on God's Green Earth would you want to 
do that?" they wonder, despite the fact that many, many people have been 
drooling over the thought of being able to do so for a long time now.

-  Backward compatability is an issue and puts the kebosh on dramatic 
departures from exisitng MLM versions. It sounded like Sympa was finally 
moving forward with SQL offerings, but when you look behind the scenes 
you see that they haven't made the departure, only applied patchy 
add-ons that simulate new behaviour but keep the old mechanisms intact. 
They just couldn't cut ties to "the old way."  With a Mailman 3, radical 
changes would be needed, in my opinion, but are developers willing to 
have MM3 be a new, different, separate beast than MM2? I have a feeling 
that there is not enough wilingness to let MM3 be a fresh, new start.

Personally, I think a new MLM is needed, built from the ground up, and 
taking into account today's wants and needs. An MLM built for the 21st 
century. Completely open source and well-managed by people who have the 
time and the inclination to do it. New Project with New Ideas and Eager 
People. Either MM3 needs to start happening or a new MLM project needs 
to be created. If some people don't have time, fine, but then loosen the 
reins. Let it happen. And if it comes down to money, well, some people 
may be surprised at the amount of funding that is available for these 
kinds of projects. But the projects need to be able to move forward, 
unencumbered by control and competing commitments. Otherwise nobody will 
fund it. 

Again, I'm not trying to throw out criticisms, just stating realities.

Do developers here have any comments? Is there interest to move forward 
with MM3 now, one way or another? Is there interest among other parties 
to start a new project? Who wants to see a highly integratable MLM, and 
are you willing to contribute in any of these areas:  design, coding, 
project management, documentation, funding?


- Kevin






.













From brad at stop.mail-abuse.org  Wed Nov 16 23:56:19 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Wed, 16 Nov 2005 16:56:19 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437BA4FF.6090003@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
Message-ID: <p06200769bfa16016316e@[192.168.1.102]>

At 4:30 PM -0500 2005-11-16, Kevin McCann wrote:

>>>  Hello.  How might one configure Mailman (version 2.1.6) list settings
>>>  using PHP scripts?

	Mailman is a Python project.  PHP is always going to be an alien 
in this environment.

>>  The quick answer would be to not bother and wait until version 3 of
>>  Mailman which will use a MySQL backend and instead manipulate that
>>  directly (if I have been reading past discussions correctly).
>
>  I don't mean to be a pessimist, but I don't think this will ever happen.

	The better integration with MySQL?  No, that's definitely going 
to happen.  It may not happen as early as you (or Barry) would like, 
but it will happen.

>  -  The Mailman project is not as open as it could be. There is too much
>  control over who can contribute code, how they can do it, when they can
>  do it. I understand wanting to maintain quality and stability, but
>  effort and goodwill are going to waste.

	All open source projects have to have a source code control 
system, otherwise they can't survive.  You also have to have some 
controls over who is allowed to do what within the source code 
control system.  Again, it's a matter of simple survival.

	If you, or anyone else, is interested in contributing to the code 
base, it's not hard to add you to the system.  Once Barry saw that 
Tokio was posting patches and being a useful contributor to the 
project, he got added to the system, and is now the primary person 
responsible for the 2.x code base.  There are a number of other 
people who also have write access to the code base, but whose names 
you may not have seen very much of recently.

	There is a certain lack of involved developers who are able to 
contribute a good deal of time to the project.  If you're prepared to 
do that, then we will all benefit.

>  -  Not everyone sees the need for a highly integratable MLM, despite the
>  fact that people have been begging for it for half a decade. They beg
>  for it on the Mailman list. They beg for it on the Sympa list.

	They're begging for this kind of stuff in the wrong places. 
There a whole host of CRM and other related tools out there.

	But for whatever reason, people seem to be unwilling or unable to 
go look for them.  Instead, they glom onto tools like Mailman and 
instead expect us to make it do backflips, because they can't be 
bothered to go find the right tool for the job.

>                                                                  But MLM
>  developers apparently do not work with organizations or people who see
>  the need to integrate MLM's with other collaborative tools.

	Before you throw stones, you should make sure that you know what 
it is that you're going to be throwing stones at.

	In the case of Mailman, you clearly do not.

>                                                               MLM
>  developers do not buy into the concept of making the three main data
>  stores available in SQL (those being list config, member and message
>  archives)

	Oh?  That's news to me.

>  -  Backward compatability is an issue and puts the kebosh on dramatic
>  departures from exisitng MLM versions.

	For Mailman 2.x, that's true.  But Mailman 3.x is a complete 
ground-up re-design and re-write.  That's part of why it's taking so 
long to get there.

>  They just couldn't cut ties to "the old way."  With a Mailman 3, radical
>  changes would be needed, in my opinion, but are developers willing to
>  have MM3 be a new, different, separate beast than MM2?  I have a feeling
>  that there is not enough wilingness to let MM3 be a fresh, new start.

	Obviously you haven't been tracking the Mailman3 development very closely.

>  Personally, I think a new MLM is needed, built from the ground up, and
>  taking into account today's wants and needs. An MLM built for the 21st
>  century. Completely open source and well-managed by people who have the
>  time and the inclination to do it. New Project with New Ideas and Eager
>  People.

	If that's what you want, and Mailman3 isn't doing it for you, 
then you need to go off and set up your own project.

>           Either MM3 needs to start happening or a new MLM project needs
>  to be created. If some people don't have time, fine, but then loosen the
>  reins. Let it happen. And if it comes down to money, well, some people
>  may be surprised at the amount of funding that is available for these
>  kinds of projects. But the projects need to be able to move forward,
>  unencumbered by control and competing commitments. Otherwise nobody will
>  fund it.
>
>  Again, I'm not trying to throw out criticisms, just stating realities.

	That sounds to me like criticism.  Badly placed and very poorly 
informed criticism.

	Please do not continue to spread falsehoods and FUD about a 
project you obviously haven't been paying enough attention to.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From kmccann at cruciverb.com  Thu Nov 17 05:49:08 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Wed, 16 Nov 2005 23:49:08 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200769bfa16016316e@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
Message-ID: <437C0BC4.6090108@cruciverb.com>

Brad Knowles wrote:

>     The better integration with MySQL?  No, that's definitely going to 
> happen.  It may not happen as early as you (or Barry) would like, but 
> it will happen.
>

I'll believe that when I see it.

>     They're begging for this kind of stuff in the wrong places. There 
> a whole host of CRM and other related tools out there.
>
>     But for whatever reason, people seem to be unwilling or unable to 
> go look for them.  Instead, they glom onto tools like Mailman and 
> instead expect us to make it do backflips, because they can't be 
> bothered to go find the right tool for the job.


This kind of response is precisely what makes me realize there is a huge 
disconnect between people who run mailing lists and ONLY want to run 
mailing lists and those who want to have a mailing list be a critical 
component of something more useful in the way of comunication and 
collaboration tools tha thelp build communities of practice. I'm not 
going to try to make you "get it" but I will say that the right tool for 
"the job" just doesn't exist yet. It would be nice if it did.

>>                                                                  But MLM
>>  developers apparently do not work with organizations or people who see
>>  the need to integrate MLM's with other collaborative tools.
>
>
>     Before you throw stones, you should make sure that you know what 
> it is that you're going to be throwing stones at.
>     In the case of Mailman, you clearly do not.


I'm not throwing stones, Brad. I've tried to make that clear. And I know 
precisely what Mailman is and isn't. When it comes to looking at what it 
isn't, I'm hoping for solutions. It won't happen in MM2, I know that. 
MM3? I've seen no developments on the MM3 list. I have heard Barry 
mention he's too busy to really do anything (I think he's hoping for 
spare time soon but "soon" is elusive for many). If there are 
significant developments, why are they not mentioned on the MM3 list?


>>                                                               MLM
>>  developers do not buy into the concept of making the three main data
>>  stores available in SQL (those being list config, member and message
>>  archives)
>
>
>     Oh?  That's news to me.


Took a while to convince some on list config and member data. Still work 
to do on message archives.


>>  -  Backward compatability is an issue and puts the kebosh on dramatic
>>  departures from exisitng MLM versions.
>
>
>     For Mailman 2.x, that's true.  But Mailman 3.x is a complete 
> ground-up re-design and re-write.  That's part of why it's taking so 
> long to get there.


No, Brad. That is not why. The reason is that people have other 
commitments and the project is not as open as it could be so that those 
who do have more time or MONEY could help move things along.

>>  They just couldn't cut ties to "the old way."  With a Mailman 3, 
>> radical
>>  changes would be needed, in my opinion, but are developers willing to
>>  have MM3 be a new, different, separate beast than MM2?  I have a 
>> feeling
>>  that there is not enough wilingness to let MM3 be a fresh, new start.
>
>
>     Obviously you haven't been tracking the Mailman3 development very 
> closely.


I went to the MM3 sprint. I'm on the MM3 list. I tried to get tens of 
thousands of dollars in funding for it, and came damn close, but things 
fell through because there was no movement on the project and the 
potential funders were nervous about it. Barry can confirm that I was 
trying to get things to happen from my end. Unless there is some sort of 
MM3 Secret Society that I was not invited to, I think I have followed 
things as closely as possible.

So educate, Brad. Don't be coy. Please, share your pearls of wisdom and 
knowledge. Where, specifically are things with MM3?

>>  Personally, I think a new MLM is needed, built from the ground up, and
>>  taking into account today's wants and needs. An MLM built for the 21st
>>  century. Completely open source and well-managed by people who have the
>>  time and the inclination to do it. New Project with New Ideas and Eager
>>  People.
>
>
>     If that's what you want, and Mailman3 isn't doing it for you, then 
> you need to go off and set up your own project.


Yes, that is precisely what may have to happen, hence my post.

>>           Either MM3 needs to start happening or a new MLM project needs
>>  to be created. If some people don't have time, fine, but then loosen 
>> the
>>  reins. Let it happen. And if it comes down to money, well, some people
>>  may be surprised at the amount of funding that is available for these
>>  kinds of projects. But the projects need to be able to move forward,
>>  unencumbered by control and competing commitments. Otherwise nobody 
>> will
>>  fund it.
>>
>>  Again, I'm not trying to throw out criticisms, just stating realities.
>
>
>     That sounds to me like criticism.  Badly placed and very poorly 
> informed criticism.


I'm not at all surprised it sounds like criticism to you. You just don't 
get it and I doubt you ever will..

>     Please do not continue to spread falsehoods and FUD about a 
> project you obviously haven't been paying enough attention to.


I have been watching this project closer than I'd like to admit for 5 
years. You're happy with the status quo, I'd prefer to try to get things 
happening. That's where we differ. No need to be snide and arrogant.

- Kevin  (trying very hard to be civil)



From stephen at xemacs.org  Thu Nov 17 06:19:05 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 17 Nov 2005 14:19:05 +0900
Subject: [Mailman-Developers] Informal "MEP" process,
	anyone? [was:  PHP Wrappers?]
In-Reply-To: <437BA4FF.6090003@cruciverb.com> (Kevin McCann's message of
	"Wed, 16 Nov 2005 16:30:39 -0500")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
Message-ID: <87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Kevin" == Kevin McCann <kmccann at cruciverb.com> writes:

[about project management]

    Kevin> - The Mailman project is not as open as it could be. There
    Kevin> is too much control over who can contribute code, how they
    Kevin> can do it, when they can do it. I understand wanting to
    Kevin> maintain quality and stability, but effort and goodwill are
    Kevin> going to waste.

The code is open source, easily available in public, and with the
exception of security bugs planning is done on public channels.  The
project is as open as it needs to be to enable progress.

OTOH, since running Mailman (like any network application) is a
security risk, I _want_ to see firm controls over who can commit to
the codebase _I_ install from.  Those of you who _need_ to get to the
bottom of the cliff in sqrt(2*s/g) seconds should jump, of course.  But
I'm taking the tram.<wink>

    Kevin> But the projects need to be able to move forward,
    Kevin> unencumbered by control and competing
    Kevin> commitments. Otherwise nobody will fund it.

There is no "control"; the code base is open source.  What you want to
do by getting the MM cabal to do and/or distribute the work is to
leverage the _trust_ MM users have in the project leaders, and the
_access to beta testers_ that the project gets in return.  That's a
valid way to proceed, but to get that leverage you need to help the
developers maintain the trust by giving them accurate specifications
to work from.

    Kevin> are developers willing to have MM3 be a new,
    Kevin> different, separate beast than MM2?

The MM3 prototype code is new from the ground up.  The MM2.0->MM2.1
transition was a remarkably radical refactoring, plus a huge effort
for internationalization, for all that upgrading was trivial for most
people.  I'd bet on trying to work with the current developers rather
than forking---they have a history of doing radical stuff and succeeding.

[about why current leadership has not produced the feature]

    Kevin> -  Not everyone sees the need for a highly integratable
    Kevin> MLM,

Of course the developers see it.  They've paid plenty of lip service,
and even incorporated some code.  I don't feel like they're
disingenuous, though.  I think they personally don't need it, and
people who _articulate the requirements_ (rather than "beg for the
'feature'") are lacking.

So it's very difficult for them to specify the requirements.  They've
tried: MemberAdapter was supposed to enable integration of databases
for membership management.  But it evidently didn't work very well,
and it doesn't seem to have gotten a very enthusiastic reception.
John Dennis has been pushing that line forward, but I don't get the
impression that he is getting tons of good input on the requirements.
Instead, he posts here asking the same leadership that didn't really
know what the requirements were the first time what they think the
requirements might be!

On the other hand, the ad hoc DB integration ideas I've seen discussed
to date all have a very strong "works for me" flavor to them.  Ie, "if
you want something generalizable, then MM people will have to do
that, but here's a proof of concept."

    Kevin> despite the fact that people have been begging for it for
    Kevin> half a decade. They beg for it on the Mailman list. They
    Kevin> beg for it on the Sympa list.

Beg, build, or buy.  Plan A has failed.  Try Plan B or Plan C.

My suggestion is Plan B, because Plan C probably requires a fork (as
you mention, Barry is committed elsewhere).  If I needed what you
need, instead of posting the call for discussion _here_, I would post
on *Mailman-Users*:

  (1) summarize the current facilities (like MemberAdapter, however
  weak they may be),

  (2) find out what John Dennis has been up to and what ad hoc patches
  have been submitted, and summarize their interfaces (not the
  implementations!),

  (3) find out what the objections to the methods described in (1) and
  (2) are, both from would-be users and from the leading developers,
  and summarize them.

Those summaries, plus response from potential users, will be the
foundation to work forward from there to (a) specifications and (b)
designs.  Actual prototype code would be groovy, of course, but the
current developers (and 3rd parties? I think John is a 3rd party?) 
have already shown willingness to write at least some code.

Once you've got that, you can bring it back here.  (Python-dev people
will recognize this---including the recommendation to ask users, not
developers, about the requirements---as an informal version of the PEP
process.  It works.)

And if in fact you're right, the MM developers don't care, and snub
you ... you've lost nothing!  You've got the spec you need to attract
both developers and backing (including funding)---and the MM2.1 code
base to start from.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From kmccann at cruciverb.com  Thu Nov 17 06:27:25 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Thu, 17 Nov 2005 00:27:25 -0500
Subject: [Mailman-Developers] MM3?
In-Reply-To: <1130003789.11004.75.camel@geddy.wooz.org>
References: <1129464435.6891.12.camel@jo.birdsense.com>
	<1130003789.11004.75.camel@geddy.wooz.org>
Message-ID: <437C14BD.80405@cruciverb.com>

Barry Warsaw wrote:

>>I have been watching with anticipation, but it's been a while since I
>>have heard anything on MM3.  Any noteworthy updates?
>>    
>>
>
>Sadly, no.  My job has been incredible time consuming so I just haven't
>had much time to work on MM3.  If things go well, I have some plans for
>jump starting development that I'd like to share with the group around
>the December time frame.
>  
>

Hi Barry,

I realize you replied to this message last Oct. 22, but in view of a 
current thread, I'm wondering if you could further share your thoughts 
on MM3 development over the next 6-12 months. To what extent does the 
project depend on your availability? Have there been developments behind 
the scenes that have not been discussed on MM3? I'm being told by 
someone on the developers list that I have not been following this 
project closely enough to be able to comment on it. If anyone know this 
is untue, it's you. As you know, I have championed Mailman and have 
really wanted to see MM3 come to fruition. I'm no longer with Bellanet 
and can't get funding through those channels, but maybe there are other 
ways to contribute in the future. It would be helpful, however, to get a 
good picture of where things stand with MM3. And not necessarily from a 
perspective of what your personal plans are, but what the collective 
prpject plans are or ought to be. This gives people the opportunity to 
decide whether they should hang in there with MM or try to get something 
going with a new MLM project.

Cheers,
Kevin




From kmccann at cruciverb.com  Thu Nov 17 06:52:07 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Thu, 17 Nov 2005 00:52:07 -0500
Subject: [Mailman-Developers] Informal "MEP" process,
	anyone? [was:  PHP Wrappers?]
In-Reply-To: <87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>	<437b81ed-f30b@Islandnet.com>
	<437BA4FF.6090003@cruciverb.com>
	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <437C1A87.2020406@cruciverb.com>

Stephen J. Turnbull wrote:

>On the other hand, the ad hoc DB integration ideas I've seen discussed
>to date all have a very strong "works for me" flavor to them.  Ie, "if
>you want something generalizable, then MM people will have to do
>that, but here's a proof of concept."
>
>    Kevin> despite the fact that people have been begging for it for
>    Kevin> half a decade. They beg for it on the Mailman list. They
>    Kevin> beg for it on the Sympa list.
>
>Beg, build, or buy.  Plan A has failed.  Try Plan B or Plan C.
>  
>

I guess I have to watch the words I choose. Erase the word "beg", cease 
any mental imagery it might be conjuring up. I simply mean that there is 
a clear requirement for easier integration and people have expressed 
that need. That's all. Should it be articulated better than it has been 
so far on this list? Yes, probably.

>My suggestion is Plan B, because Plan C probably requires a fork (as
>you mention, Barry is committed elsewhere).  If I needed what you
>need, instead of posting the call for discussion _here_, I would post
>on *Mailman-Users*:
>
>  (1) summarize the current facilities (like MemberAdapter, however
>  weak they may be),
>
>  (2) find out what John Dennis has been up to and what ad hoc patches
>  have been submitted, and summarize their interfaces (not the
>  implementations!),
>
>  (3) find out what the objections to the methods described in (1) and
>  (2) are, both from would-be users and from the leading developers,
>  and summarize them.
>  
>

Rather than look at what has been done in the way of patches I'd be more 
inclined to contribute toward a design for MM3. I have actually worked 
on the specs for a SQL-enabled MLM system, based on user and admin 
requirements. Picture an open source version of Lyris but with better 
integration capabilities. I'd be happy to share them. I worked on it in 
2002, so it might take a bit of digging.

>And if in fact you're right, the MM developers don't care, and snub
>you ... you've lost nothing!  You've got the spec you need to attract
>both developers and backing (including funding)---and the MM2.1 code
>base to start from.
>  
>

Absolutely right. It would be nice to see developments happen in the MM 
project, but ultimately another project may be required to make certain 
things happen.

- Kevin







From brad at stop.mail-abuse.org  Thu Nov 17 08:54:41 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 17 Nov 2005 01:54:41 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437C0BC4.6090108@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
Message-ID: <p06200770bfa1deefec6f@[192.168.1.102]>

At 11:49 PM -0500 2005-11-16, Kevin McCann wrote:

>                                                                  I'm not
>  going to try to make you "get it" but I will say that the right tool for
>  "the job" just doesn't exist yet. It would be nice if it did.

	Mailman is not, and never will be, the be-all and end-all of 
community collaboration tools.  By necessity, those tools must be 
all-encompassing, and mailing list management is just a small part of 
the much greater picture.  You can't just take a bunch of independent 
tools and throw them into a blender and hope that something useful 
comes out the other end.

	If you want the be-all and end-all of community collaboration 
tools, you're not just barking up the wrong tree, you're in the wrong 
bloody forest on the wrong damn planet in the wrong friggin' solar 
system in the wrong galaxy in the wrong Universe.

	Mailman will move towards greater integration with database 
tools, yes.  But it is not now, nor will it ever be, the be-all and 
end-all of community collaboration tools.


	Moreover, if it was going to be such a thing, it would be highly 
commercially saleable, and you wouldn't be getting it for free.  You 
wouldn't be getting it for anything remotely approaching free.

	The ultimate community collaboration tool or free.  Pick one.

>  I'm not throwing stones, Brad. I've tried to make that clear.

	I'm sorry, despite all your claims to the contrary, whether or 
not you say you are throwing stones does not necessarily have any 
bearing on whether or not you actually are throwing stones.

>  Took a while to convince some on list config and member data. Still work
>  to do on message archives.

	I don't think there's any problem at all convincing anyone that 
message archives would be very useful to have indexed in a database. 
The issue is how to change the code so as to make that happen.

	You might as well just cross this one off your list now, because 
otherwise you're just going to make yourself look even more foolish.

>  No, Brad. That is not why. The reason is that people have other
>  commitments and the project is not as open as it could be so that those
>  who do have more time or MONEY could help move things along.

	It's an open source project.  If you don't like the way it's 
being run, you can always take a copy of the code and go play in your 
own GPL sandbox.

	But this project is as open as any other I've seen, and 
considerably more open than most.  Do you have any idea what kind of 
work it takes to get a mod bit in FreeBSD that allows you to directly 
make any changes you want to the code and without having to have them 
approved by a mentor?  And even then, you're only allowed to make 
changes within your small part of the kingdom?

	Yes, there are a relatively large number of people who have 
achieved that goal, but they are a much, much, much bigger project 
and much better financed, and they've been around a lot longer.


	Give us a thousand or a million times as many good programmers, 
millions of dollars, and a decade to put it all together, and we 
might be able to do something that could potentially begin to achieve 
some progress towards the ultimate collaboration tool.

>  I'm not at all surprised it sounds like criticism to you. You just don't
>  get it and I doubt you ever will..

	When you're being abused and the person doing the abuse tells you 
that you're not being abused, who and what are you going to believe?

	The facts are the facts.  Your claims regarding the facts do not 
necessarily have any bearing whatsoever on the facts themselves.

>  I have been watching this project closer than I'd like to admit for 5
>  years. You're happy with the status quo, I'd prefer to try to get things
>  happening.

	Once again, you have mis-characterized the situation to fit your 
own agenda.

	It's not that I'm "happy with the status quo", it's that I'm a 
realist and I understand that short of being able to take people like 
Barry and Tokio and pay them money to do little but work on Mailman 
full-time, we can't expect to see a Universe of change overnight.

	This is going to take some time.  More time than I would like, 
much more time than Barry would like, and obviously a lot more time 
than you would like.


	The question is what are you going to do to try to help that 
situation, or are you going to continue to just bluster and make 
noise?


	Actions speak louder than words.  So, let's see some action.

	If you can't come up with the money to pay for Barry to work on 
Mailman3 full-time, then come up with code to fix all the problems 
you've outlined.  If you can't come up with code, then come up with 
something else to help break your perceived logjam.

>              That's where we differ. No need to be snide and arrogant.

	Then stop doing one thing and claiming something else.

	If you want to criticize, then please at least attempt to be 
constructive in your criticism.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From kmccann at cruciverb.com  Thu Nov 17 10:10:41 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Thu, 17 Nov 2005 04:10:41 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200770bfa1deefec6f@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
	<p06200770bfa1deefec6f@[192.168.1.102]>
Message-ID: <437C4911.30001@cruciverb.com>

Brad Knowles wrote:

>
>     Mailman is not, and never will be, the be-all and end-all of 
> community collaboration tools.  By necessity, those tools must be 
> all-encompassing, and mailing list management is just a small part of 
> the much greater picture.  You can't just take a bunch of independent 
> tools and throw them into a blender and hope that something useful 
> comes out the other end.


A design that supports independent functionality *and* integration is a 
Good Thing. It's how a lot of software works.
 

>     If you want the be-all and end-all of community collaboration 
> tools, you're not just barking up the wrong tree, you're in the wrong 
> bloody forest on the wrong damn planet in the wrong friggin' solar 
> system in the wrong galaxy in the wrong Universe.


A great community collaboration tool would be nice. Be-all and end-all? 
Not necessarily. Do I expect MM to become that? Of course not. But if it 
can integrate easily with a collab tool that offers most of the other 
desired functionality, then that's a good step in the right direction. 
So what exactly is wrong with that premise? If that puts me in a 
different universe, well, I have a lot of company out here.

>     Mailman will move towards greater integration with database tools, 
> yes.  But it is not now, nor will it ever be, the be-all and end-all 
> of community collaboration tools.


Your first sentence above: that is all I'm looking for!  I don't want or 
expect MM to be a be-all and end-all tool! I want it to be able to be 
PART of a very good solution. I hope to see that in MM3. Why can't you 
understand that?

Please read the above, three times, just to make sure you got it.

>>  I have been watching this project closer than I'd like to admit for 5
>>  years. You're happy with the status quo, I'd prefer to try to get 
>> things
>>  happening.
>
>
>     Once again, you have mis-characterized the situation to fit your 
> own agenda.


No I have not.

>     It's not that I'm "happy with the status quo", it's that I'm a 
> realist and I understand that short of being able to take people like 
> Barry and Tokio and pay them money to do little but work on Mailman 
> full-time, we can't expect to see a Universe of change overnight.


Once again, paying money for Barry (and others) to do work on MM3 is 
precisely what I tried to arrange. Availability was always the main issue.

>     This is going to take some time.  More time than I would like, 
> much more time than Barry would like, and obviously a lot more time 
> than you would like.
>     The question is what are you going to do to try to help that 
> situation, or are you going to continue to just bluster and make noise?
>     Actions speak louder than words.  So, let's see some action.


What the? I really don't understand your hostility. And you haven't read 
a word I've written have you? Understand this:  I have put A LOT of time 
and effort into trying to move MM3 develoment forward through funding. 
These are ACTIONS, whether you recognize it or not. The funding hasn't 
happened due to Barry's schedule. I don't begrudge him for that, but 
that is the reality. It's not his fault, but you can't blame me for not 
trying.

>     If you can't come up with the money to pay for Barry to work on 
> Mailman3 full-time, then come up with code to fix all the problems 
> you've outlined.  If you can't come up with code, then come up with 
> something else to help break your perceived logjam.


I obviously can't get through to you, can I?  READ THIS:  The money was 
there, the availability wasn't. DO YOU UNDERSTAND?

Brad, try treating people a) like you would have them treat you, and b) 
as if they were in the same room as you. If you're already doing that, 
then I guess you're a rude masochist. Really, I suppose I'm the 
masochist because I'm banging my head against a wall here, at least 
where you're concerned.

You know, I'm reminded by all of this that no good deed goes unpunished. 
I did a lot of lobbying for MM3 development funding. It didn't work out 
because of Barry's schedule, but Lord knows I put in the effort. And I'd 
still like to see MM3 happen. And for this I get vitriolic sewage. Give 
your head a flippin' shake.

km






From brad at stop.mail-abuse.org  Thu Nov 17 10:53:25 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 17 Nov 2005 03:53:25 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437C4911.30001@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
	<p06200770bfa1deefec6f@[192.168.1.102]>
	<437C4911.30001@cruciverb.com>
Message-ID: <p06200775bfa1fe88547f@[192.168.1.102]>

At 4:10 AM -0500 2005-11-17, Kevin McCann wrote:

>  A design that supports independent functionality *and* integration is a
>  Good Thing. It's how a lot of software works.

	There are cases where this is possible, and cases where it is 
not.  The Unix philosophy of tying a multitude of tiny little tools 
together with pipes doesn't work for everything.

	Show me examples of stand-alone tools that are intended to be 
part of a complete community collaboration system, but which are also 
fully functional on their own.


	I'm sorry.  This is a case where you have to own all the pieces 
to the puzzle yourself before you can have a reasonable hope of being 
able to make them all fit together.

	Or did you think that you could just take arbitrary pieces from a 
dozen random puzzles and they'd all magically work together and 
create a beautiful picture?

>                                                                  But if it
>  can integrate easily with a collab tool that offers most of the other
>  desired functionality, then that's a good step in the right direction.
>  So what exactly is wrong with that premise?

	That you'd get that utopia for free?  That you could simply 
continue to badger and browbeat us until we provided it for you, for 
free?

>                                              If that puts me in a
>  different universe, well, I have a lot of company out here.

	Yeah, on the badgering front, you certainly have a lot of company 
there.  Not that this is a good thing, however.

>>      Mailman will move towards greater integration with database tools,
>>  yes.  But it is not now, nor will it ever be, the be-all and end-all
>>  of community collaboration tools.
>
>  Your first sentence above: that is all I'm looking for!

	Not according to everything else you've said.  Among other 
things, greater integration with database tools says nothing for 
sharing the database schema designs with other projects.  Nor does it 
say anything for sharing the supported database packages with other 
projects -- maybe we'd like MySQL and they'd like PostgreSQL.  And 
that's just the tip of the ice shelf.

	Or did you expect that just because you get everyone in the UN to 
speak English (or at least understand it through an interpreter), 
that they would automatically agree on everything and work together 
towards the same set of goals?


	I think you're expecting a level of integration here that cannot 
possibly be provided by any one project, unless they own all the 
various pieces to their puzzle.

>                                                           I don't want or
>  expect MM to be a be-all and end-all tool! I want it to be able to be
>  PART of a very good solution. I hope to see that in MM3. Why can't you
>  understand that?

	Why can't you understand that you're speaking out of both sides 
of your mouth at the same time, and saying different things?

>  Once again, paying money for Barry (and others) to do work on MM3 is
>  precisely what I tried to arrange. Availability was always the main issue.

	Pay them enough money, and I'm sure that they'll solve the 
availability problem.  But you'll have to guarantee them the payment 
-- they're not going to quit their day jobs just because you claim to 
have ten million dollars in a vault.

>  What the? I really don't understand your hostility. And you haven't read
>  a word I've written have you? Understand this:  I have put A LOT of time
>  and effort into trying to move MM3 develoment forward through funding.
>  These are ACTIONS, whether you recognize it or not.

	I don't see any action there.  I see failure to act, sure.  Claim 
of action, sure.  Possibility of attempted action, maybe.  If so, 
then there was certainly a failure to complete the action -- 
regardless of who you try to blame that on.

>  Brad, try treating people a) like you would have them treat you,

	I might do that, if you would have done the same.  Instead, you 
post your diatribe and expect all problems to be solved for you.

	I'm sorry.  I'm not going to react well to that kind of 
treatment, and I doubt anyone else is, either.

>  and b) as if they were in the same room as you.

	Again, Physician -- heal thyself.  Once you've done that, maybe 
others will follow suit.

>  You know, I'm reminded by all of this that no good deed goes unpunished.

	Yup, you're certainly providing lots of punishment here.  We must 
have done lots of good deeds.

>  I did a lot of lobbying for MM3 development funding. It didn't work out
>  because of Barry's schedule, but Lord knows I put in the effort.

	I've put in lots of effort on lots of projects, some of which was 
successful and some of which wasn't.

	But I don't recall ever posting a diatribe of the sort you did, 
and then expect everyone else to kowtow to my wishes, cater to my 
every desire, and magically solve all my problems.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From iane at sussex.ac.uk  Thu Nov 17 11:49:52 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 17 Nov 2005 10:49:52 +0000
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437BA4FF.6090003@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
Message-ID: <0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>


On 16 Nov 2005, at 21:30, Kevin McCann wrote:

> MLM
> developers do not buy into the concept of making the three main data
> stores available in SQL (those being list config, member and message
> archives)

Add to that Sender privacy rules, so that the Mail Transport Agent  
can do SMTP time rejections. Bouncing  messages isn't really  
acceptable these days, since sender addresses are so frequently forged.

-- 
Ian Eiloart
Postmaster,
IT Services
University of Sussex

Warning: The Surgeon General Has Determined That Windows Can Be  
Dangerous To Your Health
<http://news.bbc.co.uk/2/hi/uk_news/4405042.stm>





From stephen at xemacs.org  Thu Nov 17 10:45:20 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 17 Nov 2005 18:45:20 +0900
Subject: [Mailman-Developers] Informal "MEP" process, anyone?
In-Reply-To: <437C1A87.2020406@cruciverb.com> (Kevin McCann's message of
	"Thu, 17 Nov 2005 00:52:07 -0500")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
	<437C1A87.2020406@cruciverb.com>
Message-ID: <878xvnvc9b.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Kevin" == Kevin McCann <kmccann at cruciverb.com> writes:

    Kevin> I guess I have to watch the words I choose. Erase the word
    Kevin> "beg",

No.  It's the right word for the behavior I've observed so far on the
MM lists.  (I'm excluding your most recent reply to Brad, which
demonstrates (to me, anyway) that you personally have done more than
"beg".)

    Kevin> I simply mean that there is a clear requirement for easier
    Kevin> integration and people have expressed that need.

Word choice, again.  That people are in need is clear, their
requirements are not clear to me, and from what I've observed on the
MM lists, not to Barry & Co either.

    Kevin> Rather than look at what has been done in the way of
    Kevin> patches I'd be more inclined to contribute toward a design
    Kevin> for MM3. I have actually worked on the specs for a
    Kevin> SQL-enabled MLM system, based on user and admin
    Kevin> requirements.

That would be a fine step forward!  Whether it works better than what
I suggested depends on how fast you get past the singularity of "I".
The point of the process I described (and its model, ie the Python
Enhancement Proposal process) is to show that there's broad or deep
support in the community.  Whatever else you do, you need to get
concrete discussion going to show that there is a group of "enough"
users with consensus on what the "important" requirements are, and
what those requirements are.

    Kevin> It would be nice to see developments happen in the MM
    Kevin> project, but ultimately another project may be required to
    Kevin> make certain things happen.

Oh, it probably will end up being another project, and it'll get to
something merely useful in about the same effort and time that would
have taken the Mailman project to excellence.  We've seen that happen
often enough.  :-(

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From iane at sussex.ac.uk  Thu Nov 17 12:00:10 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 17 Nov 2005 11:00:10 +0000
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
Message-ID: <ECDABEA9-B086-42AB-9646-452B508B6271@sussex.ac.uk>


On 17 Nov 2005, at 10:49, Ian Eiloart wrote:

>
> On 16 Nov 2005, at 21:30, Kevin McCann wrote:
>
>> MLM
>> developers do not buy into the concept of making the three main data
>> stores available in SQL (those being list config, member and message
>> archives)
>
> Add to that Sender privacy rules, so that the Mail Transport Agent
> can do SMTP time rejections. Bouncing  messages isn't really
> acceptable these days, since sender addresses are so frequently  
> forged.

Er, sorry, I didn't mean here to support the "MLM developers do not  
buy into" part of the above. I think that what's planned for MM3 IS  
to support SQL access for those things. SQL provision should be  
enough that portal projects can then build list modules around  
Mailman. Actually, they already could - at a push.

Seems to me the big misunderstanding in this debate lies around the  
differences between Mailman 2 and Mailman 3. As far as I can see,  
they are big differences - of the sort that Kevin is looking for.  
Unfortunately, they're not highly visible - probably due to the fact  
that they're at the early stages of development.

Perhaps someone should point Kevin at the Mailman 3 codebase, so he  
can develop views from there.

-- 
Ian Eiloart
Postmaster,
IT Services
University of Sussex

Warning: The Surgeon General Has Determined That Windows Can Be  
Dangerous To Your Health
<http://news.bbc.co.uk/2/hi/uk_news/4405042.stm>





From kmccann at cruciverb.com  Thu Nov 17 12:32:50 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Thu, 17 Nov 2005 06:32:50 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <ECDABEA9-B086-42AB-9646-452B508B6271@sussex.ac.uk>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<ECDABEA9-B086-42AB-9646-452B508B6271@sussex.ac.uk>
Message-ID: <437C6A62.9080208@cruciverb.com>

Ian Eiloart wrote:

> Seems to me the big misunderstanding in this debate lies around the  
> differences between Mailman 2 and Mailman 3. As far as I can see,  
> they are big differences - of the sort that Kevin is looking for.  
> Unfortunately, they're not highly visible - probably due to the fact  
> that they're at the early stages of development.
>
> Perhaps someone should point Kevin at the Mailman 3 codebase, so he  
> can develop views from there.


Thank you, Ian, for a polite, level-headed response.

- Kevin


From kmccann at cruciverb.com  Thu Nov 17 13:16:09 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Thu, 17 Nov 2005 07:16:09 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200775bfa1fe88547f@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
	<p06200770bfa1deefec6f@[192.168.1.102]>
	<437C4911.30001@cruciverb.com>
	<p06200775bfa1fe88547f@[192.168.1.102]>
Message-ID: <437C7489.5040704@cruciverb.com>

This is my last response to Brad's messages (actually *these* are 
diatribes if anything), and I only do so to make a few things clear:

- I'm not begging for anything; I'd like to see some things come to 
fruition for the greater good. I have no personal stake in this, 
financial or otherwise.
- I don't want people to "solve my problems." I see possible solutions 
to challenges and would like to try to help meet them.
- I have seen missed opportunities to help move MM3 forward. Yes, I'm 
disappointed, but for entirely unselfish reasons

For what it's worth, the kind of tool that I'm hoping to see--from a 
functional point of view--has already been created. At Bellanet (my 
former org.) we created something called Dgroups (see www.dgroups.org) 
several years ago. The problem is that it relies on commercial software 
(Lyris, ColdFusion, MS SQL). We wanted other international development 
organizations, especially in developing countries, to be able to have a 
dgroups for themselves. Essentially decentralize the service and build 
capacity in the south. But commercial software was not practical, and we 
really had moved toward open source policies by this point, anyway.

The idea, then, had been to find/develop the same kind of tool using 
open source components. It didn't need to be a dozen tings thrown 
together, as Brad insinuated. Only three (MLM, CMS or custom PHP front 
end, SQL database).

It didn't look like MM2 was going to cut it because of, among other 
things, data storage issues. So I suggested to the org. that we try to 
get something happening with MM3. That's when we talked to Barry, 
attended the sprint, etc. But when all was said and done, it just didn't 
work out. So, instead of a good chunk of money going to the MM3 cause, 
it is now going to go to some questionable attempt at integrating Sympa 
with something (not my decision).

So, yes, I'm disappointed in the lost opportunity but for exactly two 
reasons: 1) it means missed resources for MM3, 2)  it means that 
international development groups will wait longer for the tool we had 
hoped to provide them with. In international development, time is an 
issue because quicker solutions means less suffering.  I have absolutely 
no personal stake in any of this. But having been in international 
development for 13 years, hoping for advances for the common good 
becomes second nature.

Having said all of this, I should add that I went back and read my 
original message. Yes, I came off strong. I wish I had said things 
differently. It *did* sound critical. For that, I apologize. But I want 
you to know is that my interest is solely in the greater good and 
nothing else.  So, go ahead, kick me in the head again if it'll make you 
feel better, but you should know that you completely misunderstand my 
motivations and my agenda.

- Kevin


From kmccann at cruciverb.com  Thu Nov 17 13:28:19 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Thu, 17 Nov 2005 07:28:19 -0500
Subject: [Mailman-Developers] Informal "MEP" process, anyone?
In-Reply-To: <878xvnvc9b.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>	<437b81ed-f30b@Islandnet.com>
	<437BA4FF.6090003@cruciverb.com>	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>	<437C1A87.2020406@cruciverb.com>
	<878xvnvc9b.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <437C7763.3000106@cruciverb.com>

Stephen J. Turnbull wrote:

>    Kevin> Rather than look at what has been done in the way of
>    Kevin> patches I'd be more inclined to contribute toward a design
>    Kevin> for MM3. I have actually worked on the specs for a
>    Kevin> SQL-enabled MLM system, based on user and admin
>    Kevin> requirements.
>
>That would be a fine step forward!  Whether it works better than what
>I suggested depends on how fast you get past the singularity of "I".
>  
>

Is this fair, Stephen? The word "I" was used to indicate who had worked 
on the specs, not who would be involved in implementing them. Why 
insinuate a personality trait here?

>The point of the process I described (and its model, ie the Python
>Enhancement Proposal process) is to show that there's broad or deep
>support in the community.  Whatever else you do, you need to get
>concrete discussion going to show that there is a group of "enough"
>users with consensus on what the "important" requirements are, and
>what those requirements are.
>  
>

I'd love to engage in such discussion, provided I not get beaten up at 
every comment, question, idea.

>    Kevin> It would be nice to see developments happen in the MM
>    Kevin> project, but ultimately another project may be required to
>    Kevin> make certain things happen.
>
>Oh, it probably will end up being another project, and it'll get to
>something merely useful in about the same effort and time that would
>have taken the Mailman project to excellence.  We've seen that happen
>often enough.  :-(
>  
>

I'd prefer it not be another project. Which is why I'm hoping for MM3 
success. So aside from my initial, poorly-crafted message, which has 
obvioulsy hit a raw nerve, are we really at odds when all is said and done?

- Kevin






From jag at fsf.org  Thu Nov 17 18:46:43 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Thu, 17 Nov 2005 12:46:43 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <fc.001d02110070155d001d0211006ff51a.701597@whatifnet.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<1132171318.15630.22.camel@localhost.localdomain>
	<fc.001d02110070155d001d0211006ff51a.701597@whatifnet.com>
Message-ID: <1132249603.29441.22.camel@localhost.localdomain>

Well, it's pretty much about as vanilla of an XMLRPC interface as we
could generate... I'm not a PHP programmer, so I don't know exactly how
the XMLRPC bindings work on PHP, but the Readers' Digest version of
XMLRPC goes like this...

XMLRPC is a request-response based remote procedure call mechanism over
HTTP. The client initiates a request to the XMLRPC "listener" and posts
an XML document that represents a request. For example, let's say I wrap
the function multiply(x, y) which multiplies two numbers together.
First, I need to give the function an XMLRPC methodname, so we'll call
it "foo.multiply". A request might look like:

<?xml version="1.0"?>
<methodCall>
  <methodName>foo.multiply</methodName>
  <params>
    <param><i4><value>2</value></i4></param>
    <param><i4><value>5</value></i4></param>
  </params.
</methodCall>

which the "listener" would parse and dispatch to multiply(x, y) and get
back 10. Which it would then send as a response to the client.

<?xml version="1.0"?>
<methodResponse>
  <params>
    <param><i4><value>10</value></i4></param>
  </params>
</methodResponse>

and so your XMLRPC client would return 10.

There are a handful of standard "system" methods, so for example you can
execute system.listMethods() to see what methods are implemented; or
system.methodHelp(methodName) to see documentation on a method. Also, if
errors occur, they are raised as "faults" with a fault code and a fault
string.

Fortunately most programming languages wrap the details of all of this
up for you to make it easy. In Python, you instantiate an object that
represents a connection to an XMLRPC listener. Then all methods
implemented by that listener become attributes of that object. So in
Python:

>>> import xmlrpclib
>>> sp = xmlrpclib.ServerProxy('http://lists.mysite.com/mailman/RPC2')
>>> sp.system.listMethods()
['Mailman.addMember', 'Mailman.changeMemberAddress',
'Mailman.createList', 'Mailman.deleteList', 'Mailman.deleteMember',
'Mailman.getDigestMembers', 'Mailman.getMembers', 'Mailman.getOptions',
'Mailman.getRegularMembers', 'Mailman.listAdvertisedLists',
'Mailman.listAllLists', 'Mailman.resetListPassword',
'Mailman.setOptions', 'system.listMethods', 'system.methodHelp',
'system.methodSignature']

So these are the methods exported by the Mailman RPC listener. So how do
they work?

>>> print sp.system.methodHelp('Mailman.addMember')
"add_member(listname, admin_pw, address, fullname, password, digest, now):

Subscribes the email address provided to the mailing list.

listname -- the name of the list to configure
admin_pw -- the list or site administrator password
address -- the email address to add
fullname -- the user's full name
password -- the password the user would like to have, leave blank to
    generate a random password
digest -- True or False implying if they wish to receive batched digest
    delivery
now -- True or False implying whether to bypass normal mailing list rules
    about confirmation/approval

Returns True if everything succeeded; raises Fault -32501 if the user needs
to confirm their subscription; raises Fault -32502 if the list administrator
needs to approve their subscription"

So I could execute Mailman.addMember('whatifnet-announce', 'f00bar',
'jag at fsf.org', 'jagpass', False, True) to add myself to the list
whatifnet-announce with regular delivery and without having to confirm
my email address. The method would return True if everything succeeded.
In Python, I'd do:

>>> sp.Mailman.addMember('whatifnet-announce', 'f00bar', 'jag at fsf.org',
'jagpass', False, True)

There are some pretty good references for how PHP's XMLRPC client works,
so I'd refer to those to figure out how to write a PHP client for this
interface.

Does that answer your questions somewhat?

-jag

On Thu, 2005-11-17 at 09:55 -0500, Adrian Wells wrote:
> Jag,
> 
> Thank you for the reply.  I had briefly looked over this XMLRPC patch
> before posting to the mailing list, but I do not understand how it
> would provide the desired functionality.  However, having received
> your message, I want to learn more and understand how this might
> work.  Do you have some examples, documentation, or other resources
> that I might be able to review to learn more?
> 
> In the meantime, I'll look at the patch more closely to try to
> understand how it works and how to interface with it.
> 
> Thank you,
> -Adrian
> 
> Joshua Ginsberg <jag at fsf.org> on Wednesday, November 16, 2005 at 3:01
> PM +0000 wrote:
> This would be something that could take advantage of the XMLRPC patch
> under review:
> http://www.lnk4.com/?437B8F9B45D7
> See also:
> http://www.lnk4.com/?437B900345F7
> http://www.lnk4.com/?437B901745F9
> -jag
> On Wed, 2005-11-16 at 13:12 -0400, Adrian Wells wrote:
> > Hello.  How might one configure Mailman (version 2.1.6) list
> settings
> > using PHP scripts?  The goal is to configure Mailman list settings
> such as
> > domain name of list, non-digest footer, set welcome/goodbye
> messages, etc.
> >  An approach that comes to mind is to use bin/config_list.  This
> would
> > require writing/reading files and using bin/config_list to process
> them. 
> > Is there another recommended or preferred way to accomplish this?
> > 
> > There was a post about "PHP Wrappers" which suggested, "...just use
> a
> > setuid mailman wrapper script that does caller-checking to see if
> it's
> > called correctly, by the right user, and with 'safe' values"
> >
> <http://mail.python.org/pipermail/mailman-developers/2001-March/008421.html>.
> >  This was recommended over simply adding the www user to the mailman
> group.
> > 
> > I do not completely understand how one creates a setuid mailman
> wrapper
> > script.  Is this a matter of creating something similar to
> mail-wrapper.c?
> > 
> > If someone has written a wrapper script or has some good resources
> further
> > explaining this to share and is willing to do so, I would appreciate
> it. 
> > Thank you,
> > -Adrian
> > 
> > _______________________________________________
> > Mailman-Developers mailing list
> > Mailman-Developers at python.org
> > http://mail.python.org/mailman/listinfo/mailman-developers
> > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> > Searchable Archives: http://www.mail-archive.com/mailman-users%
> 40python.org/
> > Unsubscribe:
> http://mail.python.org/mailman/options/mailman-developers/jag%
> 40fsf.org
> > 
> > Security Policy:
> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
> > 
> -- 
> Joshua Ginsberg <jag at fsf.org>
> Free Software Foundation - Senior Systems Administrator
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051117/a4fafdd2/attachment.pgp

From peterjh at mennonot.net  Thu Nov 17 21:39:30 2005
From: peterjh at mennonot.net (Peter John Hartman)
Date: Thu, 17 Nov 2005 15:39:30 -0500 (EST)
Subject: [Mailman-Developers] Informal "MEP" process,
 anyone? [was:  PHP Wrappers?]
In-Reply-To: <87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <Pine.LNX.4.63.0511171536300.17743@mennonot.mennonite.net>

I'd just like to pop in for a second about one thing:
>
> So it's very difficult for them to specify the requirements.  They've
> tried: MemberAdapter was supposed to enable integration of databases
> for membership management.  But it evidently didn't work very well,
> and it doesn't seem to have gotten a very enthusiastic reception.
> John Dennis has been pushing that line forward, but I don't get the
> impression that he is getting tons of good input on the requirements.
> Instead, he posts here asking the same leadership that didn't really
> know what the requirements were the first time what they think the
> requirements might be!
>
> On the other hand, the ad hoc DB integration ideas I've seen discussed
> to date all have a very strong "works for me" flavor to them.  Ie, "if
> you want something generalizable, then MM people will have to do
> that, but here's a proof of concept."
>

I'll admit I've been on the scene for only a few weeks, and I'd not like to speak
for fil or Kev Green, but the MySqlMemberAdaptor they developed works fairly
easily with the intended design of MemberAdaptor.  You are spot on that they
have a "works for me" flavor, and I look forward to more MemberAdaptors coming out.
I'd disagree with any word that "this will never reach the next Mailman release";
the whole idea of an adaptor is that it will.

Peter


From adrian at whatifnet.com  Thu Nov 17 19:18:03 2005
From: adrian at whatifnet.com (Adrian Wells)
Date: Thu, 17 Nov 2005 13:18:03 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <1132249603.29441.22.camel@localhost.localdomain>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com> <	>
	<1132171318.15630.22.camel@localhost.localdomain> <	>
	<fc.001d02110070155d001d0211006ff51a.701597@whatifnet.com>
	<1132249603.29441.22.camel@localhost.localdomain>
Message-ID: <fc.001d0211007019f2001d0211006ff51a.701aa3@whatifnet.com>

Joshua Ginsberg <jag at fsf.org> on Thursday, November 17, 2005 at 12:46 PM
+0000 wrote:
>Well, it's pretty much about as vanilla of an XMLRPC interface as we
>could generate... I'm not a PHP programmer, so I don't know exactly how
>the XMLRPC bindings work on PHP, but the Readers' Digest version of
>XMLRPC goes like this...


[snipped helpful examples and explanation...]

>
>There are some pretty good references for how PHP's XMLRPC client works,
>so I'd refer to those to figure out how to write a PHP client for this
>interface.
>Does that answer your questions somewhat?

Yes. Your reply was helpful and informative.  Thank you for taking the
time to provide it,
-Adrian


From fil at rezo.net  Thu Nov 17 19:38:57 2005
From: fil at rezo.net (Fil)
Date: Thu, 17 Nov 2005 19:38:57 +0100
Subject: [Mailman-Developers] Informal "MEP" process,
	anyone? [was:  PHP Wrappers?]
In-Reply-To: <Pine.LNX.4.63.0511171536300.17743@mennonot.mennonite.net>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
	<Pine.LNX.4.63.0511171536300.17743@mennonot.mennonite.net>
Message-ID: <20051117183857.GD4653@rezo.net>

> I'll admit I've been on the scene for only a few weeks, and I'd not like
> to speak for fil or Kev Green, but the MySqlMemberAdaptor they developed
> works fairly easily with the intended design of MemberAdaptor.  You are
> spot on that they have a "works for me" flavor, and I look forward to more
> MemberAdaptors coming out.

Well, it currently has a "works *not* for me" flavor and I'd appreciate som
help on the two outstanding bugs I still have (in my version, but I guess
Kev's version has them too).

1) if the DB connection dies or fades away, ping() is never called. I
suspect this is due to the fact that the function self._prodServerConnection
is not called with parenthesis. However if I add the parenthesis, I get
bumped by an error because the function ping() itself does not exist at this
point.

2) There's an issue with the bounce daemon not properly calling the __init__
sequence (or so it seems), and I get failures when I activate this daemon.

In both cases, I'd appreciate feedback, a hint to documentation, plain tests
or even a full patch :)

                                     ***

As for the main topic of this thread, I think the issues of building a
developers' community are very similar in many projects. In brief, you need
to be familiar with the code to enter the community, and at the same time
you almost need to belong to the developers' community to (have the
incentive to) get familiar with the code.

This kind of loop  has plagued my main pet project for years, and we're
trying to solve it by opening parts of the development, in two directions:
1) modular code (MemberAdaptors are a good idea, in this sense)
2) a common and open development platform for modules (imho SourceForge sucks)
   where people test each other's patches and cooperate a lot.

-- Fil


From brad at stop.mail-abuse.org  Thu Nov 17 16:00:40 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 17 Nov 2005 09:00:40 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
Message-ID: <p06200776bfa24b0c437e@[192.168.1.102]>

At 10:49 AM +0000 2005-11-17, Ian Eiloart wrote:

>>  MLM
>>  developers do not buy into the concept of making the three main data
>>  stores available in SQL (those being list config, member and message
>>  archives)
>
>  Add to that Sender privacy rules, so that the Mail Transport Agent
>  can do SMTP time rejections. Bouncing  messages isn't really
>  acceptable these days, since sender addresses are so frequently forged.

	I'm not sure I understand.  Are you talking about integrating the 
MTA into Mailman, so that it can directly access the list of allowed 
senders for a given mailing list and take appropriate action for 
other addresses before actually accepting a message?

	It seems to me that this concept is moving even further towards 
the "kitchen sink" approach, where one group has to have complete 
control over all aspects of the system.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From brad at stop.mail-abuse.org  Thu Nov 17 16:28:50 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 17 Nov 2005 09:28:50 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437C7489.5040704@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
	<p06200770bfa1deefec6f@[192.168.1.102]>
	<437C4911.30001@cruciverb.com>
	<p06200775bfa1fe88547f@[192.168.1.102]>
	<437C7489.5040704@cruciverb.com>
Message-ID: <p06200777bfa24c2c870f@[192.168.1.102]>

At 7:16 AM -0500 2005-11-17, Kevin McCann wrote:

>  For what it's worth, the kind of tool that I'm hoping to see--from a
>  functional point of view--has already been created. At Bellanet (my
>  former org.) we created something called Dgroups (see www.dgroups.org)
>  several years ago. The problem is that it relies on commercial software
>  (Lyris, ColdFusion, MS SQL).

	And the folks at Kabissa.org have put together a somewhat 
comparable system based on open-source components (including an old 
version of Mailman), primarily for the people on the African 
continent.  I'm sure it's much more kludgey than your stuff, and I 
know it's a hell of a lot more brittle than anyone would like, and I 
know it doesn't do anywhere near as much stuff as people would like.

	However, there's a great deal of integration work that has been 
done there and part of the reason I agreed to volunteer my time with 
the group and help run the mailing list side of their site was to try 
to learn as much as I could about what they had done and how they did 
it, and then bring that back to the Mailman project.

	If you look at the Mailman FAQ Wizard entries related to this 
subject (and the threads that they link to), most of the useful 
information regarding integration with CMSes, web board discussion 
systems, etc... has come from Tobias Eigen at Kabissa and various 
things that he's said on the mailman-users mailing list.


	If you had information that was useful in these areas and you 
were willing to share it with us, I guarantee that this would go into 
the FAQ and would benefit the larger community.

>                                We wanted other international development
>  organizations, especially in developing countries, to be able to have a
>  dgroups for themselves. Essentially decentralize the service and build
>  capacity in the south. But commercial software was not practical, and we
>  really had moved toward open source policies by this point, anyway.

	The folks at Kabissa have taught me that commercial stuff can be 
practical, if it is the best way to achieve the desired goals.  They 
have commercial hosting.  They have commercial support for their 
platform.  They have some commercial software that they have used as 
part of their system.

	It's not forbidden to spend money.  They try to avoid commercial 
stuff and use open source where possible, but sometimes the only 
viable solution is commercial -- and that's okay.  What's important 
is to minimize the overall total cost of development and support of 
the system, and sometimes to keep TCO down it's better to spend a bit 
more money up-front.


	Of course, Kabissa is just one organization that is trying to 
help under-privileged groups in more impoverished nations, and there 
are presumably other groups that don't have as much money to spend as 
Kabissa has had.

	But I would hope that these other groups would take the same 
approach -- don't just look for open source solutions to the 
exclusion of everything else, but instead try to keep a lid on TCO as 
a whole, and make use of what services are available from what 
sources when and where possible.

>  So, yes, I'm disappointed in the lost opportunity but for exactly two
>  reasons: 1) it means missed resources for MM3, 2)  it means that
>  international development groups will wait longer for the tool we had
>  hoped to provide them with. In international development, time is an
>  issue because quicker solutions means less suffering.

	From the sound of it, you've already got a tool that does the 
job.  Okay, it's based on commercial software, but one thing that 
using commercial software does usually buy you is speed and improved 
time-to-delivery.

	So now you're going back and trying to re-work things so as to do 
everything with open source, and you're frustrated that it's not as 
easy to do with open source as it was with commercial software. 
That's easy to understand -- a lot of stuff can be frustrating with 
open source if you're trying to compare it to commercial software.

>                                                                But I want
>  you to know is that my interest is solely in the greater good and
>  nothing else.

	Fair enough.

>                 So, go ahead, kick me in the head again if it'll make you
>  feel better, but you should know that you completely misunderstand my
>  motivations and my agenda.

	You meant well, although you chose a method of expressing 
yourself that I found objectionable.  I think we can get past this.


	I still feel that there's going to be a great deal more work that 
needs to be done to integrate any version of Mailman into a larger 
community collaboration system, and tighter database integration with 
future versions of Mailman is going to be just one small part of this 
overall picture.

	The database integration is a necessary, but not sufficient, condition.


	That integration is coming, albeit slower than anyone would like, 
and with less regularity than anyone would like.  But it is coming. 
You can choose whether or not you believe in that, and you can choose 
your level of involvement in helping to make that happen.  You can 
also ask for perspective or guidance with regards to the best way 
that you can help make that happen.

	But none of this changes the fact that the improved database 
integration is going to be just the first step in a long road towards 
that combined community collaboration system.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From jag at fsf.org  Thu Nov 17 20:24:29 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Thu, 17 Nov 2005 14:24:29 -0500
Subject: [Mailman-Developers] Informal "MEP" process,
	anyone? [was: 	PHP Wrappers?]
In-Reply-To: <20051117183857.GD4653@rezo.net>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
	<Pine.LNX.4.63.0511171536300.17743@mennonot.mennonite.net>
	<20051117183857.GD4653@rezo.net>
Message-ID: <1132255470.29441.29.camel@localhost.localdomain>

The MySQLMemberAdaptor you guys produced is quite good. IMHO, a final
version to be included in 2.2 branch should include:

1) Abstractions of SQL queries on a per list basis, i.e. I don't want to
necessarily have to use your schema. Your schema should be the default,
but I want to be able to override it to best integrate it into existing
user databases.

2) Ability to switch MemberAdaptors through the web interface as well as
configure SQL queries through the web interface.

But yeah, that's my pipe dream. I'd be happy to help hack some of that
out if that would be helpful.

-jag

On Thu, 2005-11-17 at 19:38 +0100, Fil wrote:
> > I'll admit I've been on the scene for only a few weeks, and I'd not like
> > to speak for fil or Kev Green, but the MySqlMemberAdaptor they developed
> > works fairly easily with the intended design of MemberAdaptor.  You are
> > spot on that they have a "works for me" flavor, and I look forward to more
> > MemberAdaptors coming out.
> 
> Well, it currently has a "works *not* for me" flavor and I'd appreciate som
> help on the two outstanding bugs I still have (in my version, but I guess
> Kev's version has them too).
> 
> 1) if the DB connection dies or fades away, ping() is never called. I
> suspect this is due to the fact that the function self._prodServerConnection
> is not called with parenthesis. However if I add the parenthesis, I get
> bumped by an error because the function ping() itself does not exist at this
> point.
> 
> 2) There's an issue with the bounce daemon not properly calling the __init__
> sequence (or so it seems), and I get failures when I activate this daemon.
> 
> In both cases, I'd appreciate feedback, a hint to documentation, plain tests
> or even a full patch :)
> 
>                                      ***
> 
> As for the main topic of this thread, I think the issues of building a
> developers' community are very similar in many projects. In brief, you need
> to be familiar with the code to enter the community, and at the same time
> you almost need to belong to the developers' community to (have the
> incentive to) get familiar with the code.
> 
> This kind of loop  has plagued my main pet project for years, and we're
> trying to solve it by opening parts of the development, in two directions:
> 1) modular code (MemberAdaptors are a good idea, in this sense)
> 2) a common and open development platform for modules (imho SourceForge sucks)
>    where people test each other's patches and cooperate a lot.
> 
> -- Fil
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jag%40fsf.org
> 
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
> 
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051117/462b425c/attachment.pgp

From kmccann at cruciverb.com  Thu Nov 17 20:49:38 2005
From: kmccann at cruciverb.com (Kevin McCann)
Date: Thu, 17 Nov 2005 14:49:38 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200777bfa24c2c870f@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
	<p06200770bfa1deefec6f@[192.168.1.102]>
	<437C4911.30001@cruciverb.com>
	<p06200775bfa1fe88547f@[192.168.1.102]>
	<437C7489.5040704@cruciverb.com>
	<p06200777bfa24c2c870f@[192.168.1.102]>
Message-ID: <437CDED2.3010503@cruciverb.com>

Brad Knowles wrote:

>     If you look at the Mailman FAQ Wizard entries related to this 
> subject (and the threads that they link to), most of the useful 
> information regarding integration with CMSes, web board discussion 
> systems, etc... has come from Tobias Eigen at Kabissa and various 
> things that he's said on the mailman-users mailing list.
>

Yes, I'm familiar with Kabissa. And Tobias and I have had a few back and 
forth messages. I had wanted to follow up with him on a few things a 
while back but life got in the way. (Hi, Tobias... hope all is well!)

>     If you had information that was useful in these areas and you were 
> willing to share it with us, I guarantee that this would go into the 
> FAQ and would benefit the larger community.


Well, yes, I think I do have things to share. I have been running MLM's 
for 12 years and I had significant involvement in the development of 
Dgroups (created the message interface (including QP and base64 
decoding), events calendar module, list creation/deletion/renaming 
routines, and a few other tidbits. Lessons were certainly learned in 
developing a front end to an MLM (in this case, Lyris) and if there is 
any way I can share some of those things as a positive contribution to 
MM activities, that would be great.

>>                                We wanted other international development
>>  organizations, especially in developing countries, to be able to have a
>>  dgroups for themselves. Essentially decentralize the service and build
>>  capacity in the south. But commercial software was not practical, 
>> and we
>>  really had moved toward open source policies by this point, anyway.
>
>
>     The folks at Kabissa have taught me that commercial stuff can be 
> practical, if it is the best way to achieve the desired goals.  They 
> have commercial hosting.  They have commercial support for their 
> platform.  They have some commercial software that they have used as 
> part of their system.
>
>     It's not forbidden to spend money.  They try to avoid commercial 
> stuff and use open source where possible, but sometimes the only 
> viable solution is commercial -- and that's okay.  What's important is 
> to minimize the overall total cost of development and support of the 
> system, and sometimes to keep TCO down it's better to spend a bit more 
> money up-front.


I hear what you're saying, and in fact my inital response, when asked 
about an OS version of Dgroups, was "the time is not right." I came to 
that conculsion after having a look at the OS MLM landscape. I said from 
the get-go that developing an OS version of Dgroups without the 
existence of a DB-based MLM was pure folly. But politics came into play. 
The powers that be said "OS version: Make it happen"

Personally, I could totally deal with using some commercial components. 
But, as much as I like Lyris as a product, the fees they charge are 
exhorbitant and beyond the means of many organizations. And, again, the 
goal was to be able to allow these smaller organizations to set 
something up themselves and run with it. It allows computer 
professionals in impoverished nations to develop skills and be 
self-supporting. A noble goal, in my opinion.

>     So now you're going back and trying to re-work things so as to do 
> everything with open source, and you're frustrated that it's not as 
> easy to do with open source as it was with commercial software. That's 
> easy to understand -- a lot of stuff can be frustrating with open 
> source if you're trying to compare it to commercial software.


For me, the most frustrating part is knowing that the time is not right 
for technical reasons but having to do it anyway because of political 
reasons (and, of course, the political reasons are borne from good 
intentions: helping the needy). To say that I have felt caught in the 
middle in all of this over the past few years would be an understatement.

>     You meant well, although you chose a method of expressing yourself 
> that I found objectionable.  I think we can get past this.


I think we can get past this, too. In the end we're on the same team, 
even if our goals are a bit different.

Admittedly, I responded as a frustrated person. See, I tried very hard 
to get MM3 funding to happen behind the scenes. I wrote concept papers, 
drew diagrams at staff meetings. I spent a lot of time and energy 
convincing colleagues that connecting MM2 to other components with 
Scotch Tape was pure folly and that MM3 investment was the way to go. I 
finally got buy-in, only to see the whole thing go up in smoke because 
of availability issues. Seeing the MM3 funding go down the toilet was a 
*huge* disappointment to me. And when I saw someone on the list suggest 
that the quick solution is to wait for MM3, well, I guess I let my 
frustration show.  :-(    I do apologize for that.

Nevertheless, I still want to help. Eventhough I'm no longer with my 
previous org. (or in international development at the moment), I still 
want to see solutions for the Dgroups and the Kabissas of the world who 
want to do good things for people who need a helping hand. So, when MM3 
gets moving, I'll be sure to listen in, try to learn what I can from the 
group, and offer anything that might be of value.

Sound fair? Are we good?

- Kevin


From fil at rezo.net  Thu Nov 17 22:27:55 2005
From: fil at rezo.net (Fil)
Date: Thu, 17 Nov 2005 22:27:55 +0100
Subject: [Mailman-Developers] Informal "MEP" process,
	anyone? [was: PHP Wrappers?]
In-Reply-To: <1132255470.29441.29.camel@localhost.localdomain>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
	<Pine.LNX.4.63.0511171536300.17743@mennonot.mennonite.net>
	<20051117183857.GD4653@rezo.net>
	<1132255470.29441.29.camel@localhost.localdomain>
Message-ID: <20051117212748.GI4653@rezo.net>

> The MySQLMemberAdaptor you guys produced is quite good.

I must point out that there are two versions currently:

- the original written by Kev Green, available @
        http://www.orenet.co.uk/

- my somehow extensive rewrite of Kev's work, available @
        http://trac.rezo.net/trac/rezo/browser/Mailman/

We will hopefully be able to merge things back together when I find time to
debug my stuff and Kev finds time to review the changes

> IMHO, a final version to be included in 2.2 branch should include:

I'm not sure version 2.2 should wait for this to be stabilized... it
depends, at the very least, on our collective capacity testing/building it.

> 1) Abstractions of SQL queries on a per list basis, i.e. I don't want to
> necessarily have to use your schema. Your schema should be the default,
> but I want to be able to override it to best integrate it into existing
> user databases.

Yes, that's the way "sympa" does. It can be very complex to implement if you
want full genericity. What could be done, though, is a mapping of the field
names (instead of fixed names), and some relaxing of the requirements of
available fields (we don't necessarily need to store bounce information if
we don't process bounces, for instance); but I don't think it's worth the
work authorizing to store bounce information in table A and subscription
info in table B, for example.

> 2) Ability to switch MemberAdaptors through the web interface as well as
> configure SQL queries through the web interface.

A first step could be to decide the MemberAdaptor at the time of creation.
Switching from an adaptor to another can be fairly long if you have many
many subscribers, and you can't assure that the process will not be killed
before it finishes.

However I think that the extend.py mechanism is already a good step fwd, as
it allows to have some lists on the MySQL backend, and the others on the
classical pickle thing.

> But yeah, that's my pipe dream. I'd be happy to help hack some of that
> out if that would be helpful.

You're most welcome!

-- Fil


From brad at stop.mail-abuse.org  Fri Nov 18 00:41:48 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu, 17 Nov 2005 17:41:48 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437CDED2.3010503@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
	<p06200770bfa1deefec6f@[192.168.1.102]>
	<437C4911.30001@cruciverb.com>
	<p06200775bfa1fe88547f@[192.168.1.102]>
	<437C7489.5040704@cruciverb.com>
	<p06200777bfa24c2c870f@[192.168.1.102]>
	<437CDED2.3010503@cruciverb.com>
Message-ID: <p06200779bfa2bfeea894@[192.168.1.102]>

At 2:49 PM -0500 2005-11-17, Kevin McCann wrote:

>  For me, the most frustrating part is knowing that the time is not right
>  for technical reasons but having to do it anyway because of political
>  reasons (and, of course, the political reasons are borne from good
>  intentions: helping the needy).

	Indeed, that is extremely frustrating.  One thing I've always 
really hated is when bad technical decisions get made because of bad 
political decisions.  Long-term, that's been one of my biggest hot 
buttons.

>  I think we can get past this, too. In the end we're on the same team,
>  even if our goals are a bit different.
>
>  Admittedly, I responded as a frustrated person. See, I tried very hard
>  to get MM3 funding to happen behind the scenes.

	And I have to confess that I wasn't aware of the things you had 
tried to do behind the scenes -- From what I read, it seemed to me 
like you didn't know what was going on within the project and were 
making unreasonable complaints.

	With this irreconcilable difference between our starting 
positions, I think the outcome we arrived at was at least somewhat 
unavoidable.

>                                And when I saw someone on the list suggest
>  that the quick solution is to wait for MM3,

	I'd have to go back and check the exact wording, but I don't know 
if it was intended as being the "quick solution".  I think it was 
intended to be taken as the "least slow" solution, in the overall 
scheme of open source alternatives.  But that's neither here nor 
there.

>                                              well, I guess I let my
>  frustration show.  :-(    I do apologize for that.

	And I was too quick to lump your response in with others that I 
had seen in the past, and my response was harsher than it should have 
been.  I apologize for both of those mistakes.

>  Nevertheless, I still want to help. Eventhough I'm no longer with my
>  previous org. (or in international development at the moment), I still
>  want to see solutions for the Dgroups and the Kabissas of the world who
>  want to do good things for people who need a helping hand. So, when MM3
>  gets moving, I'll be sure to listen in, try to learn what I can from the
>  group, and offer anything that might be of value.

	I think that would be very welcome.  We each contribute in our 
own ways, and it sounds like you've got some ideas and methods that 
are relatively rare.  Ideas which might help open further doors for 
others, and allow them to be able contribute even more, better and 
faster.

	The frustrating part here will be waiting until we can make our 
contributions.

>  Sound fair? Are we good?

	Yeah, I think we're good.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From barry at python.org  Fri Nov 18 01:30:31 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Nov 2005 19:30:31 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
Message-ID: <1132273831.6357.70.camel@geddy.wooz.org>

On Wed, 2005-11-16 at 13:12 -0400, Adrian Wells wrote:
> Hello.  How might one configure Mailman (version 2.1.6) list settings
> using PHP scripts?

Wow, this thread opened up a can of worms. :)  Since I'm sitting here
waiting for some compiles, I'll try to answer them as best I can.
First, the technical one brought up here...

I don't know anything about PHP, but one question is whether the box
running PHP will live on the same system as the Mailman server.  If the
answer is yes, then your approach might be fairly easy for a Python
hacker.  Basically, what I'd do is write some custom Python scripts,
modeled on the cron, command line, or mail filter scripts, which does
the specific tasks you want them to do.  Then basically call them from
PHP to make things happen.  I don't know if you can embed a Python
interpreter in PHP (kind of like mod_python w/Apache), but if so, then
you don't even have to go through the command line.  Write importable
modules and make the appropriate calls.

If not, write them as command line scripts.  Do all your input
validation in PHP and your Python scripts can be mostly trustworthy
(assuming all your other system security is up to snuff).

If PHP is running on a different machine, then, as someone I think
suggests in a later message, check out the XMLRPC interface.  This seems
to me like a very reasonable way to provide external access to Mailman
and should seriously be considered for Mailman 2.2 (more on that later).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051117/57f2f8ea/attachment.pgp

From barry at python.org  Fri Nov 18 01:49:04 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Nov 2005 19:49:04 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437BA4FF.6090003@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com>  <437BA4FF.6090003@cruciverb.com>
Message-ID: <1132274944.6358.90.camel@geddy.wooz.org>

And now for the political answers... ;)

On Wed, 2005-11-16 at 16:30 -0500, Kevin McCann wrote:

> I don't mean to be a pessimist, but I don't think this will ever happen. 

I hope this isn't the case, but realistically, things have to change
before we're going to make significant progress.  I hope that's more
along the lines of a huge lotto winning rather than becoming
unexpectedly unemployed ;).  Seriously though, Kevin is essentially
right that the development process needs to open up so that it can
progress regardless of my availability.

> -  The Mailman project is not as open as it could be. There is too much 
> control over who can contribute code, how they can do it, when they can 
> do it. I understand wanting to maintain quality and stability, but 
> effort and goodwill are going to waste.

I've been meaning to do this for many weeks now, but haven't had time to
do it properly.  So let me just blurt it out now and welcome Mark Sapiro
to the development team.  As you know Tokio Kikuchi has been doing a
great job in getting the trunk back in shape and committing lots of
fixes to the 2.1 branch.  Mark has now joined us, as I'm sure those of
you watching the checkins list have noticed.  Welcome, Mark!

If there are people out there that think they have the background,
skills, desire, and time to also help out, please let us know.  I think
we can reasonably grow the developer community and still maintain a high
level of quality.  We don't have a process in place to approve new
developers, but I think in general we can model ourselves on the Python
community.  It's a meritocracy and membership requires an existing
committer to vouch for you.  I hope we don't need to get real formal
here.

> -  Not everyone sees the need for a highly integratable MLM, despite the 
> fact that people have been begging for it for half a decade. They beg 
> for it on the Mailman list. They beg for it on the Sympa list. But MLM 
> developers apparently do not work with organizations or people who see 
> the need to integrate MLM's with other collaborative tools. MLM 
> developers do not buy into the concept of making the three main data 
> stores available in SQL (those being list config, member and message 
> archives) so that one can easily get and update this data from within a 
> Drupal, Mambo or Xaraya CMS. "Why on God's Green Earth would you want to 
> do that?" they wonder, despite the fact that many, many people have been 
> drooling over the thought of being able to do so for a long time now.

I disagree that MLM developers do not see the value in this.  I
definitely do.  That I haven't been able to /do/ anything about that
makes me sad, but I'm definitely in favor of Mailman becoming less of an
island and more of a component in the larger universe of collaboration
tools.  SQL makes my brain hurt, but I think there are Pythonic ways to
accomplish the goal of making the three data stores available to
external SQL-speaking tools.

> -  Backward compatability is an issue and puts the kebosh on dramatic 
> departures from exisitng MLM versions. 

There's no question that backward compatibility is an issue.  For
example, I think it's going to be very difficult to migrate a Mailman 2
system to any future Mailman 3 database.  But it can probably be done
with a lot of heuristics and hints from the admins.

> With a Mailman 3, radical 
> changes would be needed, in my opinion, but are developers willing to 
> have MM3 be a new, different, separate beast than MM2? I have a feeling 
> that there is not enough wilingness to let MM3 be a fresh, new start.

It has to be.  It also has to avoid second system syndrome failure.
That's the challenge.  No one's going to argue that the existing default
data model is usable in Mailman 3.

> Personally, I think a new MLM is needed, built from the ground up, and 
> taking into account today's wants and needs. An MLM built for the 21st 
> century. Completely open source and well-managed by people who have the 
> time and the inclination to do it. New Project with New Ideas and Eager 
> People. Either MM3 needs to start happening or a new MLM project needs 
> to be created. If some people don't have time, fine, but then loosen the 
> reins. Let it happen. And if it comes down to money, well, some people 
> may be surprised at the amount of funding that is available for these 
> kinds of projects. But the projects need to be able to move forward, 
> unencumbered by control and competing commitments. Otherwise nobody will 
> fund it. 

I agree.  I hope MM3 can be that vehicle because I think we've solved a
lot of the problems any MLM is going to have.  I think we have a pretty
good architecture for the backend delivery machinery.  I'd save a lot of
that (with some updating and streamlining, but most of that's already in
the MM3 code base -- yes, there /is/ an MM3 code base!).

> Again, I'm not trying to throw out criticisms, just stating realities.
> 
> Do developers here have any comments? Is there interest to move forward 
> with MM3 now, one way or another? Is there interest among other parties 
> to start a new project? Who wants to see a highly integratable MLM, and 
> are you willing to contribute in any of these areas:  design, coding, 
> project management, documentation, funding?

Great questions.  Can we move this to the mailman3-dev list though?
I'll probably be taking some time off during the holidays and I'm
planning to spend some time discussing my thoughts on it.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051117/718b09c8/attachment.pgp

From barry at python.org  Fri Nov 18 02:01:47 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Nov 2005 20:01:47 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <437C0BC4.6090108@cruciverb.com>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
Message-ID: <1132275707.6364.102.camel@geddy.wooz.org>

On Wed, 2005-11-16 at 23:49 -0500, Kevin McCann wrote:

> This kind of response is precisely what makes me realize there is a huge 
> disconnect between people who run mailing lists and ONLY want to run 
> mailing lists and those who want to have a mailing list be a critical 
> component of something more useful in the way of comunication and 
> collaboration tools tha thelp build communities of practice. I'm not 
> going to try to make you "get it" but I will say that the right tool for 
> "the job" just doesn't exist yet. It would be nice if it did.

A quick bit of history might help explain why Mailman is the way it is.
John Viega wrote Mailman to support mailing lists for some of his
favorite bands.  We (Ken Manheimer first, then joined by me) resurrected
it because we were tired of using Majordomo to support the python.org
mailing lists.  So Mailman clearly comes out of the open discussion
technical and fanboy mailing list tradition.  I believe that's why it's
very easy for people who want wide-ranging open discussion lists to
adopt Mailman and just use it, and why it's more difficult for people to
make it do things it wasn't originally intended to do.  Not that I think
those things are impossible, but they're more painful than they need to
be.

> I'm not throwing stones, Brad. I've tried to make that clear. And I know 
> precisely what Mailman is and isn't. When it comes to looking at what it 
> isn't, I'm hoping for solutions. It won't happen in MM2, I know that. 
> MM3? I've seen no developments on the MM3 list. I have heard Barry 
> mention he's too busy to really do anything (I think he's hoping for 
> spare time soon but "soon" is elusive for many). If there are 
> significant developments, why are they not mentioned on the MM3 list?

It's a valid point. I will make it a priority over the holidays to
discuss MM3 project management on the mailman3-dev list.

> I went to the MM3 sprint. I'm on the MM3 list. I tried to get tens of 
> thousands of dollars in funding for it, and came damn close, but things 
> fell through because there was no movement on the project and the 
> potential funders were nervous about it. Barry can confirm that I was 
> trying to get things to happen from my end. Unless there is some sort of 
> MM3 Secret Society that I was not invited to, I think I have followed 
> things as closely as possible.

There is no MSU @$(X...bEDF1abz... (carrier lost)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051117/b6ef0a90/attachment.pgp

From barry at python.org  Fri Nov 18 02:27:48 2005
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Nov 2005 20:27:48 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200776bfa24b0c437e@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
Message-ID: <1132277268.6357.116.camel@geddy.wooz.org>

On Thu, 2005-11-17 at 09:00 -0600, Brad Knowles wrote:

> 	I'm not sure I understand.  Are you talking about integrating the 
> MTA into Mailman, so that it can directly access the list of allowed 
> senders for a given mailing list and take appropriate action for 
> other addresses before actually accepting a message?

I don't think that's ever going to happen.  However, I've long thought
that there /are/ ways that could make the MLM/MTA interface more useful.
Examples include an MLM-friendly VERP protocol (not XVERP).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051117/61c5e0da/attachment.pgp

From jwblist at olympus.net  Fri Nov 18 06:03:08 2005
From: jwblist at olympus.net (John W. Baxter)
Date: Thu, 17 Nov 2005 21:03:08 -0800
Subject: [Mailman-Developers] Informal "MEP" process,
 anyone? [was:  PHP Wrappers?]
In-Reply-To: <1132255470.29441.29.camel@localhost.localdomain>
Message-ID: <BFA2A08C.91B8%jwblist@olympus.net>

On 11/17/05 11:24 AM, "Joshua Ginsberg" <jag at fsf.org> wrote:

> 2) Ability to switch MemberAdaptors through the web interface as well as
> configure SQL queries through the web interface.

This comment led me to think "ah, most people working on the development
will be running Mailman on servers to which they have root access.  The
needs of the increasing body of CPanel installation users and other hosted
situations need to be accounted for, and that will be hard for the developer
group."

  --John (running Mailman on servers to which I have root access and never
having "sat in front of" CPanel)




From stephen at xemacs.org  Fri Nov 18 07:08:44 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 18 Nov 2005 15:08:44 +0900
Subject: [Mailman-Developers] Informal "MEP" process, anyone?
In-Reply-To: <437C7763.3000106@cruciverb.com> (Kevin McCann's message of
	"Thu, 17 Nov 2005 07:28:19 -0500")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<87psozvol2.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
	<437C1A87.2020406@cruciverb.com>
	<878xvnvc9b.fsf@tleepslib.sk.tsukuba.ac.jp>
	<437C7763.3000106@cruciverb.com>
Message-ID: <87u0eaqyhf.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Kevin" == Kevin McCann <kmccann at cruciverb.com> writes:

    Kevin> Is this fair, Stephen? The word "I" was used to indicate
    Kevin> who had worked on the specs, not who would be involved in
    Kevin> implementing them. Why insinuate a personality trait here?

My point is that I know of two people who will participate: you and
Barry.  That's not enough, especially since the core developers don't
seem to have a lot of need for what you propose.  So nobody can know
when some requirement is particular to you.  (Not even you! :-)

    Kevin> I'd love to engage in such discussion,

Another way to put it is that you can't just "engage": you've got to
go collect the other discussants.  Nobody else is going to.

That doesn't mean you have to beat bushes, but you do have to get the
idea that somebody is willing to put time and maybe money into keeping
things moving across to other potential users.  They're mostly not on this
list, AFAICT---they're on Mailman-Users or not using Mailman yet at all.

NB: I see Barry said he wants the discussion on the MM3 list, not
here.  But those folks aren't there yet, either; somebody has to pass
the word.

    Kevin> are we really at odds when all is said and done?

No.  Basically, I'm irrelevant, I think it would be a good thing but
I'm not equipped to help in specification and am unwilling to invest
what it would take to become competent.  I only spoke up because I
believe that there are plenty of users out there who need what you
need, and that Barry (inter alia) is sympathetic so it _can_ happen.
But we still lack a spec AFAIK, and I wanted to propose a way to get
to a spec that Barry et al can implement and fill the need.  I didn't
see the subthread between you and Brad going in that direction.  ;-)

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From iane at sussex.ac.uk  Fri Nov 18 13:57:11 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Fri, 18 Nov 2005 12:57:11 +0000
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200776bfa24b0c437e@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
Message-ID: <E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>


On 17 Nov 2005, at 15:00, Brad Knowles wrote:

> At 10:49 AM +0000 2005-11-17, Ian Eiloart wrote:
>
>>>  MLM
>>>  developers do not buy into the concept of making the three main  
>>> data
>>>  stores available in SQL (those being list config, member and  
>>> message
>>>  archives)
>>
>>  Add to that Sender privacy rules, so that the Mail Transport Agent
>>  can do SMTP time rejections. Bouncing  messages isn't really
>>  acceptable these days, since sender addresses are so frequently  
>> forged.
>
> 	I'm not sure I understand.  Are you talking about integrating the  
> MTA into Mailman, so that it can directly access the list of  
> allowed senders for a given mailing list and take appropriate  
> action for other addresses before actually accepting a message?

Erm, I'm not sure what you mean by "integrating the MTA into  
Mailman". I certainly don't mean that Mailman should replace my MTA.  
I do mean that my MTA should work closer with Mailman, either by  
sharing data, or by letting Mailman reject (not bounce) messages  
somehow. "Integrating with" might be a better way of expressing it.

This is going to be an absolutely essential requirement. It's no  
longer acceptable to generate email bounces for spam. Blackholing  
spam isn't a very good idea either, since false positives go  
undetected. The only acceptable options for spam are markup, and SMTP  
time rejection. SMTP time rejection has the added advantage of  
discouraging spam-bots.

The UK's Joint Academic Network (JANET) recently published an article  
"Spam Bounces Considered Harmful". http://www.ja.net/newcert/email/ 
bounceUKN.html

Let's be clear. The *requirement* is that my MTA should never accept  
an email that isn't going to prove undeliverable. Currently there are  
two main reasons why it might: a full mailbox, or a Mailman rule. I'm  
agnostic as to how the requirement is met, but there are issues of  
performance, and configurability to be considered.

> 	It seems to me that this concept is moving even further towards  
> the "kitchen sink" approach, where one group has to have complete  
> control over all aspects of the system.

No, I just need to be able to access the rules from some other  
system. That means that the rules need to be stored in a manner  
that's accessible to my MTA. SQL, LDAP, flat files, I don't really  
care, but they do need to be accessible. They also need to be  
represented in a manner that's easy to understand. For example, a  
list of regular expressions. Exim can easily manage that.

Alternatively, I should be able to have my MTA ask Mailman whether it  
will accept the message. It might need an SMTP or LMTP interface to  
do that - I don't know LMTP well enough to know whether it can reject  
messages.

Anyway, if the intention is to have open rosters (ie rosters that I  
can access from any application), then we're pretty close to what's  
required. It would help if a roster can include regular expressions   
to say things like *@sussex.ac.uk or not *@sussex.ac.uk, and if ban  
lists can be expressed as rosters. My MTA (Exim) has ACL rules that  
can say things like:
	if /local/mailman/lists($local_part) is a file, then
	if $sender is in the list (SQL query|LDAP query)
	then accept the message
	else reject the message

Actually, I *thought* this was all in the plan for Mailman 3, but I'm  
glad to get the opportunity to make clear a requirement that - for me  
- is the single most important requirement that Mailman doesn't  
currently meet easily.

I say "easily", because I *could* have my MTA run a python script to  
get the list of permitted senders, but I've not invested any time  
into doing that, mainly because I've never done any python programming.

-- 
Ian Eiloart
Postmaster,
IT Services
University of Sussex




From brad at stop.mail-abuse.org  Sat Nov 19 07:35:15 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Sat, 19 Nov 2005 00:35:15 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
Message-ID: <p0620077fbfa4770b93dd@[192.168.1.102]>

At 12:57 PM +0000 2005-11-18, Ian Eiloart wrote:

>  I do mean that my MTA should work closer with Mailman, either by
>  sharing data, or by letting Mailman reject (not bounce) messages
>  somehow. "Integrating with" might be a better way of expressing it.

	How do you propose to do that?  Each MTA has their own way of 
working.  Should we pick one MTA and tell everyone that they have to 
use that one exclusively and we don't allow any other MTAs to be 
used/supported?

	Please give me details on precisely what level and kind of 
integration would be required.

>  Let's be clear. The *requirement* is that my MTA should never accept
>  an email that isn't going to prove undeliverable.

	I'm sorry.  That sentence just isn't parsing right now.  It seems 
like a double or maybe triple negative or something.  Can you try 
re-wording that?

>  No, I just need to be able to access the rules from some other
>  system. That means that the rules need to be stored in a manner
>  that's accessible to my MTA. SQL, LDAP, flat files, I don't really
>  care, but they do need to be accessible. They also need to be
>  represented in a manner that's easy to understand. For example, a
>  list of regular expressions. Exim can easily manage that.

	Okay, do everything in your MTA.  Problem solved.  We don't need 
any Mailman integration for that.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From msapiro at value.net  Sat Nov 19 18:49:20 2005
From: msapiro at value.net (Mark Sapiro)
Date: Sat, 19 Nov 2005 09:49:20 -0800
Subject: [Mailman-Developers] MysqlMemberships.py [was: Informal "MEP"
	process, anyone? [was:  PHP Wrappers?]]
In-Reply-To: <20051117183857.GD4653@rezo.net>
Message-ID: <PC1740200511190949200656389eaac4@msapiro>

Fil wrote:
>
>Well, it currently has a "works *not* for me" flavor and I'd appreciate som
>help on the two outstanding bugs I still have (in my version, but I guess
>Kev's version has them too).


Yes, Kev's has them too, at least the 1.61 version.


>1) if the DB connection dies or fades away, ping() is never called. I
>suspect this is due to the fact that the function self._prodServerConnection
>is not called with parenthesis. However if I add the parenthesis, I get
>bumped by an error because the function ping() itself does not exist at this
>point.


Well, yes and no. You are correct that the statement

    self._prodServerConnection

has no effect other than to tell a human reader what needs to be done
there. It needs to be

    self._prodServerConnection()

The reason that doesn't work is because ping() is a method of the
MySQLdb.connect class which has been instantiated in
MySqlMemberships.py as 'connection'. Thus, just as for example, to pop
an item off the end of a list L, you need to do

    x = L.pop()

and not

    x = pop(L)

in _prodServerConnection(), you can't do

    if ping(self.connection) == 0:

you need to do

    if self.connection.ping() == 0:



>2) There's an issue with the bounce daemon not properly calling the __init__
>sequence (or so it seems), and I get failures when I activate this daemon.


This is a known (at least to me) issue (and I don't even use
MysqlMemberships.py). I alluded to this in last month's thread on
MysqlMemberships.py in the post at
<http://mail.python.org/pipermail/mailman-developers/2005-October/018264.html>
where I said

>If MysqlMemberships.py were just storing and retrieving the
>representation that it is passed, it wouldn't have to worry about
>things like the fact that the 'cookie' argument disappeared from the
>_BounceInfo instantiation call in Mailman 2.1.4

More explicitly, in Mailman 2.1.4 the 'cookie' argument was dropped
from the __init__ method of the _BounceInfo. Looking at your code, it
seems that you have adjusted for this. Kev's 1.61 has


    # Otherwise, populate a bounce_info structure.
    bounce_info = _BounceInfo(member, row[1], (row[6],row[7],row[8]),
            row[2], row[0])
    bounce_info.lastnotice = (row[3],row[4],row[5])
    return bounce_info

Yours has

    # Otherwise, populate a bounce_info structure.
    bounce_info = _BounceInfo(member, row[0],
        (row[5],row[6],row[7]), row[1])
    bounce_info.lastnotice = (row[2],row[3],row[4])
    bounce_info.cookie = row[8]
    return bounce_info

which is correct if you rearranged the columns to move the cookie from
column 0 to column 8 and shifted the other columns to the left, and it
looks like you've done that.

There is still a larger issue discussed in last months thread about how
and when to commit the bounce info to the MySQL database since the
'stock' Bouncer.py relies on the fact that it passes a reference to
the _BounceInfo instance which is stored in the list structure so it
can change the _BounceInfo instance between calling setBounceInfo and
saving the list and have those changes saved. This cannot work with
MysqlMemberships.py so Bouncer.py must call setBounceInfo after all
changes are complete.

There is also the issue of how much knowledge of the (private)
_BounceInfo class MysqlMemberships.py should have. Granted, it must
have some knowledge since it can't directly store the instance
reference in the MySQL database, and it is also desirable to have this
info in the database in a more useable form than say a Python pickle,
but this all leads to problems when the _BounceInfo class definition
or its methods change.

So, my cursory examination makes me think your MysqlMemberships.py code
is OK. What are the actual errors that you get from bounce processing?


>In both cases, I'd appreciate feedback, a hint to documentation, plain tests
>or even a full patch :)


HTH

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


From hatukanezumi at users.sourceforge.net  Sun Nov 20 10:06:51 2005
From: hatukanezumi at users.sourceforge.net (Hatuka*nezumi)
Date: Sun, 20 Nov 2005 18:06:51 +0900
Subject: [Mailman-Developers] respond_to_post_requests
Message-ID: <20051120180651.bf40b9d2.hatukanezumi@users.sourceforge.net>

Hi list.

I found that list default for respond_to_post_requests is hardcoded
as 1.  I guess it may not be suitable for some kind of unadvertised
lists.

A short patch is attached.


  --- nezmi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mailman-cvs20051120-respond_to_post_requests.patch
Type: application/octet-stream
Size: 1559 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051120/53a8ecec/mailman-cvs20051120-respond_to_post_requests.obj

From msapiro at value.net  Sun Nov 20 20:54:02 2005
From: msapiro at value.net (Mark Sapiro)
Date: Sun, 20 Nov 2005 11:54:02 -0800
Subject: [Mailman-Developers] MysqlMemberships.py [was: Informal
	"MEP"process, anyone? [was:  PHP Wrappers?]]
In-Reply-To: <PC1740200511190949200656389eaac4@msapiro>
Message-ID: <PC17402005112011540207967151eb5e@msapiro>

Mark Sapiro wrote:

>in _prodServerConnection(), you can't do
>
>    if ping(self.connection) == 0:
>
>you need to do
>
>    if self.connection.ping() == 0:


If looked at this a bit more closely, and it turns out not to be quite
that simple. The major issue is the way things currently exist in your
MysqlMemberships.py, rev 19, 'connection' is a local variable in the
MysqlMemberships class __init__ method. It is not visible to
_prodServerConnection() at all.

I've made a few changes to MysqlMemberships.py, rev 19 which I _think_
will make it work. I did a test of a highly stripped down version
which worked, but this didn't come close to the real thing.

My suggestions are attached as MysqlMemberships19.patch.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MysqlMemberships19.patch
Type: application/octet-stream
Size: 2458 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051120/0cb3f84e/MysqlMemberships19.obj

From fil at rezo.net  Sun Nov 20 21:09:28 2005
From: fil at rezo.net (Fil)
Date: Sun, 20 Nov 2005 21:09:28 +0100
Subject: [Mailman-Developers] MysqlMemberships.py [was: Informal
	"MEP"process, anyone? [was:  PHP Wrappers?]]
In-Reply-To: <PC17402005112011540207967151eb5e@msapiro>
References: <PC1740200511190949200656389eaac4@msapiro>
	<PC17402005112011540207967151eb5e@msapiro>
Message-ID: <20051120200928.GH32641@rezo.net>

> If looked at this a bit more closely, and it turns out not to be quite
> that simple. The major issue is the way things currently exist in your
> MysqlMemberships.py, rev 19, 'connection' is a local variable in the
> MysqlMemberships class __init__ method. It is not visible to
> _prodServerConnection() at all.

Yes! Now I understand why I was getting the "ping() does not exist"; it was
applied on a non existent object :)

> I've made a few changes to MysqlMemberships.py, rev 19 which I _think_
> will make it work. I did a test of a highly stripped down version
> which worked, but this didn't come close to the real thing.

I'm running the patch as is, and there's trouble. Here is the error log:

Nov 20 21:04:49 2005 (5788) SHUNTING: 1132460671.983129+5ac04378494de5d308a14cc372ae564cdd20cb3e
Nov 20 21:04:49 2005 (5788) Uncaught runner exception: cursor closed
Nov 20 21:04:49 2005 (5788) Traceback (most recent call last):
  File "/var/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop
    self._onefile(msg, msgdata)
  File "/var/local/mailman/Mailman/Queue/Runner.py", line 161, in _onefile
    lang = mlist.getMemberLanguage(sender)
  File "/var/local/mailman/Mailman/MysqlMemberships.py", line 361, in getMemberLanguage
    lang = self.select_on('lang',member)
  File "/var/local/mailman/Mailman/MysqlMemberships.py", line 268, in select_on
    "address='%s'" %(self.escape(address)))
  File "/var/local/mailman/Mailman/MysqlMemberships.py", line 250, in select
    return self.queryall(query + ' ORDER BY address', True)
  File "/var/local/mailman/Mailman/MysqlMemberships.py", line 230, in queryall
    self.query(query)
  File "/var/local/mailman/Mailman/MysqlMemberships.py", line 226, in query
    return self.cursor.execute (query)
  File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line 137, in execute
    self.errorhandler(self, exc, value)
  File "/usr/lib/python2.3/site-packages/MySQLdb/connections.py", line 33, in defaulterrorhandler
    raise errorclass, errorvalue
ProgrammingError: cursor closed


-- Fil


From fil at rezo.net  Sun Nov 20 21:16:07 2005
From: fil at rezo.net (Fil)
Date: Sun, 20 Nov 2005 21:16:07 +0100
Subject: [Mailman-Developers] MysqlMemberships.py [was: Informal
	"MEP"process, anyone? [was:  PHP Wrappers?]]
In-Reply-To: <20051120200928.GH32641@rezo.net>
References: <PC1740200511190949200656389eaac4@msapiro>
	<PC17402005112011540207967151eb5e@msapiro>
	<20051120200928.GH32641@rezo.net>
Message-ID: <20051120201605.GI32641@rezo.net>

> I'm running the patch as is, and there's trouble. Here is the error log:

OK, good. A quick fix is to add on line 153
        self.cursor = self.connection.cursor()

The correct fix would be to isolate the connection/reconnection procedure in
a unique function, but that'll be for later.

-- Fil


From iane at sussex.ac.uk  Mon Nov 21 11:25:56 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon, 21 Nov 2005 10:25:56 +0000
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p0620077fbfa4770b93dd@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
Message-ID: <3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>


On 19 Nov 2005, at 06:35, Brad Knowles wrote:

> At 12:57 PM +0000 2005-11-18, Ian Eiloart wrote:
>
>>  I do mean that my MTA should work closer with Mailman, either by
>>  sharing data, or by letting Mailman reject (not bounce) messages
>>  somehow. "Integrating with" might be a better way of expressing it.
>
> 	How do you propose to do that?  Each MTA has their own way of  
> working.  Should we pick one MTA and tell everyone that they have  
> to use that one exclusively and we don't allow any other MTAs to be  
> used/supported?
>
> 	Please give me details on precisely what level and kind of  
> integration would be required.

No, I'm not suggesting that Mailman prefer one mail client over  
another. Simply that the ACLs for posting to the list are accessible  
in some open format. That is, they should be stored in some  
accessible database like an SQL or LDAP database, or even in flat files.

The ACLs themselves should be represented in some open format, like  
regular expressions.


>>  Let's be clear. The *requirement* is that my MTA should never accept
>>  an email that isn't going to prove undeliverable.
> 	I'm sorry.  That sentence just isn't parsing right now.  It seems  
> like a double or maybe triple negative or something.  Can you try  
> re-wording that?

OK, the MTA should ONLY accept email that it can deliver.

>>  No, I just need to be able to access the rules from some other
>>  system. That means that the rules need to be stored in a manner
>>  that's accessible to my MTA. SQL, LDAP, flat files, I don't really
>>  care, but they do need to be accessible. They also need to be
>>  represented in a manner that's easy to understand. For example, a
>>  list of regular expressions. Exim can easily manage that.
> 	Okay, do everything in your MTA.  Problem solved.  We don't need  
> any Mailman integration for that.

Well, I'm still hoping that the MLM can handle list creation, and  
configuration, and subscription, and bounce handling, and content  
filters (if the sender is permitted to post to the list, then I don't  
mind bouncing mail to them), and topics, and delivery suspension, and  
all the other things that Mailman does.

My MTA can't manage creation of ACLs. Now, I know that Mailman 3  
development is focussed on operation, not list configuration, but my  
point here is that I want my MTA to be able to share Mailman's sender  
ACLs - and that's a design requirement.
-- 
Ian Eiloart
Postmaster, University of Sussex
()  ascii ribbon campaign - against html mail
/\                        - against microsoft attachments





From fil at rezo.net  Mon Nov 21 11:53:40 2005
From: fil at rezo.net (Fil)
Date: Mon, 21 Nov 2005 11:53:40 +0100
Subject: [Mailman-Developers] MysqlMemberships.py [was: Informal
	"MEP"process, anyone? [was:  PHP Wrappers?]]
In-Reply-To: <20051120201605.GI32641@rezo.net>
References: <PC1740200511190949200656389eaac4@msapiro>
	<PC17402005112011540207967151eb5e@msapiro>
	<20051120200928.GH32641@rezo.net> <20051120201605.GI32641@rezo.net>
Message-ID: <20051121105340.GG4355@rezo.net>

@ Fil <fil at rezo.net> :
> > I'm running the patch as is, and there's trouble. Here is the error log:
> 
> OK, good. A quick fix is to add on line 153
>         self.cursor = self.connection.cursor()
> 
> The correct fix would be to isolate the connection/reconnection procedure in
> a unique function, but that'll be for later.

Unfortunately this still doesn't succeed reconnecting to the server: I get
this traceback:

  File "/var/local/mailman/Mailman/MysqlMemberships.py", line 141, in _prodServerConnection
    if self.connection.ping() == 0: OperationalError: (2006, 'MySQL server has gone away')

-- Fil


From barry at python.org  Mon Nov 21 18:09:03 2005
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Nov 2005 12:09:03 -0500
Subject: [Mailman-Developers] Ubuntu/Launchpad Rosetta for i18n translations?
Message-ID: <1132592943.9977.68.camel@geddy.wooz.org>

Hello translators,

In what will hopefully be just the first of several improvements to the
Mailman development process, I would like to get some feedback from the
i18n developers on moving translation coordination to Rosetta.

Rosetta is part of Ubuntu's Launchpad and while I haven't played around
with it too much (problems with my ancient gpg keys I suspect ;) it
looks a lot like what a few of us dreamed of writing several years ago
(but of course, never did).  Rosetta is essentially a web based
interface for translating open source applications.  The site has the
potential to be a much better collaboration platform for translations
than the mailing list or my inbox.  It also looks like it would open us
to collaborating with a much larger i18n community.

The ultimate goal of course is to continually improve the quality and
breadth of Mailman's translation.  The current set of champions have
done a great job getting Mailman i18n to where it is now, but I think
that something like Rosetta can make all our lives easier.
Specifically, I think Rosetta could help eliminate me as a bottleneck,
or require translators to deal with all the nastiness of committing
updates to the CVS trees themselves.

I would like to get feedback from the current i18n champions on this
plan.  If you have experience with Rosetta, both positive and negative,
as a translator or developer, I would be very interested in hearing your
opinion.

For more information see:

http://launchpad.com/rosetta

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051121/0fe056ed/attachment.pgp

From asmodai at in-nomine.org  Mon Nov 21 18:28:14 2005
From: asmodai at in-nomine.org (Jeroen Ruigrok/asmodai)
Date: Mon, 21 Nov 2005 18:28:14 +0100
Subject: [Mailman-Developers] Ubuntu/Launchpad Rosetta for i18n
	translations?
In-Reply-To: <1132592943.9977.68.camel@geddy.wooz.org>
References: <1132592943.9977.68.camel@geddy.wooz.org>
Message-ID: <20051121172814.GQ51142@nexus.ninth-circle.org>

-On [20051121 18:09], Barry Warsaw (barry at python.org) wrote:
>If you have experience with Rosetta, both positive and negative,
>as a translator or developer, I would be very interested in hearing your
>opinion.

Rosetta works quite well.  I've done some translations for several projects
this way.

Make sure to log any issues you encounter in the bug tracker on launchpad,
the async guys are pretty darn fast in handling and fixing these.

Overal: very positive.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
Free Tibet! http://www.savetibet.org/ | http://www.andf.info/
http://www.tendra.org/ | http://www.in-nomine.org/ | catcher at in-nomine.org
Friends are angels who lift us to our feet when our wings have trouble
remembering how to fly...

From rmg at terc.edu  Mon Nov 21 21:27:03 2005
From: rmg at terc.edu (Robby Griffin)
Date: Mon, 21 Nov 2005 15:27:03 -0500
Subject: [Mailman-Developers] MTA Integration (was PHP Wrappers?)
In-Reply-To: <3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
Message-ID: <7066f1bb23307912f5833f7482f2b997@terc.edu>

On Nov 21, 2005, at 05:25, Ian Eiloart wrote:

> OK, the MTA should ONLY accept email that it can deliver.

FWIW, Mailman currently avoids doing anything about this for a 
documented reason (scripts/post):

     # Immediately queue the message for the incoming qrunner to 
process.  The
     # advantage to this approach is that messages should never get lost 
--
     # some MTAs have a hard limit to the time a filter prog can run.  
Postfix
     # is a good example; if the limit is hit, the proc is SIGKILL'd 
giving us
     # no chance to save the message.

The extent of sanity-checking it does before queueing the message is to 
make sure the requested list exists, which is purely a file existence 
test and involves no list-locking or interpretation of the list 
configuration.

If you were able to adjust the MTA's filter timeout or perform the ACL 
check from within the MTA itself and not from a filter program, this 
might be a moot point. But I suppose you would still need to worry 
about SMTP conversation timeouts in the client. Whatever you do to vet 
senders has to be fast and nonblocking to work for large lists.

Also, keep in mind that it should obey the various admin options for 
allowing mail from some nonmembers, holding mail from some nonmembers, 
the default action for nonmembers, etc., as well as whether to restrict 
nonmembers at all, in which case I think it needs some understanding of 
Mailman internals and not just access to the roster.

	--Robby


From Dale at Newfield.org  Mon Nov 21 21:59:53 2005
From: Dale at Newfield.org (Dale Newfield)
Date: Mon, 21 Nov 2005 15:59:53 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200775bfa1fe88547f@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<p06200769bfa16016316e@[192.168.1.102]>
	<437C0BC4.6090108@cruciverb.com>
	<p06200770bfa1deefec6f@[192.168.1.102]>
	<437C4911.30001@cruciverb.com> <p06200775bfa1fe88547f@[192.168.1.102]>
Message-ID: <6177-SnapperMsg420417FABFA7E776@[68.244.199.143]>

"Brad Knowles" <brad at stop.mail-abuse.org> wrote:
>	I'm sorry.  This is a case where you have to own all the pieces 
>to the puzzle yourself before you can have a reasonable hope of being 
>able to make them all fit together.

I do not believe this is the case.  Given a sufficiently generalizable sql 
schema mapping mechanism, mailman should be able to directly use the DB 
tables of practically any SQL based store.  Mailman can always add it's own 
tables to store mailman specific info, and it could even add columns to 
non-mailman tables.

> Among other 
>things, greater integration with database tools says nothing for 
>sharing the database schema designs with other projects.  Nor does it 
>say anything for sharing the supported database packages with other 
>projects -- maybe we'd like MySQL and they'd like PostgreSQL.  And 
>that's just the tip of the ice shelf.

SQL is a standard ("Standard Query Language").  Any system needing a DB should be able to deal 
with any standards compliant DB implementation, and if it can't the system was poorly 
implemented.

-Dale

From brad at stop.mail-abuse.org  Tue Nov 22 00:37:38 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Mon, 21 Nov 2005 17:37:38 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
Message-ID: <p06200701bfa80a1a1b74@[192.168.1.102]>

At 10:25 AM +0000 2005-11-21, Ian Eiloart wrote:

>  No, I'm not suggesting that Mailman prefer one mail client over
>  another. Simply that the ACLs for posting to the list are accessible
>  in some open format. That is, they should be stored in some accessible
>  database like an SQL or LDAP database, or even in flat files.

	Show me a single open data format that all MTAs understand. 
Hell, there aren't many file formats that they all understand.

>  The ACLs themselves should be represented in some open format, like
>  regular expressions.

	Again, show me a single open format that all MTAs understand.


	Trust me, this issue is far more complex than you think it is.

>  OK, the MTA should ONLY accept email that it can deliver.

	Considering that there are anti-spam rules inside of Mailman 
itself that can take on various actions, including rejection of the 
e-mail, that's simply not physically possible.  At least, not without 
gutting a considerable amount of existing functionality in Mailman.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From stephen at xemacs.org  Tue Nov 22 06:53:10 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 22 Nov 2005 14:53:10 +0900
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200701bfa80a1a1b74@[192.168.1.102]> (Brad Knowles's message
	of "Mon, 21 Nov 2005 17:37:38 -0600")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
Message-ID: <878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:

    Brad> 	Show me a single open data format that all MTAs
    Brad> understand. Hell, there aren't many file formats that they
    Brad> all understand.

C'mon, Brad, don't let the perfect be the enemy of all improvement.

For access to the ACL database, we really need only to consider two
MTAs (at most): Exim and Postfix.  Sendmail has milters for this
purpose; you don't need to do surgery on sendmail itself, just
configure the mailman-acl milter.  qmail users are fanatics, let them
deal with it, because you know they will.  Which others matter to
Mailman?  So make it Exim and Postfix compatible, and we can do the
others later, or leave it to their users/developers.

The point is that if Mailman does a reasonable job of specifying
access to a database of list ACLs, people can and will write adapters
for their drug of choice.  Other MLMs will follow the Mailman spec if
it's decent and we get there first.  The whole Internet wins.

    >> The ACLs themselves should be represented in some open format,
    >> like regular expressions.

    Brad> 	Again, show me a single open format that all MTAs
    Brad> understand.

The ACL format is a much tougher requirement, and will require a lot
of thought.  Do we want to specify archive ACLs in the same database?
How do we condition access on the various authentication methods that
users may use?  "Like regular expressions" means exactly what?  Etc,
etc.

Again, if we specify and mostly implement such an interface well, the
users will come and they'll make their other tools work with it.

If you want to say that specifying these formats _well enough_ to
attract users and to make related products (both substitutes like
Majordomo and complements like Postfix) willing to support them is
"too hard" or "is a project for MM3 or maybe MM3.1", I'll defer to you
on that.  But saying "it's gotta be perfect on introduction or it's no
good" is not a way to communicate.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From brad at stop.mail-abuse.org  Tue Nov 22 07:14:29 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Tue, 22 Nov 2005 00:14:29 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <p06200706bfa864453d9a@[192.168.1.102]>

At 2:53 PM +0900 2005-11-22, Stephen J. Turnbull wrote:

>>>>>>  "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:
>
>      Brad> 	Show me a single open data format that all MTAs
>      Brad> understand. Hell, there aren't many file formats that they
>      Brad> all understand.
>
>  C'mon, Brad, don't let the perfect be the enemy of all improvement.
>
>  For access to the ACL database, we really need only to consider two
>  MTAs (at most): Exim and Postfix.

	You have to give the MTA direct access to the internal filters of 
Mailman in some sense.  I don't think we can restrict ourselves to 
just these two MTAs.

	Moreover, who owns this code?  It crosses the boundary between 
Mailman and the MTAs -- do we have to continue to track their 
development ad infinitum?  Do we have to patch their code?

>                                     Sendmail has milters for this
>  purpose; you don't need to do surgery on sendmail itself, just
>  configure the mailman-acl milter.

	Mailman-acl milter?  This is the first I've heard of it.  Is this 
a new thing?  Who maintains this code?

>  The point is that if Mailman does a reasonable job of specifying
>  access to a database of list ACLs, people can and will write adapters
>  for their drug of choice.  Other MLMs will follow the Mailman spec if
>  it's decent and we get there first.  The whole Internet wins.

	Okay, I can see Mailman providing a single, hopefully reasonably 
well-specified specification, and letting everyone else adapt. 
That's a far cry from what Ian was talking about.

>  The ACL format is a much tougher requirement, and will require a lot
>  of thought.  Do we want to specify archive ACLs in the same database?
>  How do we condition access on the various authentication methods that
>  users may use?  "Like regular expressions" means exactly what?  Etc,
>  etc.
>
>  Again, if we specify and mostly implement such an interface well, the
>  users will come and they'll make their other tools work with it.

	I'm willing to go that route.  But you do seem to agree with me 
that this problem is going to be a lot tougher to solve than Ian 
implies, yes?

>  If you want to say that specifying these formats _well enough_ to
>  attract users and to make related products (both substitutes like
>  Majordomo and complements like Postfix) willing to support them is
>  "too hard" or "is a project for MM3 or maybe MM3.1", I'll defer to you
>  on that.

	I am not convinced that this is a question that can be answered 
within the overall scheme of MM3.  I'm willing to be proven wrong, 
but what I know of the problem is that it's a much bigger mountain 
than I think it's being given credit for.

>            But saying "it's gotta be perfect on introduction or it's no
>  good" is not a way to communicate.

	That is not an accurate characterization of what I was saying. 
Re-read my previous message to Ian -- I said to him:

		Trust me, this issue is far more complex than you think it is.

	Now, if you can agree that this is a big issue that will need to 
have a lot of thought and work put into it, and it not something 
you're likely to knock out on a single late-night hacking session, 
well that's all I'm really asking for.


	It's one thing to identify a desired long-term design goal.  It's 
another to imply that this will be trivially easy to implement.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From stephen at xemacs.org  Tue Nov 22 09:18:06 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 22 Nov 2005 17:18:06 +0900
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200706bfa864453d9a@[192.168.1.102]> (Brad Knowles's message
	of "Tue, 22 Nov 2005 00:14:29 -0600")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
Message-ID: <87sltphz9d.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:

    >> For access to the ACL database, we really need only to consider
    >> two MTAs (at most): Exim and Postfix.

    Brad> 	You have to give the MTA direct access to the internal
    Brad> filters of Mailman in some sense.

To get all the way to "MTA doesn't accept anything that MM is going to
refuse to deliver", yes.  But we certainly could define an interface
to an auxiliary service such that if the MTA tells us (AuthType,
AuthCredentials, EnvelopeSender, Sender, From, To) we'll say "nuke it"
or "OK, we'll handle that".  That would allow us to push a lot of
simple cases (such as "authenticated user not a list member") back to
the MTA, and never invoke the heavy equipment of Mailman itself.

    Brad> I don't think we can restrict ourselves to just these two
    Brad> MTAs.

Permanently, no.  I'm saying that to start with if we do Exim and
Postfix, the sendmail milter interface makes it likely that sendmail
can adapt code from one or the other, the qmail people will take care
of qmail like they always do, and that is enough to get the ball
rolling.

    Brad> 	Moreover, who owns this code?  It crosses the boundary
    Brad> between Mailman and the MTAs

No, the point is to define the boundary, and give a well-defined API
for crossing it.

    Brad> Do we have to patch their code?

Not "have to", but that may be the most effective way to jump start
it, may even be necessary for jump starting.  It's not our "job", but
it's something we may need to budget resources for if we want to do
it.  Of course if those resources are large and won't come from fresh
blood, that kills the idea.  But we haven't shown that the needed
resources are large, and there are a couple of people who I don't
recognize as frequent code contributors who are pushing hard---there
might be fresh blood out there to do this.

    >> Sendmail has milters for this purpose; you don't need to do
    >> surgery on sendmail itself, just configure the mailman-acl
    >> milter.

    Brad> 	Mailman-acl milter?  This is the first I've heard of
    Brad> it.  Is this a new thing?  Who maintains this code?

It's so new it's vapor.<wink> The point is that while I worry that
Exim and Postfix may require source patches, sendmail can be done as a
separate milter module.  This is exactly the kind of thing that the
milter API was designed for.

    Brad> 	Okay, I can see Mailman providing a single, hopefully
    Brad> reasonably well-specified specification, and letting
    Brad> everyone else adapt. That's a far cry from what Ian was
    Brad> talking about.

Was it?  I don't know.  My feeling is that Ian is lacking some
necessary facts, and consequently expressed his requirements in terms
that can't be satisfied.  But if we give him the details and withhold
judgment on the substance until he's reformulated, we might find that
what he really wants is a lot closer to what would be do-able than our
initial impressions are.

    Brad> 	I'm willing to go that route.  But you do seem to
    Brad> agree with me that this problem is going to be a lot tougher
    Brad> to solve than Ian implies, yes?

I think so.  Solving them for Ian probably is not too hard.  Solving
them in a way that generalizes is going to be hard.  But Python is a
very good environment for such generalization.

    Brad> I am not convinced that this is a question that can be
    Brad> answered within the overall scheme of MM3.  I'm willing to
    Brad> be proven wrong, but what I know of the problem is that it's
    Brad> a much bigger mountain than I think it's being given credit
    Brad> for.

Well, you may have a bigger problem in mind, but 90% of Mailman users
would get a big bonus from getting only halfway there.  Or maybe you
know something I don't.

    >> But saying "it's gotta be perfect on introduction or it's no
    >> good" is not a way to communicate.

    Brad> 	That is not an accurate characterization of what I was
    Brad> saying. Re-read my previous message to Ian -- I said to him:

    Brad> 		Trust me, this issue is far more complex than
    Brad> you think it is.

You said that, true.  You also said "open data formats that ALL MTAs
understand", and "ACL formats that ALL MTAs understand" (emphasis
mine).  Of course you meant something substantially weaker than "all
MTAs must understand as an absolute requirement", but surely it was
something at least as strong as "we cannot ask users to change MTAs to
get this feature."  Agreed?

Speaking for myself, I see nothing wrong with asking the bleeding edge
adopters to change MTAs, and I see nothing wrong with restricting
Mailman-supplied MTA code to a couple of MTAs that we "like".  Of
course we help other MTAs to incorporate the feature, but we don't
need to promise that they can use it in advance.  Some MTAs may never
get it.

Now, that may inhibit adoption to the extent that creating the feature
isn't worth it, but that is not a foregone conclusion as far as I can
see.  It depends on how big a win this feature would be, and how hard
implementing the MTA-side code would be.

    Brad> 	Now, if you can agree that this is a big issue that
    Brad> will need to have a lot of thought and work put into it, and
    Brad> it not something you're likely to knock out on a single
    Brad> late-night hacking session, well that's all I'm really
    Brad> asking for.

Definitely.  That's been my main theme both in this thread and in the
SQL database thread---simply specifying requirements is a big job.
The users know the effects they want, but UI/API/implementation
constraints haven't been presented at all.  And users won't really be
able to express them until they've got a prototype to work with.

OTOH, I wonder if you're not overestimating the degree of difficulty
and underestimating the benefits of the structural work required.
Mailman itself is partially structured to do this kind of hacking, but
mostly in the posting pipeline at this point.  I've done a fair amount
of experimenting with the posting pipeline, though, and it's safe and
easy.

The "database backend" is _not_ structured that way yet, but I think
it would probably be worthwhile to move in that direction for its own
sake.  Mailman has a lot of databases: users, list config, site
config, filter rules, archives, maybe others.  I think there would be
substantial, though mostly unpredictable, benefits from regularizing
the database APIs to Mailman's current user base.  The benefits to the
"integration" crowd (like Kevin McCann) are more obvious, but I think
there will be benefits to people running traditional discussion lists,
too.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From iane at sussex.ac.uk  Tue Nov 22 12:38:16 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 22 Nov 2005 11:38:16 +0000
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <p06200706bfa864453d9a@[192.168.1.102]>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
Message-ID: <DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk>


On 22 Nov 2005, at 06:14, Brad Knowles wrote:

> At 2:53 PM +0900 2005-11-22, Stephen J. Turnbull wrote:
>
>>>>>>>  "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:
>>
>>      Brad> 	Show me a single open data format that all MTAs
>>      Brad> understand. Hell, there aren't many file formats that they
>>      Brad> all understand.
>>
>>  C'mon, Brad, don't let the perfect be the enemy of all improvement.
>>
>>  For access to the ACL database, we really need only to consider two
>>  MTAs (at most): Exim and Postfix.
>
> 	You have to give the MTA direct access to the internal filters of  
> Mailman in some sense.  I don't think we can restrict ourselves to  
> just these two MTAs.
>
> 	Moreover, who owns this code?  It crosses the boundary between  
> Mailman and the MTAs -- do we have to continue to track their  
> development ad infinitum?  Do we have to patch their code?

No, I don't seem to be getting this across. All Mailman needs to do  
is use some kind of storage that lets the MTA have a chance of  
getting at the data. Then it's up to the MTA coders to do it.

Now, for Exim, nothing needs to be done by the coders. Exim is  
flexible enough that it can be configured to read lists of addresses,  
domains, regular expressions from almost any kind of SQL, LDAP or  
flat file database that you care to use.



>>                                     Sendmail has milters for this
>>  purpose; you don't need to do surgery on sendmail itself, just
>>  configure the mailman-acl milter.
>
> 	Mailman-acl milter?  This is the first I've heard of it.  Is this  
> a new thing?  Who maintains this code?

We're talking about Mailman 3 here.

>>  The point is that if Mailman does a reasonable job of specifying
>>  access to a database of list ACLs, people can and will write  
>> adapters
>>  for their drug of choice.  Other MLMs will follow the Mailman  
>> spec if
>>  it's decent and we get there first.  The whole Internet wins.
>
> 	Okay, I can see Mailman providing a single, hopefully reasonably  
> well-specified specification, and letting everyone else adapt.  
> That's a far cry from what Ian was talking about.


No, it's exactly what I was saying.

>>  The ACL format is a much tougher requirement, and will require a lot
>>  of thought.  Do we want to specify archive ACLs in the same  
>> database?
>>  How do we condition access on the various authentication methods  
>> that
>>  users may use?  "Like regular expressions" means exactly what?  Etc,
>>  etc.
>>
>>  Again, if we specify and mostly implement such an interface well,  
>> the
>>  users will come and they'll make their other tools work with it.
>
> 	I'm willing to go that route.  But you do seem to agree with me  
> that this problem is going to be a lot tougher to solve than Ian  
> implies, yes?
>

No, you've evidently completely misunderstood me. All I do want is  
for Mailman to use *exactly* the same mechanisms for sender ACLs that  
it does for rosters. If that's LDAP, that's fine. If it's SQL, that's  
fine. If it's flat files, that's fine.


-- 
Ian Eiloart
Postmaster,
IT Services
University of Sussex

Warning: The Surgeon General Has Determined That Windows Can Be  
Dangerous To Your Health
<http://news.bbc.co.uk/2/hi/uk_news/4405042.stm>





From iane at sussex.ac.uk  Tue Nov 22 12:41:50 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 22 Nov 2005 11:41:50 +0000
Subject: [Mailman-Developers] MTA Integration (was PHP Wrappers?)
In-Reply-To: <7066f1bb23307912f5833f7482f2b997@terc.edu>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<7066f1bb23307912f5833f7482f2b997@terc.edu>
Message-ID: <B9FD6B0E-AE8B-4454-9D5B-84883D520CA2@sussex.ac.uk>


On 21 Nov 2005, at 20:27, Robby Griffin wrote:

> On Nov 21, 2005, at 05:25, Ian Eiloart wrote:
>
>> OK, the MTA should ONLY accept email that it can deliver.
>
> FWIW, Mailman currently avoids doing anything about this for a  
> documented reason (scripts/post):
>
>     # Immediately queue the message for the incoming qrunner to  
> process.  The
>     # advantage to this approach is that messages should never get  
> lost --
>     # some MTAs have a hard limit to the time a filter prog can  
> run.  Postfix
>     # is a good example; if the limit is hit, the proc is SIGKILL'd  
> giving us
>     # no chance to save the message.

Well, this is OK if the MTA can see the ACL. Then, it can reject or  
accept the message before passing it to Mailman.



-- 
Ian Eiloart
Postmaster,
IT Services
University of Sussex

Warning: The Surgeon General Has Determined That Windows Can Be  
Dangerous To Your Health
<http://news.bbc.co.uk/2/hi/uk_news/4405042.stm>





From stephen at xemacs.org  Tue Nov 22 17:36:26 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Nov 2005 01:36:26 +0900
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk> (Ian
	Eiloart's message of "Tue, 22 Nov 2005 11:38:16 +0000")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk>
Message-ID: <87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Ian" == Ian Eiloart <iane at sussex.ac.uk> writes:

    Ian> No, you've evidently completely misunderstood me. All I do
    Ian> want is for Mailman to use *exactly* the same mechanisms for
    Ian> sender ACLs that it does for rosters. If that's LDAP, that's
    Ian> fine. If it's SQL, that's fine. If it's flat files, that's
    Ian> fine.

As Brad says, that's easier said than done.  As it happens, Mailman
does (by default) use exactly the same method---it's called a "Python
pickle".

But a Python pickle is an _object_ database.  LDAP is about
tree-structured databases, SQL about relational databases.  It's
non-trivial to put most of the stuff in Mailman into those formats.

The problem isn't really that pickles are Python-specific, that's what
Fred Brooks would call an "accidental" obstacle.  You're right, we
could, at a fairly predictable amount of effort, convert from a
Python-specific data store to a standard one accessible by a
well-defined protocol such as LDAP or SQL.  The problem is that the
data used by Mailman doesn't necessarily fit those models, and we
won't know how hard the conversion is (ie, what effects there will be
on various parts of Mailman) until we do it.  It's a good bet that it
will be harder than it looks.

Regards,



-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From msapiro at value.net  Tue Nov 22 18:12:46 2005
From: msapiro at value.net (Mark Sapiro)
Date: Tue, 22 Nov 2005 09:12:46 -0800
Subject: [Mailman-Developers] MysqlMemberships.py [was: Informal
	"MEP"process, anyone? [was:  PHP Wrappers?]]
In-Reply-To: <20051121105340.GG4355@rezo.net>
Message-ID: <PC1740200511220912460734fb01712c@msapiro>

Fil wrote:
>
>Unfortunately this still doesn't succeed reconnecting to the server: I get
>this traceback:
>
>  File "/var/local/mailman/Mailman/MysqlMemberships.py", line 141, in _prodServerConnection
>    if self.connection.ping() == 0: OperationalError: (2006, 'MySQL server has gone away')


Apparently the ping() method is not the way to test if the connection
is still viable. I suppose you could wrap it in a try: and treat the
exception the same as a non-zero result, but I don't know if that's
appropriate.

I don't think I can be of further help on this one. Sorry.

You need someone who's familiar with the methods in the MySQLdb module.
Maybe Kev Green can help.

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


From iane at sussex.ac.uk  Tue Nov 22 18:15:07 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Tue, 22 Nov 2005 17:15:07 +0000
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk>
	<87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <CA7C8E92-2E0C-4F1E-824F-497E1F4E1E12@sussex.ac.uk>


On 22 Nov 2005, at 16:36, Stephen J. Turnbull wrote:

>>>>>> "Ian" == Ian Eiloart <iane at sussex.ac.uk> writes:
>
>     Ian> No, you've evidently completely misunderstood me. All I do
>     Ian> want is for Mailman to use *exactly* the same mechanisms for
>     Ian> sender ACLs that it does for rosters. If that's LDAP, that's
>     Ian> fine. If it's SQL, that's fine. If it's flat files, that's
>     Ian> fine.
>
> As Brad says, that's easier said than done.  As it happens, Mailman
> does (by default) use exactly the same method---it's called a "Python
> pickle".
>
> But a Python pickle is an _object_ database.  LDAP is about
> tree-structured databases, SQL about relational databases.  It's
> non-trivial to put most of the stuff in Mailman into those formats.
>
> The problem isn't really that pickles are Python-specific, that's what
> Fred Brooks would call an "accidental" obstacle.  You're right, we
> could, at a fairly predictable amount of effort, convert from a
> Python-specific data store to a standard one accessible by a
> well-defined protocol such as LDAP or SQL.  The problem is that the
> data used by Mailman doesn't necessarily fit those models, and we
> won't know how hard the conversion is (ie, what effects there will be
> on various parts of Mailman) until we do it.  It's a good bet that it
> will be harder than it looks.

Yes, I know all this. However, we're talking about Mailman 3, and I  
understood that Mailman 3 *is* going to support LDAP, SQL, etc  
rosters. All I'm asking is that these include the sender ACLs for the  
lists. Now, sender ACL's already are *just* lists of regular  
expressions. So, what's so hard?

-- 
Ian Eiloart
Postmaster,
IT Services
University of Sussex

Warning: The Surgeon General Has Determined That Windows Can Be  
Dangerous To Your Health
<http://news.bbc.co.uk/2/hi/uk_news/4405042.stm>





From stephen at xemacs.org  Tue Nov 22 18:33:38 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Nov 2005 02:33:38 +0900
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <CA7C8E92-2E0C-4F1E-824F-497E1F4E1E12@sussex.ac.uk> (Ian
	Eiloart's message of "Tue, 22 Nov 2005 17:15:07 +0000")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk>
	<87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>
	<CA7C8E92-2E0C-4F1E-824F-497E1F4E1E12@sussex.ac.uk>
Message-ID: <87zmnwfuz1.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Ian" == Ian Eiloart <iane at sussex.ac.uk> writes:

    Ian> Now, sender ACL's already are *just* lists of regular
    Ian> expressions. So, what's so hard?

You're aware that "regular expression" is not exactly well-defined,
and that python REs are a unique dialect among regular expression
languages?


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From barry at python.org  Tue Nov 22 19:04:22 2005
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Nov 2005 13:04:22 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
Message-ID: <1132682662.15461.21.camel@geddy.wooz.org>

On Fri, 2005-11-18 at 12:57 +0000, Ian Eiloart wrote:

> Let's be clear. The *requirement* is that my MTA should never accept  
> an email that isn't going to prove undeliverable. Currently there are  
> two main reasons why it might: a full mailbox, or a Mailman rule. I'm  
> agnostic as to how the requirement is met, but there are issues of  
> performance, and configurability to be considered.

The problem as I see it is either that the MTA has to make this decision
synchronously in the middle of its SMTP conversation.  It's unlikely
that Mailman will store its data in anything other than a natural format
for itself (e.g. using Python regexps), so either your MTA has to be
taught to understand that Mailman-native data, or we need some
out-of-band way to get Mailman do that calculation.

One of the things I'd really like to move to in 3.0 is using the maildir
format as the preferred way to get messages into Mailman's incoming
queue.  Actually, that all works in the current 3.0 code.  What's nice
is that it completely decouples Mailman from the MTA, but from your
perspective above, that's also what sucks.

It's definitely a possibility that we could prevent Mailman from ever
bouncing unacceptable messages.

> Anyway, if the intention is to have open rosters (ie rosters that I  
> can access from any application), then we're pretty close to what's  
> required. It would help if a roster can include regular expressions   
> to say things like *@sussex.ac.uk or not *@sussex.ac.uk, and if ban  
> lists can be expressed as rosters. My MTA (Exim) has ACL rules that  
> can say things like:
> 	if /local/mailman/lists($local_part) is a file, then
> 	if $sender is in the list (SQL query|LDAP query)
> 	then accept the message
> 	else reject the message
> 
> Actually, I *thought* this was all in the plan for Mailman 3, but I'm  
> glad to get the opportunity to make clear a requirement that - for me  
> - is the single most important requirement that Mailman doesn't  
> currently meet easily.

The current MM3 schema does express rosters in a table, and regexps are
allowed in those rosters (IIRC), but be aware that they are going to be
Python regexps, and that may not match the regexp language that Exim (or
any other non-Python application) will understand.

> I say "easily", because I *could* have my MTA run a python script to  
> get the list of permitted senders, but I've not invested any time  
> into doing that, mainly because I've never done any python programming.

That's the easy part. :)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051122/e93f5109/attachment.pgp

From barry at python.org  Tue Nov 22 19:07:28 2005
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Nov 2005 13:07:28 -0500
Subject: [Mailman-Developers] MTA Integration (was PHP Wrappers?)
In-Reply-To: <7066f1bb23307912f5833f7482f2b997@terc.edu>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<7066f1bb23307912f5833f7482f2b997@terc.edu>
Message-ID: <1132682848.15455.24.camel@geddy.wooz.org>

On Mon, 2005-11-21 at 15:27 -0500, Robby Griffin wrote:

> > OK, the MTA should ONLY accept email that it can deliver.
> 
> FWIW, Mailman currently avoids doing anything about this for a 
> documented reason (scripts/post):

Right, and AFAIK all major MTAs now support the maildir format.  The
plan is for MM3 to use that as the preferred way of getting messages
into its queue, because such decoupling solves lots of problems.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051122/87870993/attachment-0001.pgp

From barry at python.org  Tue Nov 22 19:22:18 2005
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Nov 2005 13:22:18 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <87sltphz9d.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<87sltphz9d.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <1132683738.15454.37.camel@geddy.wooz.org>

On Tue, 2005-11-22 at 17:18 +0900, Stephen J. Turnbull wrote:
> >>>>> "Brad" == Brad Knowles <brad at stop.mail-abuse.org> writes:

> To get all the way to "MTA doesn't accept anything that MM is going to
> refuse to deliver", yes.  But we certainly could define an interface
> to an auxiliary service such that if the MTA tells us (AuthType,
> AuthCredentials, EnvelopeSender, Sender, From, To) we'll say "nuke it"
> or "OK, we'll handle that".  That would allow us to push a lot of
> simple cases (such as "authenticated user not a list member") back to
> the MTA, and never invoke the heavy equipment of Mailman itself.

I think that's an acceptable goal.  My own feeling is that the way to
accomplish this is through an out of band (though well-specified)
communication protocol, probably based on some standard interoperable
IPC, like XMLRPC or some such.

> It's so new it's vapor.<wink> The point is that while I worry that
> Exim and Postfix may require source patches, sendmail can be done as a
> separate milter module.  This is exactly the kind of thing that the
> milter API was designed for.

I'm fairly confident you can extend Postfix in this direction, though I
haven't done it myself.  And I'd be very surprised if you couldn't do it
in Exim, that being traditionally a very extensible MTA.

> Well, you may have a bigger problem in mind, but 90% of Mailman users
> would get a big bonus from getting only halfway there.  Or maybe you
> know something I don't.

Actually, I'll bet 90% of Mailman users won't care. :)  But the other
10% will care A LOT, so it's worth thinking about.

> Speaking for myself, I see nothing wrong with asking the bleeding edge
> adopters to change MTAs, and I see nothing wrong with restricting
> Mailman-supplied MTA code to a couple of MTAs that we "like".  Of
> course we help other MTAs to incorporate the feature, but we don't
> need to promise that they can use it in advance.  Some MTAs may never
> get it.

I definitely want us to think about ways to improve the entire tool
chain, from MTA to archiver.  I'd prefer solutions that are geared more
toward interoperable specifications first, followed by implementation
and/or patches to the tools in those chains.  For example, we can
publish X-* headers, or XMLRPC specs, etc.  By striving for MTA, web
server, and even MLM agnosticism where possible, we can push the entire
state of the art forward.

A good example of something I've looked for for a long time is an
interface between MLM and archiver, where the MLM could anticipate the
archiver URL without having to actually archive the message first.  If
we had that spec, we could include the archive URL in an X-header or a
footer when we send the copy to the list members.

> Definitely.  That's been my main theme both in this thread and in the
> SQL database thread---simply specifying requirements is a big job.
> The users know the effects they want, but UI/API/implementation
> constraints haven't been presented at all.  And users won't really be
> able to express them until they've got a prototype to work with.

One of the things I plan on doing is to get a new project wiki up where
we can start collecting all this information.  That's all part of my
plan to improve project management, which I'm personally committed to
addressing by year's end.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051122/7c74196a/attachment.pgp

From barry at python.org  Tue Nov 22 19:42:24 2005
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Nov 2005 13:42:24 -0500
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk>
	<87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <1132684944.15461.41.camel@geddy.wooz.org>

On Wed, 2005-11-23 at 01:36 +0900, Stephen J. Turnbull wrote:

> The problem isn't really that pickles are Python-specific, that's what
> Fred Brooks would call an "accidental" obstacle.  You're right, we
> could, at a fairly predictable amount of effort, convert from a
> Python-specific data store to a standard one accessible by a
> well-defined protocol such as LDAP or SQL.  The problem is that the
> data used by Mailman doesn't necessarily fit those models, and we
> won't know how hard the conversion is (ie, what effects there will be
> on various parts of Mailman) until we do it.  It's a good bet that it
> will be harder than it looks.

We actually made excellent progress at this during the last sprint (how
many months ago was that?!).  It is very difficult because IMO, an
object database is a better fit for Mailman's data model than a table.
Tools like SQLObject (which we used during the sprint) did help out a
lot, but some of the access patterns resulting in fairly convoluted
queries.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051122/c8eaf185/attachment.pgp

From barry at python.org  Tue Nov 22 20:58:47 2005
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Nov 2005 14:58:47 -0500
Subject: [Mailman-Developers] [Mailman-i18n] Ubuntu/Launchpad Rosetta
	for i18n translations?
In-Reply-To: <43823D7E.9040904@v.loewis.de>
References: <1132592943.9977.68.camel@geddy.wooz.org>
	<43823D7E.9040904@v.loewis.de>
Message-ID: <1132689527.15461.50.camel@geddy.wooz.org>

On Mon, 2005-11-21 at 22:34 +0100, "Martin v. L?wis" wrote:

> The thing that worries me (as a TP coordinator) about Rosetta and open
> translation processes is the legal copyright issues. In principle, each
> translator has the copyright to the translation, so the translator would
> need to do license the translations somehow. I'm actually unsure what
> the procedures at Rosetta are, so this might be FUD - but it should be
> clarified before making such a change.

Excellent point Martin, thanks.  I'll ask the Rosetta folks if/how they
handle these questions.

> I don't know how much mailman has to implement FSF policies (it still
> is part of the GNU project, right?): the FSF would require assignments
> from each contributor, or, in the specific case of translators, a
> signed copyright disclaimer.

I think at the least, a disclaimer is necessary, and I'm not sure how
this would be handled if translations were coordinated through Rosetta.

I'll follow up here with whatever I learn.  Thanks,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051122/4cef985a/attachment.pgp

From jwblist at loricamail.com  Tue Nov 22 19:49:23 2005
From: jwblist at loricamail.com (John W. Baxter)
Date: Tue, 22 Nov 2005 10:49:23 -0800
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <87sltphz9d.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <BFA8A833.93A4%jwblist@loricamail.com>

On 11/22/05 12:18 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> Speaking for myself, I see nothing wrong with asking the bleeding edge
> adopters to change MTAs, and I see nothing wrong with restricting
> Mailman-supplied MTA code to a couple of MTAs that we "like".  Of
> course we help other MTAs to incorporate the feature, but we don't
> need to promise that they can use it in advance.  Some MTAs may never
> get it.

None of what I'm about to say is meant to imply that the idea being
discussed is bad.  Because I don't think it is a bad idea.


You're ideas are workable, but not--easily--here.  Mail from the world and
from customers arrives (into different Exim instances) on machine 1 (which
is multiple machines in practice); the mail for mailing list addresses is
then sent to the machine running mailman (machine 2).  Machine 1 does not
run a web server, and is unlikely ever to do so (mail storage and retrieval
being over on machine 3, where web servers run for webmail only).

We don't (now, but could) do a recipient-verification callout from machine 1
to machine 2 for mail coming from the world (*), but only the addressing
would be available, not whatever content-based rejection is desired in the
Mailman configuration.  (We also could let the world talk directly to the
Mailman machine, at the cost of duplicating our greylisting (which keeps
most spam and many viruses out of Mailman) and virus filtering and
supplementary spam filtering on that machine.  We'd have to see a major
benefit to do that.

* Also, unless one's collection of local users uses non-majority MUAs (any
MUA other than Outlook and Outlook Express is statistically insignificant in
the general market), it's not a good idea to reject at SMTP time for
submissions from one's own users, because the MUAs do such a rotten job of
informing the user about the error.  (Further, some send pending messages
before retrieving, so the ISP gets support calls about "I can't get my mail"
when the problem is that they are trying to send a message with a bogus
address and don't realize that the odd little thing down in the corner is
trying to tell them that.

So, at the MTA end, it's likely that for all-purpose ISPs, only some
incoming email bound for Mailman will be checked at SMTP time (so Mailman
will continue to have to check as it does now).  Non-connectivity Mailman
host operations--unless they accept message submission directly from
MUAs--won't have that problem.



From brad at stop.mail-abuse.org  Tue Nov 22 20:13:39 2005
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Tue, 22 Nov 2005 13:13:39 -0600
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <87sltphz9d.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<87sltphz9d.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <p06200708bfa91507a73b@[192.168.1.102]>

At 5:18 PM +0900 2005-11-22, Stephen J. Turnbull wrote:

>  To get all the way to "MTA doesn't accept anything that MM is going to
>  refuse to deliver", yes.  But we certainly could define an interface
>  to an auxiliary service such that if the MTA tells us (AuthType,
>  AuthCredentials, EnvelopeSender, Sender, From, To) we'll say "nuke it"
>  or "OK, we'll handle that".  That would allow us to push a lot of
>  simple cases (such as "authenticated user not a list member") back to
>  the MTA, and never invoke the heavy equipment of Mailman itself.

	The problem is that this process is basically what Mailman goes 
through anyway, and I don't see any reason why we would want to 
develop code to duplicate all that functionality -- you'd still have 
to touch all the same Python pickles, deal with file locking 
contention, etc....  Moreover, that's going to be a heavy process, 
and MTAs have some very tight constrictions upon them to get a 
response back to the sender in a reasonable amount of time.


	I agree that the feature is desirable, but short of a complete 
ground-up rewrite, I don't see any way to do it.  Morever, as stated 
in my previous response, I think that a lot of thought needs to go 
into this before we even get to the design stage.

	Given that MM3 is already early in the implementation phase, we 
may have to wait quite a bit longer, especially since the designers 
and developers are few and far between, and what time they have is 
already very tightly spread.

>  Not "have to", but that may be the most effective way to jump start
>  it, may even be necessary for jump starting.  It's not our "job", but
>  it's something we may need to budget resources for if we want to do
>  it.  Of course if those resources are large and won't come from fresh
>  blood, that kills the idea.  But we haven't shown that the needed
>  resources are large, and there are a couple of people who I don't
>  recognize as frequent code contributors who are pushing hard---there
>  might be fresh blood out there to do this.

	If there are people who want to push forward on this now, I think 
they'll have to wait until the specifications and design phase are 
done, before they can start hacking on their favourite MTAs.  Either 
that, or everyone starts inventing their own APIs and hacking their 
MTAs to support those APIs, and then we'll have a half-dozen 
different competing solutions that we've got to try to support.

	People should definitely get some real-world experience in how to 
do this sort of stuff, but no one should have any real hope of 
getting their personal pet version incorporated into Mailman.  The 
Mailman developers might take advantage of their experience in 
designing their own API, but that's about as far as they could hope 
to go.

>  Was it?  I don't know.  My feeling is that Ian is lacking some
>  necessary facts, and consequently expressed his requirements in terms
>  that can't be satisfied.  But if we give him the details and withhold
>  judgment on the substance until he's reformulated, we might find that
>  what he really wants is a lot closer to what would be do-able than our
>  initial impressions are.

	Okay, fair enough.  Let's give him time to re-formulate what he's 
asking for.

>  I think so.  Solving them for Ian probably is not too hard.

	That depends on what MTA Ian is using, and how much code in the 
MTA that Ian is willing (and able) to hack himself, or get someone 
else to hack for him.  Likewise, there will probably be a fair amount 
of hacking on Mailman that would need to be done to support his 
particular requirements, and a lot would depend on who's going to be 
doing that hacking and how much time (and experience) they've got to 
put towards that effort.

>                                                               Solving
>  them in a way that generalizes is going to be hard.  But Python is a
>  very good environment for such generalization.

	The Python part is not the hard part of the equation.  The hard 
parts of the equation are going to be the API specification and 
design process, hacking on the MTA code, etc....

>  Well, you may have a bigger problem in mind, but 90% of Mailman users
>  would get a big bonus from getting only halfway there.  Or maybe you
>  know something I don't.

	I disagree.  I don't think a 50% solution is going to help many 
people, and it certainly won't help them for long.

	It will just push out the event horizon a bit, and since we have 
exponential growth of spam and other forms of mail abuse, it's going 
to be a very short period of time before we're right back where we 
were -- and where there are no more easy 50% solutions possible, and 
where we have yet to spend any time stepping back from the problem a 
bit and working on a better 80-90% solution.

>          Of course you meant something substantially weaker than "all
>  MTAs must understand as an absolute requirement", but surely it was
>  something at least as strong as "we cannot ask users to change MTAs to
>  get this feature."  Agreed?

	If they're using any of the mainstream MTAs, then they should be 
able to expect that they can use virtually all of the features of 
Mailman.  They might be able to use other programs to fulfill other 
components of the system (e.g., the people who use mhonarc instead of 
pipermail), but that should be an optional additional extra 
enhancement that they can add to the base system.

	As I see it, the kind of thing you're talking about would be a 
core component, one that could not be easily changed or substituted, 
and if it's going to be useful at all it will need to support all the 
major MTAs -- or be supported by them.

>  Speaking for myself, I see nothing wrong with asking the bleeding edge
>  adopters to change MTAs, and I see nothing wrong with restricting
>  Mailman-supplied MTA code to a couple of MTAs that we "like".  Of
>  course we help other MTAs to incorporate the feature, but we don't
>  need to promise that they can use it in advance.  Some MTAs may never
>  get it.

	The problem is that there are way too many whackos who then take 
those bleeding edge features and throw them into CPanel or a 
vendor-proprietary version, and then dump off the after-sales support 
onto us.

	And way too many whackos will take whatever code is available and 
blindly install it, without really understanding that they need to 
have a certain minimum level of competence before they take bleeding 
edge code and try to start working with it.


	Many vendors restrict who has access to development beta code, 
and for good reason.  If you're a MM3 developer or want to be, then 
you should be free to play with that code about as much as you want 
-- after all, the only risk should be to you and your mailing lists.

	But you should anticipate that many people may expect you to hack 
on the code yourself to fix whatever problems you may end up creating 
for yourself.

>  OTOH, I wonder if you're not overestimating the degree of difficulty
>  and underestimating the benefits of the structural work required.

	I don't think I'm underestimating the benefits of the structural 
work.  We won't know whether I'm overestimating the degree of 
difficulty until the actual work is done and we can look back and see 
what it took to get where we did.

>  The "database backend" is _not_ structured that way yet,

	Which is a large component of my caution on this topic.  Code 
hacking is easy.  Database hacking is harder, because you've not only 
got to hack the code which accesses the database, but also the 
database structures that would be accessed.  More importantly, since 
you're talking about exposing some aspect of this database structure 
to the outside world, you can't just take the easy way out and 
directly access everything but you instead have to work through a 
published API layer.

	In programming, global variables make a lot of things easier in 
one aspect, but they greatly complicate life in others.  It takes 
more work to write code in such a way to avoid global variables, but 
in the end it usually pays off.

	Working through published API layers has a lot of benefits too, 
but it also takes a lot more work to make that happen -- compare the 
classic C version of "Hello, world" to what you have to do to get the 
same results with a standard X11 library.  The source of the X11 
version is likely to be many times larger than the compiled code of 
the C version.


	In this case, you're asking us to create the equivalent of the 
X11 API and library, plus the associated database structures, etc....

	Yes, we most likely have a smaller overall problem space, but we 
also have many fewer programmers, each of whom is probably spending 
less time on this work, and there are many classes of pre-existing 
programs that we will have to somehow find interoperability with.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From iane at sussex.ac.uk  Wed Nov 23 12:33:38 2005
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Wed, 23 Nov 2005 11:33:38 +0000
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <87zmnwfuz1.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk>
	<87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>
	<CA7C8E92-2E0C-4F1E-824F-497E1F4E1E12@sussex.ac.uk>
	<87zmnwfuz1.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <39F2474C-C121-42B4-B1F0-AD7249DF7792@sussex.ac.uk>


On 22 Nov 2005, at 17:33, Stephen J. Turnbull wrote:

>>>>>> "Ian" == Ian Eiloart <iane at sussex.ac.uk> writes:
>
>     Ian> Now, sender ACL's already are *just* lists of regular
>     Ian> expressions. So, what's so hard?
>
> You're aware that "regular expression" is not exactly well-defined,
> and that python REs are a unique dialect among regular expression
> languages?

Yes, I'm aware of that. It is an issue that users will have to be  
aware of. However, I don't think it's a killer. I think Python  
regular expressions have enough in common with the PCRE (perl  
compatible regular expressions) library to be useful. For example, I  
think ^[^@]*@(.*\.)?sus(se)?\.ac\.uk$ has the same meaning in both  
dialects.

If I'm wrong, then I can make do with .*sussex\.ac\.uk$ and .*susx\.ac 
\.uk$



-- 
Ian Eiloart
Postmaster,
IT Services
University of Sussex




From fil at rezo.net  Wed Nov 23 12:38:46 2005
From: fil at rezo.net (Fil)
Date: Wed, 23 Nov 2005 12:38:46 +0100
Subject: [Mailman-Developers] MysqlMemberships.py
In-Reply-To: <20051121105340.GG4355@rezo.net>
References: <PC1740200511190949200656389eaac4@msapiro>
	<PC17402005112011540207967151eb5e@msapiro>
	<20051120200928.GH32641@rezo.net> <20051120201605.GI32641@rezo.net>
	<20051121105340.GG4355@rezo.net>
Message-ID: <20051123113846.GB13624@rezo.net>

> Unfortunately this still doesn't succeed reconnecting to the server: I get
> this traceback:
> 
>   File "/var/local/mailman/Mailman/MysqlMemberships.py", line 141, in _prodServerConnection
>     if self.connection.ping() == 0: OperationalError: (2006, 'MySQL server has gone away')

A little bit of hacking makes this problem less painful, but I'm sure I got
it wrong, or it is that my MySQL server "goes away" quite a lot. I don't
know for sure, anyway, but if you're currently trying my version of
MysqlMemberships.py you might want to update

the patch is @ http://trac.rezo.net/trac/rezo/changeset/59

-- Fil

From barry at python.org  Wed Nov 23 23:55:13 2005
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Nov 2005 17:55:13 -0500
Subject: [Mailman-Developers] A better way of doing templates?
Message-ID: <1132786513.20488.153.camel@geddy.wooz.org>

Jordi Mallach brings up a good point on the rosetta-users mailing list,
in response to my queries there.

Rosetta doesn't really work with non-po files, so the fact that we have
templates that need translating will cause us some grief.  Well, even
more grief than it has over the years. ;)

Does anybody have any good ideas for handling this in the Mailman 2
tree?  For MM3, it's a top priority that any templating system we use
must support po-ification for i18n.  For Mailman 2.2 it's more difficult
because I don't think we should adopt an entirely new template system.
It's even worse for 2.1 because we're not accepting new features,
although if we came up with something simple and minimally disruptive,
I'd consider it for the benefit of improving the translation process.

Ideas are welcome!
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051123/f4589125/attachment.pgp

From jwblist at loricamail.com  Wed Nov 23 23:16:06 2005
From: jwblist at loricamail.com (John W. Baxter)
Date: Wed, 23 Nov 2005 14:16:06 -0800
Subject: [Mailman-Developers] MysqlMemberships.py
In-Reply-To: <20051123113846.GB13624@rezo.net>
Message-ID: <BFAA2A26.9451%jwblist@loricamail.com>

On 11/23/05 3:38 AM, "Fil" <fil at rezo.net> wrote:

>> Unfortunately this still doesn't succeed reconnecting to the server: I get
>> this traceback:
>> 
>>   File "/var/local/mailman/Mailman/MysqlMemberships.py", line 141, in
>> _prodServerConnection
>>     if self.connection.ping() == 0: OperationalError: (2006, 'MySQL server
>> has gone away')
> 
> A little bit of hacking makes this problem less painful, but I'm sure I got
> it wrong, or it is that my MySQL server "goes away" quite a lot. I don't
> know for sure, anyway, but if you're currently trying my version of
> MysqlMemberships.py you might want to update
> 
> the patch is @ http://trac.rezo.net/trac/rezo/changeset/59
> 
> -- Fil


What sort of setting does the MySQL server you are running have for timing
out idle connections?  Could it be that you aren't "hitting" it often
enough?  In which case, going away a lot is normal.

(I have that problem regularly with a desktop query client (CocoaMySQL for
Mac OS X).  It responds to a vanished connection by hanging unresponsively
until killed...your code is clearly better than that.  ;-))

  --John



From tkikuchi at is.kochi-u.ac.jp  Thu Nov 24 02:44:19 2005
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Thu, 24 Nov 2005 10:44:19 +0900
Subject: [Mailman-Developers] A better way of doing templates?
In-Reply-To: <1132786513.20488.153.camel@geddy.wooz.org>
References: <1132786513.20488.153.camel@geddy.wooz.org>
Message-ID: <43851AF3.7060303@is.kochi-u.ac.jp>

Hi,

Barry Warsaw wrote:
> Jordi Mallach brings up a good point on the rosetta-users mailing list,
> in response to my queries there.
> 
> Rosetta doesn't really work with non-po files, so the fact that we have
> templates that need translating will cause us some grief.  Well, even
> more grief than it has over the years. ;)
> 
> Does anybody have any good ideas for handling this in the Mailman 2
> tree?

How about adding current templates into pot/po and pickup and generate
language templates during "make install."  I don't know if it could be
done at all but I will look at it this weekend.

As regards the whole translation process, I've already submitted a patch
 to select languages when configuring.  This should help separating the
translations from the main developement code base.
http://sourceforge.net/tracker/index.php?func=detail&aid=1298355&group_id=103&atid=300103

-- 
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/

From stephen at xemacs.org  Thu Nov 24 05:41:31 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 24 Nov 2005 13:41:31 +0900
Subject: [Mailman-Developers] PHP Wrappers?
In-Reply-To: <39F2474C-C121-42B4-B1F0-AD7249DF7792@sussex.ac.uk> (Ian
	Eiloart's message of "Wed, 23 Nov 2005 11:33:38 +0000")
References: <fc.001d0211006ff51a001d0211006ff51a.70084d@whatifnet.com>
	<437b81ed-f30b@Islandnet.com> <437BA4FF.6090003@cruciverb.com>
	<0B8F1780-E4BA-4C98-B24E-4034AF5921F5@sussex.ac.uk>
	<p06200776bfa24b0c437e@[192.168.1.102]>
	<E55A3F7C-643D-4237-8E30-2630DC8343C2@sussex.ac.uk>
	<p0620077fbfa4770b93dd@[192.168.1.102]>
	<3A2A6A35-AC9C-4FFA-8666-801CC14E4CEC@sussex.ac.uk>
	<p06200701bfa80a1a1b74@[192.168.1.102]>
	<878xvhjkjd.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06200706bfa864453d9a@[192.168.1.102]>
	<DACCA260-8E47-4654-9F5E-E388F89C2F46@sussex.ac.uk>
	<87hda4hc6t.fsf@tleepslib.sk.tsukuba.ac.jp>
	<CA7C8E92-2E0C-4F1E-824F-497E1F4E1E12@sussex.ac.uk>
	<87zmnwfuz1.fsf@tleepslib.sk.tsukuba.ac.jp>
	<39F2474C-C121-42B4-B1F0-AD7249DF7792@sussex.ac.uk>
Message-ID: <877jayfyis.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Ian" == Ian Eiloart <iane at sussex.ac.uk> writes:

    Ian> I think Python regular expressions have enough in common with
    Ian> the PCRE (perl compatible regular expressions) library to be
    Ian> useful. For example, I think ^[^@]*@(.*\.)?sus(se)?\.ac\.uk$
    Ian> has the same meaning in both dialects.

    Ian> If I'm wrong, then I can make do with .*sussex\.ac\.uk$ and
    Ian> .*susx\.ac \.uk$

The semantics of what you just posted are "I would like Mailman to
impose and maintain a hack appropriate to my site on all users of this
facility."  I see the attraction of this proposal for a fair number of
users like you, and it's precisely what open source is for: you can
maintain your own variant, in cooperation with those other users.

But when I suggested a 50% solution would be good enough, the 50% I
meant was precisely what you're leaving out: a specification of the
syntax (you deliberately leave the syntax vague!) and semantics of the
data that Mailman passes to the MTA.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From fil at rezo.net  Thu Nov 24 10:12:40 2005
From: fil at rezo.net (Fil)
Date: Thu, 24 Nov 2005 10:12:40 +0100
Subject: [Mailman-Developers] MysqlMemberships.py
In-Reply-To: <BFAA2A26.9451%jwblist@loricamail.com>
References: <20051123113846.GB13624@rezo.net>
	<BFAA2A26.9451%jwblist@loricamail.com>
Message-ID: <20051124091240.GP13624@rezo.net>

> What sort of setting does the MySQL server you are running have for timing
> out idle connections?  Could it be that you aren't "hitting" it often
> enough?  In which case, going away a lot is normal.

Right. It's optimized for apache (short connexions), so I guess it's normal :)

-- Fil


From maxb1 at ukf.net  Fri Nov 25 11:23:22 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Fri, 25 Nov 2005 10:23:22 +0000
Subject: [Mailman-Developers] Handlers/SpamDetect.py 'Accept' action does
 not interact well with other access-control handlers
Message-ID: <4386E61A.1040103@ukf.net>

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

If I set up an Accept rule in header_filter_rules, it does not truly
accept the message.

Instead, it only causes the individual handler, SpamDetect.py, to accept
the message. Any further handler in the pipeline may cause a
hold/reject/discard in spute of the accept header_filter_rule.


In particular, messages accepted by header_filter_rules will still be
subjected to *_these_nonmembers and generic_nonmember_action.


This makes it impossible to use header_filter_rules to accept only real
automated commit/bugtracker notification emails, whilst not accepting
spam that forges the automated notifier address.

Max.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDhuYafFNSmcDyxYARAiy8AJ999p8RE8jNBmMEE2jg+FpJ4le+YACghJhA
6DZrKR/jRl1XzuqC59s4/SM=
=FLNz
-----END PGP SIGNATURE-----

From maxb1 at ukf.net  Fri Nov 25 22:12:59 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Fri, 25 Nov 2005 21:12:59 +0000
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
Message-ID: <43877E5B.404@ukf.net>

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

I've taken over responsibility for an old Mailman installation which
used to be configured with incorrect vhost information. As a result,
web_page_url is incorrect for many lists.

I have found the info about using config_list to adjust web_page_url,
and now I have some questions/suggestions:

Is there any reason not to add web_page_url to the configurable options
in the admin GUI? Right below host_name in the general category would be
a good place.

Or, if the web_page_url is to remain hidden, should it not be
re-calculated based on the current mm_cfg.py settings whenever the
host_name setting for a list is changed - or even, calculated every time
that information is required?


Thanks,

Max.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDh35bfFNSmcDyxYARAnY/AJwIKOQvvDevwtunG2+iLhOBI/AUiACfZAoS
Hth3dW+nc6NWmFNax7cndf0=
=KsI8
-----END PGP SIGNATURE-----

From stephen at xemacs.org  Sat Nov 26 10:25:58 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 26 Nov 2005 18:25:58 +0900
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <43877E5B.404@ukf.net> (Max Bowsher's message of "Fri, 25 Nov
	2005 21:12:59 +0000")
References: <43877E5B.404@ukf.net>
Message-ID: <87br0769qx.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Max" == Max Bowsher <maxb1 at ukf.net> writes:

    Max> Is there any reason not to add web_page_url to the
    Max> configurable options in the admin GUI? Right below host_name
    Max> in the general category would be a good place.

Yes, please!


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From jwblist at loricamail.com  Sat Nov 26 17:02:49 2005
From: jwblist at loricamail.com (John W. Baxter)
Date: Sat, 26 Nov 2005 08:02:49 -0800
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <87br0769qx.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <BFADC729.9571%jwblist@loricamail.com>

On 11/26/05 1:25 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

>>>>>> "Max" == Max Bowsher <maxb1 at ukf.net> writes:
> 
>     Max> Is there any reason not to add web_page_url to the
>     Max> configurable options in the admin GUI? Right below host_name
>     Max> in the general category would be a good place.
> 
> Yes, please!
> 

Yes, there is a reason.  It is the same reason that the ability was taken
out many Mailman versions ago.

Thought experiment:
1.  Make a typo which cripples the URL such that you can't reach the admin
web page.

2.  Now fix it from the browser.

The sort of thing in #1 (sometimes not a typo but a more fundamental
mistake) happened often enough to make removing the ability seem quite
desirable.

One thing which has changed since the decision is that a much higher
proportion of list operators don't have command line access than was the
case then.  So *perhaps* it would make sense to revisit the decision (making
it a site option, please).

  --John



From stephen at xemacs.org  Sat Nov 26 19:58:42 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 27 Nov 2005 03:58:42 +0900
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <BFADC729.9571%jwblist@loricamail.com> (John W. Baxter's
	message of "Sat, 26 Nov 2005 08:02:49 -0800")
References: <BFADC729.9571%jwblist@loricamail.com>
Message-ID: <878xvb2q3h.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "John" == John W Baxter <jwblist at loricamail.com> writes:

    John> Thought experiment: 1.  Make a typo which cripples the URL
    John> such that you can't reach the admin web page.

I actually don't care what the admin URL(s) are.  That's what
bookmarks are for, and my list admins can learn to use them, too, or
they can be ex-admins.

What I would like is for it to be (a lot) easier to change the user
URLs, because there presentation matters.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From cfmd at bredband.net  Sat Nov 26 14:04:47 2005
From: cfmd at bredband.net (Magnus Danielson)
Date: Sat, 26 Nov 2005 14:04:47 +0100 (CET)
Subject: [Mailman-Developers] Default Spam Header Filter Rules hack
Message-ID: <20051126.140447.15403311.cfmd@bredband.net>

Hi!

As I am working on setting up a multilist/multidomain setup using
Mailman 2.1.6, I encountered the need that I wanted to be able to set the
default header filter rules so that the lists I create will all have the same
basic rule (since we concluded we want one as default). It proved to be a
fairly small hack, so I thought I contribute it to you.

diff MailList.py.orig MailList.py
342c342,343
<         self.header_filter_rules = []
---
>         self.header_filter_rules = \
>               mm_cfg.DEFAULT_HEADER_FILTER_RULES

diff Defaults.py.orig Defaults.py
908a909,918
> # New style SPAM Privacy header filtering
> # Mailman can match the patterns of header content and decide upon different
> # actions (Defer, Hold, Reject Discard and Accept). These properties is
> # configured per list, and here can the list default be set.
> # A list of rules where each entry contains the matching string, the action
> # code and an empty flag (set False).
> # Example (discard mails marked by SpamAssassin):
> #DEFAULT_HEADER_FILTER_RULES = [('X-Spam-Status: Yes', DISCARD, False)]
> DEFAULT_HEADER_FILTER_RULES = []
> 

OK, it certainly could be cleaned up in the aspect of comments/documentation,
but it should be the trivia part for you guys. It has been tested to work.

Cheers,
Magnus

From maxb1 at ukf.net  Sat Nov 26 20:03:49 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Sat, 26 Nov 2005 19:03:49 +0000
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <BFADC729.9571%jwblist@loricamail.com>
References: <BFADC729.9571%jwblist@loricamail.com>
Message-ID: <4388B195.30501@ukf.net>

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

John W. Baxter wrote:
> On 11/26/05 1:25 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> 
>>>>>>>"Max" == Max Bowsher <maxb1 at ukf.net> writes:
>>
>>    Max> Is there any reason not to add web_page_url to the
>>    Max> configurable options in the admin GUI? Right below host_name
>>    Max> in the general category would be a good place.
>>
>>Yes, please!
> 
> Yes, there is a reason.  It is the same reason that the ability was taken
> out many Mailman versions ago.
> 
> Thought experiment:
> 1.  Make a typo which cripples the URL such that you can't reach the admin
> web page.
> 
> 2.  Now fix it from the browser.
> 
> The sort of thing in #1 (sometimes not a typo but a more fundamental
> mistake) happened often enough to make removing the ability seem quite
> desirable.
> 
> One thing which has changed since the decision is that a much higher
> proportion of list operators don't have command line access than was the
> case then.  So *perhaps* it would make sense to revisit the decision (making
> it a site option, please).

OK, that is a good reason.

Still, sometimes it really is necessary to change web_page_url. So here
are two different possibilities for providing some amount of
web_page_url control through the admin GUI, whilst avoiding the
possibility of typos blocking web admin access:

OPTION ONE: Whenever the host_name configvar is changed, *if* the new
value can be found in mm_cfg.VIRTUAL_HOSTS, *then* recalculate
web_page_url based on mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.VIRTUAL_HOSTS.


OPTION TWO: Make links and form action URLs within the admin interface
relative, so that an incorrect web_page_url does not render the admin
interface inoperable.


What do you think? Either? Both?

Thanks,

Max.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDiLGVfFNSmcDyxYARAhZyAJ4n9mKI7AgnHiVbLLFjFG6nt5UE1ACgwyT+
AvLCTzCXVRxKx8Q3l6f+dBs=
=Di43
-----END PGP SIGNATURE-----

From maxb1 at ukf.net  Sat Nov 26 20:05:28 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Sat, 26 Nov 2005 19:05:28 +0000
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <878xvb2q3h.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <BFADC729.9571%jwblist@loricamail.com>
	<878xvb2q3h.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <4388B1F8.3000404@ukf.net>

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

Stephen J. Turnbull wrote:
>>>>>>"John" == John W Baxter <jwblist at loricamail.com> writes:
> 
> 
>     John> Thought experiment: 1.  Make a typo which cripples the URL
>     John> such that you can't reach the admin web page.
> 
> I actually don't care what the admin URL(s) are.  That's what
> bookmarks are for, and my list admins can learn to use them, too, or
> they can be ex-admins.
> 
> What I would like is for it to be (a lot) easier to change the user
> URLs, because there presentation matters.

Actually, I think the point John was making was that if web_page_url is
set incorrectly, the admin UI becomes inoperable, because it uses
absolute URLs generated using web_page_url to make links and form
submission URLs.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDiLH4fFNSmcDyxYARAo3HAJ9X7Fwb90Yha27+iEHjaunmWV4mmACgw9Hk
A7a/TYYAo63ITW+nVf1YOIA=
=jHQf
-----END PGP SIGNATURE-----

From lists05 at equinephotoart.com  Sat Nov 26 21:49:00 2005
From: lists05 at equinephotoart.com (JC Dill)
Date: Sat, 26 Nov 2005 12:49:00 -0800
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <BFADC729.9571%jwblist@loricamail.com>
References: <BFADC729.9571%jwblist@loricamail.com>
Message-ID: <4388CA3C.6040303@equinephotoart.com>

John W. Baxter wrote:

>>>>>>>"Max" == Max Bowsher <maxb1 at ukf.net> writes:
>>
>>    Max> Is there any reason not to add web_page_url to the
>>    Max> configurable options in the admin GUI? Right below host_name
>>    Max> in the general category would be a good place.

> Yes, there is a reason.  It is the same reason that the ability was taken
> out many Mailman versions ago.
> 
> Thought experiment:
> 1.  Make a typo which cripples the URL such that you can't reach the admin
> web page.

As I read it, Max's request is to be able to set the URL to the user
webpage, not for the admin webpage.  Then the right URL will show up in
the list footer, etc.

> 2.  Now fix it from the browser.
> 
> The sort of thing in #1 (sometimes not a typo but a more fundamental
> mistake) happened often enough to make removing the ability seem quite
> desirable.
> 
> One thing which has changed since the decision is that a much higher
> proportion of list operators don't have command line access than was the
> case then.  So *perhaps* it would make sense to revisit the decision (making
> it a site option, please).

How about an option to set a new URL as the "default for displaying in
the footer" (and archives, and elsewhere within your list's web
structure), while still maintaining an alias (or having the new URL be 
the alias) to the machine address.

That way the machine address will always work and give you a way to
reach your list via the default machine name/listname path if you make a
typo or otherwise change the URL in a way that doesn't work.

As an example, this list is at:

http://mail.python.org/mailman/listinfo/mailman-developers

We could add a function to let the list admin set a "default URL".  If
Barry wanted to change this list to:

http://www.list.org/mailman/listinfo/mailman-developers

Then this would be the new URL displayed in the list footer, and mail
sent to mailman-developers at list.org would be sent on to the list
membership etc, BUT we could still always reach the list thru the
original (default servername) URL and email address.

jc



From maxb1 at ukf.net  Sat Nov 26 22:00:00 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Sat, 26 Nov 2005 21:00:00 +0000
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <4388CA3C.6040303@equinephotoart.com>
References: <BFADC729.9571%jwblist@loricamail.com>
	<4388CA3C.6040303@equinephotoart.com>
Message-ID: <4388CCD0.5020406@ukf.net>

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

JC Dill wrote:
> John W. Baxter wrote:
> 
>>>>>>>>"Max" == Max Bowsher <maxb1 at ukf.net> writes:
>>>
>>>   Max> Is there any reason not to add web_page_url to the
>>>   Max> configurable options in the admin GUI? Right below host_name
>>>   Max> in the general category would be a good place.
> 
> 
>>Yes, there is a reason.  It is the same reason that the ability was taken
>>out many Mailman versions ago.
>>
>>Thought experiment:
>>1.  Make a typo which cripples the URL such that you can't reach the admin
>>web page.
> 
> 
> As I read it, Max's request is to be able to set the URL to the user
> webpage, not for the admin webpage.  Then the right URL will show up in
> the list footer, etc.

No, not at all.

Mailman doesn't really have two distinct web interfaces. It has a single
web interface, portions of which are restricted to administrators.


>>2.  Now fix it from the browser.
>>
>>The sort of thing in #1 (sometimes not a typo but a more fundamental
>>mistake) happened often enough to make removing the ability seem quite
>>desirable.
>>
>>One thing which has changed since the decision is that a much higher
>>proportion of list operators don't have command line access than was the
>>case then.  So *perhaps* it would make sense to revisit the decision (making
>>it a site option, please).
> 
> 
> How about an option to set a new URL as the "default for displaying in
> the footer" (and archives, and elsewhere within your list's web
> structure), while still maintaining an alias (or having the new URL be 
> the alias) to the machine address.
> 
> That way the machine address will always work and give you a way to
> reach your list via the default machine name/listname path if you make a
> typo or otherwise change the URL in a way that doesn't work.
> 
> As an example, this list is at:
> 
> http://mail.python.org/mailman/listinfo/mailman-developers
> 
> We could add a function to let the list admin set a "default URL".  If
> Barry wanted to change this list to:
> 
> http://www.list.org/mailman/listinfo/mailman-developers
> 
> Then this would be the new URL displayed in the list footer, and mail
> sent to mailman-developers at list.org would be sent on to the list
> membership etc, BUT we could still always reach the list thru the
> original (default servername) URL and email address.

So, then you have one address considered canonical for users and another
 considered canonical for administrators?

Umm... sounds like a recipe for confusion to me.

See my previous mail containing proposals for "OPTION ONE" and "OPTION
TWO", for two ways I think would be a better approach.


Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDiMzPfFNSmcDyxYARAmhaAJ9IMj+jLEyaMLhPR4GRpz1qOpiDZgCgua4w
DRqb+MDr8gqvbbJVRcryd9U=
=qVYS
-----END PGP SIGNATURE-----

From lists05 at equinephotoart.com  Sat Nov 26 22:16:43 2005
From: lists05 at equinephotoart.com (JC Dill)
Date: Sat, 26 Nov 2005 13:16:43 -0800
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <4388CCD0.5020406@ukf.net>
References: <BFADC729.9571%jwblist@loricamail.com>
	<4388CA3C.6040303@equinephotoart.com> <4388CCD0.5020406@ukf.net>
Message-ID: <4388D0BB.2040706@equinephotoart.com>

Max Bowsher wrote:

>Mailman doesn't really have two distinct web interfaces. It has a single
>web interface, portions of which are restricted to administrators.
>  
>
That isn't important to the issue, is it?

As I understand it, your issue is what URL is "shown".  My suggestion is 
that we make a change to the code that allows list administrators to 
change what URL is "shown" to list users.  The new URL will also work 
for list administrators, but the default URL will *also* continue to work.

>
>
>So, then you have one address considered canonical for users and another
> considered canonical for administrators?
>  
>
No.  You have one address that *always* works (the server name address) 
and the option to add another address that also works (assuming you 
didn't make any errors when you configured the additional URL) and which 
is the address displayed on the email footer, list help pages, etc.

For instance, many websites that are hosted on virtual domains can be 
reached thru several different URLs (options vary from host to host):

www.domain.com  (the preferred URL, obviously)
www.host.com/domain.com
www.host.com/~username
www.host.com/user/~username
www.host.com/user/domain.com

Etc.  Only one of these (at most) is the "real" URL to the directory to 
the domain files on the server.  The others are aliases to the same 
directory.  We can do the same thing with mailman, add an alias and mark 
the alias as the "preferred" URL to be used and displayed on the list 
webpages and mail footers.

jc




From maxb1 at ukf.net  Sun Nov 27 00:22:32 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Sat, 26 Nov 2005 23:22:32 +0000
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <4388D0BB.2040706@equinephotoart.com>
References: <BFADC729.9571%jwblist@loricamail.com>	<4388CA3C.6040303@equinephotoart.com>
	<4388CCD0.5020406@ukf.net> <4388D0BB.2040706@equinephotoart.com>
Message-ID: <4388EE38.4090903@ukf.net>

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

JC Dill wrote:
> Max Bowsher wrote:
> 
>>Mailman doesn't really have two distinct web interfaces. It has a single
>>web interface, portions of which are restricted to administrators.
> 
> That isn't important to the issue, is it?

You said:
  "As I read it, Max's request is to be able to set
   the URL to the user webpage, not for the admin webpage."

My point in saying what I did was that 'the URL to the user webpage' and
 'the URL for the admin webpage' are not independently settable entities.
They are, in fact, identical, just one has things like 'listinfo' or
'options' appended, whilst the other has things like 'admin' or
'admindb' appended.

> As I understand it, your issue is what URL is "shown".  My suggestion is 
> that we make a change to the code that allows list administrators to 
> change what URL is "shown" to list users.  The new URL will also work 
> for list administrators, but the default URL will *also* continue to work.
> 
>>So, then you have one address considered canonical for users and another
>>considered canonical for administrators?
> 
> No.  You have one address that *always* works (the server name address) 
> and the option to add another address that also works (assuming you 
> didn't make any errors when you configured the additional URL) and which 
> is the address displayed on the email footer, list help pages, etc.
> 
> For instance, many websites that are hosted on virtual domains can be 
> reached thru several different URLs (options vary from host to host):
> 
> www.domain.com  (the preferred URL, obviously)
> www.host.com/domain.com
> www.host.com/~username
> www.host.com/user/~username
> www.host.com/user/domain.com
> 
> Etc.  Only one of these (at most) is the "real" URL to the directory to 
> the domain files on the server.  The others are aliases to the same 
> directory.  We can do the same thing with mailman, add an alias and mark 
> the alias as the "preferred" URL to be used and displayed on the list 
> webpages and mail footers.

You are talking about very approximately the same issue as I am, but you
are approaching it from a different direction, and speaking about it in
abstract ways, which, as far as I can see, become partially irrelevant
and/or incompatible when applied to Mailman specifically.

First incompatibility:
At the moment, the Mailman interface uses absolute URLs based on
web_page_url all over the place. This has two consequences: First, even
if you have multiple URLs configured in your web server to reach the
Mailman interface, the moment follow a link or submit a form, you will
end up using the URL defined by web_page_url.
Second: If Mailman isn't actually visible at the URL defined by
web_page_url, the web interface will be inoperable, even if you manually
 type an URL at which it is visible, since all links and form submission
destinations will be invalid.


Second incompatibility:
You are talking about adding a feature to set the preferred URL. But
this is what web_page_url already is!!!



Taking account of those incompatibilities and modifying your suggestion
accordingly, I think what is reached is essentially what I suggested
headed by "OPTION TWO" in my mail that I previously referred you to.

Restating:
  Make links and form action URLs within the admin interface
  relative, so that an incorrect web_page_url does not render
  the admin interface inoperable.

and the earlier context in that mail implied '... and then it will be
safe for web_page_url to be a normally accessible configvar in the web UI.


Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDiO44fFNSmcDyxYARAkQwAJ4ts7WFBg8IGpEFrnSfn/iicYKjIwCg3huT
rCb7rzTiNA9KewHMZR/v5Yc=
=4LCB
-----END PGP SIGNATURE-----

From asmodai at in-nomine.org  Sun Nov 27 10:06:22 2005
From: asmodai at in-nomine.org (Jeroen Ruigrok/asmodai)
Date: Sun, 27 Nov 2005 10:06:22 +0100
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <4388EE38.4090903@ukf.net>
References: <BFADC729.9571%jwblist@loricamail.com>
	<4388CA3C.6040303@equinephotoart.com> <4388CCD0.5020406@ukf.net>
	<4388D0BB.2040706@equinephotoart.com> <4388EE38.4090903@ukf.net>
Message-ID: <20051127090621.GJ51142@nexus.ninth-circle.org>

-On [20051127 00:23], Max Bowsher (maxb1 at ukf.net) wrote:
>Second incompatibility:
>You are talking about adding a feature to set the preferred URL. But
>this is what web_page_url already is!!!

Read again, he is not talking about adding a preferred URL option, but
rather explaining what the web_page_url feature could accomplish (since
there seemed to be confusion about what it would do).

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
Free Tibet! http://www.savetibet.org/ | http://www.andf.info/
http://www.tendra.org/ | http://www.in-nomine.org/ | catcher at in-nomine.org
Felix, qui potuit rerum cognoscere causas...

From tanner at real-time.com  Sun Nov 27 04:50:51 2005
From: tanner at real-time.com (Bob Tanner)
Date: Sat, 26 Nov 2005 21:50:51 -0600
Subject: [Mailman-Developers] Parsing templates with '%' in them?
Message-ID: <dmbaeu$p9o$1@sea.gmane.org>

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

I wanted to change the article.html template and do some CSS in it, but I
found mailman -silently- failed to parse the template files.

I've submitted the attached patch to at least log the fact the template
parsing failed.

- ----------------------- snip --------------------------------
- --- HyperArch.py        2003-12-26 14:41:30.000000000 -0600
+++ HyperArch.py-bob    2005-11-23 03:19:13.000000000 -0600
@@ -217,8 +217,9 @@
                                     Utils.GetCharSet(lang),
                                     'replace')
                 text = sdict.interpolate(utemplate)
- -        except (TypeError, ValueError):
+        except (TypeError, ValueError), e:
             # The template is really screwed up
+            syslog('error', 'The template is really screwed up: %s\n', e)
             pass
     # Make sure the text is in the given character set, or html-ify any
     # bogus
     # characters.
- ----------------------- snip --------------------------------

Next, I could not seem to isolate the "bug", but my CSS had the following
entries:

        div#main {
        margin-right: 20%;
        }
        div#menu {
        width: 15%;
        float: right;
        }

The html template parser was failing on the 20% and the 15%, looking like it
was keying off the '%' for key=value in the SafeDict class and failing.

I "solved" the problem by making the CSS an external html reference, but I
thought I'd post this info to the developer list as a FYI.


- -- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDiS0bfPGnCSzBsogRAjO2AJ94i5AM4VyQbMGTppwwILeygUALSwCdHpkj
mw8ylEsCQxXZzqKfSAFbxiw=
=rTtc
-----END PGP SIGNATURE-----


From stephen at xemacs.org  Mon Nov 28 04:19:54 2005
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 28 Nov 2005 12:19:54 +0900
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <4388EE38.4090903@ukf.net> (Max Bowsher's message of "Sat, 26
	Nov 2005 23:22:32 +0000")
References: <BFADC729.9571%jwblist@loricamail.com>
	<4388CA3C.6040303@equinephotoart.com> <4388CCD0.5020406@ukf.net>
	<4388D0BB.2040706@equinephotoart.com> <4388EE38.4090903@ukf.net>
Message-ID: <87ek51zcf9.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Max" == Max Bowsher <maxb1 at ukf.net> writes:

    Max> My point in saying what I did was that 'the URL to the user
    Max> webpage' and 'the URL for the admin webpage' are not
    Max> independently settable entities.  They are, in fact,
    Max> identical, just one has things like 'listinfo' or 'options'
    Max> appended, whilst the other has things like 'admin' or
    Max> 'admindb' appended.

Right.  That has to be changed for me to get what I want.

What I would like to see is a structure where we have

# sitewide
site_base_url        # the default URL for all Mailman stuff at the site
                     # used for all admin pages at the site
# list-specific
list_base_url        # the URL for the list member stuff, archives, etc
                     # defaults to site_base_url

It seems like that's not what you want, and that's OK with me.  I can
live without this and it would probably be a fair amout of work to get
right.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

From barry at python.org  Mon Nov 28 09:09:16 2005
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Nov 2005 03:09:16 -0500
Subject: [Mailman-Developers] Make web_page_url visible in the admin	GUI?
In-Reply-To: <4388B195.30501@ukf.net>
References: <BFADC729.9571%jwblist@loricamail.com>  <4388B195.30501@ukf.net>
Message-ID: <1133165356.1376.17.camel@geddy.wooz.org>

On Sat, 2005-11-26 at 19:03 +0000, Max Bowsher wrote:

> OPTION TWO: Make links and form action URLs within the admin interface
> relative, so that an incorrect web_page_url does not render the admin
> interface inoperable.

I think ultimately, it would be great if the urls could all be relative,
but that was tried in the past and caused worlds of hurt, so everything
was changed to absolute urls.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051128/11a8eb5f/attachment.pgp

From barry at python.org  Mon Nov 28 09:11:56 2005
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Nov 2005 03:11:56 -0500
Subject: [Mailman-Developers] Make web_page_url visible in the admin	GUI?
In-Reply-To: <4388D0BB.2040706@equinephotoart.com>
References: <BFADC729.9571%jwblist@loricamail.com>
	<4388CA3C.6040303@equinephotoart.com> <4388CCD0.5020406@ukf.net>
	<4388D0BB.2040706@equinephotoart.com>
Message-ID: <1133165516.1377.18.camel@geddy.wooz.org>

On Sat, 2005-11-26 at 13:16 -0800, JC Dill wrote:

> As I understand it, your issue is what URL is "shown".  My suggestion is 
> that we make a change to the code that allows list administrators to 
> change what URL is "shown" to list users.  The new URL will also work 
> for list administrators, but the default URL will *also* continue to work.

Of course, it's currently easy to do this at least for message footers.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051128/7ab4d36d/attachment.pgp

From maxb1 at ukf.net  Mon Nov 28 12:57:24 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Mon, 28 Nov 2005 11:57:24 +0000
Subject: [Mailman-Developers] Make web_page_url visible in the admin	GUI?
In-Reply-To: <1133165356.1376.17.camel@geddy.wooz.org>
References: <BFADC729.9571%jwblist@loricamail.com> <4388B195.30501@ukf.net>
	<1133165356.1376.17.camel@geddy.wooz.org>
Message-ID: <438AF0A4.9040803@ukf.net>

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

Barry Warsaw wrote:
> On Sat, 2005-11-26 at 19:03 +0000, Max Bowsher wrote:
> 
>>OPTION TWO: Make links and form action URLs within the admin interface
>>relative, so that an incorrect web_page_url does not render the admin
>>interface inoperable.
> 
> 
> I think ultimately, it would be great if the urls could all be relative,
> but that was tried in the past and caused worlds of hurt, so everything
> was changed to absolute urls.

Can you elaborate?

I'd quite like to have a go at fixing this, but obviously I'd rather not
spend time on it if there are reasons I haven't thought about which
would make such a patch unacceptable.


Max.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDivCjfFNSmcDyxYARAoiEAJ44LdqS+2WmmKqQ0ntP8RBjYpzvqgCfVgCH
ffOcvF9ZRChC/MZ6EzQj31w=
=nEDD
-----END PGP SIGNATURE-----

From maxb1 at ukf.net  Mon Nov 28 13:10:36 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Mon, 28 Nov 2005 12:10:36 +0000
Subject: [Mailman-Developers] Make web_page_url visible in the admin GUI?
In-Reply-To: <87ek51zcf9.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <BFADC729.9571%jwblist@loricamail.com>	<4388CA3C.6040303@equinephotoart.com>
	<4388CCD0.5020406@ukf.net>	<4388D0BB.2040706@equinephotoart.com>
	<4388EE38.4090903@ukf.net>
	<87ek51zcf9.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <438AF3BC.7060106@ukf.net>

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

Stephen J. Turnbull wrote:
>>>>>>"Max" == Max Bowsher <maxb1 at ukf.net> writes:
> 
> 
>     Max> My point in saying what I did was that 'the URL to the user
>     Max> webpage' and 'the URL for the admin webpage' are not
>     Max> independently settable entities.  They are, in fact,
>     Max> identical, just one has things like 'listinfo' or 'options'
>     Max> appended, whilst the other has things like 'admin' or
>     Max> 'admindb' appended.
> 
> Right.  That has to be changed for me to get what I want.
> 
> What I would like to see is a structure where we have
> 
> # sitewide
> site_base_url        # the default URL for all Mailman stuff at the site
>                      # used for all admin pages at the site
> # list-specific
> list_base_url        # the URL for the list member stuff, archives, etc
>                      # defaults to site_base_url
> 
> It seems like that's not what you want, and that's OK with me.  I can
> live without this and it would probably be a fair amout of work to get
> right.

OK. I agree that this is considerably beyond the scope of what I have in
mind.

I suggest you start a separate thread if you want to pursue this.

If you do pursue it, one note:

Currently, all the the list-specific configvars are lower_case, but all
the sitewide configvars (in mm_cfg.py) are UPPER_CASE.

Max.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDivO8fFNSmcDyxYARAiU3AJ9CPnaZxhYjTdyiiI89bqv8NwTxHACfVWP6
TZ5EsJDFzNMHnJUB/2h2brc=
=ZVv5
-----END PGP SIGNATURE-----

From maxb1 at ukf.net  Mon Nov 28 13:22:17 2005
From: maxb1 at ukf.net (Max Bowsher)
Date: Mon, 28 Nov 2005 12:22:17 +0000
Subject: [Mailman-Developers] Pipermail threading and Debian bug 167758
Message-ID: <438AF679.3010301@ukf.net>

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

Pipermail's threadKeys currently assume that the Date header of each
mail message sent to the list is unique.

If two messages with the same Date both start new threads, then the
thread display in the pipermail archives will erroneously intermingle
the two threads. This is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167758
.

Debian have applied a patch to fix this, by including Message-IDs in the
threadKeys too. Ironically, this actually creates an even worse bug,
since they have failed to notice that '-' is a perfectly legal character
in a message-id, thus, when pipermail counts the number of '-'
characters in the threadKey to determine the nesting depth, it often
gets a totally wrong answer.

This happens often, since all it needs is a message-id containing a
dash. Exim message-ids always contain at least two, and message-ids
often include domain names, which sometimes include dashes.


So, after that little bit of rambling, my essential question is:

Was there ever any previous discussion about this issue, or did the
Debian folks not raise the issue upstream?

Max.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDivZ5fFNSmcDyxYARAuroAJ9o7fzyy4kBtepLPg9PkEVKp5F+AACghh7f
RyhxrGfae810YN1K8zfpGnE=
=BOP5
-----END PGP SIGNATURE-----

From barry at python.org  Mon Nov 28 14:03:28 2005
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Nov 2005 08:03:28 -0500
Subject: [Mailman-Developers] Make web_page_url visible in the	admin	GUI?
In-Reply-To: <438AF0A4.9040803@ukf.net>
References: <BFADC729.9571%jwblist@loricamail.com> <4388B195.30501@ukf.net>
	<1133165356.1376.17.camel@geddy.wooz.org>  <438AF0A4.9040803@ukf.net>
Message-ID: <1133183008.1377.24.camel@geddy.wooz.org>

On Mon, 2005-11-28 at 11:57 +0000, Max Bowsher wrote:

> Can you elaborate?
> 
> I'd quite like to have a go at fixing this, but obviously I'd rather not
> spend time on it if there are reasons I haven't thought about which
> would make such a patch unacceptable.

I don't remember too many details, but I do remember that it was very
difficult to get everything working correctly and we had lots of related
bug reports.  Maybe you'll have better luck. ;)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051128/7186fca2/attachment.pgp

From barry at python.org  Mon Nov 28 14:04:18 2005
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Nov 2005 08:04:18 -0500
Subject: [Mailman-Developers] Pipermail threading and Debian bug 167758
In-Reply-To: <438AF679.3010301@ukf.net>
References: <438AF679.3010301@ukf.net>
Message-ID: <1133183058.1377.26.camel@geddy.wooz.org>

On Mon, 2005-11-28 at 12:22 +0000, Max Bowsher wrote:

> Was there ever any previous discussion about this issue, or did the
> Debian folks not raise the issue upstream?

I don't remember anything specific, but it's certainly possible that the
issue's been raised before.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051128/b08904fb/attachment.pgp

From jag at fsf.org  Mon Nov 28 18:44:34 2005
From: jag at fsf.org (Joshua Ginsberg)
Date: Mon, 28 Nov 2005 12:44:34 -0500
Subject: [Mailman-Developers] XMLRPC Patch
In-Reply-To: <1131488690.20278.23.camel@geddy.wooz.org>
References: <1129307125.6026.10.camel@localhost.localdomain>
	<1129335154.32365.56.camel@geddy.wooz.org>
	<1130886730.30605.70.camel@localhost.localdomain>
	<1131485036.7487.25.camel@localhost.localdomain>
	<1131488690.20278.23.camel@geddy.wooz.org>
Message-ID: <1133199874.25354.9.camel@localhost.localdomain>

Hi Barry --

Hope you had an excellent and relaxing holiday... did you have a chance
to look over the patch?

One of the things I was thinking might be useful to add to the interface
would be a set of API calls to talk to admindb... thoughts?

-jag

On Tue, 2005-11-08 at 17:24 -0500, Barry Warsaw wrote:
> On Tue, 2005-11-08 at 16:23, Joshua Ginsberg wrote:
> 
> > Does anybody have any feedback on this patch? Is it something that can
> > be committed? Thanks!
> 
> I'd really like to look at this in more detail, but because of work
> constraints, I won't be able to spend any time on it until later in this
> month.  Thanksgiving is Mailman time! :)
> 
> -Barry
> 
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051128/882b720d/attachment.pgp

From msapiro at value.net  Mon Nov 28 19:01:56 2005
From: msapiro at value.net (Mark Sapiro)
Date: Mon, 28 Nov 2005 10:01:56 -0800
Subject: [Mailman-Developers] Scrubber mungs Quoted Printable
In-Reply-To: <PC17402005110509492200467b8e29e4@msapiro>
Message-ID: <PC1740200511281001560625907bfc09@msapiro>

Mark Sapiro wrote:
>
>I think the fix for the current problem is the following patch -
>
>--- mailman-2.1.6/Mailman/Handlers/Scrubber.py
>+++ mailman-mas/Mailman/Handlers/Scrubber.py
>@@ -376,9 +376,8 @@
>         # Now join the text and set the payload
>         sep = _('-------------- next part --------------\n')
>         del msg['content-type']
>-        msg.set_payload(sep.join(text), charset)
>         del msg['content-transfer-encoding']
>-        msg.add_header('Content-Transfer-Encoding', '8bit')
>+        msg.set_payload(sep.join(text), charset)
>     return msg

I still think this is the correct fix, but it turns out there are some
tricky issues here that I believe come down to an error in the
set_payload() method.

Under certain circumstances, in particular when charset is 'iso-8859-1',

    msg.set_payload(text, charset)

'apparently' encodes the text as quoted-printable and adds a

Content-Transfer-Encoding: quoted-printable

header to msg. I say 'apparently' because if one prints msg or creates
a Generator instance and writes msg to a file, the message is
printed/written as a correct, quoted-printable encoded message, but

    text = msg._payload
or

    text = msg.get_payload()

gives the original text, not quoted-printable encoded, and

    text = msg.get_payload(decode=1)

gives a quoted-printable decoding of the original text which is munged
if the original text included '=' in some ways.

This is a problem for Mailman because if Scrubber is processing
individual messages, the 'apparently' quoted-printable message gets
passed ultimately to SMTPDirect which calls Decorate, and Decorate
does msg.get_payload(decode=1) when adding the header and/or footer
and can mung the message in the process.

There is also an issue with archiving when the archiver gets a
multipart message which is subsequently flattened by Scrubber.

The following is a transcript of a Python interactive session that
illustrates the above problems with set_payload() and get_payload().
This session is with Python 2.4.1, but exactly the same behavior
occurs with 2.3.4 and 2.4.2.

Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>>
>>> msg = email.message_from_file(open('plain2.eml'))
>>>
>>> print msg
>From nobody Mon Nov 28 09:18:41 2005
From: "Mark Sapiro" <msapiro at value.net>
To: list1 at localhost
Subject: HTML - all
Date: Sun, 27 Nov 2005 09:02:33 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"


How about just a line of stuff with some ==== and a few words.

X=91**2 (x is 91 squared)

>>>
>>> del msg['content-type']
>>> del msg['content-transfer-encoding']
>>> msg.set_payload(str(msg.get_payload()), 'iso-8859-1')
>>>
>>> print msg
>From nobody Mon Nov 28 09:18:41 2005
From: "Mark Sapiro" <msapiro at value.net>
To: list1 at localhost
Subject: HTML - all
Date: Sun, 27 Nov 2005 09:02:33 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


How about just a line of stuff with some =3D=3D=3D=3D and a few words.

X=3D91**2 (x is 91 squared)

>>>
>>> print msg.get_payload()

How about just a line of stuff with some ==== and a few words.

X=91**2 (x is 91 squared)

>>>
>>> print msg.get_payload(decode=1)

How about just a line of stuff with some == and a few words.

X`**2 (x is 91 squared)

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


From nathanh at microsoft.com  Tue Nov 29 00:20:12 2005
From: nathanh at microsoft.com (Nathan Herring)
Date: Mon, 28 Nov 2005 15:20:12 -0800
Subject: [Mailman-Developers] Use of tabs when folding header lines
Message-ID: <37DC14690351E04386D42BF916E8DC630754F0CA@RED-MSG-41.redmond.corp.microsoft.com>

I am a member of a list which uses mailman 2.1.2, and I am experiencing strangeness in Outlook as a result of the modifications mailman performs on list posts. Specifically, when it (re)folds the Subject: and/or Thread-Topic: headers, it replaces a space character in the original subject with a tab character.

According to RFC 2822 ?2.2.3, unfolding one of these lines consists of only removing the CRLF. As a result, what had been a subject of the form "source_line1 source_line2" is now "source_line1\tsource_line2" in the mailman-altered mail, which is incorrect, and is displayed oddly by Outlook (due to some differences between tabs and space characters). (The other modification to the subject line, specifically, the addition of the "[mailinglist] " string, is fine.)

When wrapping header lines, mailman should only insert (or move around) CRLFs and retain the original WSP characters from the original, lest issues like these arise.

Is this a known issue, or should I post a new bug?

Thanks in advance,
Nathan

----
Nathan Herring
MacBU SDE/Development