From rjohnson at dogstar-interactive.com  Wed Mar  1 04:56:32 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Tue, 28 Feb 2006 22:56:32 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
Message-ID: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>

AKA, "The Perennial Issue" (TPI)

I've been looking at this for a while; I've scanned the archives; and  
I've perused the code (well a chunk of it anyway).
I realize that mailman _sort of_ supports virtual domains, but  
doesn't _really_ support virtual domains.

As I look at the situation from the perspective of a sysadmin or ISP,  
there are two aspects that really bother me:
  - comingling of data from separate virtual domains
  - ''site'' password shared between virtual domains

 From my perusals I think what I'm really asking for is a per-domain  
assignment of VAR_PREFIX to segregate the domain's data.  If so, the  
question becomes how to achieve it.

-------------------------------

Here's the proposal:
  -- add a configfile option to the mailman utilities.

That's it!
. . . . . . . . . . . . .

Advantages include:
  - heavy lifting is limited to mm_cfg.py (or Defaults.py).  I  
propose adding a "configure( filename)" function to incorporate the  
configfile
  - VAR_PREFIX could be defined on a per-domain basis;  
mm_cfg.configure() would have to be prepared for this.
  - multiple instances of mailman utilities no longer required.
  - transparent to existing configurations.
  - ability to manage any of the mm_cfg parameters on a per-domain  
basis.

Disadvantages include:
  - changes woulld be pervasive, and this cannot be underestimated.   
However, most changes are either an additional getopt elif clause or  
insuring that the configfile specification is propagated  
appropriately.  For the most part, these changes are  straightforward.
- all utility invocations for a given domain must use the same  
configfile.  This is no improvement over, but not more difficult  
than,  managing a separate mailman installation for each domain.

Other comments:
  - an Exim ''mailman_vdom_transport'' can provide domain specific  
config file to the mail wrapper.
  - httpd rewrite rules could generate domain (vhost) sepcific  -- 
config=<confile>  args to listinfo etc.
  - I'm not sure about mailer requirements for Postfix, qmail, etc.
  - a qrunner for each domain will be required; as is the case for  
multiple installation copies.

--------------------------------

Expected usage of the --config option for virtual domain processing  
would be:
(this example is targeted for a Debian system running Exim4/Apache2  
where all domain specific data for virtual domain "domain1.tld" is  
kept in /var/vdomains/domain1.tld.))

Each virtual domain supplies a configfile.  This config file might be  
a 1 liner like:
      VAR_PREFIX = /var/vdomains/domain1.tld/mailman/data

or it might contain other specializations as well.

The various system utiltiies would dereference the configfile for the  
domain before invoking mailman utilities.  For example (may contain  
typos):

      /etc/crontab might include lines like:
        0 9 * * * list [ -x /usr/lib/mailman/cron/disabled ] && /usr/ 
lib/mailman/cron/disabled --config=/var/domains/domain1.tld/mailman.conf

    An exim transport might contain a line like:
       command = MAILMAN_WRAP --config=/var/vdomains/$domain/ 
mailman.conf \
         '${if def:local_part_suffix \
         {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
         {post}}' \
         $local_part

    An apache2 virtual host would contain directives like
       <Location /cgi-bin/>
	        RewriteEngine on
  		RewriteRule  ^listinfo$  listinfo?--config=/var/vdomains/ 
domain1.tld/mailman.conf
        </Location>
      or
        ScriptAliasMatch ^/mailing_lists/(.*)   /usr/lib/mailman/cgi- 
bin/$1?--config=/var/vdomains/domain1.tld/mailman.conf

where the <configfile> contains my_cfg.py segments.

------------------------

Comments?  Advice?  Reactions of Horror?  Am I WAAAY off base?

Has this approach been previously considered and rejected?

FWIW, I've worked out  a _basic_ implementation for mm_cfg.configure 
(filename) and it's use by the cron utilities and would like to get  
some reaction before going any further.

--rich



From dev+lists at humph.com  Wed Mar  1 00:52:09 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Wed, 1 Mar 2006 00:52:09 +0100
Subject: [Mailman-Developers] incorrect generated HTML
Message-ID: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>

Hello,

I have recently installed mailman.
As a result of customising the user interface, I have noticed that  
the HTML of both the administrative and user interface is quite  
incorrect. In particular the user interface, which shows many layers  
of intervention (tags appear with too many case changes!).
I am attempting to clean up the code (as HTML 4.01 Transitional), but  
I wonder if there is already an ongoing tidying up or redesign that  
would make my work a waste of time.

One change in Mailman that would make correction and editing of HTML  
templates easier would be to have all Mailman inner tags written  
without using <> or other strange characters. For instance <MM-Form- 
End> could be simply MMFormEnd. This way a template could validate as  
valid HTML without being parsed first, as long as these Mailman tags  
are not required in strange places.
Clearly the documents could loose its validity once parsed, but this  
too can be avoided with careful design of the tags. For instance the  
footer tag (I think <MM-Mailman-Footer>) generates at the moment  
incorrect HTML all by itself and so cannot be corrected by a list  
administrator.

I see now that there is a General Web UI item in the TODO. Let me add  
a plea: please do not use php for the future UI!

Thanks

Giuliano



From iane at sussex.ac.uk  Thu Mar  2 12:05:39 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 02 Mar 2006 11:05:39 +0000
Subject: [Mailman-Developers] incorrect generated HTML
In-Reply-To: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>
References: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>
Message-ID: <BD5F2CE74C4F791D212D2E78@lewes.staff.uscs.susx.ac.uk>



--On 1 March 2006 00:52:09 +0100 Giuliano Gavazzi <dev+lists at humph.com> 
wrote:

> Hello,
>
> I have recently installed mailman.
> As a result of customising the user interface, I have noticed that
> the HTML of both the administrative and user interface is quite
> incorrect. In particular the user interface, which shows many layers
> of intervention (tags appear with too many case changes!).
> I am attempting to clean up the code (as HTML 4.01 Transitional), but
> I wonder if there is already an ongoing tidying up or redesign that
> would make my work a waste of time.
>
> One change in Mailman that would make correction and editing of HTML
> templates easier would be to have all Mailman inner tags written
> without using <> or other strange characters. For instance <MM-Form-
> End> could be simply MMFormEnd.

Perhaps a comment could be used instead:

<!-- MMFormEnd -->

> This way a template could validate as
> valid HTML without being parsed first, as long as these Mailman tags
> are not required in strange places.
> Clearly the documents could loose its validity once parsed, but this
> too can be avoided with careful design of the tags. For instance the
> footer tag (I think <MM-Mailman-Footer>) generates at the moment
> incorrect HTML all by itself and so cannot be corrected by a list
> administrator.
>
> I see now that there is a General Web UI item in the TODO. Let me add
> a plea: please do not use php for the future UI!

Well, it's a Python project, so you should be safe there!

> Thanks
>
> Giuliano
>
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives:
> http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
> http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a
> c.uk
>
> Security Policy:
> http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp



-- 
Ian Eiloart
IT Services, University of Sussex

From barry at python.org  Thu Mar  2 15:23:51 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 2 Mar 2006 09:23:51 -0500
Subject: [Mailman-Developers] incorrect generated HTML
In-Reply-To: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>
References: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>
Message-ID: <76683934-63FF-4AD9-B510-EB33F761A89E@python.org>

On Feb 28, 2006, at 6:52 PM, Giuliano Gavazzi wrote:

> I see now that there is a General Web UI item in the TODO. Let me add
> a plea: please do not use php for the future UI!

Don't worry, that won't happen.  What might/should eventually happen  
is the adoption of a decent Python templating engine that works much  
better than our homegrown version, and is more i18n friendly to boot.

-Barry


From dev+lists at humph.com  Thu Mar  2 17:05:25 2006
From: dev+lists at humph.com (g)
Date: Thu, 2 Mar 2006 17:05:25 +0100
Subject: [Mailman-Developers] bug in mailman-2.1.7/Mailman/Cgi/listinfo.py
	and HTML generation
Message-ID: <B3C84532-87B4-40A0-8E48-1767687F666A@humph.com>

     if not mlist.digestable or not mlist.nondigestable:
         replacements['<mm-digest-radio-button>'] = ""
         replacements['<mm-undigest-radio-button>'] = ""
         replacements['<mm-digest-question-start>'] = '<!-- '
         replacements['<mm-digest-question-end>'] = ' -->'
     else:
         replacements['<mm-digest-radio-button>'] =  
mlist.FormatDigestButton()
         replacements['<mm-undigest-radio-button>'] = \
                                                     
mlist.FormatUndigestButton()
         replacements['<mm-digest-question-start>'] = ''
         replacements['<mm-digest-question-end>'] = ''
     replacements['<mm-plain-digests-button>'] = \

apart that I do not know where the if ends (is it determined by the  
formatting?), there is, I think, a bug. Shouldn't it be:


     if not mlist.digestable or mlist.nondigestable:

and the parsing of the HTML template does not work anyway, as I have

digestable = 0

but the digest option still appears in my users option page.

Giuliano

From jag at fsf.org  Thu Mar  2 17:57:27 2006
From: jag at fsf.org (Joshua Ginsberg)
Date: Thu, 02 Mar 2006 11:57:27 -0500
Subject: [Mailman-Developers] incorrect generated HTML
In-Reply-To: <76683934-63FF-4AD9-B510-EB33F761A89E@python.org>
References: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>
	<76683934-63FF-4AD9-B510-EB33F761A89E@python.org>
Message-ID: <1141318647.2455.7.camel@localhost.localdomain>

I vote for Zope Page Templates.
http://www.owlfish.com/software/simpleTAL/

-jag

On Thu, 2006-03-02 at 09:23 -0500, Barry Warsaw wrote:
> On Feb 28, 2006, at 6:52 PM, Giuliano Gavazzi wrote:
> 
> > I see now that there is a General Web UI item in the TODO. Let me add
> > a plea: please do not use php for the future UI!
> 
> Don't worry, that won't happen.  What might/should eventually happen  
> is the adoption of a decent Python templating engine that works much  
> better than our homegrown version, and is more i18n friendly to boot.
> 
> -Barry
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jag%40fsf.org
> 
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
> 
-- 
Joshua Ginsberg <jag at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060302/6b792287/attachment.pgp 

From msapiro at value.net  Thu Mar  2 18:08:38 2006
From: msapiro at value.net (Mark Sapiro)
Date: Thu, 2 Mar 2006 09:08:38 -0800
Subject: [Mailman-Developers] bug in
	mailman-2.1.7/Mailman/Cgi/listinfo.pyand HTML generation
In-Reply-To: <B3C84532-87B4-40A0-8E48-1767687F666A@humph.com>
Message-ID: <PC1740200603020908380546181c8d08@msapiro>

g wrote:

>     if not mlist.digestable or not mlist.nondigestable:
>         replacements['<mm-digest-radio-button>'] = ""
>         replacements['<mm-undigest-radio-button>'] = ""
>         replacements['<mm-digest-question-start>'] = '<!-- '
>         replacements['<mm-digest-question-end>'] = ' -->'
>     else:
>         replacements['<mm-digest-radio-button>'] =  mlist.FormatDigestButton()
>         replacements['<mm-undigest-radio-button>'] = \
>                                                    mlist.FormatUndigestButton()
>         replacements['<mm-digest-question-start>'] = ''
>         replacements['<mm-digest-question-end>'] = ''
>     replacements['<mm-plain-digests-button>'] = \
>
>apart that I do not know where the if ends (is it determined by the  
>formatting?),


Yes. Block structure in Python is determined by indentation.


> there is, I think, a bug. Shouldn't it be:

>     if not mlist.digestable or mlist.nondigestable:


No. The intent is to not offer the digest radio buttons if there is no
choice, i.e. if you can't choose digest or you can't choose nondigest
because the choice is unavailable.


>and the parsing of the HTML template does not work anyway, as I have
>
>digestable = 0
>
>but the digest option still appears in my users option page.


The code you quote above has to do with presenting a digest yes/no
option on the subscribe form on the listinfo page. It doesn't affect
whether or not the digest option appears on the user's options page.

The default user options page has the digest selection, but processing
won't allow selection of an unavailable digest option.

If you want to remove the question altogether from the user options
page, you have to edit the options.html template. See
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.048.htp>
for information on making a list specific, domain specific or sitewide
edited version of this template, or you can make a list specific
version via the "Edit the public HTML pages and text files" link on
the list's admin pages.

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


From barry at python.org  Thu Mar  2 18:09:19 2006
From: barry at python.org (Barry Warsaw)
Date: Thu, 02 Mar 2006 12:09:19 -0500
Subject: [Mailman-Developers] incorrect generated HTML
In-Reply-To: <1141318647.2455.7.camel@localhost.localdomain>
References: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>
	<76683934-63FF-4AD9-B510-EB33F761A89E@python.org>
	<1141318647.2455.7.camel@localhost.localdomain>
Message-ID: <1141319359.7666.19.camel@geddy.wooz.org>

On Thu, 2006-03-02 at 11:57 -0500, Joshua Ginsberg wrote:
> I vote for Zope Page Templates.
> http://www.owlfish.com/software/simpleTAL/

I actually spent a lot of time when prototyping MM3 and used TAL (the
one from Zope3) and found it excruciating to use, especially when i18n
was added.  It's been a while, but from what I can remember, it got to
the point where the templates where inscrutable, impossible to debug,
very difficult to extend or modify, and very difficult to reason about.
I really /wanted/ to use TAL but it was way too unwieldy to develop.
The implementation was also very slow.

-Barry

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

From dev+lists at humph.com  Thu Mar  2 17:42:18 2006
From: dev+lists at humph.com (g)
Date: Thu, 2 Mar 2006 17:42:18 +0100
Subject: [Mailman-Developers] bug in
	mailman-2.1.7/Mailman/Cgi/listinfo.py and HTML generation
In-Reply-To: <B3C84532-87B4-40A0-8E48-1767687F666A@humph.com>
References: <B3C84532-87B4-40A0-8E48-1767687F666A@humph.com>
Message-ID: <1921B2CB-4C76-4280-B736-DEB7A1BCEB2D@humph.com>

Sorry, I mixed up the options with list subscription page, the list  
subscription page is fine, as it uses mm-digest-question-start/end to  
comment out the digest section and they are parsed correctly by  
listinfo (apart from a possible extra 'not'), but in the options page  
the digest section is not enclosed and the options.py file does not  
parse the mm-digest-question-start/end values anyway. I see that an  
error message is returned in the page when the digest mode is  
prohibited, but I guess most users will not notice it.

On 2 Mar 2006, at 17:05, g wrote:

>      if not mlist.digestable or not mlist.nondigestable:
[...]


From dev+lists at humph.com  Thu Mar  2 18:26:49 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Thu, 2 Mar 2006 18:26:49 +0100
Subject: [Mailman-Developers] bug in
	mailman-2.1.7/Mailman/Cgi/listinfo.pyand HTML generation
In-Reply-To: <PC1740200603020908380546181c8d08@msapiro>
References: <PC1740200603020908380546181c8d08@msapiro>
Message-ID: <DE6EA71E-97A2-4025-A0B3-86A8BF408E74@humph.com>


On 2 Mar 2006, at 18:08, Mark Sapiro wrote:

>> there is, I think, a bug. Shouldn't it be:
>
>>     if not mlist.digestable or mlist.nondigestable:
>
>
> No. The intent is to not offer the digest radio buttons if there is no
> choice, i.e. if you can't choose digest or you can't choose nondigest
> because the choice is unavailable.
>

ok, I misunderstood the meaning of nondigestable (I tought it was an  
equivalent alternative to not digestable...)!

>
>> and the parsing of the HTML template does not work anyway, as I have
>>
>> digestable = 0
>>
>> but the digest option still appears in my users option page.
>
>
> The code you quote above has to do with presenting a digest yes/no
> option on the subscribe form on the listinfo page. It doesn't affect
> whether or not the digest option appears on the user's options page.
>
> The default user options page has the digest selection, but processing
> won't allow selection of an unavailable digest option.
>

yes, I found that out (but my post is waiting to be vetted). As I  
wrote there I think many users will not notice the error message though.

> If you want to remove the question altogether from the user options
> page, you have to edit the options.html template. See
> <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.048.htp>

thanks, that is very clear an useful.

Giuliano

From stephen at xemacs.org  Fri Mar  3 05:04:23 2006
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 03 Mar 2006 13:04:23 +0900
Subject: [Mailman-Developers] incorrect generated HTML
In-Reply-To: <1141319359.7666.19.camel@geddy.wooz.org> (Barry Warsaw's
	message of "Thu, 02 Mar 2006 12:09:19 -0500")
References: <BA86043A-9925-4817-B43D-EB1830EAC785@humph.com>
	<76683934-63FF-4AD9-B510-EB33F761A89E@python.org>
	<1141318647.2455.7.camel@localhost.localdomain>
	<1141319359.7666.19.camel@geddy.wooz.org>
Message-ID: <878xrs8988.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "BAW" == Barry Warsaw <barry at python.org> writes:

    BAW> I really /wanted/ to use TAL but it was way too unwieldy to
    BAW> develop.

+1  Unfortunately, TAL doesn't seem to scale _down_ to typical
volunteer-staffed open source.


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

From hun at n-dimensional.de  Fri Mar  3 14:23:06 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Fri, 03 Mar 2006 14:23:06 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	(Rich Johnson's message of "Tue, 28 Feb 2006 22:56:32 -0500")
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
Message-ID: <864q2fwtl1.fsf@n-dimensional.de>

Rich Johnson <rjohnson at dogstar-interactive.com> writes:

> AKA, "The Perennial Issue" (TPI)

Hehe. Right, we have run into this here again and again as well. :)

> I've been looking at this for a while; I've scanned the archives; and  
> I've perused the code (well a chunk of it anyway).
> I realize that mailman _sort of_ supports virtual domains, but  
> doesn't _really_ support virtual domains.
>
> As I look at the situation from the perspective of a sysadmin or ISP,  
> there are two aspects that really bother me:
>   - comingling of data from separate virtual domains

There are two aspects to that:

 1. On a filesystem level, the data from different virtual domains
    will always be thrown in some places under the same system user
    id, so this is something which cannot be solved without becoming
    root and doing some setuid magic.

 2. Mailman's internal namespace for mailing lists does not include
    the virtual domain, so there are name clashes between the lists
    "foo", "foo at domain1.com" and "foo at domain2.com".

I am currently working on the "internal namespace" problem for a
certain installation, and I'm not overly concerned with the "same
system user" issue.

As far as I can tell, the "internal namespace" problem itself is not
very difficult to solve. However, some of its consequences may be, and
I'll solve those problems as they come.

I had not really planned to go public with that branch of mine yet,
but I think it makes sense in with respect to this discussion:

   http://nix.lauft.net/mailman/README.VHOST
      Project description

   http://nix.lauft.net/mailman/
      GNU-style patches

   http://git.n-dimensional.de/mailman-virtualhost.git/
      git repository, forked off the Mailman 2.1.7 release.

bawue.net is currently using Mailman 2.1.7, and we require a solution
which allows three different lists named "foo", "foo at bar.com" and
"foo at bla.org" on the same mailman installation. Thus we have started
adapting Mailman accordingly mid-2006-02, naming it our "vhost branch".

The general idea is to have use the "foo", "foo at bar.com" and
"foo at bla.org" strings as the internal list identifiers, and then
successively solve or work around all the issues this change implies.

For more details, read http://nix.lauft.net/mailman/README.VHOST (the
code itself is not of practical use yet).

Our goal is to give this branch to the Mailman project if they want
it. If they do not for any reason, we'll have to maintain our vhost
branch until Mailman 3 with all the necessary features has been
released. :)

>   - ''site'' password shared between virtual domains

According to some "Mailman 3" documents I've stumbled upon, that issue
is going to be addressed in Mailman 3's user database. However, I
have not seen anything looking like a timeframe :)

This is obviously a problem which will need to be addressed in some
way. I have not gotten that far yet, though, so I have not yet worked
out any solution options.

>  From my perusals I think what I'm really asking for is a per-domain  
> assignment of VAR_PREFIX to segregate the domain's data.  If so, the  
> question becomes how to achieve it.

That sounds suspiciously similar to "one mailman installation per
domain" :) 

> Here's the proposal:
>   -- add a configfile option to the mailman utilities.

Indeed. Then you have one software installation (binaries, programs,
libraries) and all the rest is duplicated per virtual domain. OK, that
may fix your problem, but not mine :)

Gru?,

Hans Ulrich Niedermann

From brad at stop.mail-abuse.org  Fri Mar  3 16:05:48 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri, 3 Mar 2006 16:05:48 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <864q2fwtl1.fsf@n-dimensional.de>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
Message-ID: <p06200737c02e0b4db590@[10.0.1.211]>

At 2:23 PM +0100 2006-03-03, Hans Ulrich Niedermann wrote:

>  Our goal is to give this branch to the Mailman project if they want
>  it. If they do not for any reason, we'll have to maintain our vhost
>  branch until Mailman 3 with all the necessary features has been
>  released. :)

	If you upload the code to the SourceForge "patches" page for 
Mailman, the core developers will be much more likely to look at what 
you've got and to consider it for inclusion in a future version.

	The key people you've got to convince are Tokio and Mark -- Barry 
is primarily working on his real job, and doing what he can for 
Mailman3 in his non-existent "spare time", although he does try to at 
least keep abreast of what is going on with Mailman 2.x.

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

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

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

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From hun at n-dimensional.de  Fri Mar  3 16:18:14 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Fri, 03 Mar 2006 16:18:14 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <p06200737c02e0b4db590@[10.0.1.211]> (Brad Knowles's message of
	"Fri, 3 Mar 2006 16:05:48 +0100")
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de> <p06200737c02e0b4db590@[10.0.1.211]>
Message-ID: <861wxjtv49.fsf@n-dimensional.de>

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

> At 2:23 PM +0100 2006-03-03, Hans Ulrich Niedermann wrote:
>
>>  Our goal is to give this branch to the Mailman project if they want
>>  it. If they do not for any reason, we'll have to maintain our vhost
>>  branch until Mailman 3 with all the necessary features has been
>>  released. :)
>
> 	If you upload the code to the SourceForge "patches" page for
> Mailman, the core developers will be much more likely to look at what
> you've got and to consider it for inclusion in a future version.

I'll do that as soon as I have something
  a) working
  b) clean (code)
  c) pretty (concept)
  d) as small a change as absolutely necessary

> 	The key people you've got to convince are Tokio and Mark --
> Barry is primarily working on his real job, and doing what he can for
> Mailman3 in his non-existent "spare time", although he does try to at
> least keep abreast of what is going on with Mailman 2.x.

I'll keep that in mind, thank you.

Gru?,

Hans Ulrich Niedermann

From msapiro at value.net  Fri Mar  3 22:39:18 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 03 Mar 2006 13:39:18 -0800
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <861wxjtv49.fsf@n-dimensional.de>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de>
Message-ID: <4408B786.3030800@value.net>

Hans Ulrich Niedermann wrote:
> Brad Knowles <brad at stop.mail-abuse.org> writes:
>
>> 	The key people you've got to convince are Tokio and Mark --

Since I've been nominated as a key person to convince, here's one remark.

> The general idea is to have use the "foo", "foo at bar.com" and
> "foo at bla.org" strings as the internal list identifiers, and then
> successively solve or work around all the issues this change implies.

There are existing patches that are linked directly or indirectly from 
FAQ 4.47. These all seem to use things like foo_bar.com and foo_bla.org 
as the internal list identifier and they all seem to do an incomplete 
job of "solve or work around all the issues this change implies".

Anyway, my intent is not to critique other solutions, but to say that I 
would much prefer to see a directory inserted rather than a host_name 
appended. This has performance advantages and might fit better with a 
scheme of "hashed" intermediate directories to help sites with very 
large numbers of lists. Once you add the infrastructure for one 
intermediate directory, it may become simpler to add more intermediate 
directories

I.e, for the initial cut, split the lists/<listname> structure into 
lists/<hostname>/<listname> and similarly for archives/private and 
archives/public.

Anyway, it's your project, but I think we'd all welcome a complete 
solution to this problem.

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

From hun at n-dimensional.de  Sat Mar  4 06:16:12 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Sat, 04 Mar 2006 06:16:12 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <4408B786.3030800@value.net> (Mark Sapiro's message of "Fri, 03
	Mar 2006 13:39:18 -0800")
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de> <p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
Message-ID: <8664mun61v.fsf@n-dimensional.de>

Mark Sapiro <msapiro at value.net> writes:

> Anyway, my intent is not to critique other solutions, but to say that
> I would much prefer to see a directory inserted rather than a
> host_name appended. This has performance advantages and might fit
> better with a scheme of "hashed" intermediate directories to help
> sites with very large numbers of lists. Once you add the
> infrastructure for one intermediate directory, it may become simpler
> to add more intermediate directories.
>
> I.e, for the initial cut, split the lists/<listname> structure into
> lists/<hostname>/<listname> and similarly for archives/private and
> archives/public.

Actually, implementing the lists/<hostname>/<localpart> and
archives/(private|public)/<hostname>/<localpart> was one of the first
things I have implemented, as it is one of the easiest parts and had
been mentioned at
http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/VirtualHosting

It's not as clean as I'd like it to be yet, though: There is the very
same code to create those directories in both Mailman/Site.py and
Mailman/Archives/Archives.py (two nested try: blocks with the
os.umask() where the inner try finally calls os.makedirs()).

OTOH, one can argue that Site.py and Archives.py handle fundamentally
different things and just happen to need the same code. Still, I
always become wary when I see the same code in different places :)

> Anyway, it's your project, but I think we'd all welcome a complete
> solution to this problem.

Good. Let's see how far I can get.

Gru?,

Hans Ulrich Niedermann

From bob at nleaudio.com  Sat Mar  4 20:57:10 2006
From: bob at nleaudio.com (Bob Puff)
Date: Sat, 4 Mar 2006 14:57:10 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <4408B786.3030800@value.net>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
Message-ID: <20060304195620.M62195@nleaudio.com>


> I.e, for the initial cut, split the lists/<listname> structure into 
> lists/<hostname>/<listname> and similarly for archives/private and 
> archives/public.

Definite +1 on that!

BOb

From barry at python.org  Mon Mar  6 05:45:16 2006
From: barry at python.org (Barry Warsaw)
Date: Sun, 05 Mar 2006 23:45:16 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060304195620.M62195@nleaudio.com>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de> <p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<20060304195620.M62195@nleaudio.com>
Message-ID: <1141620316.32263.161.camel@resist.wooz.org>

On Sat, 2006-03-04 at 14:57 -0500, Bob Puff wrote:
> > I.e, for the initial cut, split the lists/<listname> structure into 
> > lists/<hostname>/<listname> and similarly for archives/private and 
> > archives/public.
> 
> Definite +1 on that!

Yep, that's definitely where my thinking was leading the last time I
worked on this.  FWIW, in Mailman 3 I've been thinking that the "list
id" will essentially be the full posting address, so that it's pretty
clear what "foo at dom1.org" and "foo at dom2.org" point to.

Let me make two other suggestion for those of you working on patches.
First, generate your patches against the Mailman trunk, for what will
eventually be Mailman 2.2.  There's no way we can add this stuff to
MM2.1, but Tokio did the heavy lifting a while back to whip the trunk
into shape, and all patches are being applied to both the trunk and the
2.1-maint branch.  At some point, they'll start to diverge but for now
they should be pretty similar (modulo some i18n stuff).

Also, now that SF provides Subversion support, I very strongly want to
migrate to it.  Among many other advantages, this will make it easier to
create experimental branches to work on things like this.

-Barry

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

From sub1.dev.mailman at msquared.id.au  Mon Mar  6 06:44:19 2006
From: sub1.dev.mailman at msquared.id.au (Msquared)
Date: Mon, 6 Mar 2006 13:44:19 +0800
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <4408B786.3030800@value.net>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
Message-ID: <20060306054419.GF8513@sliderule.msquared.com.au>

On Fri, Mar 03, 2006 at 01:39:18PM -0800, Mark Sapiro wrote:

> I.e, for the initial cut, split the lists/<listname> structure into 
> lists/<hostname>/<listname> and similarly for archives/private and 
> archives/public.

Just a thought on this: might it be better to mangle the directories
like so:

  <hostname>/lists/<listname>
  <hostname>/archives/<listmame>
  etc

so as to group things on a per-host basis?  One reason for doing so is
that it (to me) makes more sense especially if you are hosting many
domains that are not related or are different clients, etc.  It simplifies
the view of things from a per-host perspective.

Perhaps even this:

  <hostname>/<listname>/list
  <hostname>/<listname>/archive
  etc

Even better, perhaps make it configurable.  :o)

Regards, Msquared...

From hun at n-dimensional.de  Mon Mar  6 11:01:41 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Mon, 06 Mar 2006 11:01:41 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <1141620316.32263.161.camel@resist.wooz.org> (Barry Warsaw's
	message of "Sun, 05 Mar 2006 23:45:16 -0500")
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de> <p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<20060304195620.M62195@nleaudio.com>
	<1141620316.32263.161.camel@resist.wooz.org>
Message-ID: <86wtf7dh8a.fsf@n-dimensional.de>

Barry Warsaw <barry at python.org> writes:

> On Sat, 2006-03-04 at 14:57 -0500, Bob Puff wrote:
>> > I.e, for the initial cut, split the lists/<listname> structure into 
>> > lists/<hostname>/<listname> and similarly for archives/private and 
>> > archives/public.
>> 
>> Definite +1 on that!
>
> Yep, that's definitely where my thinking was leading the last time I
> worked on this.  FWIW, in Mailman 3 I've been thinking that the "list
> id" will essentially be the full posting address, so that it's pretty
> clear what "foo at dom1.org" and "foo at dom2.org" point to.

Yupp, I like that, too. My "vhost branch" supports both types of list
id (MailList.internal_name()):
   * traditional site wide (and postfix style virtual) lists (named
     "foo")
   * new "vhost lists" named ("foo at dom1.org" and "foo at dom2.org")
That should make vhost->MM3 migration easier :)

> Let me make two other suggestion for those of you working on patches.
> First, generate your patches against the Mailman trunk, for what will
> eventually be Mailman 2.2.

That is CVS HEAD in the "mailman" CVS module, I presume. Now that I
have finally gotten through to the anoncvs server, I have fetched
mailman HEAD and 2.1-maint.

> There's no way we can add this stuff to MM2.1, but Tokio did the
> heavy lifting a while back to whip the trunk into shape, and all
> patches are being applied to both the trunk and the 2.1-maint
> branch.  At some point, they'll start to diverge but for now
> they should be pretty similar (modulo some i18n stuff).

Ah good. If the difference is that small, I'll continue with 2.1 first
(as I have started from there) and port to HEAD (2.2) when I have the
basics working on 2.1.

> Also, now that SF provides Subversion support, I very strongly want to
> migrate to it.  Among many other advantages, this will make it easier to
> create experimental branches to work on things like this.

Definite +1 on ditching CVS. And (at least theoretically by using
svk), SVN is even supposed to be usable by the non-priviledge masses
who have not been blessed with write access to the central
repository. *That* is the killer advantage IMHO.

Gru?,

Hans Ulrich Niedermann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060306/e246445f/attachment.pgp 

From dev+lists at humph.com  Mon Mar  6 16:32:25 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Mon, 6 Mar 2006 16:32:25 +0100
Subject: [Mailman-Developers] 552 SMTP CODE in bounce
Message-ID: <3D8A9EB6-8CE4-4CB3-B2FC-38B285384A49@humph.com>

Hello,

I thought that mailman would attempt to parse a bounce caused by a  
failed delivery to establish if that failure was temporary or permanent.
It might be that mailman parses the error code correctly if that is  
received directly from the outgoing mailserver, but it seems that if  
the code is in a bounce (DSN), the parsing might fail.

I use exim 4.60 as outgoing mailserver and when attempting to deliver  
to an overquota mailbox it will return a message with the following  
body:


This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

   user at example.domain
     SMTP error from remote mail server after RCPT  
TO:<user at example.domain>:
     host mail-mx-4.tiscali.it [213.205.33.33]: 552 RCPT  
TO:<user at example.domain> Mailbox disk quota exceeded

------ This is a copy of the message, including all the headers. ------
[...]


The user is then given 1 point as with a permanent failure.
If this is not what's supposed to happen, where do I look in the code  
to fix this?
I see 552 only in Mailman/Handlers/SMTPDirect.py but this is not a  
direct SMTP error.

Or perhaps i should teach exim to treat 552 as temporary errors  
(until the maximum retry has been reached).

Thanks

Giuliano

From msapiro at value.net  Mon Mar  6 17:38:59 2006
From: msapiro at value.net (Mark Sapiro)
Date: Mon, 6 Mar 2006 08:38:59 -0800
Subject: [Mailman-Developers] 552 SMTP CODE in bounce
In-Reply-To: <3D8A9EB6-8CE4-4CB3-B2FC-38B285384A49@humph.com>
Message-ID: <PC17402006030608385908900e27f455@msapiro>

Giuliano Gavazzi wrote:
>
>I thought that mailman would attempt to parse a bounce caused by a  
>failed delivery to establish if that failure was temporary or permanent.


I know that the Bounce Processing page says that 'soft' bounces score
0.5 and 'hard' bounces score 1.0, but this is not actually implemented.

However, in any case, RFC 2821 defines any 5yx status as a permanent
failure, even 552.


>It might be that mailman parses the error code correctly if that is  
>received directly from the outgoing mailserver, but it seems that if  
>the code is in a bounce (DSN), the parsing might fail.


Mailman does treat a 552 received during delivery by SMTPDirect as
retryable, but this is different. Normally, a 552 - full mailbox will
never be seen by SMTPDirect, since delivery to the remote MTA won't be
attempted until after the SMTP transaction is complete. The 552 that
might be seen by SMTPDirect is based on RFC 821 which says a 552
response can be used for "too many recipients".


>I use exim 4.60 as outgoing mailserver and when attempting to deliver  
>to an overquota mailbox it will return a message with the following  
>body:
>
>
>This message was created automatically by mail delivery software.
>
>A message that you sent could not be delivered to one or more of its
>recipients. This is a permanent error. The following address(es) failed:
                       ^^^^^^^^^
>
>   user at example.domain
>     SMTP error from remote mail server after RCPT  
>TO:<user at example.domain>:
>     host mail-mx-4.tiscali.it [213.205.33.33]: 552 RCPT  
>TO:<user at example.domain> Mailbox disk quota exceeded


Exim is behaving properly in this case. The problem, if any, is with
the receiving MTA that is returning a 552 instead of a 452.


>The user is then given 1 point as with a permanent failure.
>If this is not what's supposed to happen, where do I look in the code  
>to fix this?


I'm currently working on the code in this area, but only to increase
the variety of notices that are recognized, and one other change in
the area of 'delayed' notices. The current code/design actually
provides no way to assign different scores to different bounces. The
recognizers (in Mailman/Bouncers) return either a list of bouncing
addresses or a 'stop' signal in the case of a 'delayed' or 'warning
only' DSN. Mailman treats the 'stop' signal as an empty list, so these
notices are treated the same as 'unrecognized'. In Mailman 2.1.8, the
'stop' signal will result in the bounce being ignored.

If you want to discuss implementation of variable scoring, we should
probably do that on mailman-developers.


>Or perhaps i should teach exim to treat 552 as temporary errors  
>(until the maximum retry has been reached).


If you want to actually keep retrying these, this would be the way to
go.

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


From msapiro at value.net  Mon Mar  6 18:00:40 2006
From: msapiro at value.net (Mark Sapiro)
Date: Mon, 6 Mar 2006 09:00:40 -0800
Subject: [Mailman-Developers] 552 SMTP CODE in bounce
In-Reply-To: <PC17402006030608385908900e27f455@msapiro>
Message-ID: <PC17402006030609004004531275044d@msapiro>

Mark Sapiro wrote:
>
>If you want to discuss implementation of variable scoring, we should
>probably do that on mailman-developers.


Sorry, this IS mailman-developers. My mistake.

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


From rjohnson at dogstar-interactive.com  Mon Mar  6 18:27:44 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Mon, 6 Mar 2006 12:27:44 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060306054419.GF8513@sliderule.msquared.com.au>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<20060306054419.GF8513@sliderule.msquared.com.au>
Message-ID: <6BFB62B4-3F74-4B72-9200-A068FA07B05F@dogstar-interactive.com>


On Mar 6, 2006, at 12:44 AM, Msquared wrote:

> On Fri, Mar 03, 2006 at 01:39:18PM -0800, Mark Sapiro wrote:
>
>> I.e, for the initial cut, split the lists/<listname> structure into
>> lists/<hostname>/<listname> and similarly for archives/private and
>> archives/public.
>
> Just a thought on this: might it be better to mangle the directories
> like so:
>
>   <hostname>/lists/<listname>
>   <hostname>/archives/<listmame>
>   etc
>
> so as to group things on a per-host basis?  One reason for doing so is
> that it (to me) makes more sense especially if you are hosting many
> domains that are not related or are different clients, etc.  It  
> simplifies
> the view of things from a per-host perspective.
>
> Perhaps even this:
>
>   <hostname>/<listname>/list
>   <hostname>/<listname>/archive
>   etc
>
> Even better, perhaps make it configurable.  :o)
>
> Regards, Msquared...
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users% 
> 40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman- 
> developers/rjohnson%40dogstar-interactive.com
>
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py? 
> req=show&amp;file=faq01.027.htp

I'll second this!

In general I object to co-mingling domain specific data.  it was the  
main motivation for my initial post.  I'm glad it triggered a bit  
more discussion that I expected. :-)

I'd encourage all to consider also:
  - domains are likely to have different requirements and/or be  
separately administered.
  - The storage format is not necessarily a file-system.  (as other  
discussions have indicated)
  - There's even an argument that storage format may vary between  
lists in a single domain.

In any case we have:
   archives <= f(domain,list,fmt)
   list <= f(domain,list, fmt)

How about a macro capability with $hosthame and $listname (ala Exim's  
$local_part, $domain) for filesystem storage?
One could specify:
     LIST_DATA_DIR = /var/lib/mailman/%hostname/lists
or
     LIST_DATA_DIR = /var/vdomains/%hostname/mailman/lists

in the config file according to your system/site conventions.

Another, more configurable, mechanism would be implementing  
''repository'' objects (initially implemented for filesystem  
storage):  These ''repositories'' would be indexed by ''hostname''.   
Their specification could be modeled after Apache's <VirtualHost>.   
To wit (assuming a way to interpret this snippit):
<VirtualHost  low-volume.tld>
     ArchivesRepository  filesystem
     ListsRepository         filesystem
     FilesystemRoot       /var/vdomains/low_volume/mailman
</VirtualHost>

<VirtualHost  high-volume.tld>
     ArchivesRepository  filesystem
     ListsRepository     database
     DatabaseType      Postgres
     FilesystemRoot     /var/vdomains/high_volume/mailman
     DB_info    mailman_db/mailman_usr/mailman_dbpwd
  </VirtualHost>
-----------------

Or even (tying these two together):

FilesystemRoot   /var/vdomains/%hostname/mailman
DatabaseType  postgres
DB_info          mailman-db/db-user/db-pwd
<VirtualHost low-volume.tld>
   ArchivesRepository  filesystem
   ListsRepository  filesystem
</VirtualHost>
<VirtualHost high-volume.tld>
   ArchivesRepository filesystem
   ListsRepository database
</VirtualHost>

--rich


From iane at sussex.ac.uk  Thu Mar  9 15:50:05 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 09 Mar 2006 14:50:05 +0000
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <4408B786.3030800@value.net>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
Message-ID: <5936888378F74F58528B366F@lewes.staff.uscs.susx.ac.uk>



--On 3 March 2006 13:39:18 -0800 Mark Sapiro <msapiro at value.net> wrote:

>
> Anyway, my intent is not to critique other solutions, but to say that I
> would much prefer to see a directory inserted rather than a host_name
> appended.

I guess that's a legacy term. Shouldn't we be using the term "domain_name" 
to refer to mail domains? I don't have lots of hosts, and lots of mail 
domains, but none of my host names match any of my domain names.


-- 
Ian Eiloart
IT Services, University of Sussex

From iane at sussex.ac.uk  Thu Mar  9 15:55:14 2006
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Thu, 09 Mar 2006 14:55:14 +0000
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <8664mun61v.fsf@n-dimensional.de>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>	<861wxjtv49.fsf@n-dimensional.de>
	<4408B786.3030800@value.net> <8664mun61v.fsf@n-dimensional.de>
Message-ID: <CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>



--On 4 March 2006 06:16:12 +0100 Hans Ulrich Niedermann 
<hun at n-dimensional.de> wrote:

>
> Actually, implementing the lists/<hostname>/<localpart> and
> archives/(private|public)/<hostname>/<localpart> was one of the first
> things I have implemented, as it is one of the easiest parts and had
> been mentioned at
> http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/VirtualHosting

I'd propose a slight variation on that, to better accommodate 
campus/corporate setups, as well as hosting providers:

lists/tld/subdomain/.../listname

for example, I'd have:

lists/uk/ac/sussex/
lists/uk/ac/sussex/physics
lists/uk/ac/sussex/chemistry
lists/uk/ac/sussex/english
...
and we host some 'external' domains, too:
lists/com/example


-- 
Ian Eiloart
IT Services, University of Sussex

From rjohnson at dogstar-interactive.com  Thu Mar  9 19:02:31 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Thu, 9 Mar 2006 13:02:31 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>	<861wxjtv49.fsf@n-dimensional.de>
	<4408B786.3030800@value.net> <8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
Message-ID: <73BF7D6A-E598-4CEA-8006-D65C6890FA22@dogstar-interactive.com>

On Mar 9, 2006, at 9:55 AM, Ian Eiloart wrote:
>>
>> Actually, implementing the lists/<hostname>/<localpart> and
>> archives/(private|public)/<hostname>/<localpart> was one of the first
>> things I have implemented, as it is one of the easiest parts and had
>> been mentioned at
>> http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/VirtualHosting
>
> I'd propose a slight variation on that, to better accommodate
> campus/corporate setups, as well as hosting providers:
>
> lists/tld/subdomain/.../listname
>
> [...snip...]

With all these variations, it might be reasonable to consider dumping  
the path macros altogether and switch to a functional model.
The path mapping functions could be supplied by mm_cfg and modified  
as appropriate for the installation.

For example, the existing 2.1 storage is functionally equivalent to:
     def  list_dir ( domain, list_localpart ) {
            return os.path.join( VAR_PREFIX,  'lists',  list_localpart )

Whereas what you're asking for is:
    def  list_dir( domain, list_localpart ){
           leaf = list_localpart
           for dom_part in domain.split('.'):
                leaf = os.path.join( dom_part, leaf )
            return os.path.join( VAR_PREFIX, 'lists', leaf )

And what works for _my systems_ would be:
    def  list_dir( domain, list_localpart ){
           return  os.path.join( '/var/vdomains/', domain, '/mailman/ 
lists', list_localpart)

IF one simply _MUST_ have different mapping regimes for different  
domains....well, then encode it into your mm_cfg.list_dir().




From rjohnson at dogstar-interactive.com  Thu Mar  9 20:25:19 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Thu, 9 Mar 2006 14:25:19 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <73BF7D6A-E598-4CEA-8006-D65C6890FA22@dogstar-interactive.com>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>	<861wxjtv49.fsf@n-dimensional.de>
	<4408B786.3030800@value.net> <8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<73BF7D6A-E598-4CEA-8006-D65C6890FA22@dogstar-interactive.com>
Message-ID: <272775E7-6EEF-4162-9620-3FDF4CC7149D@dogstar-interactive.com>


On Mar 9, 2006, at 1:02 PM, Rich Johnson wrote:

> On Mar 9, 2006, at 9:55 AM, Ian Eiloart wrote:
>>>
>>> Actually, implementing the lists/<hostname>/<localpart> and
>>> archives/(private|public)/<hostname>/<localpart> was one of the  
>>> first
>>> things I have implemented, as it is one of the easiest parts and had
>>> been mentioned at
>>> http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/ 
>>> VirtualHosting
>>
>> I'd propose a slight variation on that, to better accommodate
>> campus/corporate setups, as well as hosting providers:
>>
>> lists/tld/subdomain/.../listname
>>
>> [...snip...]
>
> With all these variations, it might be reasonable to consider dumping
> the path macros altogether and switch to a functional model.
> The path mapping functions could be supplied by mm_cfg and modified
> as appropriate for the installation.

Oh wait!

Mailman/Site.py already provides this function--but the rest of the  
system never propagates the domain--neither do the support utilities  
(like check_perms)

From hun at n-dimensional.de  Thu Mar  9 21:25:41 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Thu, 09 Mar 2006 21:25:41 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <272775E7-6EEF-4162-9620-3FDF4CC7149D@dogstar-interactive.com>
	(Rich Johnson's message of "Thu, 9 Mar 2006 14:25:19 -0500")
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de> <p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<73BF7D6A-E598-4CEA-8006-D65C6890FA22@dogstar-interactive.com>
	<272775E7-6EEF-4162-9620-3FDF4CC7149D@dogstar-interactive.com>
Message-ID: <8664mn74ca.fsf@n-dimensional.de>

Rich Johnson <rjohnson at dogstar-interactive.com> writes:

> On Mar 9, 2006, at 1:02 PM, Rich Johnson wrote:

[ 
  lists/<hostname>/<localpart>
  vs.
  lists/tld/subdomain/.../listname
  vs.
  ...
]

>> With all these variations, it might be reasonable to consider dumping
>> the path macros altogether and switch to a functional model.
>> The path mapping functions could be supplied by mm_cfg and modified
>> as appropriate for the installation.
>
> Oh wait!
>
> Mailman/Site.py already provides this function--but the rest of the  
> system never propagates the domain--neither do the support utilities  
> (like check_perms)

There are multiple places in the code where pathnames and URLs are
built outside of Mailman/Site.py. In the vhost branch, I need to
change all the code parts generating a path anyway, so I'm moving the
actual generation into a function in Mailman/Site.py while I'm at it.

Then if someone needs special file system layout later, he can rewrite
Mailman/Site.py into "from MySite import *" and implement his own
functions mapping objects to files and vice versa in a MySite.py
module. However, I'm not overly concerned with the details of all
possible layouts - that stuff is easy to change once it is
concentrated in a single module.

Gru?,

Hans Ulrich Niedermann

From sub1.dev.mailman at msquared.id.au  Fri Mar 10 01:37:53 2006
From: sub1.dev.mailman at msquared.id.au (Msquared)
Date: Fri, 10 Mar 2006 08:37:53 +0800
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
Message-ID: <20060310003753.GU8513@sliderule.msquared.com.au>

On Thu, Mar 09, 2006 at 02:55:14PM +0000, Ian Eiloart wrote:

> I'd propose a slight variation on that, to better accommodate 
> campus/corporate setups, as well as hosting providers:
> 
> lists/tld/subdomain/.../listname
> 
> for example, I'd have:
> 
> lists/uk/ac/sussex/
> lists/uk/ac/sussex/physics
> lists/uk/ac/sussex/chemistry
> lists/uk/ac/sussex/english

I second that.

Regards, Msquared...

From bob at nleaudio.com  Fri Mar 10 02:16:39 2006
From: bob at nleaudio.com (Bob Puff)
Date: Thu, 9 Mar 2006 20:16:39 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060310003753.GU8513@sliderule.msquared.com.au>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
Message-ID: <20060310011450.M35990@nleaudio.com>

I don't follow why one would need that, if you already separated based on
email domain.  In other words, if you had list at sussex.com,
list at physics.sussex.com, and list at english.sussex.com, why not:

/lists/sussex.com/list
/lists/physics.sussex.com/list
/lists/english.sussex.com/list

?

Bob


---------- Original Message -----------
From: Msquared <sub1.dev.mailman at msquared.id.au>
To: mailman-developers at python.org
Sent: Fri, 10 Mar 2006 08:37:53 +0800
Subject: Re: [Mailman-Developers] Virtual Domains Redux (w proposal)

> On Thu, Mar 09, 2006 at 02:55:14PM +0000, Ian Eiloart wrote:
> 
> > I'd propose a slight variation on that, to better accommodate 
> > campus/corporate setups, as well as hosting providers:
> > 
> > lists/tld/subdomain/.../listname
> > 
> > for example, I'd have:
> > 
> > lists/uk/ac/sussex/
> > lists/uk/ac/sussex/physics
> > lists/uk/ac/sussex/chemistry
> > lists/uk/ac/sussex/english
> 
> I second that.
> 
> Regards, Msquared...
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
> 
> Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp
------- End of Original Message -------


From tkikuchi at is.kochi-u.ac.jp  Fri Mar 10 02:51:26 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri, 10 Mar 2006 10:51:26 +0900
Subject: [Mailman-Developers] Released: Mailman 2.1.7a1
Message-ID: <4410DB9E.7010603@is.kochi-u.ac.jp>

Hi Developers and i18ners,

Mailman 2.1.8a1 was released for alpha test and i18n translations.
Unfortunately, SF file upload is currently down, so I've put up the tar
ball and the GPG signature on my Japanese Mailman site.

 gzipped tar file ... http://mm.tkikuchi.net/mailman-2.1.8a1.tgz
 GPG signature ... http://mm.tkikuchi.net/mailman-2.1.8a1.tgz.sig

And, here is the excerpts from NEWS file.

Cheers,

Tokio
---------------------------------------------------
Here is a history of user visible changes to Mailman.

2.1.8a1 (10-Mar-2006)

  Bug fixes and other patches

    - Bouncers support added: 'unknown user', Microsoft SMTPSVC, Prodigy.net
      and several others.

    - Updated email library to 2.5.7 which will encode payload into
qp/base64
      upon setting.  This enabled backing out the scrubber related patches
      including 'X-Mailman-Scrubbed' header in 2.1.7.

    - Fix SpamDetect.py potential hold/reject loop problem.

    - A warning message from email package to the stderr can cause error
      in Logging because stderr may be detached from the process during
      the qrunner run.  We chose not to output errors to stderr but to
      the logs/error if the process is running under mailmanctl subprocess.

    - DKIM header cleansing was separated from Cleanse.py and added to
      -owner messages too.

    - Fixes: Lose Topics when go directly to topics URL (1194419).
      UnicodeError running bin/arch (1395683).  edithtml.py missing import
      (1400128).  Bad escape in cleanarch.  Wrong timezone in list archive
      index pages (1433673).  bin/arch fails with TypeError (1430236).
      Subscription fails with some Language combinations (1435722).
      Postfix delayed notification not recognized (863989).  2.1.7 (VERP)
      mistakes delay notice for bounce (1421285).  show_qfiles: 'str'
      object has no attribute 'as_string' (1444447).

  Miscellaneous

    - Brad Knowles' mailman daily status report script updated to 0.0.16.


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




From tkikuchi at is.kochi-u.ac.jp  Fri Mar 10 02:59:50 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri, 10 Mar 2006 10:59:50 +0900
Subject: [Mailman-Developers] Mailman 2.1.8a1 (was Released: Mailman 2.1.7a1)
In-Reply-To: <4410DB9E.7010603@is.kochi-u.ac.jp>
References: <4410DB9E.7010603@is.kochi-u.ac.jp>
Message-ID: <4410DD96.8040404@is.kochi-u.ac.jp>

Ooooops! Sorry for the typo in the subject. :-(

Tokio Kikuchi wrote:
> Hi Developers and i18ners,
> 
> Mailman 2.1.8a1 was released for alpha test and i18n translations.
> Unfortunately, SF file upload is currently down, so I've put up the tar
> ball and the GPG signature on my Japanese Mailman site.
> 
>  gzipped tar file ... http://mm.tkikuchi.net/mailman-2.1.8a1.tgz
>  GPG signature ... http://mm.tkikuchi.net/mailman-2.1.8a1.tgz.sig
> 
> And, here is the excerpts from NEWS file.
> 
> Cheers,
> 
> Tokio
> ---------------------------------------------------
> Here is a history of user visible changes to Mailman.
> 
> 2.1.8a1 (10-Mar-2006)
> 
>   Bug fixes and other patches
> 
>     - Bouncers support added: 'unknown user', Microsoft SMTPSVC, Prodigy.net
>       and several others.
> 
>     - Updated email library to 2.5.7 which will encode payload into
> qp/base64
>       upon setting.  This enabled backing out the scrubber related patches
>       including 'X-Mailman-Scrubbed' header in 2.1.7.
> 
>     - Fix SpamDetect.py potential hold/reject loop problem.
> 
>     - A warning message from email package to the stderr can cause error
>       in Logging because stderr may be detached from the process during
>       the qrunner run.  We chose not to output errors to stderr but to
>       the logs/error if the process is running under mailmanctl subprocess.
> 
>     - DKIM header cleansing was separated from Cleanse.py and added to
>       -owner messages too.
> 
>     - Fixes: Lose Topics when go directly to topics URL (1194419).
>       UnicodeError running bin/arch (1395683).  edithtml.py missing import
>       (1400128).  Bad escape in cleanarch.  Wrong timezone in list archive
>       index pages (1433673).  bin/arch fails with TypeError (1430236).
>       Subscription fails with some Language combinations (1435722).
>       Postfix delayed notification not recognized (863989).  2.1.7 (VERP)
>       mistakes delay notice for bounce (1421285).  show_qfiles: 'str'
>       object has no attribute 'as_string' (1444447).
> 
>   Miscellaneous
> 
>     - Brad Knowles' mailman daily status report script updated to 0.0.16.
> 
> 


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

From sub1.dev.mailman at msquared.id.au  Fri Mar 10 03:00:07 2006
From: sub1.dev.mailman at msquared.id.au (Msquared)
Date: Fri, 10 Mar 2006 10:00:07 +0800
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060310011450.M35990@nleaudio.com>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
Message-ID: <20060310020007.GX8513@sliderule.msquared.com.au>

On Thu, Mar 09, 2006 at 08:16:39PM -0500, Bob Puff wrote:

> I don't follow why one would need that, if you already separated based on
> email domain.  In other words, if you had list at sussex.com,
> list at physics.sussex.com, and list at english.sussex.com, why not:
> 
> /lists/sussex.com/list
> /lists/physics.sussex.com/list
> /lists/english.sussex.com/list

Scope of ownership and management.

These might have different owners:

  /lists/mine.example.net/
  /lists/yours.example.net/

but these might have the same owner:

  /lists/dept1.foo.org/
  /lists/dept2.foo.org/

If it were possible to control access/ownership/etc according to
subdirectories, this would allow you to grant control of subdirectories
from the appropriate level down:

  /lists/org/foo/  is for *.foo.org
  /lists/net/example/mine/ is for me
  /lists/net/exmaple/yours/ is for you

Of course I don't know if mailman yet allows such delegation of control,
but it would be nifty...

You could still control access like that through unix/linux directory
ownerships, for example, though.

Regards, Msquared...

From bob at nleaudio.com  Fri Mar 10 03:04:59 2006
From: bob at nleaudio.com (Bob Puff)
Date: Thu, 9 Mar 2006 21:04:59 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060310020007.GX8513@sliderule.msquared.com.au>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
	<20060310020007.GX8513@sliderule.msquared.com.au>
Message-ID: <20060310020230.M87058@nleaudio.com>




---------- Original Message -----------
From: Msquared <sub1.dev.mailman at msquared.id.au>
To: mailman-developers at python.org
Sent: Fri, 10 Mar 2006 10:00:07 +0800
Subject: Re: [Mailman-Developers] Virtual Domains Redux (w proposal)

> On Thu, Mar 09, 2006 at 08:16:39PM -0500, Bob Puff wrote:
> 
> > I don't follow why one would need that, if you already separated based on
> > email domain.  In other words, if you had list at sussex.com,
> > list at physics.sussex.com, and list at english.sussex.com, why not:
> > 
> > /lists/sussex.com/list
> > /lists/physics.sussex.com/list
> > /lists/english.sussex.com/list
> 
> Scope of ownership and management.
> 
> These might have different owners:
> 
>   /lists/mine.example.net/
>   /lists/yours.example.net/
> 
> but these might have the same owner:
> 
>   /lists/dept1.foo.org/
>   /lists/dept2.foo.org/
> 
> If it were possible to control access/ownership/etc according to
> subdirectories, this would allow you to grant control of subdirectories
> from the appropriate level down:
> 
>   /lists/org/foo/  is for *.foo.org
>   /lists/net/example/mine/ is for me
>   /lists/net/exmaple/yours/ is for you
> 
> Of course I don't know if mailman yet allows such delegation of 
> control, but it would be nifty...
> 
> You could still control access like that through unix/linux directory
> ownerships, for example, though.


I think we're drifting here from a logical format.  If there is to be shared
ownership, I think that needs to be done with a different database.  It could
be a nightmare from the admin side if you group things by who wants to own
what lists, rather than by domain.  I believe the initial point behind the
start of this is that list at foo and list at bar should be able to cohabitate on
the same install.

Bob

From sub1.dev.mailman at msquared.id.au  Fri Mar 10 03:22:52 2006
From: sub1.dev.mailman at msquared.id.au (Msquared)
Date: Fri, 10 Mar 2006 10:22:52 +0800
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060310020230.M87058@nleaudio.com>
References: <864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
	<20060310020007.GX8513@sliderule.msquared.com.au>
	<20060310020230.M87058@nleaudio.com>
Message-ID: <20060310022252.GY8513@sliderule.msquared.com.au>

On Thu, Mar 09, 2006 at 09:04:59PM -0500, Bob Puff wrote:

> I think we're drifting here from a logical format.

You could be right.  My structural and pedantic parts liked the
subdirectories for parts of hostnames, but I'm not glued to the idea yet.
:o)

> I believe the initial point behind the start of this is that list at foo
> and list at bar should be able to cohabitate on the same install.

You are right, and /lists/foo.example.net/list is a perfectly good way to
differentiate.

Regards, Msquared...

From brad at stop.mail-abuse.org  Fri Mar 10 03:33:17 2006
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri, 10 Mar 2006 03:33:17 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060310020230.M87058@nleaudio.com>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
	<20060310020007.GX8513@sliderule.msquared.com.au>
	<20060310020230.M87058@nleaudio.com>
Message-ID: <p0620077bc03694f7f13d@[10.0.1.211]>

At 9:04 PM -0500 2006-03-09, Bob Puff wrote:

>  I think we're drifting here from a logical format.  If there is to be shared
>  ownership, I think that needs to be done with a different database.  It could
>  be a nightmare from the admin side if you group things by who wants to own
>  what lists, rather than by domain.

	Actually, his proposed scheme does make sense for a larger-scale 
environment.  Indeed, that's the second-most scalable way I know of 
to do it.  The most scalable would have some sort of side index 
system and use good hashing algorithms to avoid having a billion 
subdirectories under /usr/local/mailman/lists/com/ and maybe just a 
few hundred under /usr/local/mailman/lists/info/.

	For smaller environments, you might want a different option.


	I think what we really need is some way to guarantee that any of 
several different suitable formats could be used, some of which might 
be more easily understood at a glance, others which might be more 
complex but also more scalable.

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

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

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

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

From rjohnson at dogstar-interactive.com  Fri Mar 10 03:58:34 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Thu, 9 Mar 2006 21:58:34 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <20060310020230.M87058@nleaudio.com>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
	<20060310020007.GX8513@sliderule.msquared.com.au>
	<20060310020230.M87058@nleaudio.com>
Message-ID: <1365633D-51B6-4ECD-B1D8-5BEB368CED6B@dogstar-interactive.com>

> [...snip...]
>
> I think we're drifting here from a logical format.  If there is to  
> be shared
> ownership, I think that needs to be done with a different  
> database.  It could
> be a nightmare from the admin side if you group things by who wants  
> to own
> what lists, rather than by domain.  I believe the initial point  
> behind the
> start of this is that list at foo and list at bar should be able to  
> cohabitate on
> the same install.

Not quite.    It depends on your interpretation of what 'cohabitate'  
means.

As the initiator, I'll chime in with the following:

_processed_ by the same install? yes.
  _cohabitate_? perhaps.  But this is a site and/or  domain  
administrator configuration decision--and not imposed by the  
developer.  I've been pretty consistent about my aversion to  
comingling data from separate domains in the same tree.  I view the  
domain split as _more_ important that the virtual service provided-- 
be it apache vhosts, exim vusers, or mailman.  Ideally it could be a  
mount point.

IMO:
- Ephemeral data such as queues and logs might or might not cohabit.
- Persistent data such as list configuration, subscriber lists, and  
archives must be severable
- HTTP and mail message templates probably require list->sub-domain- 
 >base-domain->site scoping  [N.B.  I'm still thinking about my  
position on this issue]

A good part of this discussion seems to revolve around whether  
mailman ''plays well with others''.  Where the ''others'' are  
amorphously defined.

From rjohnson at dogstar-interactive.com  Fri Mar 10 04:07:24 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Thu, 9 Mar 2006 22:07:24 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <p0620077bc03694f7f13d@[10.0.1.211]>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
	<20060310020007.GX8513@sliderule.msquared.com.au>
	<20060310020230.M87058@nleaudio.com>
	<p0620077bc03694f7f13d@[10.0.1.211]>
Message-ID: <DE5D3387-6B0A-4032-B16D-BBF6540F0D9B@dogstar-interactive.com>


On Mar 9, 2006, at 9:33 PM, Brad Knowles wrote:


> [...snip...]
> I think what we really need is some way to guarantee that any of
> several different suitable formats could be used, some of which might
> be more easily understood at a glance, others which might be more
> complex but also more scalable.
>
>

Put 3 or 4 variants in Mailman/Site.py and activate one during  
installation?

We're getting dangerously close to some OO programming issues!


From hun at n-dimensional.de  Fri Mar 10 20:11:47 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Fri, 10 Mar 2006 20:11:47 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <1365633D-51B6-4ECD-B1D8-5BEB368CED6B@dogstar-interactive.com>
	(Rich Johnson's message of "Thu, 9 Mar 2006 21:58:34 -0500")
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de> <p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
	<20060310020007.GX8513@sliderule.msquared.com.au>
	<20060310020230.M87058@nleaudio.com>
	<1365633D-51B6-4ECD-B1D8-5BEB368CED6B@dogstar-interactive.com>
Message-ID: <86wtf29kss.fsf@n-dimensional.de>

Rich Johnson <rjohnson at dogstar-interactive.com> writes:

> As the initiator, I'll chime in with the following:

[ list at foo and list at bar on the same MM instance ]

> _processed_ by the same install? yes.
>
>   _cohabitate_? perhaps.  But this is a site and/or  domain  
> administrator configuration decision--and not imposed by the  
> developer.  I've been pretty consistent about my aversion to  
> comingling data from separate domains in the same tree.  I view the  
> domain split as _more_ important that the virtual service provided-- 
> be it apache vhosts, exim vusers, or mailman.  Ideally it could be a  
> mount point.
>
> IMO:
> - Ephemeral data such as queues and logs might or might not cohabit.

...depending on the number of mails per day, the number of lists,
number of subdomains, number of subdomain admins, and how the admin
tasks are distributed between the site admins and the subdomain
admins.

> - Persistent data such as list configuration, subscriber lists, and  
>   archives must be severable

This can be achieved by consequent usage of Mailman/Site.py -
basically concentrating all calls to os.path.join() in Mailman/Site.py.

> - HTTP and mail message templates probably require list->sub-domain- 
>  >base-domain->site scoping  [N.B.  I'm still thinking about my  
> position on this issue]

Let me cite the comment from MM's 2.1.7 Mailman/Utils.py findtext()
function:

    # When looking for a template in a specific language, there are 4 places
    # that are searched, in this order:
    #
    # 1. the list-specific language directory
    #    lists/<listname>/<language>
    #
    # 2. the domain-specific language directory
    #    templates/<list.host_name>/<language>
    #
    # 3. the site-wide language directory
    #    templates/site/<language>
    #
    # 4. the global default language directory
    #    templates/<language>

Looks like your idea is already in place. :)

Gru?,

Hans Ulrich Niedermann

From hun at n-dimensional.de  Fri Mar 10 21:07:49 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Fri, 10 Mar 2006 21:07:49 +0100
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <1141620316.32263.161.camel@resist.wooz.org> (Barry Warsaw's
	message of "Sun, 05 Mar 2006 23:45:16 -0500")
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de> <p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<20060304195620.M62195@nleaudio.com>
	<1141620316.32263.161.camel@resist.wooz.org>
Message-ID: <86acby3vxm.fsf@n-dimensional.de>

Barry Warsaw <barry at python.org> writes:

> Also, now that SF provides Subversion support, I very strongly want to
> migrate to it.  Among many other advantages, this will make it easier to
> create experimental branches to work on things like this.

Is there a time schedule for migration SVN, and would I get to play
with a branch there? :) I think my vhost branch is ready to be turned
into an experimental SVN branch.

I would first start on MM 2.2 and introduce the necessary abstractions
for file locations and the like, without changing the actual
behaviour. Once those abstrations are in place, I would then build the
vhost branch on that and thus make the vhost patch much smaller and
easier to comprehend.

Even if you do not want my vhost changes in official Mailman, those
abstractions could still be beneficial for both official Mailman and
for independent maintenance of a vhost branch.



The following is a more detailed list which shows the current state of
the vhost branch. It is not complete yet (there will still be a number
of issues to solve, and I will do so), but the basics are there:

  * Support for three list types:
     1. site wide lists without "postfix style virtual hosting":
         - internal_name()=="foo", like in 2.1.7)
         - uses the DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST
     2. site wide lists with "postfix style virtual hosting":
         - internal_name()=="fox", like in 2.1.7
         - "fox" here conflicts with site wide "fox" even in case of
           different host_name
         - uses special email_host and (possibly) url_host
     3. vhost lists
         - internal_name()=="foo at bar" (new in vhost branch)
         - no conflicts with site-wide "foo" or vhost list "foo at bleh"
         - requires registration of the url_host<->email_host relation in
           mm_cfg (cf. VIRTUAL_HOSTS, add_virtualhost()) by the site
           admin
    Note: Type 2 lists may be migrated to type 3 lists, so I have not
          tested that type 2 lists work all that well. If we drop type
          2 lists altogether, that work would have been in vain, so
          I'm not very much concerned about them. The architecture
         itself does not prevent their continued use.

  * Web and E-Mail templates produce the expected results.

  * The Web interface works as expected, as far as one can tell
    without executing an automated test with complete coverage:
     - (un)subscribing to lists works
     - administrating the list settings works
     - moderating postings works
    The URL space looks like this (for the example lists from above):
      http://lists.site-wide/listinfo/foo
      http://lists.site-wide/listinfo/fox
      http://lists.bar/listinfo/foo
      http://lists.bleh/listinfo/bleh
    Possible issues I don't care about on my installation:
     - There is no single web site which lists all lists.
     - All lists using the same url_host must use the same
       email_host.
     - You can/must use a single Apache <VirtualHost> for all lists.*
       URLs. (They do necessarily have to be called "lists.*").
     - You cannot have different basic URLs for different url_hosts,
       i.e. integration into existing websites is
       difficult/impossible.

  * Command line list creation works.

  * Sending mail to site wide lists and vhost lists works.

  * Generate proper aliases and virtual aliases for Postfix.

A few things are still to do:

  * Introduce the role of a vhost-domain admin between the site admin
    and the list admins. This requires per vhost-domain storage
    modifiable by the vhost-domain admin which we do not have. (The
    vhost-domain admin should be able to modify his password, right?)

  * Enforce the requirement of one mailman at vhost-domain list per
    vhost-domain.

  * Should we migrate the site wide lists with "postfix style virtual
    hosting" to vhost lists? I have not done this yet in order to
    avoid additional work in the proof-of-concept phase.

  * Backing out unnecessary stuff introduced while getting to know the
    code and generally clean up stuff.

  * CGI list creation/removal do not work yet.

  * ...

If you want to examine the vhost branch yourself, here are a number of
links:

Current patch against mailman-2.1.7 with the 20060114 patch:
    http://nix.lauft.net/mailman/mailman-2.1.7-20060114-to-vhost-current.patch
The README.VHOST containing more text on issues and solutions:
    http://nix.lauft.net/mailman/README.VHOST
The overview page:
    http://nix.lauft.net/mailman/
Cogito/Git repository:
    http://git.n-dimensional.de/mailman-virtualhost.git/

Gru?,

Hans Ulrich Niedermann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060310/ea01d97c/attachment.pgp 

From rjohnson at dogstar-interactive.com  Fri Mar 10 22:37:37 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Fri, 10 Mar 2006 16:37:37 -0500
Subject: [Mailman-Developers] Virtual Domains Redux (w proposal)
In-Reply-To: <86wtf29kss.fsf@n-dimensional.de>
References: <26DF059A-19A9-4042-82A7-D8DCBE7B7FC8@dogstar-interactive.com>
	<864q2fwtl1.fsf@n-dimensional.de>
	<p06200737c02e0b4db590@[10.0.1.211]>
	<861wxjtv49.fsf@n-dimensional.de> <4408B786.3030800@value.net>
	<8664mun61v.fsf@n-dimensional.de>
	<CAC25E79D14E0EBDA4DE3A43@lewes.staff.uscs.susx.ac.uk>
	<20060310003753.GU8513@sliderule.msquared.com.au>
	<20060310011450.M35990@nleaudio.com>
	<20060310020007.GX8513@sliderule.msquared.com.au>
	<20060310020230.M87058@nleaudio.com>
	<1365633D-51B6-4ECD-B1D8-5BEB368CED6B@dogstar-interactive.com>
	<86wtf29kss.fsf@n-dimensional.de>
Message-ID: <6ABF2BE5-7F6D-4460-9429-0F0C6B3F8424@dogstar-interactive.com>


On Mar 10, 2006, at 2:11 PM, Hans Ulrich Niedermann wrote:

> Rich Johnson <rjohnson at dogstar-interactive.com> writes:
>> [...snip...]
>> - HTTP and mail message templates probably require list->sub-domain-
>> base-domain->site scoping  [N.B.  I'm still thinking about my
>> position on this issue]
>
> Let me cite the comment from MM's 2.1.7 Mailman/Utils.py findtext()
> function:
>
>     # When looking for a template in a specific language, there are  
> 4 places
>     # that are searched, in this order:
>     #
>     # 1. the list-specific language directory
>     #    lists/<listname>/<language>
>     #
>     # 2. the domain-specific language directory
>     #    templates/<list.host_name>/<language>
>     #
>     # 3. the site-wide language directory
>     #    templates/site/<language>
>     #
>     # 4. the global default language directory
>     #    templates/<language>
>
> Looks like your idea is already in place. :)

Hooray!  The scoping exists!.  (FWIW, I needed some good news today!)

Now, if I can use Site.py (or one of its siblings) to bring it all  
into a domain-rooted fs by mapping:
  - lists/<listname>/<language>   ->  /var/vdomains/<list.host_name>/ 
var/lib/mailman/lists/<llist.local_name>/<language>
  - templates/<list.host_name>   -> /var/vdomains/<list.host_name>/ 
var/lib/mailman/templates/<language>

perhaps via:  Site.list_template_dir().  Site.domain_template_dir(),   
and so on....

......I'll declare victory and wait for the next release (...well,  
maybe :-)

I hope that's not too much to ask.

From andrew.clark at ucsb.edu  Tue Mar 14 21:44:10 2006
From: andrew.clark at ucsb.edu (Andrew D. Clark)
Date: Tue, 14 Mar 2006 12:44:10 -0800
Subject: [Mailman-Developers] canonical MM-List-Name
Message-ID: <200603141244.10542.andrew.clark@ucsb.edu>

I've made a small patch to HTMLFormatter.py to provide for a canonical (aka 
lowercase) list name.  This is handy for a variety of reasons.

383a384
>             '<mm-lc-list-name>' : self.real_name.lower(),

I don't really care if it is called mm-lc-list-name or mm-canonical-list-name 
or what not, I simply find the regularized name useful for some applications.
Any comments?

-- 
Andrew Clark
Campus Network Programmer
University of California, Santa Barbara
andrew.clark at ucsb.edu (805) 893-5311

From rjohnson at dogstar-interactive.com  Tue Mar 14 23:53:50 2006
From: rjohnson at dogstar-interactive.com (Rich Johnson)
Date: Tue, 14 Mar 2006 17:53:50 -0500
Subject: [Mailman-Developers] canonical MM-List-Name
In-Reply-To: <200603141244.10542.andrew.clark@ucsb.edu>
References: <200603141244.10542.andrew.clark@ucsb.edu>
Message-ID: <861E2392-1FD9-4961-A91C-16C12F2BA80E@dogstar-interactive.com>

On Mar 14, 2006, at 3:44 PM, Andrew D. Clark wrote:

> I've made a small patch to HTMLFormatter.py to provide for a  
> canonical (aka
> lowercase) list name.  This is handy for a variety of reasons.
>
> 383a384
>>             '<mm-lc-list-name>' : self.real_name.lower(),
>
> I don't really care if it is called mm-lc-list-name or mm-canonical- 
> list-name
> or what not, I simply find the regularized name useful for some  
> applications.
> Any comments?

In general I think this is a good idea.

But I have two and a half questions:
- What is the impact on existing lists which might have case  
sensitive names?  Would a converter script be necessary?
- What does it mean for MTA configurations?   (I'm thinking exim)   
AFAIK, the local-part (i.e. listname) of an email address is case  
sensitive, though the domain-part is not.


From andrew.clark at ucsb.edu  Wed Mar 15 00:02:24 2006
From: andrew.clark at ucsb.edu (Andrew D. Clark)
Date: Tue, 14 Mar 2006 15:02:24 -0800
Subject: [Mailman-Developers] canonical MM-List-Name
In-Reply-To: <861E2392-1FD9-4961-A91C-16C12F2BA80E@dogstar-interactive.com>
References: <200603141244.10542.andrew.clark@ucsb.edu>
	<861E2392-1FD9-4961-A91C-16C12F2BA80E@dogstar-interactive.com>
Message-ID: <200603141502.24500.andrew.clark@ucsb.edu>

On Tuesday 14 March 2006 14:53, Rich Johnson wrote:
> On Mar 14, 2006, at 3:44 PM, Andrew D. Clark wrote:
> > I've made a small patch to HTMLFormatter.py to provide for a
> > canonical (aka
> > lowercase) list name.  This is handy for a variety of reasons.
> >
> > 383a384
> >
> >>             '<mm-lc-list-name>' : self.real_name.lower(),
> >
> > I don't really care if it is called mm-lc-list-name or mm-canonical-
> > list-name
> > or what not, I simply find the regularized name useful for some
> > applications.
> > Any comments?
>
> In general I think this is a good idea.
>
> But I have two and a half questions:
> - What is the impact on existing lists which might have case
> sensitive names?  Would a converter script be necessary?

None, I think.  This just provides a lower-cased name for the HTML templates.  
It's merely an addition and would need to be explicitly referenced to be 
used.

> - What does it mean for MTA configurations?   (I'm thinking exim)
> AFAIK, the local-part (i.e. listname) of an email address is case
> sensitive, though the domain-part is not.

Again, none.  This wouldn't change any existing behavior. 

-- 
Andrew Clark
Campus Network Programmer
University of California, Santa Barbara
andrew.clark at ucsb.edu (805) 893-5311

From barry at python.org  Wed Mar 15 22:59:00 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 15 Mar 2006 16:59:00 -0500
Subject: [Mailman-Developers] canonical MM-List-Name
In-Reply-To: <200603141244.10542.andrew.clark@ucsb.edu>
References: <200603141244.10542.andrew.clark@ucsb.edu>
Message-ID: <1142459941.2141.16.camel@resist.wooz.org>

On Tue, 2006-03-14 at 12:44 -0800, Andrew D. Clark wrote:
> I've made a small patch to HTMLFormatter.py to provide for a canonical (aka 
> lowercase) list name.  This is handy for a variety of reasons.
> 
> 383a384
> >             '<mm-lc-list-name>' : self.real_name.lower(),
> 
> I don't really care if it is called mm-lc-list-name or mm-canonical-list-name 
> or what not, I simply find the regularized name useful for some applications.
> Any comments?

+1, although I prefer something like 'mm-list-name-canonical'.  Submit
it to SF!

-Barry

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

From barry at python.org  Wed Mar 15 23:09:43 2006
From: barry at python.org (Barry Warsaw)
Date: Wed, 15 Mar 2006 17:09:43 -0500
Subject: [Mailman-Developers] Moving to Subversion after 2.1.8 is released
Message-ID: <1142460583.2208.25.camel@resist.wooz.org>

SourceForge has recently made Subversion available to projects, and I am
planning on switching us from CVS to Subversion after the 2.1.8 release
goes out.  If you don't access the bleeding edge Mailman code in the
source repository, you probably don't care, and can ignore the rest of
this message.

If you've used Subversion before, you're well aware of the many
advantages of using it over CVS.  I'm psyched to make the switch, and
Tokio and Mark are on-board with it.  I may even start finding time to
begin hacking on the code again. :)

If you haven't used Subversion before, now's a good time to take a look.
You can start here:

http://svnbook.red-bean.com/

You should easily be able to find Subversion clients for any major *nix
distro.  I think it's pretty easy for CVS users to learn how to use
Subversion, especially if you're mostly doing anonymous checkouts.

I will send out another message just before I make the switch.  I'm not
sure how smoothly it will go -- SF has automated the process, at least
for 'sane' CVS repositories.  Hopefully ours is sane!  Once the change
is made, I think the old CVS repository will still be available, but all
the fun stuff will be happening in the Subversion repository.

-Barry

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

From andrew.clark at ucsb.edu  Thu Mar 16 02:44:47 2006
From: andrew.clark at ucsb.edu (Andrew D. Clark)
Date: Wed, 15 Mar 2006 17:44:47 -0800
Subject: [Mailman-Developers] canonical MM-List-Name
In-Reply-To: <1142459941.2141.16.camel@resist.wooz.org>
References: <200603141244.10542.andrew.clark@ucsb.edu>
	<1142459941.2141.16.camel@resist.wooz.org>
Message-ID: <200603151744.47755.andrew.clark@ucsb.edu>

On Wednesday 15 March 2006 13:59, Barry Warsaw wrote:
> On Tue, 2006-03-14 at 12:44 -0800, Andrew D. Clark wrote:
> > I've made a small patch to HTMLFormatter.py to provide for a canonical
> > (aka lowercase) list name.  This is handy for a variety of reasons.
> >
> > 383a384
> >
> > >             '<mm-lc-list-name>' : self.real_name.lower(),
> >
> > I don't really care if it is called mm-lc-list-name or
> > mm-canonical-list-name or what not, I simply find the regularized name
> > useful for some applications. Any comments?
>
> +1, although I prefer something like 'mm-list-name-canonical'.  Submit
> it to SF!
>
> -Barry

I was waiting for Barry clearance :-)
I'll submit a patch to SF tomorrow with mm-list-name-canonical.

Andrew Clark

From hun at n-dimensional.de  Thu Mar 16 09:51:08 2006
From: hun at n-dimensional.de (Hans Ulrich Niedermann)
Date: Thu, 16 Mar 2006 09:51:08 +0100
Subject: [Mailman-Developers] Experiences migrating from CVS to SVN
Message-ID: <86zmjqojr7.fsf@n-dimensional.de>

Hi,

on 2006-03-13 I have migrated the gPhoto project from SF.net CVS to
SF.net SVN by just clicking the respective button on the web
interface.

I want to share this experience in order to help you decide as to if,
how and when to do a CVS->SVN migration of Mailman.

It started with an about 10 day's notice so people would be aware of
the change beforehand and could commit their stuff before and not
interfere with the migration itself.

On day zero, The SF.net cron job started the migration started 3
minutes after I had clicked the button and finished it 40 more minutes
later.

You can compare the results in the web interface:

    CVS: http://cvs.sourceforge.net/viewcvs.py/gphoto/
    SVN: http://svn.sourceforge.net/viewcvs.cgi/gphoto/

but I'll try to illustrate it here. The resulting SVN repository is
structured like this:

   branches/
      libgphoto2-2.1.4/
         libgphoto2/
      gphoto2-2.1.4/
         gphoto2/
   tags/
      libgphoto2-2.1.4-rc3/
         libgphoto2/
      libgphoto2-2.1.4-release/
         libgphoto2/
      gphoto2-2.1.4-rc2/
         gphoto2/
      gphoto2-2.1.4-release/
         gphoto2/
   trunk/
      gphoto2/
      libgphoto2/

where the CVS repository was structured like this:

   gphoto2/
   libgphoto2/

with "libgphoto2-2.1.4" being a branch of "libgphoto2/" leading to the
tags "libgphoto2-2.1.4-rc3" for the release candidate and
"libgphoto2-2.1.4-release" for the release, and analogously for
"gphoto2" and its branches and tags.

You can imagine what the Mailman SVN would look like after this
migration. If one need a different directory structure, things
probably get a little more interesting than just one click in the web
interface and a little waiting time :) However, I didn't have the
nerve to do that.

The CVS repository remains available, so anybody can still run
"cvs diff" on existing working copies or check out older versions
from before the migration via CVS.

Additional jobs:

 * In order to prevent people from continuing their work with CVS, I
   have patched the autogen.sh and configure scripts to abort with a
   message on the CVS->SVN migration and then have disabled commit
   access via CVSROOT.

 * I have not (yet) found a way to continue using the very same
   working copy from CVS with SVN, but have shown people the basic
   commands to check out from SVN, commit to SVN (with user
   credentials), and how to merge a patch of their uncommitted CVS
   changes into SVN.

 * Some docs and web pages referring to CVS needed to be changed, and
   finally, I made announcements on the mailinglist and the SF.net
   project News and changed the SF.net project page to show only SVN,
   not CVS.

 * Set up the commit hook scripts for e-mail and ciabot notification.
   Note that SF.net SVN does not allow fine-grained permission setup
   to the SVN repository like it allows via CVS hook scripts. With
   SVN, write access is either all or nothing.

 * Migrate the definitions from CVSROOT/modules via
      svn propedit svn:externals .

 * One or two smaller things I have forgotten to list here.

We have no experience with long term user acceptance yet. People
uncomfortable with SVN/CVS and with possibly installing a new software
package on their system may be annoyed a little. I could imagine this
won't be much of a problem for Mailman, though, as Mailman caters more
to sysadmins where (lib)gphoto2 also addresses end users.

I hope this can help with preparations. Feel free to ask questions any
time.

Gru?,

Hans Ulrich Niedermann

From dev+lists at humph.com  Thu Mar 16 12:05:52 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Thu, 16 Mar 2006 12:05:52 +0100
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
Message-ID: <50A21C7B-E519-4B1F-A84E-7E2E410B38D1@humph.com>

Hello,
I am trying to debug a problem with the confirmation from one of my  
users.
The user as replied to the invitation email but her subscriptions has  
been refused (her state is still S).

Here are the gory details:

(I have obscured only mail addresses and list details. IP addresses  
and confirmation string are untouched.
Sorry for the long line length.)


invitation sent:

2006-03-16 00:38:07 IW70BJ-000K5I-JO <= mylist-bounces 
+user=domain at list.server H=localhost (g4.local) [127.0.0.1] P=esmtp  
S=2041 id=mailman.0.1142465885.26117.mylist at list.server
2006-03-16 00:38:08 IW70BJ-000K5I-JO => user at domain R=dnslookup  
T=remote_smtp H=mx1.libero.it [193.70.193.95]


3 attempts by the user to confirm subscription, they are sent to the  
correct confirm address:



2006-03-16 10:43:17 IW7SC5-0002D5-0Z <= user at domain H=smtp5.libero.it  
[193.70.192.55] P=esmtp S=1982 id=IW7S96 
$A6460D465ACAB1F3B705458C794DF7C1 at libero.it
2006-03-16 10:43:18 IW7SC5-0002D5-0Z => mylist <mylist-confirm 
+8a671672b88489848cd212b368d290cc343af848 at list.server>  
R=mailman_router T=mailman_transport
2006-03-16 10:43:18 IW7SC5-0002D5-0Z Completed
2006-03-16 10:43:22 IW7SCA-0002DA-HL <= mylist-bounces 
+user=domain at list.server H=localhost (g4.local) [127.0.0.1] P=esmtp  
S=3833 id=mailman.54.1142502199.2491.mylist at list.server
2006-03-16 10:43:24 IW7SCA-0002DA-HL => user at domain R=dnslookup  
T=remote_smtp H=mx1.libero.it [193.70.193.95]
2006-03-16 10:43:24 IW7SCA-0002DA-HL Completed

2006-03-16 10:45:09 IW7SF9-0002DI-2J <= user at domain H=smtp2.libero.it  
[193.70.192.52] P=esmtp S=2905 id=IW7SCA 
$74805EBCDDDF86B284ECA9380FB5979F at libero.it
2006-03-16 10:45:10 IW7SF9-0002DI-2J => mylist <mylist-confirm 
+8a671672b88489848cd212b368d290cc343af848 at list.server>  
R=mailman_router T=mailman_transport
2006-03-16 10:45:10 IW7SF9-0002DI-2J Completed

2006-03-16 10:45:13 IW7SFD-0002DR-3R <= mylist-bounces 
+user=domain at list.server H=localhost (g4.local) [127.0.0.1] P=esmtp  
S=5836 id=mailman.55.1142502310.2491.mylist at list.server
2006-03-16 10:45:16 IW7SFD-0002DR-3R => user at domain R=dnslookup  
T=remote_smtp H=mx1.libero.it [193.70.193.95]
2006-03-16 10:45:16 IW7SFD-0002DR-3R Completed
2006-03-16 10:46:58 IW7SIA-0002DU-E3 <= user at domain H=smtp3.libero.it  
[193.70.192.127] P=esmtp S=1771 id=IW7SFC 
$6E27427742E6C42C9FB6F56151FC9726 at libero.it
2006-03-16 10:46:59 IW7SIA-0002DU-E3 => mylist <mylist-confirm 
+8a671672b88489848cd212b368d290cc343af848 at list.server>  
R=mailman_router T=mailman_transport
2006-03-16 10:46:59 IW7SIA-0002DU-E3 Completed



The user received the following error after the first attempt, I just  
cut some received lines.
The message is in italian and reads more or less:

Results: invalid confirmation string [...]

Not processed:
     confirm 8a671672b88489848cd212b368d290cc343af848

End


Return-Path: <mylist-bounces+user=domain at list.server>
Received: from smtp3.libero.it (193.70.192.127) by ims19c.libero.it  
(7.2.059.5)
         id 4406D169001733AB for user at domain; Thu, 16 Mar 2006  
10:43:19 +0100
[...]
Received: from localhost ([127.0.0.1] helo=g4.local)
	by tempesta.mydomain with esmtp (Exim 4.60)
	(envelope-from <mylist-bounces+user=domain at list.server>)
	id IW7SIE-0002DZ-GK
	for user at domain; Thu, 16 Mar 2006 10:47:02 +0100
Subject: =?iso-8859-1?q?Risultati_dei_comandi_nel_tuo_messaggio?=
From: mylist-bounces at list.server
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1898544924=="
Message-ID: <mailman.56.1142502420.2491.mylist at list.server>
Date: Thu, 16 Mar 2006 10:47:00 +0100
Precedence: bulk
X-BeenThere: mylist at list.server
X-Mailman-Version: 2.1.7
List-Id: newsletters <mylist.list.server>
X-List-Administrivia: yes
To: user at domain
Sender: mylist-bounces+user=domain at list.server
Errors-To: mylist-bounces+user=domain at list.server
X-HUMPH-Peer-rDNS: localhost

--===============1898544924==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

I risultati dei comandi che erano nel tuo messaggio sono mostrati qui
sotto.  Allegato trovi il tuo messaggio originale.

- Risultati:
     Stringa di conferma non valida.  Nota che le stringhe di  
convalida =

scadono approssimativamente dopo 3 giorni dalla richiesta iniziale.
Se la tua richiesta =E8 scaduta, per favore ripeti la procedura da capo.

- Non elaborati:
     confirm 8a671672b88489848cd212b368d290cc343af848

- Finito.


--===============1898544924==
Content-Type: message/rfc822
MIME-Version: 1.0

Received: from smtp3.libero.it ([193.70.192.127])
	by tempesta.mydomain with esmtp (Exim 4.60)
	(envelope-from <user at domain>) id IW7SIA-0002DU-E3 for
	mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server;
	Thu, 16 Mar 2006 10:46:58 +0100
[...]
	Thu, 16 Mar 2006 10:46:49 +0100
Date: Thu, 16 Mar 2006 10:45:12 +0100
Message-Id: <IW7SFC$6E27427742E6C42C9FB6F56151FC9726 at libero.it>
Subject: =?iso-8859-1?b? 
UmU6yCByaWNoaWVzdGEgbGEgdHVhIGNvbmZlcm1hIHBlcg==?=
	=?iso-8859-1?b?IGlzY3JpdmVydGkgYWxsYSBsaXN0YSBlbGZvLW5ld3M=?=
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
From: "user\@domain\.it" <user at domain>
To: "mylist-confirm+8a671672b88489848cd212b368d290cc343af848"
	<mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server>
X-XaM3-API-Version: 4.3 (R1) (B3pl14)
X-SenderIP: 85.18.136.77
X-Scanned: with antispam and antivirus automated system at libero.it
X-HUMPH-Peer-rDNS: ns2.libero.it ns1.libero.it

confirm 8a671672b88489848cd212b368d290cc343af848



the list pending pick contains:

     '8a671672b88489848cd212b368d290cc343af848': (   'S',
                                                     <UserDesc  
user at domain (User Name) [password] [digest? no] [it]>),
     'evictions': {   '1fb8a40026d6ba70cd0b7673aee8b981cb8357fe':  
1142730263.5198989,
                      '3e60d959c6fcbb0283b99aeb8d989dbdcfc9add5':  
1142532050.440028,
                      '4b6064163c503671ab56742747995dc69b4e5340':  
1142515273.500232,
                      '4d00983d4870ded7dd7f71b4afa076d933cb20b4':  
1142606644.057848,
                      '4f596c21fc862542571bd0a27f69fb9e28cc4d37':  
1142515273.444937,
                      '69688a2fd5d9b58b9d742fd759414f5cc7488986':  
1142730265.8702731,
                      '73216e6fe18ef24607477491f1abc345cd7f670f':  
1142724911.066819,
                      '8339c1f4fb851dbdd954f697120d367e480637cd':  
1142764046.192688,
                      '84af391da0af8bfc54b16214082ebb0f2b7c758e':  
1142684865.5612831,
                      '8a671672b88489848cd212b368d290cc343af848':  
1142725085.0594411,
                      'fe7403de2e82c6834deb1bae05b403a1fc7fa03f':  
1142730263.8872991},


Note that the confirmation string is correct but that the  
confirmation string also appears in evictions.


Any ideas?

Thanks

Giuliano

From msapiro at value.net  Thu Mar 16 18:34:19 2006
From: msapiro at value.net (Mark Sapiro)
Date: Thu, 16 Mar 2006 09:34:19 -0800
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <50A21C7B-E519-4B1F-A84E-7E2E410B38D1@humph.com>
Message-ID: <PC17402006031609341901099ab53540@msapiro>

Giuliano Gavazzi wrote:

>To: "mylist-confirm+8a671672b88489848cd212b368d290cc343af848"
>	<mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server>


This is the problem. You have VERP_CONFIRMATIONS = Yes so the
confirmation is From: and the user's reply should be To:

mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server

but the user's MUA has replied To: as above.

VERP_CONFIRM_REGEXP doesn't expect this and parses the cookie as

8a671672b88489848cd212b368d290cc343af848"
<mylist-confirm+8a671672b88489848cd212b368d290cc343af848

which doesn't work. Then there's been an error, so the confirm command
in the body is not processed.

Solutions:

The user can use a different MUA

The user can manually edit the To: to remove the "real name"

You can change VERP_CONFIRM_REGEXP in mm_cfg.py to parse this one
without breaking normal ones. Possibly something like

VERP_CONFIRM_REGEXP = \
r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

will work

>Note that the confirmation string is correct but that the  
>confirmation string also appears in evictions.


It has a time still in the future, so this is normal.

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


From msapiro at value.net  Fri Mar 17 06:37:53 2006
From: msapiro at value.net (Mark Sapiro)
Date: Thu, 16 Mar 2006 21:37:53 -0800
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <441A43E4.60301@equinephotoart.com>
Message-ID: <PC17402006031621375303129f7d53cd@msapiro>

JC Dill wrote:
>
>IMHO, this is a bug.  Mailman should correctly parse email sent to:
>
>"mylist-confirm+8a671672b88489848cd212b368d290cc343af848"
><mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server>
>
>since that is a correctly formatted email address header per the example:
>
>To: "Mary Smith: Personal Account" <smith at home.example>
>
>in RFC 2822:
>
><http://www.faqs.org/rfcs/rfc2822.html>


I agree that it's a bug, but I think the primary bug is in an MUA that
is generating a reply to mail

From: smith at home.example

and addresses it

To: "smith at home.example" <smith at home.example>

However, I have no objection to Mailman "working around" this MUA bug
:-) by changing

VERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

in Defaults.py.in

I ask though, does anyone have a better suggestion for a replacement
than

VERP_CONFIRM_REGEXP = \
 r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

or is that OK?

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


From lists05 at equinephotoart.com  Fri Mar 17 06:06:44 2006
From: lists05 at equinephotoart.com (JC Dill)
Date: Thu, 16 Mar 2006 21:06:44 -0800
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <PC17402006031609341901099ab53540@msapiro>
References: <PC17402006031609341901099ab53540@msapiro>
Message-ID: <441A43E4.60301@equinephotoart.com>

Mark Sapiro wrote:
> Giuliano Gavazzi wrote:
> 
>> To: "mylist-confirm+8a671672b88489848cd212b368d290cc343af848"
>> 	<mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server>
> 
> This is the problem. You have VERP_CONFIRMATIONS = Yes so the
> confirmation is From: and the user's reply should be To:
> 
> mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server
> 
> but the user's MUA has replied To: as above.
> 
> VERP_CONFIRM_REGEXP doesn't expect this and parses the cookie as
> 
> 8a671672b88489848cd212b368d290cc343af848"
> <mylist-confirm+8a671672b88489848cd212b368d290cc343af848
> 
> which doesn't work. Then there's been an error, so the confirm command
> in the body is not processed.
> 
> Solutions:
> 
> The user can use a different MUA

That's a work-around rather than a solution.  This problem needlessly 
makes it harder for both list owners and subscribers to use Mailman 
hosted lists.

> The user can manually edit the To: to remove the "real name"

IMHO, this is a bug.  Mailman should correctly parse email sent to:

"mylist-confirm+8a671672b88489848cd212b368d290cc343af848"
<mylist-confirm+8a671672b88489848cd212b368d290cc343af848 at list.server>

since that is a correctly formatted email address header per the example:

To: "Mary Smith: Personal Account" <smith at home.example>

in RFC 2822:

<http://www.faqs.org/rfcs/rfc2822.html>

jc




From dev+lists at humph.com  Fri Mar 17 11:18:14 2006
From: dev+lists at humph.com (g)
Date: Fri, 17 Mar 2006 11:18:14 +0100
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <PC17402006031621375303129f7d53cd@msapiro>
References: <PC17402006031621375303129f7d53cd@msapiro>
Message-ID: <1DDFB755-CA92-4C02-9409-326E8251D8E2@humph.com>


On 17 Mar 2006, at 06:37, Mark Sapiro wrote:

> I agree that it's a bug, but I think the primary bug is in an MUA that
> is generating a reply to mail
>
> From: smith at home.example
>
> and addresses it
>
> To: "smith at home.example" <smith at home.example>
>

Not exactly, it does only add the local_part and without quotes.
I have tested your regexp for a "regular" reply and it works. Of  
course it does not work with that buggy format (wherever one consider  
the bug to be...) and the fixed version is below.

> However, I have no objection to Mailman "working around" this MUA bug
> :-) by changing
>
> VERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>
> in Defaults.py.in
>
> I ask though, does anyone have a better suggestion for a replacement
> than
>
> VERP_CONFIRM_REGEXP = \
>  r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>
> or is that OK?

it is too specific as I said. This works instead:

VERP_CONFIRM_REGEXP = r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+) 
@.*$'

This was checked against many formats and  probably the simpler and  
less reduntant:

VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

would work too. Or even:

VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

as I do not see the point of checking for the line beginning.

Giuliano

From dev+lists at humph.com  Fri Mar 17 11:29:04 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Fri, 17 Mar 2006 11:29:04 +0100
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <1DDFB755-CA92-4C02-9409-326E8251D8E2@humph.com>
References: <PC17402006031621375303129f7d53cd@msapiro>
	<1DDFB755-CA92-4C02-9409-326E8251D8E2@humph.com>
Message-ID: <2C4F2910-6245-4381-B31F-843ECAB047B4@humph.com>


On 17 Mar 2006, at 11:18, g wrote:
> would work too. Or even:
>
> VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>
> as I do not see the point of checking for the line beginning.

well, if that is correct, then one can shorten it to:


VERP_CONFIRM_REGEXP = r'?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

(but what is the first "?" for?).

By following the old advice "if it ain't broken don't fix it", I will  
not test these alternatives..

Giuliano

From msapiro at value.net  Fri Mar 17 16:33:42 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 17 Mar 2006 07:33:42 -0800
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <1DDFB755-CA92-4C02-9409-326E8251D8E2@humph.com>
Message-ID: <PC17402006031707334207655a923967@msapiro>

Giuliano wrote:
>
>On 17 Mar 2006, at 06:37, Mark Sapiro wrote:
>
>> I agree that it's a bug, but I think the primary bug is in an MUA that
>> is generating a reply to mail
>>
>> From: smith at home.example
>>
>> and addresses it
>>
>> To: "smith at home.example" <smith at home.example>
>>
>
>Not exactly, it does only add the local_part and without quotes.


But does it ever do it in the case we are concerned with? Namely where
the message is

From: list-confirm+string_of_hex_digits at example.com.

Note that the original regexp works as long as the MUA added stuff
doesn't contain '+'.


>I have tested your regexp for a "regular" reply and it works. Of  
>course it does not work with that buggy format (wherever one consider  
>the bug to be...) and the fixed version is below.


I'm not sure what "your regexp" means here. Is it the one that is
currently in Defaults.py(.in), or my suggested change?


>> However, I have no objection to Mailman "working around" this MUA bug
>> :-) by changing
>>
>> VERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>>
>> in Defaults.py.in
>>
>> I ask though, does anyone have a better suggestion for a replacement
>> than
>>
>> VERP_CONFIRM_REGEXP = \
>>  r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>>
>> or is that OK?
>
>it is too specific as I said. This works instead:


Yes, it requires quotes, but as I ask above. Does any MUA that adds
this not put quotes around it when it contains '+'?


>VERP_CONFIRM_REGEXP = r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+) 
>@.*$'
>
>This was checked against many formats and  probably the simpler and  
>less reduntant:
>
>VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>
>would work too. Or even:
>
>VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>
>as I do not see the point of checking for the line beginning.


Well, I don't think the 'addr' field is actually used, but I think
these suggestions eat up all but the last character of it. How about

VERP_CONFIRM_REGEXP = r'(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

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


From dev+lists at humph.com  Fri Mar 17 17:47:37 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Fri, 17 Mar 2006 17:47:37 +0100
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <PC17402006031707334207655a923967@msapiro>
References: <PC17402006031707334207655a923967@msapiro>
Message-ID: <86E1444F-0904-464C-AB7E-3508522738CA@humph.com>


On 17 Mar 2006, at 16:33, Mark Sapiro wrote:

> Giuliano wrote:
>>
>> On 17 Mar 2006, at 06:37, Mark Sapiro wrote:
>>
>>> I agree that it's a bug, but I think the primary bug is in an MUA  
>>> that
>>> is generating a reply to mail
>>>
>>> From: smith at home.example
>>>
>>> and addresses it
>>>
>>> To: "smith at home.example" <smith at home.example>
>>>
>>
>> Not exactly, it does only add the local_part and without quotes.
>
>
> But does it ever do it in the case we are concerned with? Namely where
> the message is
>
> From: list-confirm+string_of_hex_digits at example.com.
>
> Note that the original regexp works as long as the MUA added stuff
> doesn't contain '+'.
>

in the case in question, if I understood you well, the MUA (it might  
be a webmail interface)
adds list-confirm+string_of_hex_digit so it does add the + and no  
quotes.

>
>> I have tested your regexp for a "regular" reply and it works. Of
>> course it does not work with that buggy format (wherever one consider
>> the bug to be...) and the fixed version is below.
>
>
> I'm not sure what "your regexp" means here. Is it the one that is
> currently in Defaults.py(.in), or my suggested change?
>
>


your suggested change.


>>> However, I have no objection to Mailman "working around" this MUA  
>>> bug
>>> :-) by changing
>>>
>>> VERP_CONFIRM_REGEXP =r'^(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>>>
>>> in Defaults.py.in
>>>
>>> I ask though, does anyone have a better suggestion for a replacement
>>> than
>>>
>>> VERP_CONFIRM_REGEXP = \
>>>  r'^(\s*"[^"]*")?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>>>
>>> or is that OK?
>>
>> it is too specific as I said. This works instead:
>
>
> Yes, it requires quotes, but as I ask above. Does any MUA that adds
> this not put quotes around it when it contains '+'?


No, and I do not think it is required is it?

>
>
>> VERP_CONFIRM_REGEXP = r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)
>> @.*$'
>>
>> This was checked against many formats and  probably the simpler and
>> less reduntant:
>>
>> VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+) 
>> @.*$'
>>
>> would work too. Or even:
>>
>> VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
>>
>> as I do not see the point of checking for the line beginning.
>
>
> Well, I don't think the 'addr' field is actually used, but I think
> these suggestions eat up all but the last character of it. How about
>
> VERP_CONFIRM_REGEXP = r'(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'


don't know. I could test it (when I know there are no pending  
subscriptions...). I am not sure I understood what ?P means here. Is  
it a macro for "print here the value of what follows". So ?P<addr>  
prints the confirmation address minus cookie?

Giuliano


--
H U M P H
    || |||
  software

Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X
http://www.humph.com/




From msapiro at value.net  Fri Mar 17 17:56:01 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 17 Mar 2006 08:56:01 -0800
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <PC17402006031707334207655a923967@msapiro>
Message-ID: <PC17402006031708560100626223d11f@msapiro>

Mark Sapiro wrote:

>Giuliano wrote:
>>
>>On 17 Mar 2006, at 06:37, Mark Sapiro wrote:
>>
>>> I agree that it's a bug, but I think the primary bug is in an MUA that
>>> is generating a reply to mail
>>>
>>> From: smith at home.example
>>>
>>> and addresses it
>>>
>>> To: "smith at home.example" <smith at home.example>
>>>
>>
>>Not exactly, it does only add the local_part and without quotes.
>
>
>But does it ever do it in the case we are concerned with? Namely where
>the message is
>
>From: list-confirm+string_of_hex_digits at example.com.
>
>Note that the original regexp works as long as the MUA added stuff
>doesn't contain '+'.


To clarify, yes I see in the OP that the added 'real name' only
contains the local part, but it was quoted in the OP, so does or does
not the MUA put quotes around it?


In any case, I've tested

VERP_CONFIRM_REGEXP = r'(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

against various forms, with and without quotes, and I think it's good,
but I'd still like more feedback.


I'v also tested all these:

VERP_CONFIRM_REGEXP = \
 r'^(\s*.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
VERP_CONFIRM_REGEXP = r'^(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
VERP_CONFIRM_REGEXP = r'(.*)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'
VERP_CONFIRM_REGEXP = r'?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$'

and only the first works (for cookie, but not addr). I'm not sure why
the second and third don't work, but they and the fourth all give

    raise error, v # invalid expression
sre_constants.error: nothing to repeat

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


From msapiro at value.net  Fri Mar 17 18:02:02 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 17 Mar 2006 09:02:02 -0800
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <86E1444F-0904-464C-AB7E-3508522738CA@humph.com>
Message-ID: <PC174020060317090202093708efaceb@msapiro>

Giuliano Gavazzi wrote:
>
>in the case in question, if I understood you well, the MUA (it might  
>be a webmail interface)
>adds list-confirm+string_of_hex_digit so it does add the + and no  
>quotes.


So where did the qoutes come from in the message you included in your
original post?

(Moot anyway, since I have moved away from the regexp that matches
quotes).

>I am not sure I understood what ?P means here. Is  
>it a macro for "print here the value of what follows". So ?P<addr>  
>prints the confirmation address minus cookie?


It assigns the value of what matched the expression in parentheses to
the named variable. See <http://docs.python.org/lib/re-syntax.html>.

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


From fil at rezo.net  Fri Mar 17 17:54:35 2006
From: fil at rezo.net (Fil)
Date: Fri, 17 Mar 2006 17:54:35 +0100
Subject: [Mailman-Developers] MysqlMemberships.py
In-Reply-To: <20051123113846.GB13624@rezo.net>
References: <PC1740200511190949200656389eaac4@msapiro>
	<PC17402005112011540207967151eb5e@msapiro>
	<20051120200928.GH32641@rezo.net> <20051120201605.GI32641@rezo.net>
	<20051121105340.GG4355@rezo.net> <20051123113846.GB13624@rezo.net>
Message-ID: <20060317165419.GL5644@rezo.net>

Hello,

I have updated the MysqlMembership extension 
http://trac.rezo.net/trac/rezo/browser/Mailman/MySQLMemberAdaptor/MysqlMemberships.py

I would appreciate it if someone could verify that this patch indeed
potentially fixes the "TypeError" bug we used to get on some SetBounceInfo:
http://trac.rezo.net/trac/rezo/changeset/72
(it was, I think, a question of priority between the + and % operators)

As usual see the readme file @
http://trac.rezo.net/trac/rezo/browser/Mailman/


-- Fil


From dev+lists at humph.com  Fri Mar 17 22:35:08 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Fri, 17 Mar 2006 22:35:08 +0100
Subject: [Mailman-Developers] Bug? Refused subscription confirmation
In-Reply-To: <PC174020060317090202093708efaceb@msapiro>
References: <PC174020060317090202093708efaceb@msapiro>
Message-ID: <3EF3268E-7818-4D2C-B93E-2498A53BAFCB@humph.com>


On 17 Mar 2006, at 18:02, Mark Sapiro wrote:

> Giuliano Gavazzi wrote:
>>
>> in the case in question, if I understood you well, the MUA (it might
>> be a webmail interface)
>> adds list-confirm+string_of_hex_digit so it does add the + and no
>> quotes.
>
>
> So where did the qoutes come from in the message you included in your
> original post?
>

mmm, I cannot understand where the quotes disappeared in my mind...  
Yes, you are correct, there are quotes, but for some reason I decided  
that there were none...


> (Moot anyway, since I have moved away from the regexp that matches
> quotes).
>
>> I am not sure I understood what ?P means here. Is
>> it a macro for "print here the value of what follows". So ?P<addr>
>> prints the confirmation address minus cookie?
>
>
> It assigns the value of what matched the expression in parentheses to
> the named variable. See <http://docs.python.org/lib/re-syntax.html>.

ah, so my expression only worked because addr is not used, while  
cookie, which is used, was correctly assigned. Whatever. I will have  
a look at that doc to understand your RE fully, thanks.

The only observation is that these errors should be probably logged,  
if not forwarded to the list admin, or they might pass undetected  
without the collaboration of attentive users.

Thanks again.

Giuliano

From barry at python.org  Sat Mar 18 19:19:33 2006
From: barry at python.org (Barry Warsaw)
Date: Sat, 18 Mar 2006 13:19:33 -0500
Subject: [Mailman-Developers] [Mailman-checkins] mailman NEWS,2.64,2.65
In-Reply-To: <20060318181558.179091E4016@bag.python.org>
References: <20060318181558.179091E4016@bag.python.org>
Message-ID: <1142705973.10625.7.camel@resist.wooz.org>

On Sat, 2006-03-18 at 10:15 -0800, msapiro at users.sourceforge.net wrote:
> Update of /cvsroot/mailman/mailman
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30399
> 
> Modified Files:
> 	NEWS 
> Log Message:
> Added a new list attribute 'subscribe_auto_approval' which is a list of email addresses
> and regular expressions matching email addresses whose subscriptions are exempt
> from admin approval. RFE 403066.

Should we be a little cautious about putting new features into 2.1?  I
think that once 2.1.8 goes out and we switch to svn, it'll be a lot
easier to start working on 2.2, where the bulk of new features like this
can go.

-Barry

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

From msapiro at value.net  Sat Mar 18 19:27:39 2006
From: msapiro at value.net (Mark Sapiro)
Date: Sat, 18 Mar 2006 10:27:39 -0800
Subject: [Mailman-Developers] [Mailman-checkins] mailman NEWS,2.64,2.65
In-Reply-To: <1142705973.10625.7.camel@resist.wooz.org>
Message-ID: <PC1740200603181027390187b653ff62@msapiro>

Barry Warsaw wrote:
>
>On Sat, 2006-03-18 at 10:15 -0800, msapiro at users.sourceforge.net wrote:
>> Update of /cvsroot/mailman/mailman
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30399
>>
>> Modified Files:
>> 	NEWS
>> Log Message:
>> Added a new list attribute 'subscribe_auto_approval' which is a list of email addresses
>> and regular expressions matching email addresses whose subscriptions are exempt
>> from admin approval. RFE 403066.
>
>Should we be a little cautious about putting new features into 2.1?  I
>think that once 2.1.8 goes out and we switch to svn, it'll be a lot
>easier to start working on 2.2, where the bulk of new features like this
>can go.

Yes, I absolutely agree. That's why this patch/feature was only applied
to the trunk and not to the Release_2_1-maint branch.

If you're saying should we hold off completely on putting new features
in CVS and wait for svn, I can do that too. Please clarify.

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


From barry at python.org  Sat Mar 18 19:44:53 2006
From: barry at python.org (Barry Warsaw)
Date: Sat, 18 Mar 2006 13:44:53 -0500
Subject: [Mailman-Developers] [Mailman-checkins] mailman NEWS,2.64,2.65
In-Reply-To: <PC1740200603181027390187b653ff62@msapiro>
References: <PC1740200603181027390187b653ff62@msapiro>
Message-ID: <1142707493.10598.10.camel@resist.wooz.org>

On Sat, 2006-03-18 at 10:27 -0800, Mark Sapiro wrote:

> Yes, I absolutely agree. That's why this patch/feature was only applied
> to the trunk and not to the Release_2_1-maint branch.
> 
> If you're saying should we hold off completely on putting new features
> in CVS and wait for svn, I can do that too. Please clarify.

Me R stupid.  No, you did absolutely the right thing!  Thanks.  No need
to hold off on trunk commits until the svn switch.

-Barry

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

From tkikuchi at is.kochi-u.ac.jp  Thu Mar 23 14:01:05 2006
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Thu, 23 Mar 2006 22:01:05 +0900
Subject: [Mailman-Developers] Released: Mailman 2.1.8b1
Message-ID: <44229C11.10308@is.kochi-u.ac.jp>

Hi Mailman-Users, -Developers and -i18ners,

Mailman 2.1.8b1 was released for beta test.  Talks are going around on 
the start of 2.2 after the release of 2.1.8 the final of 2.1-maint 
branch.  I really want to call this final than beta but we should take 
careful steps.

Please download it from Sourceforge file area:
   http://sourceforge.net/project/showfiles.php?group_id=103

Cheers,

Tokio
---------------------------------------------------
Here is a history of user visible changes to Mailman.

2.1.8b1 (23-Mar-2006)

   Bug fixes and other patches

     - Bouncers support added: 'unknown user', Microsoft SMTPSVC, 
Prodigy.net
       and several others.

     - Updated email library to 2.5.7 which will encode payload into 
qp/base64
       upon setting.  This enabled backing out the scrubber related patches
       including 'X-Mailman-Scrubbed' header in 2.1.7.

     - Fix SpamDetect.py potential hold/reject loop problem.

     - A warning message from email package to the stderr can cause error
       in Logging because stderr may be detached from the process during
       the qrunner run.  We chose not to output errors to stderr but to
       the logs/error if the process is running under mailmanctl subprocess.

     - DKIM header cleansing was separated from Cleanse.py and added to
       -owner messages too.

     - Fixes: Lose Topics when go directly to topics URL (1194419).
       UnicodeError running bin/arch (1395683).  edithtml.py missing import
       (1400128).  Bad escape in cleanarch.  Wrong timezone in list archive
       index pages (1433673).  bin/arch fails with TypeError (1430236).
       Subscription fails with some Language combinations (1435722).
       Postfix delayed notification not recognized (863989).  2.1.7 (VERP)
       mistakes delay notice for bounce (1421285).  show_qfiles: 'str'
       object has no attribute 'as_string' (1444447).  Utils.get_domain()
       wrong if VIRTUAL_HOST_OVERVIEW off (1275856).

   Miscellaneous

     - Brad Knowles' mailman daily status report script updated to 0.0.16.

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


From msapiro at value.net  Tue Mar 28 01:48:41 2006
From: msapiro at value.net (Mark Sapiro)
Date: Mon, 27 Mar 2006 15:48:41 -0800
Subject: [Mailman-Developers] Advice wanted on option to not include
	original	post in notices
Message-ID: <442879D9.7040203@value.net>

Last week, I posted the following to the mailman-users list. The silence 
was deafening as they say (I actually got one good response, but only 
one). So, does anyone here want to offer an opinion?

There have been a couple of threads on the (mailman-users) list in the 
last week or two regarding not sending the content of the original post 
in reject notices to the (alleged) poster and in owner notifications.

I'm considering implementing these options for Mailman 2.2, but I want
some feed back to be sure I'm doing what people want and to be sure
I'm not overlooking things.

Here are my areas of concern.

First, should these be site wide mm_cfg.py options or should they be
per-list options with a default from mm_cfg.py? In either case, the
Defaults.py setting would match current behavior.

I see a few different cases of notices which include the original message.

Bounce processing sends unrecognized bounces to the owner if
bounce_unrecognized_goes_to_list_owner is on. Since these notices are
meaningless without the actual message, I think there is no need for
an additional setting here. Also, if bounce_notify_owner_on_disable is
on, the owner gets a copy of the triggering bounce, but this should
always be a legitimate DSN in response to a message from the list, so
I don't see a need to provide an option to exclude the DSN from the
notification.

The privacy options reject_these_nonmembers, generic_nonmember_action
and header_filter_rules can automatically reject a post. Currently,
the original post is included. I foresee a single option (should it be
site wide or per list) to control putting the original in the reject
notice.

The moderator can reject a held post. Currently the original post is
not included. I don't see a need to change this.
	
If admin_immed_notify is on, notices of individual held posts are sent
to the owners/moderators and these include the original post. I foresee 
an option separate from the reject option (and should this be site wide
or per list) to put only summary information (From:, Subject: hold
reason) in this notice.

Note that this last can be 'almost' accomplished currently by turning
admin_immed_notify off and increasing the frequency of the
cron/checkdbs job from daily to maybe hourly, although this would
affect all lists.

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

From dev+lists at humph.com  Tue Mar 28 03:03:36 2006
From: dev+lists at humph.com (Giuliano Gavazzi)
Date: Tue, 28 Mar 2006 03:03:36 +0200
Subject: [Mailman-Developers] Advice wanted on option to not include
	original	post in notices
In-Reply-To: <442879D9.7040203@value.net>
References: <442879D9.7040203@value.net>
Message-ID: <536689AA-5C2F-4E9C-97CA-B1E427F5E812@humph.com>


On 28 Mar 2006, at 01:48, Mark Sapiro wrote:

> The privacy options reject_these_nonmembers, generic_nonmember_action
> and header_filter_rules can automatically reject a post. Currently,
> the original post is included. I foresee a single option (should it be
> site wide or per list) to control putting the original in the reject
> notice.

per list seems better. I personally don't like mailman being allowed  
at all to bounce to the alleged sender, but this is another matter..

Giuliano



From jwblist at loricamail.com  Tue Mar 28 04:14:27 2006
From: jwblist at loricamail.com (John W. Baxter)
Date: Mon, 27 Mar 2006 18:14:27 -0800
Subject: [Mailman-Developers] Advice wanted on option to not include
 original post in notices
In-Reply-To: <442879D9.7040203@value.net>
Message-ID: <C04DDC03.BA25%jwblist@loricamail.com>

On 3/27/06 3:48 PM, "Mark Sapiro" <msapiro at value.net> wrote:

> First, should these be site wide mm_cfg.py options or should they be
> per-list options with a default from mm_cfg.py? In either case, the
> Defaults.py setting would match current behavior.

> [Other good thoughts deleted, as Mark knows what he said]

Hi, Mark

It is the site's reputation which (increasingly with more aggressive
anti-spam in the world) suffers from bounces containing the content.  So
messages heading out of the site to the world should be controlled by the
site as to whether the content is included.

It should be up to the list administrator what (non-bounce) message bodies
reach the administrator/moderator in email.  (Personally, I don't much care
as long as the whole thing remains visible in the web interface.  I get
ideas about servers to block.)

I agree that bounces without content are pretty useless...so they should go
to list administrators.

Sorry I didn't answer last week...I was busy.

  --John



From jpl at ilk.org  Fri Mar 31 18:15:42 2006
From: jpl at ilk.org (Joel P. Lord)
Date: Fri, 31 Mar 2006 11:15:42 -0500 (EST)
Subject: [Mailman-Developers] Bug in 2.1.7 edithtml.py
Message-ID: <Pine.GSO.4.64.0603311111460.1786@iago.ilk.org>

    I've got a listadmin who likes to customize things, and she ran in to a 
bug in 2.1.7 on line 160 of edithtml.py.  Here's the traceback from the 
logs:

admin(23994): [----- Mailman Version: 2.1.7 -----]
admin(23994): [----- Traceback ------]
admin(23994): Traceback (most recent call last):
admin(23994):   File "/mailman/mailman-sflovers/scripts/driver", line 101, 
in ru
n_main
admin(23994):     main()
admin(23994):   File "/mailman/mailman-sflovers/Mailman/Cgi/edithtml.py", 
line 1
25, in main
admin(23994):     ChangeHTML(mlist, cgidata, template_name, doc)
admin(23994):   File "/mailman/mailman-sflovers/Mailman/Cgi/edithtml.py", 
line 1
60, in ChangeHTML
admin(23994):     code = re.sub(r'<([/]?script.*?)>', r'&lt;\1&gt;', code)
admin(23994): NameError: global name 're' is not defined
admin(23994): [----- Python Information -----]
admin(23994): sys.version     =   2.4.2 (#2, Mar 15 2006, 15:40:10)
[GCC 3.4.2]
admin(23994): sys.executable  =   /usr/local/bin/python
admin(23994): sys.prefix      =   /usr/local
admin(23994): sys.exec_prefix =   /usr/local
admin(23994): sys.path        =   /usr/local
admin(23994): sys.platform    =   sunos5

    I can include the rest if necessary, but I'd rather not toss around the 
contents of the cookies and such if it isn't.

    Seems pretty clearcut to me, I just don't know what the global there 
*should* be.

---
Joel Lord
Sound Designer, Nine, Schenectady Light Opera
Chair, Albacon 2006
Web Master, Alpha Psi Omega Grand Cast
etc... etc... etc...

From msapiro at value.net  Fri Mar 31 19:03:54 2006
From: msapiro at value.net (Mark Sapiro)
Date: Fri, 31 Mar 2006 09:03:54 -0800
Subject: [Mailman-Developers] Bug in 2.1.7 edithtml.py
In-Reply-To: <Pine.GSO.4.64.0603311111460.1786@iago.ilk.org>
Message-ID: <PC1740200603310903540859989b1491@msapiro>

Joel P. Lord wrote:

>    I've got a listadmin who likes to customize things, and she ran in to a 
>bug in 2.1.7 on line 160 of edithtml.py.  Here's the traceback from the 
>logs:


This is fixed by the Mailman 2.1.7 multiple patch at
<https://sourceforge.net/tracker/index.php?func=detail&aid=1405790&group_id=103&atid=300103>.

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


From Rafal.Krzewski at caltha.pl  Wed Mar 29 16:25:58 2006
From: Rafal.Krzewski at caltha.pl (Rafal Krzewski)
Date: Wed, 29 Mar 2006 16:25:58 +0200
Subject: [Mailman-Developers] XMLRPC interface
Message-ID: <442A98F6.9070308@caltha.pl>

Hello all,

I'm new to the list, so I'll introduce myself briefly. I'm located in 
Warsaw, Poland. I have been using free software for more that 10 years, 
I have been a member of several OS projects including Jakarta Turbine 
and MaxQ, occasional contributor in several others. I have also 
established a few OS projects in the course of my company operations. 
(see http://objectledge.org/related-projects.html). I work full time as 
Java/J2EE developer full time for 5+ years now. I don't know much Python 
yet but I'm a quick learner ;-). I happen to also be the sysadmin in my 
company and I have experience working with Mailman as list & site 
administrator.

On to the business :-)

We (http://caltha.pl) are currently developing a Java-powered WWW 
application for group collaboration (http://cyklotron2.cyklotron.org). 
The application includes (among others) discussion forums. We are 
looking for possibilities of enhancing the forums is such way that users 
could interact with them using e-mail in addition to the web-based 
interface. Messages posted to the forum using e-mail should be displayed 
along those entered through the web interface, with appropriate 
threading, and users should be able to receive all messages in their 
mailbox possibly ignoring the web interface completely. At the same time 
we would like to perform all administrative activities through the web 
interface provided by our application including moderation of 
subscription requests, and moderation of individual messages.

We are fully aware of the magnitude of complexity of the mailing list 
software, so it was natural to look for software that is already 
available. Mailman was the obvious choice because of it's maturity, 
features and the fact that we have experience in using it.

As we looked for ways of integrating Mailman with our application 
written in Java, we thought about running first thought Mailman code 
under jython, when this turned out to be impossible, we thought about 
running scripts from $MAILMAN_HOME/bin as external processes spawned by 
Java VM + writing custom glue scripts in Python invoking parts of 
Mailman  codebase. This solution has the obvious disadvantage of 
starting a python interpreter and loading Mailman code to perform each 
operation and terminating it right afterwards. Of course startup time of 
Python interpreter is nothing comparing to Java VM, still it is a waste 
of system resources. The next idea was implementing some sort of daemon 
in Python that would stay in memory with all the necessary code loaded 
and communicated with the Java application using, say XMLRPC. And bingo! 
We discovered that this is already being worked on.

We are very much interested joining the effort in developing 
mailman-xmlrpc. At this point we'll be happy to serve as early adopters 
& testers (in fact we have already built the patched codebase, launched 
it and connected to it using an ad hoc Java based client). We also hope 
to start providing patches as soon as our knowledge of Python and 
Mailman codebase increases.

My question at this point is whether this is the appropriate list to 
discuss mailman-xmlrpc specific topics, or should these be taken to 
somewhere else perhaps a dedicated list should be created at 
http://savannah.nongnu.org/mail/?group=mailman-xmlrpc ?

Rafa?