[Mailman-Developers] PHP wrappers?

[Harold Paulson]

Hey,

I was trying to wrap several of the Mailman CLI tools (list_lists and 
such) in a little PHP so I could easily integrate them into a larger 
web site.  Using PHP's System() function and the backtick operator to 
exec the Mailman tools never seems to result in any output, but no 
errors either.  However, I can drop a script of my own (a little Perl 
hack or whatever) in the ~mailman/bin directory with the same 
ownership and permissions, and it seems to exec just fine.

Any idea what I'm overlooking?

- H

-- 

Harold Paulson  Sierra Web Design
[EMAIL PROTECTED]   http://www.sierraweb.com
VOICE: 775.833.9500 FAX:   810.314.1517

___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers

[Mailman-Developers] PHP Wrappers?

[Adrian Wells]

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"
.
 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@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP wrappers?

[Chris Ryan]

You may want to check for things such as PATH information as it could be
that when executing the script it can't find python executable. One
possible idea is try executing your command in a fasion like:

system("myprogram arg1 arg2 2>&1");

This may help by showing any output that gets sent to stderr on stdout.

Chris Ryan
[EMAIL PROTECTED]

Harold Paulson wrote:
> 
> Hey,
> 
> I was trying to wrap several of the Mailman CLI tools (list_lists and
> such) in a little PHP so I could easily integrate them into a larger
> web site.  Using PHP's System() function and the backtick operator to
> exec the Mailman tools never seems to result in any output, but no
> errors either.  However, I can drop a script of my own (a little Perl
> hack or whatever) in the ~mailman/bin directory with the same
> ownership and permissions, and it seems to exec just fine.
> 
> Any idea what I'm overlooking?
> 
> - H
> 
> --
> 
> Harold Paulson  Sierra Web Design
> [EMAIL PROTECTED]   http://www.sierraweb.com
> VOICE: 775.833.9500 FAX:   810.314.1517
> 
> ___
> Mailman-Developers mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/mailman-developers

___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers

Re: [Mailman-Developers] PHP wrappers?

[Ron Jarrell]

At 09:49 AM 3/13/01 -0800, Harold Paulson wrote:
>Hey,
>
>I was trying to wrap several of the Mailman CLI tools (list_lists and such) in a 
>little PHP so I could easily integrate them into a larger web site.  Using PHP's 
>System() function and the backtick operator to exec the Mailman tools never seems to 
>result in any output, but no errors either.  However, I can drop a script of my own 
>(a little Perl hack or whatever) in the ~mailman/bin directory with the same 
>ownership and permissions, and it seems to exec just fine.

Harold, most of those commands user env to find where python is.  
If it's not in your web servers search path, you won't find it.

The scripts you wrote probably spell out the path to perl...



___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers

Re: [Mailman-Developers] PHP wrappers?

[Harold Paulson]

Good suggestions,

>You may want to check for things such as PATH information as it could be
>that when executing the script it can't find python executable. One

$PATH did include the directory where the python bin was stored, and 
actually specifying a full path like:

`/usr/local/bin/python /home/mailman/bin/list_lists`

still doesn't give me any output.

>possible idea is try executing your command in a fasion like:
>
>   system("myprogram arg1 arg2 2>&1");
>
>This may help by showing any output that gets sent to stderr on stdout.

Even better suggestion!  This gives me:

Traceback (most recent call last):
   File "/usr/local/mailman/bin/list_lists", line 108, in ?
 main()
   File "/usr/local/mailman/bin/list_lists", line 86, in main
 mlist = MailList.MailList(n, lock=0)
   File "../Mailman/MailList.py", line 79, in __init__
   File "../Mailman/MailList.py", line 879, in Load
   File "../Mailman/MailList.py", line 856, in __load
IOError: [Errno 13] Permission denied: 
'/usr/local/mailman/lists/myfirstlist/config.db'

Which makes sense.  The config.db file is 660 root.mailman.  I guess 
that is why all the mailman CGIs run with setgid mailman.  I guess 
that leaves me at an impasse.  I probably shouldn't give the web 
server elevated permissions for my little hacks.

Thanks for your help in any case.

- H


>Chris Ryan
>[EMAIL PROTECTED]
>
>Harold Paulson wrote:
>>
>>  Hey,
>>
>>  I was trying to wrap several of the Mailman CLI tools (list_lists and
>>  such) in a little PHP so I could easily integrate them into a larger
>>  web site.  Using PHP's System() function and the backtick operator to
>>  exec the Mailman tools never seems to result in any output, but no
>>  errors either.  However, I can drop a script of my own (a little Perl
>>  hack or whatever) in the ~mailman/bin directory with the same
>>  ownership and permissions, and it seems to exec just fine.
>>
>>  Any idea what I'm overlooking?
>>
>>  - H
>>
>>  --
>>
>>  Harold Paulson  Sierra Web Design
>>  [EMAIL PROTECTED]   http://www.sierraweb.com
>>  VOICE: 775.833.9500 FAX:   810.314.1517
>>
>>  ___
>>  Mailman-Developers mailing list
>>  [EMAIL PROTECTED]
>>  http://mail.python.org/mailman/listinfo/mailman-developers

-- 

Harold Paulson  Sierra Web Design
[EMAIL PROTECTED]   http://www.sierraweb.com
VOICE: 775.833.9500 FAX:   810.314.1517

___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers

Re: [Mailman-Developers] PHP wrappers?

[Ron Jarrell]

At 10:04 AM 3/14/01 -0800, Harold Paulson wrote:

>IOError: [Errno 13] Permission denied: 
>'/usr/local/mailman/lists/myfirstlist/config.db'
>
>Which makes sense.  The config.db file is 660 root.mailman.  I guess that is why all 
>the mailman CGIs run with setgid mailman.  I guess that leaves me at an impasse.  I 
>probably shouldn't give the web server elevated permissions for my little hacks.

Add your www user to the mailman group...



___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers

Re: [Mailman-Developers] PHP wrappers?

[Thomas Wouters]

On Wed, Mar 14, 2001 at 03:08:12PM -0500, Ron Jarrell wrote:
> At 10:04 AM 3/14/01 -0800, Harold Paulson wrote:
> 
> >IOError: [Errno 13] Permission denied: 
>'/usr/local/mailman/lists/myfirstlist/config.db'
> >
> >Which makes sense.  The config.db file is 660 root.mailman.  I guess that is why 
>all the mailman CGIs run with setgid mailman.  I guess that leaves me at an impasse.  
>I probably shouldn't give the web server elevated permissions for my little hacks.

> Add your www user to the mailman group...

You should *not* do that. That gives the normal webserver way too much
permissions. You should 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.

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers

Re: [Mailman-Developers] PHP Wrappers?

[slave]

> 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@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Dale Newfield]

[EMAIL PROTECTED] 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
  [EMAIL PROTECTED]
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Joshua Ginsberg]

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"
> .
>  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@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 <[EMAIL PROTECTED]>
Free Software Foundation - Senior Systems Administrator


signature.asc
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Peter John Hartman]

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, [EMAIL PROTECTED] 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@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&file=faq01.027.htp
>
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Kevin McCann]

[EMAIL PROTECTED] 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






.












___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

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, <[EMAIL PROTEC

Re: [Mailman-Developers] PHP Wrappers?

[Kevin McCann]

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 

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

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 c

Re: [Mailman-Developers] PHP Wrappers?

[Kevin McCann]

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





___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

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 s

Re: [Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

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





___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

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





___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Kevin McCann]

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

___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Kevin McCann]

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

___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Joshua Ginsberg]

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:



  foo.multiply
  
2
5
  

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.



  
10
  


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',
'[EMAIL PROTECTED]', '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', '[EMAIL PROTECTED]',
'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 <[EMAIL PROTECTED]> on Wednesday, November 16, 2005 at 3:01
> PM + 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

Re: [Mailman-Developers] PHP Wrappers?

[Adrian Wells]

Joshua Ginsberg <[EMAIL PROTECTED]> on Thursday, November 17, 2005 at 12:46 PM
+ 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

___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

At 10:49 AM + 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, <[EMAIL PROTECTED]>

"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  for more info.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

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 s

Re: [Mailman-Developers] PHP Wrappers?

[Kevin McCann]

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

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

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, <[EMAIL PROTECTED]>

"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  for more info.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

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



signature.asc
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

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? I

Re: [Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

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



signature.asc
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

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



signature.asc
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

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

> At 10:49 AM + 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 [EMAIL PROTECTED] or not [EMAIL PROTECTED], 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



___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

At 12:57 PM + 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, <[EMAIL PROTECTED]>

"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  for more info.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

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

> At 12:57 PM + 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




___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Dale Newfield]

"Brad Knowles" <[EMAIL PROTECTED]> 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
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

At 10:25 AM + 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, <[EMAIL PROTECTED]>

"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  for more info.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Stephen J. Turnbull]

> "Brad" == Brad Knowles <[EMAIL PROTECTED]> 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 TsukubaTennodai 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.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

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

>>  "Brad" == Brad Knowles <[EMAIL PROTECTED]> 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, <[EMAIL PROTECTED]>

"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  for more info.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Stephen J. Turnbull]

> "Brad" == Brad Knowles <[EMAIL PROTECTED]> 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. 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 

Re: [Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

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 <[EMAIL PROTECTED]> 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





___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Stephen J. Turnbull]

> "Ian" == Ian Eiloart <[EMAIL PROTECTED]> 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 TsukubaTennodai 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.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

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

>> "Ian" == Ian Eiloart <[EMAIL PROTECTED]> 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





___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Stephen J. Turnbull]

> "Ian" == Ian Eiloart <[EMAIL PROTECTED]> 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 TsukubaTennodai 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.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

On Fri, 2005-11-18 at 12:57 +, 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 [EMAIL PROTECTED] or not [EMAIL PROTECTED], 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



signature.asc
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

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



signature.asc
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Barry Warsaw]

On Tue, 2005-11-22 at 17:18 +0900, Stephen J. Turnbull wrote:
> > "Brad" == Brad Knowles <[EMAIL PROTECTED]> 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. 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



signature.asc
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Brad Knowles]

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 req

Re: [Mailman-Developers] PHP Wrappers?

[John W. Baxter]

On 11/22/05 12:18 AM, "Stephen J. Turnbull" <[EMAIL PROTECTED]> 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.


___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Ian Eiloart]

On 22 Nov 2005, at 17:33, Stephen J. Turnbull wrote:

>> "Ian" == Ian Eiloart <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]@(.*\.)?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



___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] PHP Wrappers?

[Stephen J. Turnbull]

> "Ian" == Ian Eiloart <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]@(.*\.)?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 TsukubaTennodai 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.
___
Mailman-Developers mailing list
Mailman-Developers@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/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp