From davek@mail.commercedata.com  Fri Jun  1 05:46:06 2001
From: davek@mail.commercedata.com (Dave Klingler)
Date: Thu, 31 May 2001 22:46:06 -0600 (MDT)
Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or
In-Reply-To: <15125.56302.501876.382172@anthem.wooz.org> from "Barry A. Warsaw" at May 31, 2001 01:51:42 AM
Message-ID: <200106010446.WAA07646@mail.commercedata.com>

> I've completely rewritten the user options page (more on this later,
> tomorrow is checkin day :), and have taken the opportunity to do
> exactly this.  I may have missed some, but the idea is that the colors
> are now overridable in mm_cfg.py.

Wonderful!
  
> Which makes me think more about having a better support for virtual
> domains by having something akin to a different mm_cfg.py per domain.

This would be very cool.  My favorite implementation of virtual domains
is Apache's, and it strikes me that adding the <virtualhost domain> 
directive might be an easy and intuitive way of accomplishing virtual domain 
directives now that you have overridable colors in mm_cfg.py.

Just a thought.  If you did key admin messages in mm_cfg.py you could put
them here this way.

Thanks for all the improvements!  Some day if I could consolidate all my
mailman virtual implementations, all in their separate chrooted environments,
back into one virtual mailman environment, I would die happy and will Barry 
my Star Trek hologram trading cards AND my wool Canadian Army cap.

Dave Klingler


> That's rumbling around in the back of my head.
> 
>     CVR> The other key one for me are some of the admin messages
>     CVR> (Mailman/Handlers/Hold.py). I've modified some of the
>     CVR> messages for various reasons, and it'd be nice if I could
>     CVR> simply override their definitions in the mm_cfg.py file
> 
> I'll have to think about this.  One hackish idea (untested) is to try
> to import Mailman.Hold from mm_cfg.py, and then set the class's
> __doc__ attribute with the message you want.  The fact that
> Mailman/Hold.py imports mm_cfg.py means you might have to play games
> with the importer to get this to work.  Not a great solution, but it
> might help localize your customizations for now.
> 
>     CVR> And the third place I've made custom changes are in some of
>     CVR> the list templates (most radically templates/listinfo.html)
>     CVR> -- but that's why they're template; you simply keep a copy
>     CVR> somewhere and watch out for additions to the updated copy...
> 
> Exactly, and the new template lookup scheme should be much more
> friendly to this approach.
> 
>     CVR> It took me about three days and a couple of exchanges with
>     CVR> the author of mod_layout to get it going the way I wanted
>     CVR> (the documentation is still being fleshed out), but it's a
>     CVR> nice improvement to the old way of doing things -- and since
>     CVR> I know others build custom skins around their installations,
>     CVR> I'd thought I'd pass this one along.
> 
> Yes, thanks!
> 
> -Barry
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> 



From chuqui@plaidworks.com  Fri Jun  1 06:20:01 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 31 May 2001 22:20:01 -0700
Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or
In-Reply-To: <200106010446.WAA07646@mail.commercedata.com>
Message-ID: <200106010518.f515I8c03498@lists.apple.com>

On Thursday, May 31, 2001, at 09:46 PM, Dave Klingler wrote:

> This would be very cool.  My favorite implementation of virtual domains
> is Apache's, and it strikes me that adding the <virtualhost domain>
> directive might be an easy and intuitive way of accomplishing virtual 
> domain
> directives now that you have overridable colors in mm_cfg.py.

The downside is that you have a single point of administration. In an 
ISP environment, it'd be nice to export that administration to the owner 
of the domain, so you don't have a support guy going crazy with "can you 
make this change?" requests.

But you could deal with that by extending it to allow included files>

<virtualhost domain>
<include /page/to/file>
</virtualhost>

so you have the option of handing it off. But that gets you into issues 
of whether those users can screw things up for everyone else with 
typoes, etc. It'd be nice if an included file has a typo that it only 
destroy the current virthost...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Always look away from the obvious answers, because if you don't find
a better one, you can always go back to them on short notice.




From ricardo@rixhq.nu  Fri Jun  1 07:12:36 2001
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Fri, 1 Jun 2001 08:12:36 +0200
Subject: [Mailman-Developers] subscriber profiler patch for mailman-2.0.5
In-Reply-To: <Pine.LNX.4.21.0105301930560.30384-100000@marakani.srikant.org>; from sh@srikant.org on Wed, May 30, 2001 at 07:56:40PM +0800
References: <Pine.LNX.4.21.0105301930560.30384-100000@marakani.srikant.org>
Message-ID: <20010601081236.B4058@rix.rixhq.nu>

Hi,

On Wed, May 30, 2001 at 07:56:40PM +0800, Swee Heng wrote:
> i've written a patch to mailman-2.0.5 that lets it handle subscribers'
> profiles. (is this the "member profiles" feature on the wishlist?)
> this is my first serious attempt at python. so please be warned. :)
> feel free to comment.

looks great to me... maybe this would be a good solution for this much
requested feature for this version of mailman untill we get the database
stuff in mailman 3.0... maybe some of the mailman developers can comment on
this? I can't comment that much on the contents of the patch though it seems
not to have a huge impact on the rest of the code base as far as I can
tell...

my comments:
1) the subscribers list on the right could be usefull but if you have a list
with 10k subscribers maybe that's not such a great idea :)
2) am I correct to assume that you can use the MM tags in the templates to
'dynamically' invent the profile field names used? 

Regards,

Ricardo



From Swee Heng <sh@srikant.org>  Fri Jun  1 08:07:00 2001
From: Swee Heng <sh@srikant.org> (Swee Heng)
Date: Fri, 1 Jun 2001 15:07:00 +0800 (SGT)
Subject: [Mailman-Developers] subscriber profiler patch for mailman-2.0.5
In-Reply-To: <20010601081236.B4058@rix.rixhq.nu>
Message-ID: <Pine.LNX.4.21.0106011452340.24819-100000@marakani.srikant.org>

| looks great to me... maybe this would be a good solution for this much
thank you. that's very encouraging. :)

| this? I can't comment that much on the contents of the patch though it seems
| not to have a huge impact on the rest of the code base as far as I can
| tell...
i've tried to minimize the impact to the original code. the only original
files modified are src/Makefile (i added " profile") and edithtml.py (i
extended the list of edittable pages).

| 1) the subscribers list on the right could be usefull but if you have a list
| with 10k subscribers maybe that's not such a great idea :)
indeed. :) actually i simply copied the idea from roster.py. each member
adds about 0.1kb. so 1000 members gives a file size of about 100kb. 10k
members gives a file size of 1Mb. ouch! :)

| 2) am I correct to assume that you can use the MM tags in the templates to
| 'dynamically' invent the profile field names used? 
yes. <MM-P--tags> are used by profile.py internally while <MM-P-tags> are
for the profile field names. the "database" entry for joe@random.org is a
pickle of the dictionary : { '<mm-p-realname>' : 'Joe Random', ... }

regards,
sweeheng



From mmd@laubster.org  Fri Jun  1 16:29:42 2001
From: mmd@laubster.org (J.D. Laub)
Date: Fri, 01 Jun 2001 09:29:42 -0600
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
Message-ID: <3B17B4E6.4871098F@laubster.org>

Please CC me on replies as I'm not a mailman-developer subscriber...

In my inbox this morning I found several monthly reminders for various
lists to which I'm subscribed.  I'm responsible enough to save off a
list's "Welcome" message, and I need no monthly reminder.  Why does
Mailman penalize me with setting up & maintaining filter rules to
clobber the unnecessary reminders?  Is adding a user level configuration
of this option in the works?  If not, here's a request for one.


From barry@digicool.com  Fri Jun  1 16:54:15 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 11:54:15 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
Message-ID: <15127.47783.269611.179914@anthem.wooz.org>

>>>>> "JDL" == J D Laub <mmd@laubster.org> writes:

    JDL> In my inbox this morning I found several monthly reminders
    JDL> for various lists to which I'm subscribed.  I'm responsible
    JDL> enough to save off a list's "Welcome" message, and I need no
    JDL> monthly reminder.  Why does Mailman penalize me with setting
    JDL> up & maintaining filter rules to clobber the unnecessary
    JDL> reminders?  Is adding a user level configuration of this
    JDL> option in the works?  If not, here's a request for one.

Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
support user-disabling of reminder messages, on a per-list, or
per-virtual domain basis.

-Barry


From jra@baylink.com  Fri Jun  1 17:07:43 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 1 Jun 2001 12:07:43 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.47783.269611.179914@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 01, 2001 at 11:54:15AM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org>
Message-ID: <20010601120743.64585@scfn.thpl.lib.fl.us>

On Fri, Jun 01, 2001 at 11:54:15AM -0400, Barry A. Warsaw wrote:
> Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
> support user-disabling of reminder messages, on a per-list, or
> per-virtual domain basis.

Well, damnit Barry, what took you so long?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Fri Jun  1 17:15:27 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 12:15:27 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <15127.47783.269611.179914@anthem.wooz.org>
 <20010601120743.64585@scfn.thpl.lib.fl.us>
Message-ID: <15127.49055.164063.874312@anthem.wooz.org>

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    >> Yes.  Just yesterday I checked in changes to the MM2.1alpha
    >> tree to support user-disabling of reminder messages, on a
    >> per-list, or per-virtual domain basis.

    JRA> Well, damnit Barry, what took you so long?

Well, it takes a long time to check in stuff over a pokie little DSL
line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
house, it would go a long way toward faster checkins of cool new
features. :)

-Barry


From jra@baylink.com  Fri Jun  1 17:48:43 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 1 Jun 2001 12:48:43 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.49055.164063.874312@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 01, 2001 at 12:15:27PM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <15127.49055.164063.874312@anthem.wooz.org>
Message-ID: <20010601124843.48860@scfn.thpl.lib.fl.us>

On Fri, Jun 01, 2001 at 12:15:27PM -0400, Barry A. Warsaw wrote:
>     JRA> Well, damnit Barry, what took you so long?
> 
> Well, it takes a long time to check in stuff over a pokie little DSL
> line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
> house, it would go a long way toward faster checkins of cool new
> features. :)

OC48.

Shyeah, right.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From chuqui@plaidworks.com  Fri Jun  1 17:52:14 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 1 Jun 2001 09:52:14 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010601124843.48860@scfn.thpl.lib.fl.us>
Message-ID: <200106011650.f51GoJc26582@lists.apple.com>

On Friday, June 1, 2001, at 09:48 AM, Jay R. Ashworth wrote:

> OC48.
>
> Shyeah, right.
>

hey, don't put it down until you try it. I love mine.

you wouldn't believe how quickly you can download movies from 
www.nudgewink.com


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Some days you're the dog, some days you're the hydrant.



From barry@digicool.com  Fri Jun  1 17:58:39 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 12:58:39 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <15127.47783.269611.179914@anthem.wooz.org>
 <20010601120743.64585@scfn.thpl.lib.fl.us>
 <15127.49055.164063.874312@anthem.wooz.org>
 <20010601124843.48860@scfn.thpl.lib.fl.us>
Message-ID: <15127.51647.715092.998526@anthem.wooz.org>

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    JRA> OC48.

    JRA> Shyeah, right.

Hey, I worked for the gubmint for 10 years.  Trust me, it never hurts
to ask.

waiting-for-that-t3-from-fla-l y'rs,
-Barry


From adamj@dumpshock.com  Fri Jun  1 18:04:09 2001
From: adamj@dumpshock.com (Adam J)
Date: Fri, 01 Jun 2001 11:04:09 -0600
Subject: [Mailman-Developers] why no user disable of the monthly
 reminder?
In-Reply-To: <15127.47783.269611.179914@anthem.wooz.org>
References: <3B17B4E6.4871098F@laubster.org>
Message-ID: <4.3.2.7.2.20010601105931.00d09538@fastjack.dumpshock.com>

At 09:54 01/06/2001, Barry A. Warsaw wrote:

 >Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
 >support user-disabling of reminder messages, on a per-list, or
 >per-virtual domain basis.

Is the default setting configurable by the list-admin, or is it hard-coded 
to a certain setting?

Adam
< http://tss.dumpshock.com / http://www.jillted.org / adamj@dumpshock.com >



From chuqui@plaidworks.com  Fri Jun  1 18:07:00 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 1 Jun 2001 10:07:00 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.51647.715092.998526@anthem.wooz.org>
Message-ID: <200106011705.f51H55W27228@lists.apple.com>

On Friday, June 1, 2001, at 09:58 AM, Barry A. Warsaw wrote:

> Hey, I worked for the gubmint for 10 years.  Trust me, it never hurts
> to ask.
>

tell you what, Barry -- I'll hook up a modem to my network at home, and 
you can dial in and share mine that way.

chuq (a typical gubmint solution to the problem...)



--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

USENET is a lot better after two or three eggnogs. We shouldn't allow
anyone on the net without a bottle of brandy. (chuq von rospach, 1992)



From jra@baylink.com  Fri Jun  1 18:07:02 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 1 Jun 2001 13:07:02 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <200106011650.f51GoJc26582@lists.apple.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Fri, Jun 01, 2001 at 09:52:14AM -0700
References: <20010601124843.48860@scfn.thpl.lib.fl.us> <200106011650.f51GoJc26582@lists.apple.com>
Message-ID: <20010601130702.59546@scfn.thpl.lib.fl.us>

On Fri, Jun 01, 2001 at 09:52:14AM -0700, Chuq Von Rospach wrote:
> > OC48.
> > Shyeah, right.
> 
> hey, don't put it down until you try it. I love mine.
> you wouldn't believe how quickly you can download movies from 
> www.nudgewink.com

Rugger bastard.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Fri Jun  1 18:13:12 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 13:13:12 -0400
Subject: [Mailman-Developers] why no user disable of the monthly
 reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <4.3.2.7.2.20010601105931.00d09538@fastjack.dumpshock.com>
Message-ID: <15127.52520.82101.167530@anthem.wooz.org>

>>>>> "AJ" == Adam J <adamj@dumpshock.com> writes:

    AJ> Is the default setting configurable by the list-admin, or is
    AJ> it hard-coded to a certain setting?

The list owner can say that password reminders are never sent for his
list, but the ability for a user to suppress passwords globally across
all lists is always available.

-Barry


From barry@digicool.com  Fri Jun  1 18:15:03 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 13:15:03 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <15127.51647.715092.998526@anthem.wooz.org>
 <200106011705.f51H55W27228@lists.apple.com>
Message-ID: <15127.52631.12204.165364@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> tell you what, Barry -- I'll hook up a modem to my network at
    CVR> home, and you can dial in and share mine that way.

    CVR> chuq (a typical gubmint solution to the problem...)

Actually, a TGS would involve going through all the expense of putting
that in place, using it once, and then letting it rot for 30 years.

-Barry


From thomas@xs4all.net  Fri Jun  1 20:41:28 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 1 Jun 2001 21:41:28 +0200
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.49055.164063.874312@anthem.wooz.org>; from barry@digicool.com on Fri, Jun 01, 2001 at 12:15:27PM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <15127.49055.164063.874312@anthem.wooz.org>
Message-ID: <20010601214128.P690@xs4all.nl>

On Fri, Jun 01, 2001 at 12:15:27PM -0400, Barry A. Warsaw wrote:

> >>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

>     >> Yes.  Just yesterday I checked in changes to the MM2.1alpha
>     >> tree to support user-disabling of reminder messages, on a
>     >> per-list, or per-virtual domain basis.

>     JRA> Well, damnit Barry, what took you so long?

> Well, it takes a long time to check in stuff over a pokie little DSL
> line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
> house, it would go a long way toward faster checkins of cool new
> features. :)

Weeeelll... If you want to move to Amsterdam, Barry, I'm pretty sure I can
find you a nice li'l sysadmin spot at a certain ISP, and an apt. within
sight of office, so you can use a 2Mbit wireless connection to leach off of
the 1Gbit (ethernet over dark fiber) links we have connected to our uplinks
and multitude of peers ;)

Unfortunately for me, there's a big appartement building smack in the middle
of *my* line of sight to the office.... so I'll have to make do with a puny
33k6 analogue leased line until they either tear down the building or get me
a decent ADSL service :P

-- 
Thomas Wouters <thomas@xs4all.net>

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


From barry@digicool.com  Fri Jun  1 20:53:20 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 15:53:20 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <15127.47783.269611.179914@anthem.wooz.org>
 <20010601120743.64585@scfn.thpl.lib.fl.us>
 <15127.49055.164063.874312@anthem.wooz.org>
 <20010601214128.P690@xs4all.nl>
Message-ID: <15127.62128.598176.238796@anthem.wooz.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Weeeelll... If you want to move to Amsterdam, Barry, I'm
    TW> pretty sure I can find you a nice li'l sysadmin spot at a
    TW> certain ISP, and an apt. within sight of office, so you can
    TW> use a 2Mbit wireless connection to leach off of the 1Gbit
    TW> (ethernet over dark fiber) links we have connected to our
    TW> uplinks and multitude of peers ;)

Don't tempt me!  There's already been a Netherlands->US imbalance in
The Force for the last 6 years.  And if we can't tip the scales for
good by /us/ hiring /you/, I might just have to help balance the
scales in the other direction.

Not that my brain can compare to Guido's, no, but Max sure is cuter,
so that evens things.  I've got a cousin just an hour or so away from
you in Germany, and if Guido can learn to speak like a
"Warshingtonian", I'm sure I can pick up enough Dutch to get by.
'Course, it /is/ a long sea voyage away. :)

i'd-just-be-coming-for-the-hash-bars-and-hookers-anyway-ly y'rs,
-Barry


From gmourani@openna.com  Fri Jun  1 21:35:18 2001
From: gmourani@openna.com (Gerhard Mourani)
Date: Fri, 1 Jun 2001 16:35:18 -0400
Subject: [Mailman-Developers] Bug under link (Tend to pending administrative requests)
Message-ID: <013e01c0eada$5eef8720$1401a8c0@openna.com>

OS      = RH Linux 7.1
Python  = 2.1
mailman = 2.0.5

clicking on the link (Tend to pending administrative requests) under the
administration web interface will return the following
error message into the mailman error log file:


admin(18366): [----- Traceback ------]
admin(18366): Traceback (most recent call last):
admin(18366):   File "/var/lib/mailman/scripts/driver", line 96, in run_main
admin(18366):     main()
admin(18366):   File "/var/lib/mailman/Mailman/Cgi/admindb.py", line 108, in
main
admin(18366):     if len(cgidata.keys()):
admin(18366): UnboundLocalError: local variable 'cgidata' referenced before
assignment
admin(18366): [----- Python Information -----]
admin(18366): sys.version    = 2.1 (#1, May 31 2001, 18:30:14)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)]
admin(18366): sys.executable = /usr/bin/python
admin(18366): sys.prefix     = /usr
admin(18366): sys.exec_prefix= /usr
admin(18366): sys.path       = /usr
admin(18366): sys.platform   = linux-i386

Any suggestion??

--
Gerhard Mourani - gmourani@openna.com
Operation & Development Manager
OpenNA.com - http://www.openna.com/
--



From barry@digicool.com  Fri Jun  1 22:01:14 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 17:01:14 -0400
Subject: [Mailman-Developers] Bug under link (Tend to pending administrative requests)
References: <013e01c0eada$5eef8720$1401a8c0@openna.com>
Message-ID: <15128.666.576627.730090@anthem.wooz.org>

>>>>> "GM" == Gerhard Mourani <gmourani@openna.com> writes:

    | OS      = RH Linux 7.1
    | Python  = 2.1
    | mailman = 2.0.5

    GM> clicking on the link (Tend to pending administrative requests)
    GM> under the administration web interface will return the
    GM> following error message into the mailman error log file:

Are you sure you really installed 2.0.5?  This bug was fixed in 2.0.5.

-Barry


From wilane@MINT.SN  Sat Jun  2 05:57:33 2001
From: wilane@MINT.SN (Ousmane Wilane)
Date: Sat, 2 Jun 2001 04:57:33 +0000 (GMT)
Subject: [Mailman-Developers] Missed _()
Message-ID: <Pine.LNX.4.33.0106020453080.10171-100000@NS.MINT.SN>

File: Mailman/Cgi/options.py
Line: 450
String: "<em>Yes, I realy want to unsubscribe</em>"

Cheers
-- 
-- Ousmane Wilane
-- "The best laid plans sometimes go awry..."



From barry@digicool.com  Sat Jun  2 05:49:23 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sat, 2 Jun 2001 00:49:23 -0400
Subject: [Mailman-Developers] Missed _()
References: <Pine.LNX.4.33.0106020453080.10171-100000@NS.MINT.SN>
Message-ID: <15128.28755.704021.811604@anthem.wooz.org>

>>>>> "OW" == Ousmane Wilane <wilane@MINT.SN> writes:

    | File: Mailman/Cgi/options.py
    | Line: 450
    | String: "<em>Yes, I realy want to unsubscribe</em>"

Awesome, thanks!

I love open source. :)

-Barry


From barry@digicool.com  Sat Jun  2 06:31:43 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sat, 2 Jun 2001 01:31:43 -0400
Subject: [Mailman-Developers] minor qrunner bug.
References: <200105310715.f4V7Fmh05534@plaidworks.com>
Message-ID: <15128.31295.781320.220845@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> Just noticed a minor bug in qrunner. when qrunner starts up,
    CVR> it opens the log files, and leaves them open.

    CVR> while open/write/close is expensive, given all of the other
    CVR> stuff qrunner's doing and the relative lack of logging, I
    CVR> don't think it's significant. Alternatively, it can notice
    CVR> the files have been moved/zeroed, or perhaps accept a HUP
    CVR> like syslog...

>>>>> "JS" == Jon Stevens <jon@latchkey.com> writes:

    JS> The way that Apache HTTPd works (as well as many other
    JS> daemons) is that you move the log files out of the way and
    JS> then you HUP Apache which will re-create the log
    JS> files. Accepting HUP's (or a graceful restart) is
    JS> functionality that should be added to qrunner if it isn't
    JS> there already.

This turned out to fairly easy to add, so I have. :)

SIGHUP on the qrunner master process now closes all the log files.
They will be reopened on the next write.

-Barry


From chuqui@plaidworks.com  Sat Jun  2 07:37:05 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 1 Jun 2001 23:37:05 -0700
Subject: [Mailman-Developers] minor qrunner bug.
In-Reply-To: <15128.31295.781320.220845@anthem.wooz.org>
Message-ID: <200106020628.f526Srh01518@plaidworks.com>

--Apple-Mail-286235841-4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	format=flowed;
	charset=us-ascii


On Friday, June 1, 2001, at 10:31 PM, Barry A. Warsaw wrote:

> This turned out to fairly easy to add, so I have. :)
>
> SIGHUP on the qrunner master process now closes all the log files.
> They will be reopened on the next write.

by the way, another app susceptible to this is mailpasswd.

It'd be nice if there were some way to tell these tools to shut down 
conveniently, and if possible, snapshot and restart where they left off. 
But that's probably asking for gold leaf instead of gold paint...




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Stress is when you wake up screaming and you realize you haven't fallen 
asleep yet.




--Apple-Mail-286235841-4
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=us-ascii


On Friday, June 1, 2001, at 10:31 PM, Barry A. Warsaw wrote:


<excerpt>This turned out to fairly easy to add, so I have. :)


SIGHUP on the qrunner master process now closes all the log files.

They will be reopened on the next write.

</excerpt>

by the way, another app susceptible to this is mailpasswd. 


It'd be nice if there were some way to tell these tools to shut down
conveniently, and if possible, snapshot and restart where they left
off. But that's probably asking for gold leaf instead of gold paint...



<color><param>0000,0000,DEB7</param>

</color>

-- 

Chuq Von Rospach, Internet Gnome <<http://www.chuqui.com>

[<<chuqui@plaidworks.com> = <<me@chuqui.com> = <<chuq@apple.com>]

Yes, yes, I've finally finished my home page. Lucky you. 


Stress is when you wake up screaming and you realize you haven't
fallen asleep yet.





--Apple-Mail-286235841-4--


From timpye@inbiworld.com  Sun Jun  3 01:24:22 2001
From: timpye@inbiworld.com (INBI-MATRIX)
Date: Sat, 2 Jun 2001 17:24:22 -0700
Subject: [Mailman-Developers] pyethon required
Message-ID: <000501c0ebc3$89f0bea0$f80686cb@venus>

To all,
Anyone interested in setting up mailman on our Linux server so we can run a
discussion forum for our members?
thanks,

Tim Pye
INBI-MATRIX
PO Box 3003
TAMARAMA NSW 2026
Australia
timpye@inbiworld.com
Tel/Fax 61-2-9365 3455
www.inbiworld.com



From thomas@xs4all.net  Sat Jun  2 15:17:45 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 2 Jun 2001 16:17:45 +0200
Subject: [Mailman-Developers] pyethon required
In-Reply-To: <000501c0ebc3$89f0bea0$f80686cb@venus>; from timpye@inbiworld.com on Sat, Jun 02, 2001 at 05:24:22PM -0700
References: <000501c0ebc3$89f0bea0$f80686cb@venus>
Message-ID: <20010602161744.S690@xs4all.nl>

On Sat, Jun 02, 2001 at 05:24:22PM -0700, INBI-MATRIX wrote:

> Anyone interested in setting up mailman on our Linux server so we can run a
> discussion forum for our members?

Setting up Mailman is a breeze. Anyone who ever installed a program using
'./configure' and 'make install', and configured/installed Apache and
Sendmail (or whatever MTA you use) will make sense of the installation
instructions.

If you really  need someone to set it up, I'd be willing to, but you have to
consider maintenance issues -- it's a lot more convenient, for you, if the
normal sysadmin does it.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From ricardo@rixhq.nu  Sat Jun  2 22:30:14 2001
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sat, 2 Jun 2001 23:30:14 +0200
Subject: [Mailman-Developers] [rather offtopic] DSL lines
In-Reply-To: <20010601214128.P690@xs4all.nl>; from thomas@xs4all.net on Fri, Jun 01, 2001 at 09:41:28PM +0200
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <15127.49055.164063.874312@anthem.wooz.org> <20010601214128.P690@xs4all.nl>
Message-ID: <20010602233014.A1560@rix.rixhq.nu>

On Fri, Jun 01, 2001 at 09:41:28PM +0200, Thomas Wouters wrote:
> > Well, it takes a long time to check in stuff over a pokie little DSL
> > line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
> > house, it would go a long way toward faster checkins of cool new
> > features. :)
> Weeeelll... If you want to move to Amsterdam, Barry, I'm pretty sure I can
> find you a nice li'l sysadmin spot at a certain ISP, and an apt. within
> sight of office, so you can use a 2Mbit wireless connection to leach off of
> the 1Gbit (ethernet over dark fiber) 

Hey, I happen to live one subway stop from that certain ISP... is that offer
open for other people too? ;-) Hmmm unfortunately my appartment isn't in the
line of sight either... oh well, i'm quite happy with the ADSL line
from that same ISP... :)

Regards,

Ricardo



From wilane@MINT.SN  Sat Jun  2 22:34:21 2001
From: wilane@MINT.SN (Ousmane Wilane)
Date: Sat, 2 Jun 2001 21:34:21 +0000 (GMT)
Subject: [Mailman-Developers] Missin )!
Message-ID: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>

		From mailman  Sat Jun  2 17:00:00 2001
[snip]
		  File "/home/mailman/cron/checkdbs", line 57
		    admin = mlist.GetAdminEmail()
		        ^
		SyntaxError: invalid syntax

missing ")" at line 55 in cron/checkdbs
    subject = _('%d %s moderator request(s) waiting' % (
           count, mlist.real_name)
Barry and i18n it's realy love at first sight :)
Cheers!


-- 
-- Ousmane Wilane
-- "The best laid plans sometimes go awry..."



From wilane@MINT.SN  Sat Jun  2 23:14:45 2001
From: wilane@MINT.SN (Ousmane Wilane)
Date: Sat, 2 Jun 2001 22:14:45 +0000 (GMT)
Subject: [Mailman-Developers] -S pb!
Message-ID: <Pine.LNX.4.33.0106022205120.3243-100000@NS.MINT.SN>

	Subject: Cron <mailman@NS> /usr/bin/python -S
	[snip]
	Traceback (most recent call last):
	  File "/home/mailman/cron/senddigests", line 25, in ?
	    from Mailman import MailList
	  File "/home/mailman/Mailman/MailList.py", line 34, in ?
	    from mimelib.address import getaddresses
	ImportError: No module named mimelib.address

mimelib is under site-packages!
Why -S?
Cheers!

-- 
-- Ousmane Wilane
-- "The best laid plans sometimes go awry..."



From dmick@utopia.West.Sun.COM  Sun Jun  3 01:50:20 2001
From: dmick@utopia.West.Sun.COM (Dan Mick)
Date: Sat, 02 Jun 2001 17:50:20 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
Message-ID: <3B1989CC.8D8FEA78@utopia.west.sun.com>


"J.D. Laub" wrote:
> 
> Please CC me on replies as I'm not a mailman-developer subscriber...
> 
> In my inbox this morning I found several monthly reminders for various
> lists to which I'm subscribed.  I'm responsible enough to save off a
> list's "Welcome" message, and I need no monthly reminder.  Why does
> Mailman penalize me with setting up & maintaining filter rules to
> clobber the unnecessary reminders?  

You would go to the trouble of setting up a filter for a *monthly*
message?

Man, I thought I was anal-retentive, but the Internet shows me how much
of a slacker I really am.


From claw@kanga.nu  Sun Jun  3 07:20:04 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sat, 02 Jun 2001 23:20:04 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: Message from Dan Mick <dmick@utopia.West.Sun.COM>
 of "Sat, 02 Jun 2001 17:50:20 PDT." <3B1989CC.8D8FEA78@utopia.west.sun.com>
References: <3B17B4E6.4871098F@laubster.org>  <3B1989CC.8D8FEA78@utopia.west.sun.com>
Message-ID: <9901.991549204@kanga.nu>

On Sat, 02 Jun 2001 17:50:20 -0700 
Dan Mick <dmick@utopia.West.Sun.COM> wrote:

> You would go to the trouble of setting up a filter for a *monthly*
> message?

When I was only on a couple Mailman-run lists I didn't bother.  Now
I get twenty or password reminder messages a month.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun  3 15:22:36 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 07:22:36 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <9901.991549204@kanga.nu>
Message-ID: <200106031414.f53EEMh02825@plaidworks.com>

On Saturday, June 2, 2001, at 11:20 PM, J C Lawrence wrote:

> When I was only on a couple Mailman-run lists I didn't bother.  Now
> I get twenty or password reminder messages a month.
>

A good reason, by the way, to be able to set things up so these messages 
are spread out across the month, not everyone sending them out from 
every installation on the same day for every list. (I realize people can 
tweak the crontab. nobody does).

I'd really prefer these things be per-list, not per-site. And 
customizable, so I can, for instance, include pointers to the FAQ, 
archives, list rules, or whatever. And then be able to configure when 
they go out for each list.

I also really wish mailpasswd had checkpoints, so if it dies, it'd 
restart where it left off -- my big mailman box has been mailing out 
password notices since friday night, for instance, and while I expect it 
to finish sometime today, this is a situation just fraught with 
potential problems. What I'd *really* like, if we must do this on a 
site-wide basis is to run mailpasswd every night, and tell it, say, to 
send out 5,000 per night, and keep track of where it left off. Having to 
run it manually because on a site as big as this one it has to happen on 
a weekend kinda bites.

Oh, and one more thing (thanks for reminding me). the password reminders 
aren't really hooked into the bounce-processed setup, since they get 
sent back to a list admin address, and not necessarily one the user is 
actually subscribed to. We're losing a major opportunity to clean up the 
mail lists here, especially when it comes to non-standard mailers and 
forwarded addresses. These really ought to be sent from a special 
address with a special envelope, so returns can be processed for 
site-wide removal (IMHO, if the password reminder bounces for any 
reason, that qualifies as removal. I'm going to have to pull the data 
out of bounce files monday and manually hack something up...




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Q: Did God really create the world in seven days?
A: He did it in six days and nights while living on cola and candy
    bars.  On the seventh day he went home and found out his girlfriend
    had left him.





From jra@baylink.com  Sun Jun  3 15:27:10 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Sun, 3 Jun 2001 10:27:10 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <200106031414.f53EEMh02825@plaidworks.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Sun, Jun 03, 2001 at 07:22:36AM -0700
References: <9901.991549204@kanga.nu> <200106031414.f53EEMh02825@plaidworks.com>
Message-ID: <20010603102710.25833@scfn.thpl.lib.fl.us>

On Sun, Jun 03, 2001 at 07:22:36AM -0700, Chuq Von Rospach wrote:
> potential problems. What I'd *really* like, if we must do this on a 
> site-wide basis is to run mailpasswd every night, and tell it, say, to 
> send out 5,000 per night, and keep track of where it left off. Having to 
> run it manually because on a site as big as this one it has to happen on 
> a weekend kinda bites.

Hey, Chuq?

I asked this before, but I don't remember you weighing in, and I
suspect you might have something useful to say...

I'm trying to get Mailman to behave itself as a *broadcast* list
manager (rather than for discussion), and I need to throttle the
*actual mail* that way (x thousand per day).

Where might be the best place to put something like that? 

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From chuqui@plaidworks.com  Sun Jun  3 15:39:32 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 07:39:32 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010603102710.25833@scfn.thpl.lib.fl.us>
Message-ID: <200106031431.f53EVHh03030@plaidworks.com>

On Sunday, June 3, 2001, at 07:27 AM, Jay R. Ashworth wrote:

> I asked this before, but I don't remember you weighing in, and I
> suspect you might have something useful to say...
>
> I'm trying to get Mailman to behave itself as a *broadcast* list
> manager (rather than for discussion), and I need to throttle the
> *actual mail* that way (x thousand per day).
>
> Where might be the best place to put something like that?
>

Good question -- I don't use mailman for this, all of my broadcast work 
is with a custom front-end, and it usually talks to bulk_mailer on the 
back end, and I build the rate limiting into a custom version of 
bulk_mailer.

I'm not sure how I'd do this with mailman; you really need to be able to 
pull subsets of subscriber data out in a reproducible format, and keep 
track of a highwater mark so you can restart delivery from the next 
address. I'm sure you could do something with the cli scripting, but you 
end up doing most of the work outside of mailman, including delivery, so 
you end up with basically a custom setup.

What I'd do in this case is add a uniq id flag to the database, so I 
could teach mailman to "mail 4000 messages in list foo starting with id 
1", and then track what the last one did, and iterate nightly until 
everyone's delivery. Something like that. It isn't too complicated, but 
it requires keeping a lot more state than mailman is set up to keep. 
but -- thinking about it -- if this were set up as a generalized 
functionality for lists, then password reminders then becomes an 
instance of this functionality, not a specialty mailing or a custom 
program like mailpasswd. you simply schedule a password reminder into 
this subsystem via cron then....


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Any connection between your reality and mine
is purely coincidental.




From jra@baylink.com  Sun Jun  3 15:44:22 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Sun, 3 Jun 2001 10:44:22 -0400
Subject: [Mailman-Developers] Maybe OT: Back to Broadcast Mail
In-Reply-To: <200106031431.f53EVHh03030@plaidworks.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Sun, Jun 03, 2001 at 07:39:32AM -0700
References: <20010603102710.25833@scfn.thpl.lib.fl.us> <200106031431.f53EVHh03030@plaidworks.com>
Message-ID: <20010603104422.11401@scfn.thpl.lib.fl.us>

On Sun, Jun 03, 2001 at 07:39:32AM -0700, Chuq Von Rospach wrote:
> > I'm trying to get Mailman to behave itself as a *broadcast* list
> > manager (rather than for discussion), and I need to throttle the
> > *actual mail* that way (x thousand per day).
> > Where might be the best place to put something like that?
> 
> Good question -- I don't use mailman for this, all of my broadcast work 
> is with a custom front-end, and it usually talks to bulk_mailer on the 
> back end, and I build the rate limiting into a custom version of 
> bulk_mailer.

Um... should I know about that, instead?  I'm not married to mailman
for this...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From claw@kanga.nu  Sun Jun  3 18:46:13 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 03 Jun 2001 10:46:13 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 03 Jun 2001 07:22:36 PDT." <200106031414.f53EEMh02825@plaidworks.com>
References: <200106031414.f53EEMh02825@plaidworks.com>
Message-ID: <8834.991590373@kanga.nu>

On Sun, 3 Jun 2001 07:22:36 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> Oh, and one more thing (thanks for reminding me). the password
> reminders aren't really hooked into the bounce-processed setup,
> since they get sent back to a list admin address, and not
> necessarily one the user is actually subscribed to. We're losing a
> major opportunity to clean up the mail lists here, especially when
> it comes to non-standard mailers and forwarded addresses. These
> really ought to be sent from a special address with a special
> envelope, so returns can be processed for site-wide removal (IMHO,
> if the password reminder bounces for any reason, that qualifies as
> removal. I'm going to have to pull the data out of bounce files
> monday and manually hack something up...

Agreed, and I'll add that the password reminders really need to be
VERPed.  Of course this will have to be optional for those MTAs
which are not VERP happy, but the password reminders are just too
cherry an opportunity to overlook for removing addresses which you
*CAN'T* deduce from bounce message processing (mail forwards etc).

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun  3 18:55:38 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 10:55:38 -0700
Subject: [Mailman-Developers] Maybe OT: Back to Broadcast Mail
In-Reply-To: <20010603104422.11401@scfn.thpl.lib.fl.us>
Message-ID: <200106031747.f53HlNh05907@plaidworks.com>

On Sunday, June 3, 2001, at 07:44 AM, Jay R. Ashworth wrote:



>> Good question -- I don't use mailman for this, all of my broadcast work
>> is with a custom front-end, and it usually talks to bulk_mailer on the
>> back end, and I build the rate limiting into a custom version of
>> bulk_mailer.
>
> Um... should I know about that, instead?  I'm not married to mailman
> for this...

Not necessarily. Bulk_mailer is a tool written for majordomo 
installations that splits up deliveries into small batches. postfix can 
do this using the default_destination_concurrency_limit option, so if 
you're using postfix, you don't really need it. Once I finish migration, 
I'll rewrite my sending tools to take advantage of that isntead of using 
bulk_mailer, and phase it out (bulk_mailer also does some other stuff, 
like set up some headers, but my custom tools can easily do that as well)

my front ends are just custom perl scripts that take pieces of content 
and address lists and puts it together. Nothing fancy (and not 
distributable), and all really stop-gap stuff while I write a real 
publishing tool for this stuff, which is the project I'm designing now 
(we want to be able to send out fully-customized e-mail using a template 
system with volume up to about 500K an hour, with full versioning 
control of the content and automatic access of the user data from the 
corporate database. A fun summer project)

I have to keep reminding people in my company that want to borrow my 
tools that the tolls I'm currently using are very stupid; it's the 
person hacking them that is doing most of the work. Once I finish this 
new mail publishing system, the tools will be smart, but since it's 
designed for corporate use, they won't need to borrow the tools, just 
have an account on them...



--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Any connection between your reality and mine
is purely coincidental.




From chuqui@plaidworks.com  Sun Jun  3 18:59:24 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 10:59:24 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <8834.991590373@kanga.nu>
Message-ID: <200106031751.f53Hp9h05954@plaidworks.com>

On Sunday, June 3, 2001, at 10:46 AM, J C Lawrence wrote:

> Agreed, and I'll add that the password reminders really need to be
> VERPed.  Of course this will have to be optional for those MTAs
> which are not VERP happy, but the password reminders are just too
> cherry an opportunity to overlook for removing addresses which you
> *CAN'T* deduce from bounce message processing (mail forwards etc).


Definitely. and I've sent the lsat few days immersed in postfix 
documentation, and it has some real interesting stuff that can be used 
for optimizing some of what I do. I really like the idea of a direct 
mysql interface, since it means I can load most of my configuration data 
into a central server and not have to worry about migrating it out to 
the farm anymore. It also makes doiing thigns like a distributed list 
server possible, since you can have two or three boxes out in round 
robin, and you can tweak the aliases data in the database to have them 
route list info to processing boxes on the fly, so you can load balance 
across multiple machines.

Lots of fun stuff here, although it might not be approppriate for a 
general mailman release, since it can't depend on these functions, I'm 
guessing.


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Any connection between your reality and mine
is purely coincidental.




From claw@kanga.nu  Sun Jun  3 19:06:29 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 03 Jun 2001 11:06:29 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: Message from "Jay R. Ashworth" <jra@baylink.com>
 of "Sun, 03 Jun 2001 10:27:10 EDT." <20010603102710.25833@scfn.thpl.lib.fl.us>
References: <9901.991549204@kanga.nu> <200106031414.f53EEMh02825@plaidworks.com>  <20010603102710.25833@scfn.thpl.lib.fl.us>
Message-ID: <13291.991591589@kanga.nu>

On Sun, 3 Jun 2001 10:27:10 -0400 
Jay R Ashworth <jra@baylink.com> wrote:

> I'm trying to get Mailman to behave itself as a *broadcast* list
> manager (rather than for discussion), and I need to throttle the
> *actual mail* that way (x thousand per day).

> Where might be the best place to put something like that?

While it gets fiddly, its not too difiicult to do this at the MTA
level with a sufficiently configurable MTA (ie Exim).  Essentially,
just have an Exim filter that rewrites all broacast mail actually
being addressed to a local user, spool it off locally, and then have
a cronjob which sucks N thousand out per day from the top of the
mbox and re-slaps them into the MTA with a custom header added
(which causes them to skip the prior filter).

You could also use a double ganged MTA approach (second MTA running
on a high port -- I used to tdo this with SMail/UUCP) but without
thinking about it ore than I want to now, I'm not sure that this
would be easier.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From listmgr@perilpoint.com  Sun Jun  3 19:36:04 2001
From: listmgr@perilpoint.com (Bradford Shaw)
Date: Sun, 03 Jun 2001 13:36:04 -0500
Subject: [Mailman-Developers] Cleaning up digests
Message-ID: <4.2.0.58.20010603132250.00cb4860@perilpoint.com>

Hello,

I need to modify the way that digests are being sent out. Can you tell me 
where I can make the following changes?

1. Remove all headers, except the From, Date and Subject from the 
individual messages in the digest
2. Create a separator line between messages in the digest
3. Strip out message footers from the messages in the digest

I would also like to know how to not have both the plain text and mime 
print to the same message in the archives.

Many thanks.

Best wishes,
Bradford "Biff" Shaw
List Administrator
PerilPoint Communications Inc.
http://www.perilpoint.com



From thomas@xs4all.net  Mon Jun  4 01:03:46 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 4 Jun 2001 02:03:46 +0200
Subject: [Mailman-Developers] -S pb!
In-Reply-To: <Pine.LNX.4.33.0106022205120.3243-100000@NS.MINT.SN>; from wilane@MINT.SN on Sat, Jun 02, 2001 at 10:14:45PM +0000
References: <Pine.LNX.4.33.0106022205120.3243-100000@NS.MINT.SN>
Message-ID: <20010604020346.U690@xs4all.nl>

On Sat, Jun 02, 2001 at 10:14:45PM +0000, Ousmane Wilane wrote:
> 	Subject: Cron <mailman@NS> /usr/bin/python -S
> 	[snip]
> 	Traceback (most recent call last):
> 	  File "/home/mailman/cron/senddigests", line 25, in ?
> 	    from Mailman import MailList
> 	  File "/home/mailman/Mailman/MailList.py", line 34, in ?
> 	    from mimelib.address import getaddresses
> 	ImportError: No module named mimelib.address
> 
> mimelib is under site-packages!
> Why -S?

Barry likes using -S to speed up the load process... loading site.py can be
a slow process. He cheats by adding the site-packages directory to his
sys.path directly, and I cheat by adding a symlink to site-packages/mimelib
from directly in my module directory. Barry'll probably add the former to
Mailman, or remove the -S, when making a real (read: functional) release. My
cheat is easier, especially when running multiple Mailmans on the same
machine :)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From thomas@xs4all.net  Mon Jun  4 01:11:04 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 4 Jun 2001 02:11:04 +0200
Subject: [Mailman-Developers] Missin )!
In-Reply-To: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>; from wilane@MINT.SN on Sat, Jun 02, 2001 at 09:34:21PM +0000
References: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>
Message-ID: <20010604021104.V690@xs4all.nl>

On Sat, Jun 02, 2001 at 09:34:21PM +0000, Ousmane Wilane wrote:
> 		From mailman  Sat Jun  2 17:00:00 2001
> [snip]
> 		  File "/home/mailman/cron/checkdbs", line 57
> 		    admin = mlist.GetAdminEmail()
> 		        ^
> 		SyntaxError: invalid syntax
> 
> missing ")" at line 55 in cron/checkdbs
>     subject = _('%d %s moderator request(s) waiting' % (
>            count, mlist.real_name)

Indeedy! Fixed in CVS, thanx.

> Barry and i18n it's realy love at first sight :)

Well, what do you expect from a guy who speaks no foreign (to him)
languages, and whose idea of l10n is microbrew and a special kind of crab...
I think it's admirable that he hasn't given up in despair, yet ;)

I-would-have-and-I-speak-and-write-4-foreign-languages-ly y'rs ;)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From barry@digicool.com  Mon Jun  4 18:22:04 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 4 Jun 2001 13:22:04 -0400
Subject: [Mailman-Developers] Missin )!
References: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>
 <20010604021104.V690@xs4all.nl>
Message-ID: <15131.50108.34538.896434@anthem.wooz.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Indeedy! Fixed in CVS, thanx.

Yes, thanks Ousmane!  I'm glad some folks are taking the cvs snapshot
out for a spin.

Unfortunately, there were a few more problems w/checkdbs, mostly it
was just out-of-date in a few places.  I'll check in a fixed script in
a few moments.

    >> Barry and i18n it's realy love at first sight :)

    TW> Well, what do you expect from a guy who speaks no foreign (to
    TW> him) languages, and whose idea of l10n is microbrew and a
    TW> special kind of crab...  I think it's admirable that he hasn't
    TW> given up in despair, yet ;)

Well, I took Spanish and Hebrew in high school, but that was so many
years ago, I think the only thing I retained was that /one/ of those
languages is written right to left. ;) And no, I won't give up, as
long as I have plenty of Dog Fish Head beer and Maryland blue crabs
(no Louisiana imports allowed!) to keep me going.

    TW> I-would-have-and-I-speak-and-write-4-foreign-languages-ly y'rs
    TW> ;)

You and Guido too.  Could Tim be right? :)

-Barry


From pisTon@iwr.ru.ac.za  Tue Jun  5 16:05:27 2001
From: pisTon@iwr.ru.ac.za (David A. Forsyth)
Date: Tue, 5 Jun 2001 15:05:27 GMT+2
Subject: [Mailman-Developers] filtering extensions?
Message-ID: <2275BE83E1E@iwr.ru.ac.za>

Hiya all

I've just joined in order to make a suggestion for futer development 
of mailman.

Let me fill you in a bit...
I'm a programmer working in Delphi, and a network admin (Novell), AND 
I have a hobby....   

In the interests of the hobby (railways) I run a list using mailman 
on a machine administered by someone else (a Unix guru of note).

My immediate problem is that multipart MIME encoded messages on the 
list I run pose a huge virus infection threat to all the members 
(apart form being just downright annoying to those who use mailers 
that don't interpret them). I'm a member of some Yahoo groups and I 
see that their list software trims off 'non text portions' of the 
messages.  In other words, it only sends on the plain text and dumps 
all the rich text, text/html, ms-tnef etc bits of junk that arrive in 
multipart MIME format.

So, I'm wondering if such filtering can be done by mailman so that 
list members need not be troubled to reset the default encoding 
schemes on their various flavours of PC, and yet be safe from 
receiving virus's via the list.

(note my list does not accept images either, so filtering out ALL 
attachments would not bother *me* in this application, yetis a 
consideration for other lists)

For now, I've done a fiddle in the list settings by putting a check 
for multipart MIME in the headers so I get to veto them as moderator.
Unfortunatly, the message sent back to offenders is a bit misleading 
in that it says 'message contained a suspicous header' no matter what 
rule triggered it.   A possible extension to mailman is to allow 
pattern specific messages and actions at this point.

thanks
--
   Living in South Africa
      Flying power Kites
         Chasing 3'6" gauge trains
http://terrapin.ru.ac.za/satrain


From Joaquim Homrighausen" <joho@webbplatsen.se  Tue Jun  5 14:49:38 2001
From: Joaquim Homrighausen" <joho@webbplatsen.se (Joaquim Homrighausen)
Date: Tue, 05 Jun 2001 15:49:38 +0200
Subject: [Mailman-Developers] Multi-lingual, translations, templates, etc.
Message-ID: <E157HDI-0006oP-00@mail.python.org>

Where is a good place to start for multi-lingual resources for
Mailman? If I find the time, etc. how do I best contribute with
translations of templates, language data, etc?

Regards,
Joaquim



:: Who dares wins ::




From barry@digicool.com  Tue Jun  5 15:04:44 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 5 Jun 2001 10:04:44 -0400
Subject: [Mailman-Developers] Multi-lingual, translations, templates, etc.
References: <E157HDI-0006oP-00@mail.python.org>
Message-ID: <15132.59132.482592.38892@anthem.wooz.org>

>>>>> "JH" == Joaquim Homrighausen <joho@webbplatsen.se> writes:

    JH> Where is a good place to start for multi-lingual resources for
    JH> Mailman? If I find the time, etc. how do I best contribute
    JH> with translations of templates, language data, etc?

The mailman-i18n@python.org list is the place to congregate with other
translators.  You'll want to check out the latest CVS snapshot of
MM2.1 for the most up-to-date templates and catalogs.

Cheers,
-Barry


From barry@digicool.com  Wed Jun  6 23:29:23 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Wed, 6 Jun 2001 18:29:23 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com>
Message-ID: <15134.44739.463393.527457@anthem.wooz.org>

[I've moved this discussion over to mailman-developers.  -BAW]

>>>>> "JCL" == J C Lawrence <claw@2wire.com> writes:

    JCL>   Ability to unroll quoted printable.

    JCL>   Ability to unroll base64 encoded plain text.

    JCL>   Ability to strip blocks from message parts that match
    JCL> stated patterns (eg Yahoo/MSN/Hotmail ads, corporate CYA
    JCL> statements, etc).

    JCL>   Ability to filter on line length (eg hold for moderation or
    JCL>   auto-discard/reject).  

Some of this will be added to mimelib when I get a chance.  On the
plus side, Python 2.1 and the future 2.2 has some nice support for all
this via its unicode codecs.  I.e. in the Python CVS there's now a
codec for quoted printable so you can essentially say something like:

    subject = msg['subject'].decode('quopri')

if your subject header is quoted as per RFC 2047.  I've only played
around with this stuff a little bit, to get a feel for what you can
do, so I haven't thought about APIs or doing the actual coding yet.

The downside is that I'm still targetting Mailman 2.1 at Python 2.0,
so some of these features may not be available.

Also, just some quick thoughts on de-mime-ing, which also address some
things that Chuq has brought up, re: regexp filtering,
auto-discarding, etc.

I'm of the opinion that regular expression predicates alone aren't
going to cut it, and that anything more complex is just way way too
complicated to attempt to expose through an email or web interface.
Complexity is already our enemy, IMHO.

So what I'm envisioning is an extensible architecture, a la the
message pipelines, where each filter is implemented in a separate
Python module, conforming to a particular, yet-to-be-defined API.
Mailman will provide a bunch of canned defaults, like
"strip-mime-leaving-only-text/plain" or "match-vbs-attachments".
There will probably be some kind of mix-in model for describing the
action to take when a filter module matches.

Then the admins can choose which filters they want, and what order
they want to run them in.  I'd actually envisioned something like this
for the delivery pipeline, but that (giving admins control) has turned
out to be not as necessary.

Even this may turn out to be too complex, so there may be yet another
level of abstraction that a site admin can glom together, so that a
list admin would be presented with a limited set of `rhythms',
`themes', or `styles' that they can pick and choose from.  I've
thought about a similar mechanism for list themes, like "announce-only
list" or "read-only mirror list".

The point is that there's a lot we can do very cleanly at the Python
level, but that the more configurability we expose at the web/email
interface, the less usable it becomes, IMHO.  So, I'm thinking
seriously about ways to preserve the power Mailman can provide to the
Python hacker while employing abstractions to reduce the cognitive
load on the list administrators and users.

-Barry


From claw@kanga.nu  Thu Jun  7 04:12:03 2001
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 06 Jun 2001 20:12:03 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw)
 of "Wed, 06 Jun 2001 18:29:23 EDT." <15134.44739.463393.527457@anthem.wooz.org>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com>  <15134.44739.463393.527457@anthem.wooz.org>
Message-ID: <18118.991883523@kanga.nu>

On Wed, 6 Jun 2001 18:29:23 -0400 
Barry A Warsaw <barry@digicool.com> wrote:

> The point is that there's a lot we can do very cleanly at the
> Python level, but that the more configurability we expose at the
> web/email interface, the less usable it becomes, IMHO.  So, I'm
> thinking seriously about ways to preserve the power Mailman can
> provide to the Python hacker while employing abstractions to
> reduce the cognitive load on the list administrators and users.

One problem with this approach is that you tend to require list
admins to have shell access.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From les@2pi.org  Thu Jun  7 06:55:54 2001
From: les@2pi.org (Les Niles)
Date: Wed, 6 Jun 2001 22:55:54 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <15134.44739.463393.527457@anthem.wooz.org> (barry@digicool.com)
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org>
Message-ID: <200106070555.WAA12753@mutiny.2pi.org>

On Wed, 6 Jun 2001 18:29:23 -0400 barry@digicool.com (Barry A. Warsaw) wrote:
>
>[I've moved this discussion over to mailman-developers.  -BAW]
>
>>>>>> "JCL" == J C Lawrence <claw@2wire.com> writes:
>
>    JCL>   Ability to unroll quoted printable.
>
>    JCL>   Ability to unroll base64 encoded plain text.
>
>    JCL>   Ability to strip blocks from message parts that match
>    JCL> stated patterns (eg Yahoo/MSN/Hotmail ads, corporate CYA
>    JCL> statements, etc).
>
>    JCL>   Ability to filter on line length (eg hold for moderation or
>    JCL>   auto-discard/reject).  
>
>Some of this will be added to mimelib when I get a chance.  On the
>...
>
>Also, just some quick thoughts on de-mime-ing, which also address some
>things that Chuq has brought up, re: regexp filtering,
>auto-discarding, etc.
>
>I'm of the opinion that regular expression predicates alone aren't
>going to cut it, and that anything more complex is just way way too
>complicated to attempt to expose through an email or web interface.
>Complexity is already our enemy, IMHO.
>
>So what I'm envisioning is an extensible architecture, a la the
>message pipelines, where each filter is implemented in a separate
>Python module, conforming to a particular, yet-to-be-defined API.
>Mailman will provide a bunch of canned defaults, like
>"strip-mime-leaving-only-text/plain" or "match-vbs-attachments".
>There will probably be some kind of mix-in model for describing the
>action to take when a filter module matches.
>...

While a general and powerful mime handler would be nice, and is
probably the right thing to do in terms of the long-term
development, I think that one can get most of the benefit from a
much simpler solution.  A few months ago I hacked together a mime
handler with the goal of making the stuff that comes from Outhouse,
AOL, etc. look like plain-text mail, as well as enforcing
prohibitions on postings images and other binaries.  The handler is
based on the mimetools library; it discards sections with certain
mime types specified by per-list regexps, and removes multipart/*
wrappers that become redundant after the stripping.  Nothing fancy,
but it has cleaned up 95% of the crap on our lists -- mostly
text/html but also the occassional image/* or application/*.
(Ripping out text/html works because so far it's always accompanied
by corresponding text/plain, except for contributions from
spammers, the deletion of which is a feature.)

I was going to post the patch, but haven't gotten around to
upgrading from 2.0beta6 and porting the code.

I agree that the UI for list admins to define what to do with what,
is likely to be the most challenging part of good general-purpose
solution.  The simple mime handler is useful, I think, because
although there's an awful lot that can be done with mime encoding,
the vast majority of email traffic these days comes from just a few
MUAs and is very pedestrian, mime-wise.  Having a good set of
canned defaults corresponding to these common cases should work
pretty well.

  -les  les@2pi.org


From pisTon@iwr.ru.ac.za  Thu Jun  7 10:13:34 2001
From: pisTon@iwr.ru.ac.za (David A. Forsyth)
Date: Thu, 7 Jun 2001 09:13:34 GMT+2
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <200106070555.WAA12753@mutiny.2pi.org>
References: <15134.44739.463393.527457@anthem.wooz.org> (barry@digicool.com)
Message-ID: <2517EE44938@iwr.ru.ac.za>

On  6 Jun 01 at 22:55, Les Niles is alleged to have scribbled:

> On Wed, 6 Jun 2001 18:29:23 -0400 barry@digicool.com (Barry A. Warsaw) wrote:
> >
> >[I've moved this discussion over to mailman-developers.  -BAW]
[]
> >So what I'm envisioning is an extensible architecture, a la the
> >message pipelines, where each filter is implemented in a separate
> >Python module, conforming to a particular, yet-to-be-defined API.
> >Mailman will provide a bunch of canned defaults, like
> >"strip-mime-leaving-only-text/plain" or "match-vbs-attachments".
> >There will probably be some kind of mix-in model for describing the
> >action to take when a filter module matches.
> >...
> 
> While a general and powerful mime handler would be nice, and is
> probably the right thing to do in terms of the long-term
> development, I think that one can get most of the benefit from a
> much simpler solution.  A few months ago I hacked together a mime
> handler with the goal of making the stuff that comes from Outhouse,
> AOL, etc. look like plain-text mail, as well as enforcing
> prohibitions on postings images and other binaries.  The handler is
> based on the mimetools library; it discards sections with certain
> mime types specified by per-list regexps, and removes multipart/*
> wrappers that become redundant after the stripping.  Nothing fancy,
> but it has cleaned up 95% of the crap on our lists -- mostly
> text/html but also the occassional image/* or application/*.
> (Ripping out text/html works because so far it's always accompanied
> by corresponding text/plain, except for contributions from
> spammers, the deletion of which is a feature.)

this is exactly what I'm looking for (as a user)!  (I started a 
thread on it yesterday)
as to the UI, I see a simple set of options like
( )  keep text/html
( )  keep image/*
( )  keep application/*
.
.

as a starting point at least.
the admin can select one or more of them.  with all of them off, only 
text/plain is kept.  if a message has no plain text portion, it is 
held for the moderator.

maybe some thought can also be given to filtering out hoax virus 
warnings?  I've put in a regexp on 'virus' in the subject which will 
stop postings for moderator approval, but as I said yesterday, the 
regexp matching is a bit limited in what it sends back to the user, 
being singularly uninformative.  some configurability would be nice 
there.... as in, when regexp x is matched, send message x, when Y is 
matched, send message Y etc.... instead of the blanket 'suspicious 
header' thing  (-:

>
[]
> pretty well.
> 
>   -les  les@2pi.org
> 
--
   Living in South Africa
      Flying power Kites
         Chasing 3'6" gauge trains
http://terrapin.ru.ac.za/satrain


From barry@digicool.com  Thu Jun  7 15:15:15 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 7 Jun 2001 10:15:15 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com>
 <15134.44739.463393.527457@anthem.wooz.org>
 <18118.991883523@kanga.nu>
Message-ID: <15135.35955.641425.315789@anthem.wooz.org>

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

    >> The point is that there's a lot we can do very cleanly at the
    >> Python level, but that the more configurability we expose at
    >> the web/email interface, the less usable it becomes, IMHO.  So,
    >> I'm thinking seriously about ways to preserve the power Mailman
    >> can provide to the Python hacker while employing abstractions
    >> to reduce the cognitive load on the list administrators and
    >> users.

    JCL> One problem with this approach is that you tend to require
    JCL> list admins to have shell access.

It does mean that list admins will be more dependent on the site admin
for customizations beyond the canned themes.  Maybe that won't be good
enough.

If not, then an approach would be an onion-type interface, where
normally the list admin is given a simplified UI, but can drill down
to a more complicated interface if necessary.  One thing I /don't/
think will be appropriate is to allow list admins to upload or write
Python code without vetting from the site admin, because then we're in
the realm of restricted execution, etc.  Going down that road has
serious security implications that will be difficult and time
consuming to get right.

Of course, we /could/ target Zope as the platform, in which case we'd
get a lot of that for free...

just-thinking-out-loud-ly y'rs,
-Barry


From barry@digicool.com  Thu Jun  7 15:42:09 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 7 Jun 2001 10:42:09 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com>
 <15134.44739.463393.527457@anthem.wooz.org>
 <200106070555.WAA12753@mutiny.2pi.org>
Message-ID: <15135.37569.701158.69342@anthem.wooz.org>

>>>>> "LN" == Les Niles <les@2pi.org> writes:

    LN> I was going to post the patch, but haven't gotten around to
    LN> upgrading from 2.0beta6 and porting the code.

Please do!  I'm not quite ready to start addressing this issue in code
yet, but it'll be nice to have a couple of approaches in the patch
manager to look at when I do.

If we can get an 80/20 solution for MM2.1, I think that'd be a big win.

-Barry


From claw@kanga.nu  Thu Jun  7 17:26:19 2001
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 07 Jun 2001 09:26:19 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw)
 of "Thu, 07 Jun 2001 10:15:15 EDT." <15135.35955.641425.315789@anthem.wooz.org>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu>  <15135.35955.641425.315789@anthem.wooz.org>
Message-ID: <6892.991931179@kanga.nu>

On Thu, 7 Jun 2001 10:15:15 -0400 
Barry A Warsaw <barry@digicool.com> wrote:

>>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

>>> The point is that there's a lot we can do very cleanly at the
>>> Python level, but that the more configurability we expose at the
>>> web/email interface, the less usable it becomes, IMHO.  So, I'm
>>> thinking seriously about ways to preserve the power Mailman can
>>> provide to the Python hacker while employing abstractions to
>>> reduce the cognitive load on the list administrators and users.

JCL> One problem with this approach is that you tend to require list
JCL> admins to have shell access.

> It does mean that list admins will be more dependent on the site
> admin for customizations beyond the canned themes.  Maybe that
> won't be good enough.

I'd look at it the other way around:  Mailman then implicitly
requires site admins to be responsive to and handle list owner
requests in regard to MIME handling configs.  As a SiteAdmin, I'd
look at that as an unwelcome chore that some bloody software went
and created for me.

Consider a site like SourceForge: In one swell foop you've upped
their SysAdm expenses significant;y.

> If not, then an approach would be an onion-type interface, where
> normally the list admin is given a simplified UI, but can drill
> down to a more complicated interface if necessary.  

I'd be tempted to do the following:

  Mailman has a default set of configs that recognises various base
types of MIME objects, text/html, text/plain,
multiplart/alternative, etc etc etc.  It then presents a simple list
of these items each one with a set of four radio buttons:

  1) Ignore
  2) Strip from message 
  3) Discard message if present
  4) Reject message if present

You then have a small text field in which the list admin can hand
enter additional MIME types that he's interested in.  Upon such
entry they join the previously extant list of recognised MIME
objects list and also gain the above four radio buttons.

A seperate section would then have the following two controls:

  a) Flatten quoted printable?
  b) Flatten base64 encoded text/* parts?

> One thing I /don't/ think will be appropriate is to allow list
> admins to upload or write Python code without vetting from the
> site admin, because then we're in the realm of restricted
> execution, etc.  

Absolutely.  That would be bad.

> Of course, we /could/ target Zope as the platform, in which case
> we'd get a lot of that for free...

. o O ( <shudder>! )
-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From nb@thinkcoach.com  Thu Jun  7 22:32:03 2001
From: nb@thinkcoach.com (Norbert Bollow)
Date: Thu, 7 Jun 2001 23:32:03 +0200
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <6892.991931179@kanga.nu> (message from J C Lawrence on Thu, 07
 Jun 2001 09:26:19 -0700)
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu>  <15135.35955.641425.315789@anthem.wooz.org> <6892.991931179@kanga.nu>
Message-ID: <200106072132.f57LW3r27985@quill>

J C Lawrence <claw@kanga.nu> wrote:
> Barry A Warsaw <barry@digicool.com> wrote:
[..]
> > One thing I /don't/ think will be appropriate is to allow list
> > admins to upload or write Python code without vetting from the
> > site admin, because then we're in the realm of restricted
> > execution, etc.  
> 
> Absolutely.  That would be bad.
> 
> > Of course, we /could/ target Zope as the platform, in which case
> > we'd get a lot of that for free...
> 
> . o O ( <shudder>! )

Please explain... what is bad about Zope?

Greetings, Norbert.

-- 
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59     Fax +41 1 972 20 69      nb@freedevelopers.net


From claw@kanga.nu  Fri Jun  8 05:44:26 2001
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 07 Jun 2001 21:44:26 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from Norbert Bollow <nb@thinkcoach.com>
 of "Thu, 07 Jun 2001 23:32:03 +0200." <200106072132.f57LW3r27985@quill>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu> <15135.35955.641425.315789@anthem.wooz.org> <6892.991931179@kanga.nu>  <200106072132.f57LW3r27985@quill>
Message-ID: <20815.991975466@kanga.nu>

On Thu, 7 Jun 2001 23:32:03 +0200 
Norbert Bollow <nb@thinkcoach.com> wrote:

> Please explain... what is bad about Zope?

Zope is not inherently bad.  It is however a large and complex
product that comes with significant baggage, and especially more
baggage than I consider justifiable for an MLM or for sites which
have no other reason (or wish) to run Zope.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From webmaster@mrpcd.com  Fri Jun  8 06:28:32 2001
From: webmaster@mrpcd.com (webmaster@mrpcd.com)
Date: Fri, 08 Jun 2001 14:28:32 +0900
Subject: [Mailman-Developers] ¼ÒÇÁÆ®¿þ¾î, ÀÌÁ¨ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù...
Message-ID: <37050.603159074073600.144244@localhost>

--ufsnltbcmiqtetjk
Content-Type: text/html; charset=iso-2022-kr
Content-Transfer-Encoding: 8bit

<HTML><HEAD><TITLE>ÄÄÇ»ÅÍ ÇÁ·Î±×·¥ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù</TITLE>
<META http-equiv=Content-Type content="text/html; charset=ks_c_5601-1987">
<META content="ÄÄÇ»ÅÍ ÇÁ·Î±×·¥ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù,¼ÒÇÁÆ®¿þ¾î ±³À°¿ë CD" 
name="ÄÄÇ»ÅÍ ÇÁ·Î±×·¥ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù,¼ÒÇÁÆ®¿þ¾î ±³À°¿ë CD">
<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY text=black vLink=purple aLink=red link=blue bgColor=white>
<TABLE cellSpacing=2 cellPadding=0 width=459 bgColor=navy border=0>
  <TBODY>
  <TR>
    <TD width=455 bgColor=white>
      <TABLE cellSpacing=0 cellPadding=0 width=454 border=0>
        <TBODY>
        <TR>
          <TD width=454 bgColor=white colSpan=2 height=4>
            <P><SPAN style="FONT-SIZE: 9pt"><FONT face=±¼¸² 
            color=gray><BR>
              &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><A target=_blank 
            href="http://www.mrpcd.com"><FONT face=±¼¸² 
            color=gray>http://www.mrpcd.com</FONT></A></SPAN></P>
          </TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=21>
            <P><IMG height=82 src=cid:head.gif width=453 
            border=0></P>
          </TD></TR>
        <TR>
          <TD vAlign=top width=454 colSpan=2 height=80>
            <TABLE cellSpacing=0 cellPadding=0 width=453 border=0>
              <TBODY>
              <TR>
                <TD vAlign=top width=76 height=126>
                  <P><SPAN style="FONT-SIZE: 9pt"><IMG height=92 
                  src=cid:head2-1.gif width=75 
                border=0></SPAN></P>
                </TD>
                <TD vAlign=top width=377 background=cid:head2-2.gif 
                height=126> 
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">Ã¥¸¸À¸·Î´Â <BR>ÄÄÇ»ÅÍ 
                  ÇÁ·Î±×·¥À» ¹è¿ì±â Èûµå½Ã´Ù±¸¿ä? <BR>ÀúÀÚÀÇ À½¼º Çؼ³°ú µ¿¿µ»óÀ» ÅëÇØ ¾ÆÁÖ ½±°Ô <BR>ÇÁ·Î±×·¥À» ÀÍÈú ¼ö 
                  ÀÖ´Â µ¿¿µ»óÀ¸·Î ¹è¿ì´Â <BR>±³À°¿ë CD ŸÀÌƲÀ» ÀÌ¿ëÇØ º¸¼¼¿ä.<BR>½±°í, »¡¸® ÇÁ·Î±×·¥À» ÀÍÈú ¼ö 
                  ÀÖ½À´Ï´Ù...</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD vAlign=top width=454 colSpan=2 height=21>
            <TABLE cellSpacing=0 cellPadding=0 width=449 border=0>
              <TBODY>
              <TR>
                <TD width=32 height=38 rowSpan=2>
                  <P>&nbsp;</P></TD>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=20>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã</FONT></P></TD>
                <TD vAlign=center align=left width=380 bgColor=#eeeeee 
height=20>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">¹Ì·¡±âȹÀº ¼ÒÇÁÆ®¿þ¾î ±³À°¿ë 
                  CD ŸÀÌƲ Á¦ÀÛ Àü¹®È¸»ç ÀÔ´Ï´Ù.<BR></SPAN></FONT></P></TD>
                <TD vAlign=top align=right width=15 bgColor=#eeeeee height=38 
                rowSpan=2>
                  <P>&nbsp;</P></TD></TR>
              <TR>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=18>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã</FONT></P></TD>
                <TD vAlign=center align=left width=380 bgColor=#eeeeee 
height=18>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">µ¿¿µ»óÀ¸·Î ¹è¿ì´Â ±³À°¿ë 
                  CDŸÀÌƲÀÇ Æ¯Â¡</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=57>
            <TABLE cellSpacing=0 cellPadding=0 width=451 border=0>
              <TBODY>
              <TR>
                <TD width=55>
                  <P>&nbsp;</P></TD>
                <TD width=396>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt"><BR>-ÅؽºÆ®¿Í ±×·¡ÇÈÀ» 
                  ÀÌ¿ëÇØ ÀÌ·Ð ¼³¸í<BR>-½ÇÁ¦·Î ÀÛ¾÷ÇÏ´Â °úÁ¤À» µ¿¿µ»óÀ¸·Î º¸¿©ÁÜ<BR>-ÇöÁ÷ ÄÄÇ»ÅÍ ¼­Àû ÀúÀÚµéÀÇ ¼öÁسôÀº 
                  Á÷°­ <BR>&nbsp;&nbsp;&nbsp;(ÀÛ¾÷ÇÏ´Â °úÁ¤À» µ¿¿µ»óÀ¸·Î º¸¿©Áָ鼭 À½¼ºÀ» ÅëÇØ ÇнÀ 
                  ½ÃÅ´)<BR>- È­¸é »çÀÌÁî°¡ Ä¿¼­ ÇнÀÇϴµ¥ ½Ã°¢ÀûÀÎ ¹æÇظ¦ ¹ÞÁö 
              ¾ÊÀ½</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=204>
            <TABLE cellSpacing=0 cellPadding=0 width=453 border=0>
              <TBODY>
              <TR>
                <TD width=68>
                  <P>&nbsp;</P></TD>
                <TD width=385>
                  <P><BR>
                    <IMG height=177 
                  src=cid:education-image.gif width=377 
                  border=0><BR>
                    &nbsp;</P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=18>
            <TABLE cellSpacing=0 cellPadding=0 width=454 border=0>
              <TBODY>
              <TR>
                <TD width=37 height=80 rowSpan=3>
                  <P>&nbsp;</P></TD>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=43>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã</FONT></P></TD>
                <TD vAlign=center width=381 bgColor=#eeeeee height=60 
                  rowSpan=2><P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt"><BR>ÇöÀç 
                  ¸¹Àº ´ëÇаú Áß°íµîÇб³, Çпø, µµ¼­°ü µî¿¡¼­ µ¿¿µ»óÀ¸·Î ¹è¿ì´Â ±³À°¿ë CD ŸÀÌƲÀ» ±³Àç ¶Ç´Â ´ë¿©¿ëÀ¸·Î 
                  äÅÃÇÏ°í ÀÖÀ¸¸ç, »õ·Î Ãâ½ÃµÇ´Â ½ÅÁ¦Ç°µéÀÇ Áö¼ÓÀûÀÎ °ø±Þ°è¾àµµ ü°á</SPAN></FONT></P></TD>
                <TD width=15 bgColor=#eeeeee height=60 rowSpan=2>
                  <P>&nbsp;</P></TD></TR>
              <TR>
                <TD width=21 bgColor=#eeeeee height=13>
                  <P>&nbsp;</P></TD></TR>
              <TR>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=12>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã<BR></FONT></P></TD>
                <TD vAlign=center width=381 bgColor=#eeeeee height=12>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">°¢ Á¦Ç° ¹× ´Ü°¡ ( ¹è¼Û·á 
                  ¹«·á )</SPAN></FONT></P></TD>
                <TD width=15 bgColor=#eeeeee height=18>
                  <P>&nbsp;</P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD align=middle width=454 colSpan=2 height=12>
            <P>&nbsp;</P></TD></TR>
        <TR>
          <TD align=middle width=72 height=199>
            <P><SPAN style="FONT-SIZE: 9pt"></SPAN>&nbsp;</P></TD>
          <TD align=left width=382 height=199>
            <TABLE cellSpacing=1 cellPadding=2 width=340 bgColor=#ff9900 
            border=0>
              <TBODY> 
              <TR> 
                <TD width=197 bgColor=#ffb445 height=23> 
                  <P align=center><FONT face=±¼¸²><B><SPAN 
                  style="FONT-SIZE: 9pt">½ÃÆÇÁßÀÎ CD ŸÀÌƲ</SPAN></B></FONT></P>
                </TD>
                <TD width=132 bgColor=#ffb445 height=23> 
                  <P align=center><FONT face=±¼¸²><B><SPAN 
                  style="FONT-SIZE: 9pt">¼ÒºñÀÚ °¡°Ý</SPAN></B></FONT></P>
                </TD>
              </TR>
              <TR>
                <TD width=197 bgColor=#edebeb height=18><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;1. ³ª¸ð 4.0°ú ÀÚ¹Ù½ºÅ©¸³Æ® 5.5</span></font></TD>
                <TD width=132 bgColor=#edebeb height=18>
                  <div align="center"><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">\25,000</span></font></div>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;2. Æ÷Åä¼¥ 6.0</span></font></TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <div align="center"><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">\25,000</span></font></div>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;3. µå¸²À§¹ö 4.0</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000</SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=21> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;4. Ç÷¡½Ã 5.0</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=21> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;</SPAN><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">5. Æ÷Åä¼¥ 6.0 Å×Å©´Ð</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;6. µð·ºÅÍ 8</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;7. ÅøºÏ 7.2 </SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;8. ¿¢¼¿ 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;9. ¿öµå 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;10. ÆÄ¿öÆ÷ÀÎÆ® 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;11. ¾×¼¼½º 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;12. ÇÁ·ÐÆ®ÆäÀÌÁö 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              </TBODY> 
            </TABLE>
          </TD></TR>
        <TR>
          <TD align=middle width=72 height=14>
            <P>&nbsp;</P></TD>
          <TD align=left width=382 height=14>
            <P><BR></P>
            <TABLE cellSpacing=1 cellPadding=2 width=340 bgColor=#0087ff 
            border=0>
              <TBODY>
              <TR>
                <TD align=right width=196 bgColor=#66b5fa height=23>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt"><B>±Ù°£ Ãâ½Ã¿¹Á¤ CD ŸÀÌƲ</B></SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#66b5fa height=23>
                  <P align=center><FONT face=±¼¸²><B><SPAN 
                  style="FONT-SIZE: 9pt">¼ÒºñÀÚ °¡°Ý</SPAN></B></FONT></P></TD></TR>
              <TR>
                <TD align=right width=196 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;1. µå¸²À§¹ö¿Í ASP 3.0</SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#edebeb height=18>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000</SPAN></FONT></P></TD></TR>
              <TR>
                <TD align=right width=196 bgColor=#edebeb height=21> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;2. PHP 4.0</SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#edebeb height=21>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P></TD></TR>
              <TR>
                <TD align=right width=196 bgColor=#edebeb height=18>
                  <P align=left><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;</SPAN><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">3. ³ª¸ð À¥¿¡µðÅÍ 5.0</SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#edebeb height=18>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 
            </SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=72 height=66>
            <P><SPAN style="FONT-SIZE: 9pt"></SPAN>&nbsp;</P></TD>
          <TD width=382 height=66>
            <P align=left><FONT face=±¼¸² color=red><SPAN style="FONT-SIZE: 9pt">¢º 
              ȨÆäÀÌÁö¸¦ ¹æ¹®ÇÏ¿© 2°³ ÀÌ»óÀÇ Á¦Ç° ±¸ÀÔ ½ÅûÀ» ÇϽô ¸ðµç <BR>
              &nbsp;&nbsp;&nbsp;&nbsp;ºÐµéÀº</SPAN><SPAN 
            style="FONT-SIZE: 12pt"><B>&nbsp;¼ÒºñÀÚ °¡°Ýº¸´Ù 20% Àú·ÅÇÑ °¡°Ý</B></SPAN><SPAN 
            style="FONT-SIZE: 9pt">À¸·Î <BR>
              &nbsp;&nbsp;&nbsp;&nbsp;ŸÀÌƲÀ» ±¸¸Å ÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù</SPAN></FONT></P>
          </TD></TR>
        <TR>
          <TD width=72 height=15>
            <P>&nbsp;</P></TD>
          <TD width=382 height=15> 
            <P><FONT face=±¼¸² size=2>¢º ¹®ÀÇ
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;E-Mail 
              : <A 
            href="mailto:webmaster@mrpcd.com">webmaster@mrpcd.com</A><br>
              ¢º ¸ÞÀÏÀ» ´õÀÌ»ó ¿øÄ¡ ¾ÊÀ¸½Ã¸é, À§ ¸ÞÀÏÀ» Ŭ¸¯ÇÏ¿© ¹ÞÀ¸½Å ¸ÞÀÏÀ» ¹Ý¼ÛÇÏ½Ã¸é µË´Ï´Ù.</FONT></P>
          </TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=11>
            <P><FONT face=±¼¸² size=2></FONT>&nbsp;</P></TD></TR>
        <TR>
          <TD width=72 height=8>
            <P>&nbsp;</P></TD>
          <TD width=382 height=8>
            <HR color=navy>
          </TD></TR>
        <TR>
          <TD width=72 height=13>
            <P>&nbsp;</P></TD>
          <TD width=382 height=13>
            <P><FONT face=±¼¸² color=gray><SPAN style="FONT-SIZE: 9pt">Copyrights 
              2001 </SPAN></FONT><A target=_blank 
            href="http://www.mrpcd.com/"><SPAN style="FONT-SIZE: 9pt"><FONT 
            face=±¼¸² color=gray>¹Ì·¡±âȹ</FONT></SPAN></A><FONT face=±¼¸² 
            color=gray><SPAN style="FONT-SIZE: 9pt"> All rights reserved.<BR>
              &nbsp;</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<P>&nbsp;</P></BODY></HTML>

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="head.gif"
Content-ID: <head.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="head.gif"

R0lGODlhxQFSAOYAAP////z49vf39/715Pr18vL09Pfx7930/PDu+PTt6e7u7uLu
8fLp5/vn2//nztDt+vHm4OXl5u7g2fndyf/epd7e3vzWvN7a7bfi+OXW0vnSuf/X
Y/bQtv/MzNbW1sva17zd5K3e9//Mmd7Qy+POxdbWnNLL6czMzM/I5pvV/tbGwPDE
UcPDw9O/uPW4kMa95JzG58O64de4qbu9vb+13YTG1vmseZy+xsmzq9Oum/SndLGx
q++ib96pKb+nnK+k1fCaYMilRfaWVpWqrMyZmaGfn8KeTIKjtaSW0bSXjfmGOfh7
KJeHzKWMY8aJAJCNf/t1G4OLjJyFWP1tDY16yP9mAIl2xYd0w5V5ZGOCkrB3DoNw
v5tyUY10M5lmmXV0bnxnwFp2eHlrS21WuZRSUktkb15gWGZaTIBMfGBGs2tNCE9N
SldKNlg8slM4rlE1rDVESlkouz4+O0gpqkg0IzovFSwtLTsbpSIiIzANoS8NoCIZ
FyUAnQgQDwAAAP4BAiH5BAUUAH8ALAAAAADFAVIAAAf/gACCg4SFhoeIiYqLjI2O
j5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubqHAgK7
v8DBwoq9w7sXTGNtaVQvhb2+xtLT1JRIVEwmhAgv3d7f3heC0NGVBcXViibdCADe
hghjfPP0fHPag+fl6fz9s9ziHrWZ50ZQjHoIE1qxNJBPm3EKFKADsA6ctx9UMmYM
6E6jR4/fOAK49vGHxXAU26hcqRKMxoANYwCgV8hEnoT09KAYFHGiv59AU73AWU8l
EkJuCAqiQRTnwkpJ+RQEICBChAIFBjVsWo+jFa4InwqKCpbewoNgZQKISmPmvG16
/+il2XkBDL07+XoG3ct3FJKyfJgQejPvzVKic9woXvxj0IUYkE8iOUo1WlTDVCtE
iDiIbNnBgOc1HkQ4NJ/GTMHuBDBnXluag5jQw9yZXlsACjYXCNC3t+9MX8veFlSa
tiB6ahWl5jq1XGkwggp40KyANwAwbu7My7O4+2JCKGjQuELeivnz2l0PfvMmPdjh
4sVDjtH67fF57WATt13oB70rgiig2Tm/FWggJBfEFx8T5tUzHADFFYIcIeaBsdph
YE2V1X58AAiAdJpFYB2Gc2hC1oWOuNdOIvWsNltpfIA2D4ojmSVIBB5s5tOB6ezI
YyL7IFLPGORtsUV6YxQSF/8fyZlAj0g03FEfH3ekcZ55lBGypIcKeJBjBBMtR8gF
abgBXT6IIDAfffRk6Ug9hIzB3htT0jMVUYRsQU+ShLiHD44VKLDbj8ZMYMGhg/gI
iqKpMDpOIo/9BZZYY83jjEH6EbIcpSzO81SXX161oZiDoNVcAQoIoidgU30okSII
0FOiICiA9ZBbCY25JB9WiPMDjLcCAOhVIxIKjBJVJHtIA4c2AIChFjgrwhTJOtuI
CM2OQ2AhzFpAgCFBSkKABYbogwg6CDBxRZnuAcZpaZcCgBaTMTy46SHjGWmkjbhN
Z9W/GMYY2zxpELLhqoANwsLCJ5zgZQUQpyovPcEul9D/HG2ciRNehEiK2IqC+Lut
sccmW8UhNiRrAwDIVqEDADqYLIQONOtgw804W8tysi+7SggBNkBhchVQuEBIOTgn
nTS2h5I7iAUmKwGRROFWFnBTeWR0Hj1UDIIADfWNQQV27doXcNfz/UAejGEF6O9m
VgVMyBWeHpIGQt6JrZHCDDvspZcS+zfPmQAIbk8MIhFCzwuyOWTIDzclBAbIgwxY
NcmzWICz0DzT/K0gMbu8cxUiACDC0KijrsEgLff8qiATcJ66Ep8P0kDquCc7BSEa
RD2OVSM/I8gFG08Z7H18dM1hWRxfbRqvblMX0Yaxmg0A3dAbAiOniSzMQsN/e7kh
//bJD0J+wWPig6s78xzfMXZujMGESCBb9Trmt6Scu9SDhP5yyxwAAAdylzqdtc4Q
E6AWAfk3iN4REHUMFKDvMqObYiWKNGC4AhJoEJB5uY9rpAlNqwBgsY3NiT0g7Bd1
fJIpeVDJDXogHIQmxIgI9C184hOEXeaRJfLdQSWRcxzy2CdERYSHQYqZR0Ai5ij8
uSJ0uAvgIHjAs9EFcIDJgoIStrhFHciOECbrGSGWYDIo6IADGqCiyUo3CAJwgAMu
qJkcdSCECQoCi1XgXwFWWLXLDcJjMsSV8maYmPhpbT6Jcx4fuKMYMDwIV6Pp0gol
xEMwvGFXs9HSnjLShu605v9WBWiY30JklQpEA0bJcSFRgkWToRQRAF9T2xiy05Tb
QOwqfnRiKzQgxzomK4IAUKMWFXjFMBqiZScbhMzeOAFBuCBqtXuWAoG5CAdWQQiE
wCM1zzWoRASnfIqbxyAd8ZgLLWecneLDpSSpI4OMoU5NGaEIowM+f0UkImBaHkfY
lpBWtbJ9g0BYWXQiiFsGT5euqBoydSYINapOEDI7pu7ACEFBtGwK0QSdyRgxAQ1o
AI5R05k2HYEqMGEFK/csBAIS1ybwiIckVFhJEKUyiHM2YnE3smc0vokYZiABRfP8
EPgCRbVebIs85CGEusiTESR0AzIX+mcRDYcQjLkEMoX/qECO7ofQhAbpmclagiEc
OrTVAWCC6GhZBGdn0V8ewpoMPesDyzoIPC7Bo29Eowaa1swA5UaronSYxBKBgtIk
53mtsqnXIIMESuFUWDrFFD3y0IYxWAFxkJrTSqZ0h/NkKQInsFwuKTGnlGSspnp4
Qxs0iNlFPIxqXX0FqgZLAAUmSwjRJKvJnGZH1rlVmRUdHTZvFA1rmhW4c02W0ySY
3Dz+7l9eEqWXIjC8K2FJQep73qxIeBeV4CScTCroLV93AQ3SgHKSUCX3CkqsTTQW
qVdgwpqSMzwjbXC+8ymEBxwWqG7GlhWoIgQyTbYEAybLBRYgYxWcNk1DKHitBz5U
/1/VeojTJSuaE0CdFrmohKSJtLmiE28pcTgdRSKET7iqxw/HkJ7t1jRhAVMLxKiz
oUaY4AdWcFMhiLedFT3GQ49AgdpGU4B/3fN1nvlungCjlv3yF7b/BXA5LEw0205h
wslaXcuc1jIoGEJmfZXrggvhyyrEFQAK9nI2e7sIPM5VjAAg5YwhVmLuckUsq71C
fYLVEPfZGSF3UAx5srQcGY93sIa4AI7TUKcRFoIKdwFDG4JIo5osuk5nKgDDwmcZ
sBRCoE0JiJO3Otooi6Ictd1tAxR84NGRi3Nc3ijMtsjqKqwMosotBJVp18Yyw5m5
zhXF2/5F7IDBV888NERU+P8M0B0PuhuLKLR4peeY8cySKy6GJQ0aO9OEPEjIVGA0
VzCj6e/5zQMbKs4VzuNCRyeIBmtiQkbgRE+H4dLUrChHmXkwRZMZbctixrKyxIy6
W4vZaTVGphk5wAPZQeFz0XAoFG4mBA4rgVrHXURHaaYEoQ3CniedrcRIVZvwFmLZ
g7hbESswieWsaMabGSxguANkAICaKNwRCWD0kAbKlLue6OZQzU3lCCfpJ5QiKzW+
P1FcAut6CsMFuKwBUGZcp87gu73RIBJIwCvzpKEgzngDNWADHnQ8dx/nIzSwIrc+
KTE6G4pK8yBdxBwxohe5aXucDx1CnJjpp4egO04yhgT/9YE3IW+4wg8Sp+l6QuyU
dRsE3ZXH9pGsqztl09CTm7j0RQmCAEBIVpht59sqrG7qUGxmzd4odjGbtQI1jh3u
ljB66gIg9M3NOBBsm9yP5yh46KjVPOarn6CvRT/BaV7Dbhnz3ERAqzjU+2s5s7w5
yI++wvuzPeQXr0RMaQ5gADwi9jjUf0GeD2NYkwspn+6yaJ7UnVfFPhrAxkSYXQnN
5GL/iIb/Rpjs9R7wMy5wdkugBEaDCEBgcQM2MzTDULiHO1tkAy6gAQxlb1xFFYPA
Fc1jfI2FVQZhHqMBACfgPeZGYtEHAOWVVCEzHfdkHUywBefFCEVGK20Ag+h1CDWW
/xGPNH4VUH731GlNoRZXsTyBthgeQWTTdYHxRwqO0gBzRDMi4FFSeGaPUDPW4gEs
EICZcDsThQhUNAVdNIEZZQgWGCTlwBXBcgI1dncjaG5AZ4IshwjTVx2NIABFhiNe
4gh2+Hz7tYZA8ldO5je6gRXWkWQIIYQbshWCoQjS8XtKt4SbIACCgghuRkAHiAgT
QGv840d2xwhu5AJAoAhlZnAa4AJSBABUuAjg004GMwjWZV1ZElp+mAg9KF0mSGK2
Vwh42F9Y0UclBX1/I1h/KCDAuF+wxwu/iEPS1V/kIAg49orn8XEHYyeQ4RGSlmnT
dVCQeGp/NWe2p1u503pr9v9bwnIIcXMIn2h2vHeK3DI0ZsdqwwU7FxdiRyOJxChd
rIgmjxBKWUhsz0dK/1KLozRn3hiQgeKPoJWEKIVPxEZnt7hfHnBk+DRnJCZKBfmP
D/k3fGQ1jxCRqlIWoJSEj7iNmCCJfChKtjeAHCY7dCUsgRWHBOB0inCOAmQDCch7
qcOOz8IBOjBgbFVXbGYI0ZWNQVJ5dwdagZWUSul4CGk/EjliSqmQWMGHGWmCUVmV
0ZWUWKmRuhEN0OAIoGV7N9dP0SGSJFkKdkiM0ZWLicBqH3dDyJVMMwl2ybUEQsCO
ILYEcDZSrsVf93Y0EhmYR4aUS1mYozSIIXdS5FBSWcn/lL2IKg5ZlRTZmOcGh5EZ
WIKSmI0Ic13plSInmBLZMLY3HkzlDWtiMGZ5lkx4h9B3jIowNG/phnGZVwzHA7YJ
BAeYkrmjRTogjgSnYR22XONYBWJlO7T5OX+jI2aYG1tpi1v5MJ0JDQEwndRJnckY
Pmq3h8WIncyHkNvJnQAZkH+DaAZDSkVVDtrZnCfAliRVhqqJliXFh6JyUsUSk+So
lHFJQPwWZ3dkMmCoAyIwhg7mnx0WoOfSn8klRdCpjen5nNNBkBDqjYLCeYdAjPnE
gwRpZNNzUhN5SxW6oQtZSozYi5eDd5mpmEaVmJ1IUu+5CmnpfIBli7ZnTQzknPmZ
/zv7GYcTgJupCJiDAAQ8epSCwIVzpaAs6F8GA4hYeWgM2ZQxZy6TEGA1pKEoSg5G
lVLjpw9WOhHwgz6gsEfEdqJTGZAn0KL5dqUn6XiCYE37KQBDBTE3SpwWd4BxKIPM
2Yd6eKda+Ju5Y6T9ZUHa0o0RKqGaqZlbagmzCBCGMD1Wyk1GWS5amk4CcwjcwA6V
8JKz2Ij7BSRfGQvv8Awj2SPXqZF3VHETNw7QSZOQoKqAiZHhs56zGKiu6mT9E4VN
41ECqlWBwigv6qROOaECUJ3CCqiL0DgPERzccwFjEER5MAYiEauN4Eomx6h+VA9f
s21YIlnhFQOvmAYn9K0fJ/9K0BpKDZOBkScJgvdoH8EEJ9EN+LAPL6Bye/KsxFqP
oXoLePePc5YIoEJU5NkI5Bem+nqLKCmwk6mMZSoJuioo9VoZhWqoFAoJwVEQwVFz
I9Ft23Eh91oqNGQ/I9MNDIIdmNQ2EzN81/M8g2CRNeWs+QA+5soHOvYIweFi1RMa
gXQdTeEm0YAEKwEGItGp1WCi/gitoDKI/wqq5FABJFiC6hlYDsqejACRf6oI1Lml
jfoI3WAShSBvVKAW2GMYLlRzHoMTepA4FfECN3gI83IbzycqgwBPXOEhy9EW5ANj
IphDHEJuy/eybfE1awIO13BBAOBCxlFCk1IIqkQUF7L/IYKXbPmwGw0LDCk6W8Cj
D9QJKluFUniokQT5qob5kBAaiJVJYhTpq+LZmCwYsZvAL0D4FF87Qx3iGLvyBj+w
bVPipZUCFrg7tyI2ibnLFXpAJLfBu+XlHkiFXx54t3W6HOiDdHHIu8wjuBEyCIWF
QmXhJlQ1BkgQA0hAFs0jMTwlGjwBZfxADoC4lCJzUlSJlVdpmeE5YqDbneLpnFiZ
j6bwHyc3Dx7yulEBZDsUu0hBD5RTNk6hKfyxd0SVcm4AT+2SB1BywLA7qapofAAg
rwGBdKPJH+6nj9P7CFNCX+6hY6q0GhuSIEggr80DPBurC/lKmaMErJDpoOCZoVQa
/3IwCqFheqITKcNJh5aDkB4WWxr7OzjHB8AR/DgQnGJNUXO8G2f2VCyqNAbtUBeR
g2J/diEw0ggQ6RiZ5HsZrB53ACM8B4vawiGOxgjucSE8xgc3iwCR4yGzSD4B4bGR
Kw1p+Z06tXbw676ciZASqaVWSrkaek+AjKZ4fIs0VseaUA6XUQhCLAjYsxBRkRwd
zLEmWwjxoX4t9WL4MW3KOQhLgrsA0DjN82cBbDbxaZC1OFiJOxzS8cUmhytn/Lhm
HAn0FjDDwcgEEx3sKXx8YEuWsxcmub7jZS5oaro5LKYhd7WgWqjMLKuD2sceu8KT
oMt8YBiEkVpbAsk4Qcnbgf/El7wIqkRfJAdzegFL9BCCwyPAnCzBZDG+gYkjDsPF
9ZAH9QPLh6UUOOiapdFZGaQwjqcZLyvB0vYhuRgVGmIIjcMHqzFe1JwLxxymUOqw
nwmaVUoO1PkI0jmdi9CrgyyYJGoK6IDQEcwvdUtDg0sPiygICDAlaats9GB4JAed
WLoc3YfOltLOpyzBiIAjrJwQuPu8KE0xUzORLNB+CME3lRmHvnw8y6HOb0vEH1II
SLAkeVA5TMQXk0vIE50oVvvVqssJk/uwh3oKI60UlmS92XPS4WwxvYIASOAeMhTQ
B50pNld89kR9NbvSguAxIENyR8wIdbrGUrLJGPhnHEH/1Jnxqke9PPpxQ9MVMMdT
s1YcMD73kQgxSAsLrf5gtdUwrKDdCmdNU+D1FP9bD92XuBeDXiM4VAP9aXgtPYOV
HnmgPjSwJC5mODISGOehL/oyx4OgSoU3WYkD2IotAMEorhzSBlrDNyx4P8sRSDDi
JrfdY1p310NCCK/F2WbqRKPtaOmcu2PwAvVx06ptJzfY2vz1su6DML5HVFJaI9sB
BmDQLurs3n33Hjt2F4Kw0Nlm3M0mAPKbi6WBTlONCEgwJzpmMdp7wvWQHGKZE5TS
r77b3VH23ZSkTrnbNQ1x0yNRJ3MgX0yAHXlgSyUYh2vc3nhttDstObBtPfxEFI9E
/z5ZshVMnCmKvQgFDglCti6JUQinnRB8bXvvRiOauqsWbmro0G4ZfilRweE5DQ8x
wGhugLEm7jcjtyfRgdmTKpVGiQDymhN8zeWEkNYs4QZpcGz0sySl7Mb0cCEeA15+
dghLYuBjwq1ykhClLAgYOw96QAgCnQiaCn9J/l/oMLOQoS7jvOHrMzxjc0ll4SEJ
yYLOyC/TSNoAIJJ4tw8xMEuKMT+H8G47GAkIo2Pzcgcrgt/IM0LX2liJLU6YvAV5
/hkZfhN5EDmtsof8ip1/yQohIAgYQAjB/uuEQOyFHgqHnha5Kxj6wdZ6zgwxsCIJ
qRnRQD6LKDGr0iqabpJ+xP+tV7IFtRsfifQICMDmh/C/fKLquMJII/vLL8sprBJ+
hoc8t5LjW47dmIHcy8iwvm4Iwx7swP4AD1AIIHDsnpDsXKEWk9zoJ7tKaGuOoWUV
1d6xmN0c215krmkI4ZsQ2KcICaJBle645RjVbEzmA11LLzvmBNwmlZbh9d5shrAq
euuDYb0Jxv7rvy7wISAAD4AAOw8AAD/shrAA66uR3G3w9SgIVlBIh7TQCm+y+iE4
VXJZKWQI086K8qoW2K7PyE1qV7rZnbrxhwgpeO4ZtHEB7aHduYgCedBD81DKZMse
GcQEIIPSHAJ+SKBKjODLdzBv26ESjibz9aaQHH0KNy//CL+OASHw779+AAIP9ABf
CA8wBGEAB3jQB32wB5qPB2uwA4ps8E2kJpCxIguvH4qmc7CepLUYWfJCHq1y6Rbv
9fm6neD79seWKQki6zFeD3++DYMAWo09PHOjz5AcX6O/CDQUDbVLIXYtidFgSe2u
ZII+VBOKCsSO8wBw/dmP/SEQAggg9Iif/QhwAEdgB5z/BUWwAziw/i2wA2FgB52P
9MRQ86VvPYaQQhiPupM0foLA5FSRmoAAUKAQUeFx6BEBAHDFx+e2GOnIFwlwN4mZ
yfd2Vel5csJy4hnZ+EiKmjoZs1iQajV5sVho6ArwppnriJDaeuJREVEg0FtsfByy
/5i8nAzwAJCcAp1ycKCsjLAQZfe1c1Kh4BlQsXMmt7ZzrL7O3u7+Dl8pUDAsYH8f
jurmyDpZPEmlFSJQvxIpOEiMFL1FuE4BEHAogoKEDwcVQqSIkSNIkUxsrNRQ0xww
SFCQumfPA0EWHlCZ4njMHiFJ/BZVsOWJyqQXsw6dsJVGl6M5bcBQQcILQAWFoIAp
KBAgXjwMkZotgzbtgbQQyw48CIGgGYAbeL5UCIC2yBMpXdo2iVKhwpM1a4pIvYs3
r96YBS4iwhghcISolmr6sxl36aI7bdogWaRAZdOIwgYdfEqP3k+GHx8Ck0ixIiFa
+UzNiYE6BhNHbUBOujOGCf+NYhEI2rb9N+PLVoIljjb0t+WiVYuCB1tkpXEbEzYl
29rCZ46bMVSYvODZi8WMGSxE4Qa9dx1VrNHIc4XGDEAKrldDPABRRg4BAAMaJJES
ZIN+/V2kLB1hhhzphEdggQYeY1FwCnqQ0BUOymKFFY8tYlsvChB0SDCV0XPRbZsB
gMQWVrDiWTATeWKPRRItYoouAUXywxY0JFVMX915h2FwoGREg4MTFhDKZAuqVMqD
xd0oSkaoVEBQPu9UoN2NuAUzzIHFtIeeelhtlV6XAhyQBR0+RFJEfvuduQIXCyi1
hh04WQlnnHkJQAhwQzKoTiiihBaJALVlGNhT9yQoGUH/b8rz2YknzfPUIkgIxceL
6swTWKE4FgRMYsAp6QmQ3Qm5YC8eSHmCMKgUIFki7TDKJKlCSgSVnJWIld4NYdx6
6w3n7aplCCkIkMwTcowiSB1nHrtBF3YBkAQeMxAma7TS8lWnpgpGwCcpTNqG0j21
/WIiPfYsQmkEOt500qaKojKPLRc4CG+E8soiSCoW2enTbYiYeFBghhzX6bagLshp
JObilkhmCqd6iJPkpmiZpoZ4+FdcCElLq61m4GFGCEOY8UXIZthRVhg1oMclABis
HIYcGSzyxApoynymFIvMIEcR2U7Lc8+MjtabYIYE7dtlAjflYY6wjtsnnf7iS7Rf
/1Tu3HQ7Ucd1p4JxBapwtRoGjbDEQXsAtGAM/5V0UxIzvLaCOW4tGEJUWwlDFnL0
YQcdWHzxBBZPEJHDDiMoUMTIe9hxwzVcHRACBmGc0YADAMiBJht2GLFC5slGxcIa
URzac+jTQnxZ6aPlm/bAhb4tKLuMBo110p9V2cs969RGatbGxY1Zt/eiHnZvpvc7
McWfPb36ZL0Vj6nugBZ9UD0YAxAG3nRIIUUTWGC/PRZceP9E+E98cXcYMJhXTRhr
DDAAAMZuIHMdduGhhRP2q1GcGWaALnr/snaLEsuYK3n6Op5fdke7VLSLHv3yS9ie
Ai17DW+CB1FJ7u6UGN7Vg/9pTatW8iiDmcwEsE4fTFQD8bWvoh3QeRn0zQZtJy0Q
yEEO22sC9rjwve5JAQs85OEX/PaEjeFBV9DAwAMeEAY2DMAAALDDmbrwhSLQoQdU
7AH+ADCCL6zBYf7rYv9eh8Ldlc5f+wrX3Jo2KBKKkYMSxJrujFcxuAUqetKrndMG
WDHf2AMtfOzj74ITGIXdS2LhYuAKM6UpovXujHG6ATdysMMmcOEJOdAeFyTZvRz2
MGTCwsMHkrEyDJRhfQ0AwBrgt58z7MEJNEuWTeZSMC/KkmdgJGQG5fa6oAmKkSdR
USKXFhM1Zi1HiJTjZRTGRmPQyWtb22UxatlCevixgRr/TGPUeGc6cfESTkfwQxFK
gEPvRXKHWJCkFC5pSe31MHwzhMY9oiCHD9ysC/vhQRrq54QebCAITyBXEeQgnFkK
lJYCjFr0AGgZOiZzHSmi5kF5CUbnPQ+bIkTJOxo6vDo+s6AujFXTMhPCPfKRgdlE
JgC7CII97GAG3ztnOHd4Qx5OEgBE4AIbJulDvuGhDNNAQOe+kA/K6ccLcUCD/VjZ
hRn4Uw6xHKhT4QQxQZoURSeVSlQryg5o2vKWdNSmRfFy1Q0ydIFYdV23FgVAAfRx
oAWwQxE8wIVzNkEFLCCCJNlABpg2gQ5mcAAFnrCHPsR1k1/wwxAW8ZUs7EEFAGiA
/wfouQGixgGfWrBLAwgQAWE19amcLRAfAchHWobWHT+7ZjVFihYD9TG17lgtaztr
IPJ5QKZJ2MEWAbADNvjhezYUgx9yIAIRUIAIcthDOffmNznYYWXV+IAZ6HBZAlTg
DGtIg3XRoAX5EaAB7TsBG77AP9iKd7y0JKtUK7pN8qpXKifog1x4WwE50KEJSehC
H8SASSzslgLCFa4EvnBf7Y0PwJ804gMcaYYRzKJzJIPDEypAAPaxDwd4GEJ614vh
DMPjs2kdrYY/rJcvmEEFOSQCgOPKhT2w4ZzlpAMb+NtfClDAAU/ogxxs6Lc9RMEr
RwzBDc7x1nDMhwB9nABaVP9gjs2CeMlMhq1rXUuAKEt5ylI2gJWvjGUDUHnLRH6y
l5/8VAXgIQp946EU+sAGG+5hD5fMnm5VQAEJUKAD/JWxA4ig4uwF0QwHsIdXAHAE
ONjBDOmQnIRLOQAGnCBAy2qyox8tUC9TOcsJqLSlL50ABlSaAZzGtKc/beksW5nL
Xf5yF1mAhyJw4QvZs8MesLfm7GVPDH0gggPkLGc6+3XGXHAxG777hC+lAAPAWtka
9mCXDDAgAPWpCA6Ue1hIS3vaPINylCl9aU5rGwLc7ra3vw3ub0eg29out7kvjeUt
fzmC0dLi+JrQBDYINt4qFsNNaY0FCTjg1jPWd27NQAT/O9BlDXezyzMOsB4AHGCU
E9GfDyBAgAnswAx7IPSFqY3xjK9jtVW2crbL3W0JiHzkI8+AyU+O8pSrfOUmh8C4
KxBuCGRa0+gW9bpfayA58M1v8r4kGezAhjYF1g9suLVf900BBQAYHaSo8Q3C8oCw
AOADcIhCACwnhzrYYet2yJmpNA72sLfD2tf+OANCXnKWn5wEbGf7CNoO9xHIXQVy
r7vd7X5yD6hcAjHvNM0TYHMvF0gAdkBD3+4mBizsQQ6MhZkfzNCHIuxb3/v+Ah5Y
EAkPmIFYuNUVAhAQdQzcwAxn+IIdhnCCIWQhCjvwxsXFDvtpc3zKZuc2yVkOdxKo
/2D3vO/97lsA/OALP/gqAL7vd38CutMd7yznu7fLXXMsu1YvEegD30wvBt+uQTG/
OEE/d2CHJOx73zVWzCKi4IcvVEIBUWhcCBA+BHnD4QjjecCaYo///APA2lieOadt
L3Iq13bHJwMFaIAHaIA4IAMKiAMN6IAPCIE4MAM4MHzC53tuRwIjsHcjR26dFn0G
gHNSoQDWFzI8lH6RUAF+sAeVsAN7UALjl2qeUAGfs359kDjQcAA3AAdyMAMHYEQC
MB/6J4QaN3tSZmnbBgEBKIC6t3sI6IQFmANRKIU+kAM+YIVXiIVZ6AM7YIVc6AM4
sIVgGIEyYIG8l3saiHIk12qBmRZqelEBfRAFZPYEHLN+AucJdvAEKhAye9AC6mAG
ZXAeGLAANwACCYEBfTaEiQhpZGcAR/h/SSgBS8h2TwiFUhiFRICJmaiJSUAEnJgE
nwiKoSiKooiFSZCFEHiAxNd7breBzgcB2hYIADs=

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="education-image.gif"
Content-ID: <education-image.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="education-image.gif"

R0lGODlheQGxANUAAAAAAPf39+PgjaK3XI6Ojv8AM1VdWA4OhjMzM+7u7sTExKam
nzt/t+Hh4ephdb29vZmZmdbW1kJGooOEnYiIiLW1ta2trczMzMTDp3V0df///5SV
s97cz8XAkb6/31dir/4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAACH5BAQUAP8ALAAAAAB5AbEAAAb/QIRwSCwaj8ikcslsOp/Q
qHRKrRI12Kx2y+16v+CweEwum7mAjHrNbrvf8Lh8TsnU73aKfs/v+/+AgYKDggSG
h4iJiouMjYkQkJGSk5QQCxUVlpAWFgsIZ6ChoqOkpVgIGBgdFBAEkKwEeq6RhLWy
jri5jJW8vb6+C5YLw8TFxsfIycOczM3Oz9DRzZjU1dQKEQoLagQPGZ6m4eLj5GII
A3cQfOp7hhSxtvG17rG69ri/+b/K/P3+0gADRrP2QB08AhZYfSrHsKHDUAiCbfBH
sSIygRgzatyo0RozayBDihxJMuSDkyhTqlzJ8uTFCgsfypxJ81Q2BQpQ4nyAc6fO
/5M9e/IM6hNozqAtiRZNKVSl0qdQo0qdSrWq1atYs0qFCQCAEK8xa4odGw7BhZMV
FnCqsBal2rUWMOFM+2AtJpTTqLmNy+lSXL05LTxgq5fn2rcfWypezLix48eQI0ue
rMBCVwQGEIAly7kzxAho4769e5Kv4EtD66IlzLMuJtMVeqodzDZ03J1/qwElrBZx
haFagwsfTry4VssADGTe7Lm58y8IFPxGOX366rvWWWZXSZrxdu7aSX+fTL68+fPo
I1vQ3PVy2OfwnZs1/tQoVOD36etvan+////GHQNTfATKBxpS+OUn1VlGJQgBW09d
cIFg9RkSVWkJysZJhjkNA/8VMxBwCOCIJC4o4YkRvFfgijSZxR0EgimmzgI5sYTT
BR7+ZBgFFtSo0gUKdLNSBBYQEJt2wdCoY04UKOnUBeooFtslNfqY3pVYZmmjiix2
2ZCLQD0QS4893YZbiFYy9cACTe5E1DY0LtWja0TRlklRZXZCZmqGbaimAhPGmWZl
mQB3m5aIJoreBVx66ag4YJb2W4w85WifU2Ua8o1P2qSVwSYLqGRBJKKm1QqMlJYm
GIyXdthJbHMJVg8FhaEESSzAqZWmorz2qhijjwZbTqQK2AFBBkztGiafChx77J4n
2VEPQgQIqoAB3xjZEwQI6JGBIWwO9Y4aYjaJ5lGjEmD/AASyfYvtA+/ogZQe4dbp
6734/tiosPyeQWyS3dQnYlBpLaDtUQrQG8lbQbUSDKyVGRAMO3Th9A6bQVb7IMGW
tImTBZ9CkvDEREFScYkop1wVsP22LEp0UnLkzEXMLOCAAwXkrPPOPPfs889ABy30
0EQXbfTRSN+MmMzRKLCvy1B7gUA2nODWoyV7AgroiVx37XXXFeR8c2xfl2322Win
rfbabLftdtsV3Cz2219jsgDLUecdhovvjHqqwQIIgEEDDSTgYQSINwAKzgVwoPfj
pCSAswOmjOw05Jhv4SKICRlJQOCDR5DAAxH8VvoDZ0ye+eqLF0A5KdrQ+DTr/cIM
/1UFHETQQAAJBOD77wn0/vvwxP9+geu/04558sUXj/MFzUdffAIFp6g85NHlJ+F+
rg9VejB2lVSd+OLnu5jKVenegJjD8DIMzu1T0szElBAz4PV6m1UBQqH2ivNvPVmO
Aab1h0O8Ax7yKMQ9GqGPfFjkHxqB0owqgLgKWrBZEOheAyyIuINYYIMcVF/hZoc/
R00NAgOslrLSo4CbMckCF8iAENZViQPSbxi3WOAjGli/B1pkI+QL4gXqMQEIJMAL
ETjAAXKmgC5kxgAb2EAE9lbCvJmFTcvoVffEVIELfEA5GZiAGMdIxjKa8YxoTKMa
18jGNkYxihN4oxznSMc62v9xAxCw4xglQADFdYEDoXpeFxoQRQ9sAHVgIGEVWTSf
oGyvJ0CiTwEghpMDCEGJSpQAJjfJyU56kpOa/KQoR0nKUprylKjc5CE3MMYPRNEA
9BpkBzAwxAJMkQsJ2IAHPDCBClBxkS5DgAcAKTrQPCABEQDSBzUgvWYSrwDD04DT
lHMACUjgA9i0ZjWtac0PXBOb2/ymN7WpTUxmM5vXTCc4U8nOdrrTlBuQjroMMIFY
YCsDFuhCADoQOAPYsgu5NOQEEAkdYAbzAh0gAE6CQYEGVIBHC7hlKQqwBQ8oxwDv
zKhGN8rRjV70ohLIAEZdccQuCGAAA/CnFxqQAQYwwAD/jkukQVuGAL/pjgPIDMAG
E7C7cFBUC4QkQBzfKMY7GvWoRZ3jUJEqx6Ue9alQjapUjQojP3YBoRjgADRliQEL
dMCqUptp7UCogQtsoAIBUB8BEtCjC0QgAKP4aRYSkLBNSKhasejimqqlFgmBrxMK
lSCPYsEuQBUDAkC6BDGEMQwVXiAThoBVkYyENdM9lGToo4+Y6pKNLOiUcA8AUgFO
AlctYKOCJS2oWIWFgAC4NQAP7aMFREeACOjqAaUNhVyxQD1XvMNisojNQ/Ugsoy1
okk8YcesYGUQS+DEHbdikzsowJPYIrcgfIAHDEG2h/E4JrMEo25ErepabMTGArbE
/+0W3KqT3HZBkauVj06DZzDoES4BFxBe8EixWw049FCqSkltmjIewuwKwKpC0EoG
fBLQ9CiZEqrgYKISya1Fxbu96iLv3MtM3wUvAVv9QvA4zAX4xtczrQXeLUeXuGOy
Sy64bYACciqG/q5vKa1Rk05w7CsfYWNrQ3nk1oTMqcBQEpJBMh91JBqG/r7sxI9K
MVyJFIBmZQC/2YjAN/Di2tBCr8ZbkPFZztuAXW5wJ9bZnyWMApouNgBIFSAc4RKX
TDnb+b7GVAtzWeUmNsnCIDleySsIG6KWKFTJ0rkAGZwMESibkHlHLAjqgre7wtlZ
A0f03Rhs/NgoDkMDu+TpA/8GMAzqqMMOc+JEtRr8G1hNqhOp5cL6MpGBeBaEAQP1
SSbqAAmDHYklnUBVQXCck0ObL9GLLoujvSRlTO/Ow77THU8nGuaciJETbI1zAwzm
CgF3IlSJA6EIN/hmwl2AcM1c36gosIFVMYBHCg6tUn41l6SIaYWKQvamlb1sRiYP
NNRTR+EA9WYSm8HG0mlL6dxaGWIky5Fdg7jXprKaqtkJUFhrUvxYYamUMPRUaHLK
vRHdxWSbwsT9rkmzeaeB0jWxcM7ksKa5YOMD1qPXPsy5zpeRsLSw4g+FVcnHjdQ/
kWt85w+UBJPBwGhQoDzlM2k2LgO3wcISiS0UeCxPq0z/pCbSfAsRKPSaHlBmDyDO
7LGGT5U/NqcG4btBSWGLWKhXpKV/oen+gnqBpF5a33EAdBEwUo63IZhkggZKC+hC
f22LmxmX3cwGd06N2sKXUHlXYE6Re00SMAu7ewHvZni63h3Cdy0kAAPH7HClCye8
DfPW4IsXVI86LL0Oxzq3pRUeQ45iMDXY3A5HzormaRJ2S3he8fwe/XNKX+XCBQ6n
OIFAm6UTeeRrgfELJfsud5nMuoxqOmw9LVG0vX3EVR8UNSpYk3iTKvIMfyY8Jeu+
T658+DA/zn+fJVttexZAobUMsdcTsYFMEeABhWN4EPZaEQYab+ZWojNnaEcOPnYf
/+fxfjJBgLNlcqUgevVHDqVHe1nlO7vTeqAQgNmnT2DwWYNkVb3jBTOHaanVd1hQ
XihTF3NXF7WlgaTAgU3mM1vQMzSXM1kgV0CoAbv1M0PIM1gAejLBfOeWAM9HJPBC
UGdggmP3eLsUAIakS1hoZga4fdvHU2YHeQUIhtx3hmboAQmAhp2iZnEBLnFhaG1y
Phb4EHS1P8f3dfRXhSWoBU7GhETohzrTZJ+3hM3hhA2QfxiQVjmRh4R4fXFSFwrw
WWPIO2W4htynO7xTZmeHOMFThh4AV+JmdppYZqZ4Z2lFOAZYLJzgLZogLS2hDuxC
h/m0efLkiH6YfAAohACYi/8/mIRKGIhDaIhMV4hGeIjJw0wzyEyemAAckIy89VaF
84hZgH1r4nVglXbwgS4hAkB2whj8kXm1SBN3mIPzt4EluDM6aIRKSI1HSIx3Z4xM
+BAfWFoFFzgdQFcNiDiT4nXxCIllogCqaIbaKHloMRve5x16Vmo2UocOUY64CIxI
M5FEY30/NY8/yIvHCI/sqJEd2Y56iJFfkowy6F/5FTgL0HzYQGkTgotWSCM8FX/k
dn6cgS56IDEEYAefsisJA0vj8mtM4ZANAZHr+GRVqI4WCY9BM4zEOIhFCIjWt5Gd
UY8zCFfItDsC4DhptZX+9Yn+NWe8A2JgF4mh0i9HsSb/CeEXBkMmSmEXY3c74wh/
t1iUjXaUoHeRHCmVeimVeFmMfvmLeTkWVNlhVRk4WWk4ESAx+BVaCyBjnkIoJlgZ
/hgsb3clQskQRHmOO9iHj0hR/YWEgiiM/2iMgBmYYjGYM+d3AtAB0JcAiDVfOUU4
2lBMkSkY/VJhX2MiRKYUZxGXFziXmjkKPNiZRfmOTMlfpckZqCmDCdAB0INM+hic
jNdezzaNz+ZhmVZ2FUSKchaWoEaKnfhW6IcX1OAnMsIwi3GZ5ZCZYLaH47CUo+mD
xvl5QLOEf4iMqbmMhMlMUBiFFKBlvtSe1UiW2geGWoiGYKhLaahTYFiACrpLUUQ4
/+NZGe9wanNoaMKAbwk3d8ApoJsZH1ApkUgZV/hZkn13ohzQAaypj/8pnWQ5iajI
U6JDacDTPPz5YR92Zz01oUXSGwb2dgAUjrvhm3bYodT4oR2IYiSpn/kJhc8InaLT
ciPIjOtTUrVJOjAngmRnbrfEdTLmWomVOA5xFGzRfxXGY3QiXAgZlET6kEb6l0ia
pMq5pMq4n8FjmBzQALV1Eg3ACtrwiSDjdS/ZRYEiGH2qV2uydpdQAVfWIRTwY2Na
Kd9yQCDnJCmRkygkixvDphyKh3TpdHKqpPlZp/mZoqzZlfsVWshkkuSWl9gnmdi5
XwIJgyOYoxagU7pDdizXEP/oAi7swFjhmCQPIhorsaG26KnBaZShShbLuYxOOjy9
03qbqFO+OKCxQnagRmm6VyBVUidagxXFqp7kwJ5HKpzLOqejeqIz2J9ZSSTOFRjM
QHZUaILftgFdqDsrgi7t020cRwknwQrFFXdtOpRvOppxeq4tQqfq2mGmOmfSRmms
Z2nVigXTiSHQuqMF0n/BJgvwMl2+RV2d4gpTIa7jQK5waq4Ie5oKW5XOmpXMw3qi
GH/A0wAFgA1kFypKUhu7Y4ByVpDO8QBK5VR5BAl2lEdUlXjHao4eirIpm7DpyrIw
iKcOJR081wCi0Vcyhl6hgk8SsyexMZDbB1Zq9wGnZAH/nxRKowQBnaq05aqsTduE
K7ufojhLq4ejsBmTVkmzB7hB1zgYPcJy0bQiAUC2mMRN1eRN2QQBoORNG3AAhPtJ
apu0EWmaoPq2URe3qRkAfycA2gpXoiiQdyNqqWeCENIvj/u4HbVJkUuOBUuaB2u5
DNGs/Imn1DMp0pcNkuZW6nBEVjh7/AK0FsBKbxS8nNBuxNsMRTUBwVtUz/Bpm4eD
k7uXbgu7sYu5ngtXHJAKigM8JcV6V9lZezmddHGbH6Mp7dBFUHEs6qKp9TGwDGFb
hhC9IvlL1DuST0t7z5eKOWqStpWHvUuFj1IjANM+VNISi8UWozIoJCsO2xYM8quL
//XrgXHbYfgYft7XmLMWUQbbckXnu8KSfhRiL+FxlrUypHMXCQ/snhEswffbgtm7
iDkqofwZpa7LwW02gDiawzpMozHXwz5MV5IKXTCyQkHyKetyQPCmE2nhw0w8PbyT
LtL3qXkHCrG6w1Z8xVicxVq8xVzcxVn8gllAlf35jBXAYsg0xBhMPWI7sS03Kmpx
E1iRFjo6x3Rcx3YsY5LaXCokI771fb7mY5lwx4I8yJZwaNggxaFHxV68yIzcyI78
yDvsXvWouaBDPRFAK//VCVl3NxkwmcnJwb1WmcCGwYNcyoLsI3eBJ/F2KXFnRKb8
ynZWyAySwuhYBmEJybicy/+6rMu59YG8Rbe7ansjaDw+u5d62gqzwEORMFsh1MzO
/MzQzHvxEgvaoHGo4iMTk81B9xMQIG7Q/M3QXBCWEEm0/LpfcMu7nM7qvM5YXFrM
N6NUlw13xplZ0MBId887NyfVXCR1oGrfYizY7Cy0EgxLwST4nHMZmKx1OQbs3NAO
7dBwVXqWvLkY4GATBsDSOWMP3dA86SfdoRhEnBYbvcOIg8hlAF8jndIq3cgaQJUB
gHrPVszSGb35uhrFKsLizJY8ZqxjkUwmTQaKhM5c3B5EnQAAkMNHHTxHndRK3RU4
ytRGTdTtscNOXdVG/dRVPdUfptVKncsB4IR3mpXlJtP/5erTUcN77BAvlroSF/N2
PC0WZr200+uCjwzVUH3VXX3XOqzXSG3FSb3UeP3Ugo3FfL3IX72ksBUBiqhunnxw
YKdo4kCT4pB+asEKa/F2CNaQ7usQcd22Cw0GkGzXfZ3XTS3VXU3Yfk3aei3aUW3a
gQ3Jkwym+gWNjn19U4Svy8gTlFbSIog4+SVjDdiqDzEoq4wpjfHWNdHZJzvXAFXX
g73V0F3Y0I3aVK3ao33a0Y3V0s3FzCeQp5dVE1LGZ+FWZ3YiOBF5i6c7iEMpbLWn
cFZeFDJbN6YO2QDZkVoZmHpAbWceyE189u3ZlRsGof3ceW3VW+3U003ghf3XV83U
/1Lt2g6e4LCN2GQHhQOAAYup3jgBGrgrIeoVlRQrjVe5QWn1Vjla4jtFOlJ6FlM6
3NUVC/Sz3+B4YZvdEMq9wcyNS44M2KXd1NmN3Q6O4Nj92oO91EKuxRE+5I/s0vrn
U4+dN1ZyIUmhypxKFjdewzm+Bc6d5KTd4AnO5RK+4NbdxVxN5I48yZsLfT8GKPV9
Wi32ZZ985R9cKU3Sr8WAY7fSMe7AJkPc3zMh53pYywLeyEku2gzO5WAO5Fd86Gau
5Iuuy2i+mriVaI81JQ1WZW4VUSS2eP/dMjYZL5oasB43I9xmQ5Lo5zIB6J+c5aZH
6NON6F6u6I6+3a8e60jN1/+0vuR0OoMrul/NLZ2dbpalYS3zNuU7Bsg1/r7BjuWf
LWKMfNc8HtiAbddHHuQPfuSnzeijvdoOzXykM8YTwilf24+OyOlQXl0Pwn5tcdNV
scDkoOpszOpztcvSHe2pncv2Xu3U/uCQjtjn1gCrOYkySjZPyFOndbLw7iXYnAd4
gGqirNmckfCUO8WDvtIWf/FYzOQz5lkken3LPufUMTGEwWAPV+xKnOzlIPHS2+xe
gPEu//Ifdn+K/XwcoBq0MYm1XY0fT5luESYhzGOlFipuHK4o/+47v+os39wwv/Qr
3d2Eo6ICKSHezIcef+4nkdZ5ANCC5i7LFeXuPg4qP7//MiUGde3apV3U+57o2l3m
YU7VEL72Er7IYowNn5WavYOxZX30jkKmqEIM3ybjLuGjp0H0Ea/3x2nOOv7se734
X17k907gQ57rDB75jt7Fk2y1fYUaJ8IMku2qht8lqCzlmIJ5Jmzln7/yAQ7arn7d
bU/5jW7m0G7k2F7d0u74Z76ysJUB9qXeclbS66jyNT0wpH/cXy8OYQ/BLb/jZv/j
tV/rfr38Xf76X27g2a7rTxsAgnO9xEP1Om/1g1Gst3XzkIHqD3H8Kuzs6yzk1N/a
aj/Uzv/4r13Ulc/dCkvJgmO18JrQvVj1Z20Y0vItQEDILAiLDAVJqSgeTefzqahY
/zRV6xWb1W6xkQsXWwCPrwiyJpFWr9lrwBseb8/pCcA8nr/b2fd9/62vLu1vkA4h
ILEqYDGgoaPjwrEhocEy4exK7Mor0/MT1IqpacHCopSCoKLiAeLU9EFBFoo2dioU
l/PrbDPXyozMULhOL3CwcDhZmXiZDVFRgxEtkYNDLSABGrS3qtP323f0gTV2XHb2
/NyCvNZJigoc1JuM2xd4rFmtGLmNXxCvGCA5xPII85fsmTRGCSxE4CBgwAIFEFZZ
2LWty8V4G88wUbDAAIFUC1JRgCASgrgHFIaopPWOo6d5Y+rlugcmH6F+bgIS2keH
X6GgQHf67Jkz4aJoDRJhWP9QwVGaCJhC1ZsZE2sWjxUgnISwoCsFsGChVCiVzqUt
eFnBXOVSE9dNLjn5/NPZ7OBQfUX57j1GN0HSaFWYBhAggGrURIsZS9tiVSNbyeLQ
skrXzmM7tZLbRn67Ue4WbPl+6jtKFKAegXCOFTR0UFgAwYwCNHwoAEODBbsrNIBV
ap1FMJA5F/dohMDXrmMfiFziBILYDCdFznJ3q7gWt49BnxkNGHx48eMHyV6sVAPT
BB0qcIg2On2iCJSyOdZCPDtbjxaQHIlekj8l0olOJCKiO+e6tfKzYrv7ujuDvAgl
nLAZDWYjLJHDKlHgggQiiCCRbDzBb8GYKPuoHHfSigL/rcoULLHBLOAKJTTRKLwR
RxwZuZAhhw7L7akpLFDAggciGDGjErHaT5UHSlmFSFesa8KCr7jaTZWvJJIFOyU1
iDGMB73LkcwyAZPmwmkC6OCBBhpJI0QReUnSy42Oy+CII1iyQIiUKGMplejwDJSC
c7pUEkxNxBzTzEYdrcOxNKdK4DBK5oPTkgsuUIAqmuisExxxppiiiCLHYccJWB4I
7okluHxxwUStmBGUGvF5FNdH7bswgAp8xC2BVsgxRZYh59TFl8aUXZbZZpsdBa1Y
ooWixWq5XMDZbJ3tNAtZq6D1E1vHiDPXciXU5pfzrqAkAAxy04Ixbj9DNpcGNthg
/wJpq3VilX79XSUKzaRVsUWBDW6CCQJa1PScTWVxmEOIIT7OPnrpWRTUjDUmIykP
E9kAqjQa+LABBeZzxAIPFRjZU4tDiWACAgxo05Kaa7ayX1N01nm3Jyf4+WcDgP75
gia4MssVJ80a8mDMuLLZEi8usJRkX6eOZeoIHrhgPq6crJhBz7iLR9yNwQHAbJvO
i8CCAFaawJGiqRzSAktSZiICBcBW1GVQGjgAcE79fWpI3qSASosEuDJlgwMkOOAD
xwGXQIKiicwTUCW+WrHpd5SlAIEHgqWg5iGmTqVDI2ie4qO9vxTbQbLTZgvt2Ws9
DxsNWlEAjTWYis8KxloO2/+XvwNvYNUiS5FoAS8y3TsBkkrZ4APq7/0A++pF/ZcV
VJum5VBHSGqzlA8jmM5kJFaGIAMjLWEC2y281QBcT8q2PZTa8c9kNsNw02A/vpLX
J0gUCuMdYGWagloDpgY185mPgbAw2QJrxgHqEACDGezKcjYIFi1t8CsiQUJyNkiA
lK1hPiN7oArNx7UPaaqBCkhO/LQDOxlhbH++0F8Ox9A/AWSAAAHImzmm5osC+g1w
CKSgJYCzMyeaghwVeeIUn0iWBKysARyI4VRsxqfl9AyMu3GFh5zHQpFdamQLtMAQ
aNgtG4ZJdjw8mxw5pi5GcAAD7gmRer5xxE8cEIvvWxX/BC6wgPpoC5HNQt46PmKB
2+RmHaX4yjqegxkm1G0D62iAB4pkiQ0YwFefXMACOfAhCLhufvXjHx1BsQ84sBIL
PuwAtipAgFXV0k258KMnAGkzsxDpAm1bUANS4SuSXOAwzaNSK2xRyVpIYTf20iQn
28QBkRhJJHWjYAROKb838g0c94MlF3Y4zjLY0TAYFN+m8jZAJPXtj0kMpAopwcBG
Ha5DXGOgAj9UiZqRbIkjY13JOCS1rLnQoAHtZg0zocoziNOcWShnRC1kRw1UQ4++
S089XTc24tUriQ8o5QNJWlKTnhSlKVXpSlna0pJeYKFubCgOKQqGiUbUhwLoQG0U
/8YbDwXnSO/8KC566VKjHhWpLB0ZDJnaVKaycIXcROU3Z0XTmm7hpub0oTojUAEP
XQAqQrwAAXI5U3jyUp4BVeta2dpWt7K1jFCFYNQMqdCpmjWcV81EVsd5ITy6xxLY
EGIuJ+EhNVBiXkM1YFrf2ljHPtat/ZSrCy8RgVEuUarexOs3IKpXz1ZBMNnAACQC
QKTmXHFIELAbV7hplgckthtU5UIvIVtb29ZWawcjkja3GdNPDY+znxVuD9HZgSEI
8UNtI5I9tcbAkmmNdx6NbfGS2MDbXhe7a7WctdKRwt7e9Vh5He54s8CrClAgRFb4
nS5/i8TjZRe+8ZVvZhka3v/gkhe/oD1PA6ASAQYgAHlPQh5YpxCLoNr3ddR9r3wZ
3GDI+vassRMvKMhlLguHB136VQQD3ZYKbDz3jHkzn1CnC9IFOxjFKV7gKCCs2OFY
FQzfufCMxbMrxnCAKcibit4yjItdZgKQ/lTxkFNMkq6A92JxzISMadxk8ETKbRd4
SAdw7D4KdFW2wE2wiQ8wJO5+GcxhFvOYyVzmAZmkxSVO8oTJwGQnvzknaBospQaA
gQR0KFj+jMePz0DQKX0P0IEW9KAJTa3o1nfN94UQnBl9pooqwgMMANGy7ryYQ5J4
y/nNbyphjIVGf5ouFa0A1z7AAA/4hizJ20/yptBROLr/WNPD5bSSY2wQN/BENf1Q
zR/ksAdeu0YojDbPfPwr6dHQJ7CUsK4lMD2yRD4b2tGW9rSpXW3GfGiz9mDUX/wC
CFvz2i9+uEtd7EJuJ5snEfbyQLqb20+9cahkrpYwYfRlZnvfG9/5znfyoDiqft2S
e/1iQpYdyrFFv+bW/4CNTsB9F3GT2x9COU25EDFqmOUrerthG1lTtpuJlDXbyCv0
yElecpNjxkkUMIArqoRmWWTzFBBohUkaMups2+Tg3B63HSTOjF8/HOjdTjioAxOV
BggBKjXLRtQmwWGMXOGK+pb61KlOdVK4ol+G222BWTEWX9kcwTgPhq2FjheIh7su
/w0v96efgYZOug15vqnARuqhAJOEEe951/ve+d53v/8d8IHnO88CfwoxHljLYr/V
X9TuyqDsGu0D4flAfj5xXD0jDfwxJAGKFgEM0t3TBJi0tUlfetMnMgEbYAADJIC9
1mcPexP4ANAYMIHa1972q9e9qT3Qew9swPcbADn9Om2Fb5cd+WRP+/LLvfAmI8IK
K1GPYOen5egNP9bFkcDqHRe5JH6AcpBjAPhXX+rdn9/UwSzSvTAo6VcrGic69/Vq
jJGMhge9+URPAyLoUynkGpYj6uH6sq9EDCADLMBxKOdxWm/7tq/UIgf9ItADaO4B
7iUJEI/4aG0u5G/n9KIviv8C/4bO3JyP4npFyn5EN0hBmPbM00aJABfkA4TGABSQ
ARUQ9h6w/MYvAoeGBycAAwuuh3LuAx9u54ow+UwjEObPKHpNBJ0MEbIhAdyFo9Qg
AFsQ+14QKwJAU3aj3hbmMiyDCQAmHRimoDbFV95P28ZuGZAh11LDNUAQ4ZDwDc0F
+kpEAF0QCzlDCxfAuLbEUJbAfNIBaLZG5QxAIgxsPpoARPKmIdBQ8eJP/yJRGOpw
Qe7wCvNwI0orjwTgEGcBSqTCHXKPEA1g5QauZvAGG4LpB4uvCiTRFQeBEvPDEjFR
MjRxAGyJX9ZBET/EHSCg9rYGAkiRaS5ja96nEYMHCMH/AKJekRnbIBazowC4ZQBp
MStKy0DYwXsMbVM049+g4BhbMRm5YBkJgvJw7Q3PUecgDtjckDUqrx3NUfImT+3U
4BmLowA0YhqpESsaB3LoQxh+7wE8IB+45gouIBy3YByHQQkTjg3xIB0bsgnzTyKN
UAQXkh7lLSYcwAGgDg/1MSYmYHIwsgquxwNeBvE0khV7ByhKgyHXjiKFDiLjsS88
cASPItjMbf9EciMMslPy0SPjIQD48QP80RB8T3SawWSM7x5T0v6QzyJx8iU70NuO
UConUvmYbw3q0R43shU78ifBQXGoSCwpSYrGcorKygEOEiGFEDU60CZ7rf4ccvJa
/zIq+UAmR1AO21Dy+EErOcMgudInv/IbTg/arCAts8zg1DA1XJIZPvDWGo8uHXIe
7RIJAYMvdZIj0tIBsMErBfOzNDMmEvJGIs7nqPL4ipAIJa4N2/IiQSUtC4ADOtMz
ayoBNBMzE3PxVlIvXYki8wLt8pI15BIrzw4qGTMi+zI7arMAHEBTZrOmquE1EXOV
FFM4y+4me7Mtn9Ixx80i7w8eg1Me5zAnN+YCXrMAzhM901M915M929M93xM+41M+
55M+63M+NVI67YctXRIi3bIch7A4IxInU1MQrlMZLnNjEgACMNA5G9RC9vM74xIv
41AhKfQqq5MlWXM8NSYwHf/UOUWzGZkROfOjQz3UM0E0RF1xRJNTNk1UMFE0RSNx
RYujRF30J2E0RoluRjmjRm1UH3G0OoEzLklwNSNUHf/TwnZUMnrUR2kRSLfTNILU
MRfOQCOTDm8TK5i0SfPwSR8TNR5vNWlyJr90xpSULbR0S1+wS7lzKn1CQ4GT8ZLv
55IUS2MCTdM0+7pUQiW0KcHDO62yBBO0RfGUSyHU/ngzPMWzQr3UKIzTURCgEhSI
yPLGEsziEglVTQ2VNEgDUXM0K8/HhDjn5FKFK0biUjE1TzXV8aQ0Ufn0UIu0SCkO
pibJLGvVVnej5QYVVVOVOtPRNH9TQA80IkmQTBCACDL/CFmTVVmXlVmX1YNkzruS
SlqnlVqr1VqnVa6k1UjU7wEgys3eNEAVDkr71AiJVUcQoOrszfBQwiQCzl3fFV7j
VV7nlV7r1V7v1V1JYQNMSEtMAs2CxF5NJgM2xQAQAAK8lVwjVDXnMEMtNFFnTDb+
bFQFRha+giWOwAAoYGI3lmM7dlSLZQIoYI1UISQGRWNF9SU2jiIK9mAzwVMl0ULI
EC2cimZr1mab6l+kYGtulmd71meb6ssmxgutRWYXRmjHMGi5q2ZbCIZWhSyKJJhO
hRV+tqkawkkwaAE661tf9twspBJE5hLIKKrmY6RO6p/ONmoAaoGIbYXSlm3T9p/a
/1auzhajAGqFDsuB1Mq7timg9nZt9Vat5CYtsEgq9jZa3dalYi6MOisauLbR0CSC
LKJYJqKSPK4CN6AJPMAJ2IQUVEGGHGAcAKU5osMskKBKlsOLUoIkXOWXHkAjm2Bf
qaQUHiBkNTaDVkVA7uVeFED1FgBhYkGEgHZBGaYJYIhIOIBfdhasmodhmiolyNB5
82ZTgHYBLgADtmZqNYU/LOBe+AVKvOAUJAamumcBJsAVVGFxuMKE+i1eL4BxG9dx
uxa0IsABAGDlMtYAPXfUOkBjVY8BKtADdgMDIIA9QAIBbCkDCoBkEQBdTUgshGAI
lEB68CQDKoCBNbZnXHc5L//3ACii90yBgUNHIx1gAT6JAi5gAyhnAipg9WRuYArW
WJFgCWrpAiaAkygiiiyi94SgUGKBN4AvOFyF81TP7lgCFwkJ+FYCAZimFdxlNzIW
YcaHAdaBFDklag4WAJaHaZqkAjaAJUCCAjrAlgqRhQslYUhCY0U2FYzkfVsxfiG2
DBpgAhCgZF2BCGa4dB/A/B7gejdgATDAdA/WWGXIEEGCFGnXCIggJMICCRbgPNuH
FDV2OVxXI7v4cSgCAibgKULYdTvAAfgjY7nXcTKJATbAhUeBgsHChJpgQYGvkXRx
VVDYjzEIYRhnAwgsioZ4AyaCCJSAK2rYA8bKAIqECSDlYIDNtyvMAY29KJQlFQIO
wFgrIhYoYhwsQCMLkZYL0QIY4GRXgiRsiYSgtY3f5I11BWwQoIZLxd8Upmj8mJC4
N5grcGAw9yNSoqtG7SN2o5CIQAqSmSsoYiK+ApkGYGsod1McgEMU4Pc2hSwUIGRv
WYxkgZ67OJMiwF1GrWmTgJJ4Jp9ZzomaIzmEJJKUhzd2pqe6Ijg4WoyKZGeeonw9
2hS6IsAmBYLGqlScyE+KhguhxCL22QmM12QMKmIaYJx31SZCGKmTWqmXmqmb2qmf
GqqjWqqnmqqr2qqvGquzWqmNukSCAAA7

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="head2-1.gif"
Content-ID: <head2-1.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="head2-1.gif"

R0lGODlhSwBcAOYAAP////39/e34//T09u/v7//nzvfe1v/epd7e3r7l+dzc3Lri
/v/WhP/Ozr3e59bW1q/f963e99bWzv/OnNbWnM7O1s7OzqXW75zW/8vLy+/Gc9bG
vcbGxrXG3pzG5729vbe3t5y9xtatnLW1pc61Wq2tra2ttZStpW+0yc6clKWlpWuv
1VKu70qw8WOrxJycnJyce5SchDyp6mahrbWMhEWk3YyUlJ6Ok06f1DSj7WaarX2V
oKWMYymg5zOd44yMhCmf3nuMhEWR0kGVu4yEe4SEhHGKhxeb7BeZ7AWb/gWb/wWZ
+w2X8AyX8gCZ/5R7YxuS4COO01qElHt7e3t7c3t7a5xzUntzc1p7e2B1cntrSmtr
a2trY15mbGNjY2NjWlpjY1pjUlpaWlpaUlpKY2NKOUZOVEpKSkpKQkpKOUpKKUpC
MUJCQms5ITk5OUoxITExMQY4VSkpKUohCAYuRCEhISEYGAgQEAAAAP4BAgAAAAAA
AAAAAAAAAAAAAAAAACH5BAUUAHkALAAAAABLAFwAAAf/gACCg4SFhoQEd1tTU0R2
KoeFY292Y2t4HJGFKnARABGgCQILmqWHdmRFU092maYqeCkABVNopoIWd3ZsJ5+f
nre3CFdwUkVXrbcbdgAHBSN2BMJ2JFp3Hr7Bph9ydXV2VyIbalTCcBsF6XBXt1dy
BwdadhcAGNqaH3UqBAQIDc5cytwiAIdCugIiFJWycScFAwYH7oTIdq/QgzsvBhEo
4EyEnQ2mCMhBlw5AijtTpBVCIEcOCQYTYKoJ4glYxUEg2HB0RuKJgXRpxpji8i6d
swIU0NTZoqJECRVi7mg50GDSGxFaglC8KSjDmQMTRMAos+bAzw1rziA4RODHHZIH
/w/CsLRmjRst6A6ImPOEB4M1WrfeVHCmwAQt3dAcTTfmjpszNghUULGlZYp0Pwtk
jsuZ40kNeufZ5CpogBwCEyYc4JHGwGLDH9zZqYNmTIzOHDdj5uxMzZMDZc5IG036
jgSwB2jYWfz6wIbXmKEX2BCDbpW48eS8YeOA9KEziuFNgPHPgHnX8Kg6O7rZtfln
b+RwoUFkDRqD6U5qrekdUZ0xE+hmlGsNpIacAQ0YhdsIT+xWQBl1mMWRHA7YRBxp
BNlhQwlaaMGRUeKlZiA86ST4IW4H1XGZOr0I1p8gL7BxBhx3OPOPYalpIKKJmf0k
YGdpcHHQGIG9aIocIuRGlf+IIpLIXDrSoAgHDUNiYeQtU3L0D1hMwmOihJphF2Y6
FHx0UBo2uHjlIFiksZ5rTKqWIJgoxrWBHF8cZIAdHaxZykUUrKeenM78RKdrChYA
Axdh2HHdQU+44acpXrihpVmYmlfoQdBlRkMYWqx4kBtgAKDSpN/lmamEi7mHm3Ml
6aZCHY9ZgKomcojBaWevGZrOF7PZsUYY7CVkhAxQ0JHmrYYgwIYbI+wqHWcjvIUU
DWfYES0McUThxLc51JERs4YUQRsRScbV45sI2VFCkrM48oMdTHxrLwt32EruSlu4
UUcaMWzwI2cxsOEYDOg8UUcN3zaxhL1diLFvJASYawf/HGN8oUXAE0ggggpEoIEA
NFW4YakBctihSxtI2IuDpBObQsUW/QZrRxqQAfAGF7OYCMe3QBxhrxM+wByzdxzo
Uka6BcAhxNDfJrEDG0f3dwZeYdymWR1DQO1EC3BAUjVpddzh00Ef2NED1CiYccbY
3rnBxRlUFgAAGFlAvYI7a8HN1RRqGDBLASXcccMMLujwrV2n+l0RARdbQcQZutQx
xxxvqGFHqY57h0ARYpxBhAQAWPBUCSY80PnqrLfu+uuwxy777LTXbvvtuOeu++68
9+7778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUV2/99dhnr/323Hfv/ffghy/+
CPjkl2++n4EAADs=

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="head2-2.gif"
Content-ID: <head2-2.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="head2-2.gif"

R0lGODlhswGBAPcAAAAAAP///+TU3BcMFPXs9Pz0/AUFB+zs9vT0/AcMEMjo/K3d
9AwUFBocHPT8/Oz09PT89OTs5Oz06PT87Oz03Ozs0vz85AwMC+zs3OTk1Pz87PT0
5Pz89PT07Ozs5OTk3Kysq9zUrPz0zMvEp+rky+TdxPz129TMstzUuvTs1PbkudzV
xNvEl8i0i9TMvOzk1OTczPTs3Pz05OnUrNzMs+zcwvzs09uoXOfVuszEuNq3iMq2
mtjEqvfkytWYSsyUTOfFmvXUq9zVzBsUDMqWWo5tS8aoifbVtNTEtNzMvOTUxOzc
zPTk1Pzs3NTMxOzk3OTc1Pz07PTs5JCPjtrZ2Md2LLt0Mdqldui2iOjIqffZvMq4
qMqFStiVW8mVaeeqedm3mffcxa1bHLhmKqtkLMh2OsqIV0s0ItiYaMaaePXAmei6
lvXKqfxsDPl+KfiIPNmGSsd8SLlzQ+mVWdiLV+ecZ+yjb/mveva4jNiph+bLuLmk
ldzEtPzk1PxkBPx1HMZnK5tVKNV2O7hoN9Z7RKtmOoNXOrl9VsWLZtabduarhta6
qO3UxFQsFKhZKsdzRWs/JicgHOW8pZZFHFwsFMhpN6dbNd99TW9JNteslpR6bPbL
tbCUhciomBoWFNTEvNzMxOzc1OTUzPTk3Pzs5KhHHLhXKtZsOYdFJZlYOlk4KNmL
ZoRkVYk1FKhKJdZgMMVaLHg3HJhIJmk0HZpsWHdWSOyrkaAwCLZKI4c4HLlaNVwt
HEglGDskG7GHd5QsDJc5HGgsGVEsIEo3McKYilJDPtzEvO3UzPXc1Pzk3HokCowp
DEcUBlYbCqg6HHgrFlQjFIg8Jax5atW8tcW7uJYwFYYsF2skEl8jFKA8JKRSP6Nf
TZVXSKprWz4rJsWspuTMxkgcEjgYEZdJOIpIOXAcDFQkHNSspV8jHBYMC9zExOzU
1Pzk5NTExNzMzOzc3OTU1Pzs7PTk5Pz09PTs7Ozk5OTc3HRxcc7MzMbExPz8/PT0
9Ozs7OTk5GRkZP///yH5BAEAAP8ALAAAAACzAYEAAAj/ABc4CKBAQYCDCBMqXMiw
ocOHECNKnEixosWLGDNqdKivo8eOHELOGxmlZDx6UlKOWskkVKglSxgpUaKnph4+
fCQtWgSmJ5hMQPPkMTI0DTGjSI36SsPJl9OmT51OiTp1CqerWLNyIraH655OxDqJ
PfftnNlpaNMaM6bOGLi3ouKug+Ly3ZMn9eTVS0mvb4cO+/bNEzyPQwHDHxN3DKDv
oMeNkCNLnky5suXLlBcnFjlyXpQOUVCmjLFy1AuXS44xkmkTpyQeknwCDUrUiJE0
uHPj9oXIqVNpvoFL00S8uPHjxH1p8nWVOVZfxLYSmx5W7FizZneqnbYWFNy4otaF
/4Lyzm5eD/L6qu9AQDDheYcPK/7IODHjiAsC5MfMv7///wD+N58+HBTWGWgdpDQa
S6cdE9NqNt0kiU6yBSVUGkYkgpuGaSDioYfSICLNISNKI003J9KiiYoqasKKizCu
iBxyJgrn21XU5Vidddidox1aa7H1nSjw1FXeXfJ4wNd6+wA2WGeGcTDglI0FaOWV
WGap5UMfScmZZ5/FoyBpoyDDBEyqQXjTTYvEVqFQt+HmxZwf1nkIIiQecgiK3dDS
Jy2ABsoNK4SyUkuhiCYK6J+BalKjib7Y6JuO04FlXVnYLQIkd8Z4B05c8EARannm
5YWSeuoFFtiThcUnJZWPIf+U335b1mrrrbgupFhIBZL0WQdixkAmE8iguRoOEWYx
oZsWFpWGF1fosMYaOuRxhRdm6KltN3p24+02RYAL7qCGcHOouYfWou666bLSTRo6
zKBFGDjMoEMah2zDzaIn9mtib5FOSumOnfT4I6fqqOMdePAUSeoH9USsJKp+Oele
Z/MQWACVuXbs8ccBNrZZgb3+KqZKozDRkrGM2JRFTm321GweaSSSiBd5ZNGDDPPI
4LMMNmgBhA6JEBGHHIUkbQk3qaTCdLnl1mKIIZhITQ4mVFetLtaHXBFEGH30QQop
JUVhQg8sILJNKtts46e3KPoboqTQQaejdQUbDKQxnyj/7J07cYlK3sN41eNBX+kx
qerFUc53EK0gRy755BKJ/JGBJIF2shQsrbwaI8jWpOyEMs+s4c3QHtGHDU3EM/Zf
HXSkgQUypKACECzogC3SqRgyjiHkkBMNJphcTfzxxJOTyiFrHKGF8yqEYQPrTUQR
T2EmBGFEvtq03Tbc4JP4aIi+2U0p3mVt4WNaCP8NeMOjklp4xPTII4Vf9AC2qmDy
xUr5/wCknOW6xJlfJWhBKTvTg0AnutExSyhCOZ2cPIQGNWxCC1roASmaEIOxkUIG
Y4tHPKJQgABwQAMakMHZbqeDaOmgBWrDBCRmCAkZQsIQh8DCEYKwCTZcMINh6IEN
/zxYkgLMwwI9AAIiCsEN7zkRfHATH4oiBZzy3W1HZUkf+z7RN4W5AxzuEAKRGgYF
e9jlHRFL4+HW055VySeAcIxjx0ZGspH8BSX2Y8lLUnOsBi6rdBDMA4fm5AUPmcEL
X8CDGtjABh46L4h9aEIy+sAEGzChBz2IpBQ2AJoTzk4GXrKAFq5AC6dtoxteUEP0
nofBMGQQk5lMgbCuV7YocMACKsjDIbTBy+458ZRQhNv4yucUYpiPOpcii/q22EVQ
gMId0BSFEMhYRnvMrx6oYo8b9SPHbnrTPwMESZTs2AHRqERle/ycy5bFrGpFsGaE
NCQizGAGNHwBC3jAghrUMP+tfS4yCM7D4PMCGsQeIKMPmGRCE0hBjxGGxAQiiKgJ
LGCCJkxvddOjXhM2yrqxyaADnpleMmSgAREAwQuHKIQ2LMHLbfjSe8Hk0zCr+JTo
5OgrYvmGTtW3BWaqox3OjOY0G2YPa9YDLx5Yo/6+ydSmZqY+GitZmBS0EmScZoGh
04MDwbCGnwTydPGcJz31ZIYrfOGsX1AEFu55T3yuwZ9s8Oc+fXiEutY1DEyI5EaF
ZdHp9cCV8xLovIKYjIV+0LApGWEUbBAGFfQgHre0QRYSkdJeWtalmP1eMOUWsPJJ
RzqVyqlOd7qFnqLlE+1ohxfDCL+iotFw6nGqbGdbkV3/Ye4zoinNVbHqR9J1NZBX
sFlYxZqtQ8QhDl1A61ntwNwv3MG5Z8UnFqQ7XTxYV65qCMJge1DJsP0VsIIl6Lwy
uVFSxEMGUfiZCKXQhL+SNwoolCxlCyGLcVj2sk+MadxqRMxigja0nRjtaE07DS6q
9pnuIKM9PlA4etD2wRDWlUe+9CvRkKlBn2uZ6P7YVSx8Vbh0Im62jvsIOXABDXVI
cR2Yy2LlttgO0L2DWhWRT0XOta7j5S4sM9mHMIC3ldLrqAijEMKSdAC9ZmtCCqaX
Ap7dsgdZuEJKxyGL++I3v5vdb2efgiPQduIrAt4pNU6bWgQT1agRTvNsw0mgAwEL
/2WmCcUxVEOT3saGWsANbiLQQKdV0DNbXDjuIeRQYjPcAA1dQHEXVMxiO6j40Yxu
9D3hStdHYhDHgfUxeH3cgyakBIT0IEUHrzfCBMmgCXnVawqaYIJW92AGV5BDfcdh
36ZZuW0vBSYU5VZFmmJlOtLZA5gHTI2e5uATTnjmNMuo5mZ/czOHIefJSMOEq7Km
JnzIwuh84k5FWEvPhFwFHf4c6OPK4WhWsMKJEV2HLnRhDihOMYoVPQc60GEO756D
vh/dXLXqc5FssGsPGUlw523ih63sdJGJHIONjnCEh2WCK6W3UUzaQAMcqEEi6JuN
bNhXG7TWBtN4yY1cY7lP3v/iNRVvpJXpCFvAWxgzap0QRig4++ZwHFnmzLkSa1+b
D7AhHRh0oANvC+UKeuazF4iAJz0d9+klHgQgrIBcedNhFXMQN77zTQc4XOISXqfD
JeYAB3zX2+wrbu49FcnIIDBy4HBVAx7YcOntFlaEruOgLBdqPVLYoAcq2MQR8Cqs
FDAhCvMwwQzygAhLZCMatE7FxyNv35Jzo4new7zb/iTM8dGUyzjyioBlrloh4Pz0
k9vMSJp0QM6hk4+tCbpsjP7tPaMBDUTwM9MRQQupXX4bSTOxGcpgBTrUAdFd6Doc
li92QhDiEs6PvvO/vvzqX8Lec4g0jJ2LT0rHNZ/P1af/4AM6r0giue8b5KAUxhaD
Hmxirlrow/qlEIMNyMACKZisHAIhi/qCnNaTxw3j4DSXV4BNdIBuEyiL4igMyF9V
lBXCtgdiNg3t4ASod4Ee0yVPsg+foRJPcFWq0Rp/9BOZAEFIZzO3d3tdQATjNla9
VwuYUAzFQDxFwAlf4QVocAPJ13XSJwiVAAivcApCOIRD+HxwMH1wcG9JeG/ZF2lf
YAdmZV1AkAX8hAXbp0jaNV56ZV4mURIKskExIHFqgAV3sEhaUD3zwF4fBEJasAZL
ZAmuAIAAGAgACHKpAHIGmIe/RwsJqIDFMRzK4RxXEYFi9gkYeIi20iUIMBh3RH+m
/1Es6iQhFDIzwRVcKegFK2gG48YFnEgEKFUEMBiDxVAL/qAJxHAF7dYFy0cIgnAK
lfAIlQALuIALsFAJr/AKleCKuVgJgtCLveh8R0gIzJd87tZudaBviQZjirAG1qVc
NNZIzpNQo2BewKJYRDY2StYDRzCG02VBTEA2RLZ3QMMEbbhxwAAMkCeH6iiHAkiA
eliAgZKAmtANDQh6hPgN1ICI+nglibGIgVFOHphOGpZtbuJVJmgztpdoLEhPnFhu
x+WJiFAEUyOKxcAKXqCDPCgIsFgJlaALsKALzlANrgALJMmRQmiSHAkIgMCLvigI
wJiEZod9XWdvxpdiyrVizv+VXVroadZzEtaTXuzXfirABtW1SGHADvOQIBvFQQsl
A1IQBm5IX+gYDbNGa+QAgFcpgFY5Du9YgKywL4EyHMOxHIL4ct+wj2gpIB6xOAB5
VE/wEsdQZ1oldCVoLTVTM3uGiQu5iZz4dGXwl+qGdIdANcPgDcVwCHbwbsvngxyp
C6ZgCrqAC85gDdYwkiXpiisZiyXJkRxZBi0pjNUXml4XmqsQbynWhInUSFrIOjEg
BTIwZOk1GgilBUEABASnBclQNunXVynQZLYzWYUQDcIJeVeJCuMQPMd5lcGTCsET
PAVIDgb4lazgh2LJchKYlth5GR+hKh3AD/zgllc1Exv/JhsQlAbgNid7yZANGQd/
2Z7plm5ecC+G4A3eUAQoVm9H6IMk+Zim4AqukA3WcA25wJ+mQJKOSZKwMAa6oAuD
oAucyZm/KIwSGoxgJ33D+G43sGJsB1BBtJQdRDYeBEJ+93c9gAM7pF1McD0bsH4y
0HDeJUsVpQJq4AVyMAnAkAvCKTzCOQ7R0JzNmZzBUwvQmYfS2SgPGBY+kp1KKhke
4QAFEBj0wA8eUA8f8AFQAAWiUGc8ABsyA0GngzqY+GeauJ7s2Z7EVwlWAAiDMAZj
wAUvJIOLlnxeRwgcWaD96Z+lAKDNgA3AMIv86Qq4QKBicKeP6ZGb+ZeC4Jmn4JI9
/6iRjioIMHkDdrCMAPdIemVY5rUBpKCp7CUsCOVKziM2MmB/ahgFHGVJrKNCPcAG
V2AG9GWjO8qjkJejqOCjtjqkBugnwEEMmQAGQrekwJoRHlEAEBAYD/Cd/fAB9gAP
caGlBVmXNgNPhSSm6hlohGCmgJlugMCmbCoGVnAItHAI7WZv0OeKsPCnpeAKNvoM
4SAO1yALuFAK6YoLrnCn6eqfrlAKgUqgsKCSKQkIv9iSZaCLlfCXoDkHdnAH+sRI
g5dQq7ZQ6xdCHpR+nxo9TNBkrnNeDYeN2ZhXq3Zqr8Z4SCMLw1mrwhM8PXqr3ACd
Q4oiaZAHy8hVQGEEnRCsNv9bWx1RrPvgnfXQD0UlBEKwAqCQBDjBE151gvAkYtXK
BYRQpu1ZBVYAtds6BlMrBmMgBmIQBzqIn6zIkbJIr/6ZDef4DOIwBOIQDJMgC/l6
r/+ZDaXQf5Pgtvm6r3Z6rrXYma7og62Yi6fgmb+YhF0AY3iwBgGXcHlVXh9kXgpC
f72JSTXgWIX1UcKysbuJSVqgAtGTqmfDBjqABodgCZYQCLxUXyYLpD7KLYiQCHkw
Le4EQUdxs7ALEWs5GMfas/ZABULgDkOLE1xal4IkrUxHBEsbB037l1zwtFUwdds6
tdxKBmNgBWUnp6xorqYQr/5po61gDew6BAMgDpSQC7L/YKM2Gr6TMAmuEL7A0HHy
SrePGai16K8PWrDtea0uuXz7lrBYYJt3hUl9QBodNH+iRgrsZVEp8F141ZTpZwMP
25ocBXgCxV2s83dHMDRX0CGDlgqgmwqFsA1yoCepuwZYoAMeVp66kQexe8IS1hGq
IqX9QAW4iw9O8AlIgAQ8wBN1WcF5Oa3q+XRxcLxmWgVADLXpxq3dirVYywXjmp9C
CAiPma/AIAvnaA2xEAzNIA7pYADpwAuzkAutkAte7MU3io6TEA1hrLau4AjVy74e
uZJ/yZkG+5JLaHzNtbDaBUmUJCweVF6GFQMF3AMYpFCjugF7FQMKzAQN13CVhEma
/xZE09MEq/NXR7AJayBIiXAFQkEtawAE0+JheoaQCGkEKBzKUKUPK9yzLowP+JAP
OVBsO/ETRIEbSidWXGAGPczDT1sGQQzEabq8RFzEVbB1dMCKsAgI5xqvNhrG1hAM
2NCu6XABBnABQxAOjRAM1PwMzxAMzzALsbDNsfAMOAoM+OqfaVyvpjAI8duZbyyM
95aKdTBpi0RQPJYChcWUMXBqk4tqsMQELCrAG5XIl5RqCAVLQTTQBbXIgGVXQRAE
WQAEQ0N0lnwzCImXaSDKJ7ydgeGdPksFqJwP1FBsW7ADnZAJr0xI2LK0DenDuIzL
QayS25qm3Xq1RjwGcLCDl//Qi+Z6rk78xblwzdAQDp5wAQkA1AbwzEPgCWUrDuHA
C9Cw1NjQ1NjwDLGQtmaMp+lazoOwpo45BujsfFywhO+2zomkBrZZuJxWSYg7Nuu3
lL2pMtw1aqLGx5S0Y/kMSzVg0AdtomygbXmtLJo8LYpQibbnBcKFGxQdux4xGDvL
DxmNyh09Wl9hGzTzLMTFiT/wA12ggzfgA5q92WXABbmcy1bArUaMtWXw1XCwtz/4
pzbqxdaszOZgxUF9Ac18Ac481LSdDmaL1OGw20odDN8Mzm4rt+SMxo5QCpBpzvMr
mmUnqWs3V1kISTYwChDrQQ03GmGYUJ62fg3Xx+4l13//lWk1IFCRPANZEFeSAARy
hwUg/NdXcHt5yWeeSEiFfbMg8aSJnawancrUAAL8LWy2ESeFNE+UTQRIR3QGrgNf
cAMKruCbzeA+8AMqDbUwPQZ0IKewSJJj0MTpOgmt0ArWfA3XAA1W/Mzp0MwlfuKz
Ldu4LQ5IDQ28EA7QgA7WnAvnSOPpKwtsWwqTUAqOMAZXXbA9DAdMC5p0wNw09lZ0
9cCUVF6jsUH0FwNx3dYbtEGP/Fc10N0GrAXhrQU4MFCRrG0LDcJYcAWKoAhfgHQp
SASZOE8fMt/BatHHit8bvd/9vQfSISclTU9dYFb5y9ALrW0MjTvTNV2C3kIKXtnH
//ueyMWDlVC98+oKYqDjUXzN1xAM0DAEt30BAyDbm54OAzAAnhDqQ3DiZosOszAL
jbDb0FDN3kzjaRu3pXCOsoDGDcqgZVC8nT2MdWBW0TXWAfdImWTIeCzA2HjdBWXI
7GV4BdxY341B4R0GW+7lm1De5c1Pa8DeSNfe7Y1owjtWh0BPiODmwHrYF23KGs3R
/A0CWoHn2VLZN6ADLAAEM4ADOFAD9k7v9D4D+q7vKjDv+p4FuYN0N0AEiP4Dq1gG
jR6Sy2ANspANk1ANwNDNIE7N7cq96cAADHABDBDqHN/xnhAJDeAJZisMsYAKqK7q
5kDN2/zN0fDFs07cx92ZwP8ojPjGaPqE5DwkL5Ak7EzZ8ySqaT1QWKNgeIrcWKwk
WOF1BNTO0NxY5kh3fIiGewxpXN/uweK+pCBx0R7QwudO5yAwBWDfHL4Q4ERABGgA
7/Ju7yTABCSw9hXQ9iSwBDUA9xXwAm1/7zPAAjyQOy3U3vn5g7I4meXQDNcQC7mg
vdeczSLO4iw+BI5f4gzg+BwfCZRf+ZXfC6oQDbEwCz3d4k2Nzd0M1VTpCoHgCGeM
xpZg64/wCMdVfck3B5PG9G83WGGTDKRRXohM9JqmMoVnuUgvUF0ucG6X12zQ12Nu
Vu3tbuR2NOfWwdpy9dh5OfsQpVyfyvmQ7mAP9snBG3P/Ei3xPgMlsAQk8AK9OQoY
QBopgAGjMLmtORoY8AJ2L/fIMgNbygJXwAWJWqf9CQzPABDYmDGDhu5ZrFizoDET
15BhuIbiPDFg4MmipwaRNHrj2LGXN2GQICkMVxLaSXPY0AWLFU3WS5iBXFkaVLNS
zTJlCOmE08XOFzxrhK7JwuZImDA9mDBpwjRGkxR9ljLpEUZL0qUpmCDVouXI168z
wm6awaYoELRrFH35cgVNFzpmzHCJU1fOXbx3Dx0K0NfvX8CBBQ8mXNjwYcSJFS9m
3NixYX2R5+3rwK/fByr48uUD0XnKZ02hNUlDlOaKDhZAZtRY8uJFihgxpMymTXuD
/5QOG27TxhDjBQkSNWrgwKFHhxlBZSoBgmXKlTNgz5o5hLbLHERxJbWHOwkNYqQh
6SpG8qRxY8dh6YepUjVyl/ft4qBhQxgNVbRouXJNCmRJFxlLHBFwjEFMGcMKQriA
o44vsFjDQTaMuqqHHqRaqg+tlqKwKqSw2rAGr46YQYsZiorwiCyyAIINobDAwi0i
uuiCCy7KiOMROQbBq6a85ODrMSCDFHJIIos0srDIIuNgMno86IeKzPKhxrPP7rlH
tNJaYCEEPYQj4YXYZqNnttt06+BMNOlBM7fZYnviiRdCWYKELLoQpJLldHGllGyA
seYa7CJyaDvuTmqGkmAogf+ml0jEa+BR8yLxRr1hikmvmPZUuQ6+7LC5JphnngkG
1GdygemlSSYpxRVXJnHFwEHK4KKLKxqEcJMjGEGKQqqmompXq7rqasMwamCEkU0i
jBCINdJSa60rrpDRjDiojSOnmqywoiYd8zpEjiPDFXdccstVTJ8AlJxnnsrqsSfK
KUH4bApNrLzSlxZaCAEHRlzrDYPaOpBiAzXV7EDNySY7s+DaZhslhlGeqAEN5SrR
xRRcnHEmm1aeEUgchgYadD5KsKGEklkQQmXlQDARRjyLIM1IUvWKsdlScYYYIiLu
sMHmPZ+xYWm/aIDZbxJUgUm1FAMrKYMONH5ysKhNdE3/SqkNiVVBCxCFxeGqGjrE
4SwXsVDkRTTSlnFGOuiqsYxHuK2JjEHoLuTuQnxE11y++/b778WULGDJg+vBTLN4
5a3yHlY0SaMFHvidswKAZ4tHN90MXnhNNPfx3GB6QpfCA9o8eCGPiivBJWPoqrGm
HPgCbQgaRINJGRVZAqHbijJOOcUUWSiJZICYZz6vUks9MeAC5tPZuTpsYi8IIf1y
iSUX/PLTT2lWm9apizoUWcOso6zelSoKh/OqKxCDiPBr9lHMwkW3vngLLjhorCun
Mrade5AxjIEMdsPb3boBOAQmUIF8S5I+CNekJ1BBCJvpjOKmYCVNcKIFI6ABa1wj
/xsphA50B+McZQiQps0V7GAipE09apCInOBpdRoDhp+ugY1mNIMZJQFZM6pDiUbE
QhZygAMd5gCHSwiCObBYXTZm0YviGU9SHGnA8hLAPCw6rxfa2SE0WHK9Z1jjevqJ
RamKprRslIJpg0hQF75gi/Ed4SqMWMJWitUhLXxNjmHQg7PYsAktMIJEWXjQFW4A
ly7kry47KQNOAAhAMvynbpIkQyEsUYhUpGKBm+RkJxvTwCWxSwrugheVLhgaTuyA
Bkr4EgYqJzrarGmEnENhwURIwjHxYxRrMEMMdYGLUmisGtV4hjJ85p3scGcX72kG
fQphhi4ckRBKhAUTMwaMVv9YIxi8yBlGIBUpT2Axi+nA4s6yM5+DBOMaiDrIM64R
qoOMcT+lgIXTCEEHO4hPEpsA5FW4UqyuiAUHM8AVIa+QB/FlASwzAALa4EKjnPjv
kXUTUN3qFslKFgJAmUyFITz5UZCGtC9JWhdlxvQEKLhDSqbUxBT2sIMT4AAGGcDA
EwimOYHZJnQk7MDlaKNCW96SHrsZnR6uAIfkWMwUwRymNdx5w2aEgxk+XCY0fPiM
QHCBDnAgBCFOUc3VuaJP1iCr9UYCxShqpAHhFKc4E7A854nDHOoMGjZE5TNR0fWd
rVCV9xbUoGZJgnyC1JVXCFqiogTBoGiolfhWZBa1pG3/Lm975BgcQQZHWPayAqKJ
RgFkiVQEwhCo8KhITXvavyVpcPuIgsCe8A4hOCFe85pCKk+wgtZggHSzQVPDpKBb
MbHQt2LCZQhDyI/fYmAJecgfF6owiF9mzHXWUMY1rIuNngVDINy5BioGAQeu3qkS
S91YDbOZC2tgLxu6owUrhhGei0TiUZ4ITxYvkA5yXnEA6ThnOJqBDnM0U7s3fOck
DAQIKwDCnj25wtmGQjXiHKGgKjJRitZgP7gw9goOEooi3DKjGzWSW6YQUIkFhFlL
DDAQKybHyiCBCdTGWMbhUi0H9nHC2aBUCO1IHCdeelsYvOAJrxSYmmgTAzgJeciV
/zMuxML0U9GBbjYegJMkEgmHaw2iOdJ13VOj57OE+NBT0SCDggixHCa6YrrTbQVf
UTEJMsThCyowQQk4UYxGOa88j1rrANp6AQas1QBwNWdJ0HHDZ0TDETrpale5kKAi
ooFBDhYKEFJUlBSZZVmWJuQXbkAHOsgobQc1W7Ticq1GmgK6mHWEK0oMIAGtOBAr
iwUqRALjGeda159MEgQ8l9MnhEIUoMjBN0Cwhz1sAcgvYDIujewBJP8GBtPOgGuG
7DAmjELbwRXhmJo0ppq+IAtoMHMclApMYTrVndGjBEK0CypUOOIRXD0FIGZIzFBt
L1WyKIUVvACEFHhgAxrggP8JduCPXoQnHRbRyEWa1zyKXGDQBsCvfEolizEQgqvg
Ba+C1laHOtiB1GWzBYf3SUgHSUIoZgGCIu73g1CDugtq68Jc4nCXSWrWxCVe8UtW
ZmuRiGTXQyc6YRo4mX2EjspxUsInprGFLSDBBSsIcpg2sKZ45PS3cIJBCZSwArBP
e6ZCrikGRhHLW055NjXNAA6usNWdPOImGBPmdMvxqU9BIhbowEYuCnGIGt0JEOTt
sjJKtbRSjOEHOiDB1YssBRkU/ASaKEZ4DDCAjKzVIn8GNPMGfYEh7IIMcJjDGzju
gzmIGuRtqUOtvqAI2CMU9inv8Oz1CQQdfLhtoJaLXNr/RiM59A+Am925rAMhi5+j
AiEiYU/Rnf98JSHgc/yox5uEnYQkIIEGKAhyb0J4dc2Nae0YeMG0lUCD7YMdBWAv
QQaGHAPgFkwC/BB/2d/0BBx8AbzTxBOe6J5udfuiaCiZYCgENaiTKvgqJnKGYWoF
/eCrzLICLriCGcCAq0u60NkA+JMCDrAAEtiDWvCGdKC48pAvTyAnzvO85ekFVCCi
OXhBGQG51qsV14O9s/GwRLiCHHQQMPAwt5hBB8HBtemCGCGCU6sLVJODbfkPMeA5
R5C1SaA1hEiIWdiFWVCF58vCXVOtX6O+eniHUFACJSCOErA23qIlI5OCaFsCGFgB
/xRIAvRbvxIoAfbrvoCRMg9wpRdYgmpjBEWgg2kSr0p4hOiqO7Jqp5aYBfoIBETY
BEmgg3qjO2AYJu5xhUFAAx1YgxmoAJ46kw3ojdjYQA7ggAlwAV+ovEGLGQbAolX8
s7cCAAPwBFUohDmwgzsQOba4gp9gi7awQYSKFmA8mzyQFqgJNTRokCuog7RZRjSQ
ix9AQt7ZkQEysZ5DPilcvlnIxubTQm5ErSRxgC6sh36wByhYAuGooyejJRLijfJr
wzeEQxrAPiWAASigwxKww90CvybZuvKrARjQA1tADkEQrzHAky0zRKdSGUiYj2iQ
gzRwuTJgDi6rBmDAuEGIA/8dqAHY2AAb8xxfU0cIgIAHgIBRhIAPZAVvgEVyWh5A
izhxEo8LSACVFIZUQAM8uIO1WMaZ0zAa5MllXAWdlLmZgz23iBZmlAskjAO5oahY
CwSkQT79UL4pzMYrFAYs7EasBCku9Bx+iIB+gAIogIHWYIIwUcfNaZNggwElWD/s
QwG3dMsS+JKuozoSGLLdkoCByUPyK78SwIEVsDJB8B08GTz/QzcGtIZlICv72Ltm
uIYhSoQ8oAOJZKpfoEhTkAMzwAJO3AdRigEmCAVkWAJGqAEl0INjaY0noIdR/AsI
EIIpGAaJc6sEYIAruiLZNAAAuIBeYIVEwAM7qIMZcTT/qEGDREgbZbyfuICm+xE1
n3wLIlAbuaCLa1FCAaoknluxKPy5loiFkajCXRAG8MxK8eSkBvK1feAHyyDHUAAT
2XA8zqQMzjmpUDC/FVAC7MO++nRDFFAC98uArqO2JeONvew6MVxL5grMU/A/VRsv
1pnE6cqFldkF/3qGcXiERPhDa2LAZViGbBgDLggfNkCKY5kBlXsQs/kCO/hN5lyF
0kgDYtiBaQAFKIgNFOCESMjNtqLNVhQnBvAz3LyASICEQogmOOgfG+ECoEQDIliF
mmsbM4gLY/SCLvACDXs9GJmL5IwDurgLEWM1noOJlbEPW6PKZQJPXvCG8UxTBDo6
/65Mzw+4NtxAk3VhFzQ5oTF5gRI4AR44AReIx/tEAVEIS7iEgSfwTzqcqWtzJTgh
ga7zOuLAgSTIA6+qN+ZYqoL8v6ZKL/sgCWywBlmwUFu4hAUcpktcg03AI35KFjVQ
AzzAAyxA0d+cgzo4oiLaKuUQIEsALW4wBENAxbayTVZMQdy8PFVIhTi4BEJ4hEcg
hDhgUjMAylWIkZljTp6Mlthzi7mwFrvonxy5qCd0BEtAmuy0HioMBuswB3PghV74
CDVtVwYiKc95AMv4gA8gHTSJgjllFxOSJdNJghHYAYBdhB0YAR5AAhwowydoQ6rL
AIalNiULtz2cw/osUDe8gv/ANEg9AQZTGK9gqiHX4atoCAYdgoZrUDQL/YI4wIVq
uAVdUISj8IoISVV+YoNVbVUXgdVZndUjktUri8ibIINACNlwGMEU5NE/a8XP6wVu
gCYFWYVojVZm1MmZS0Zg1LD74QKbqwve8R+6YTXjs0Zay8ZdwIZ05QV1VdczcFe1
HZckQQBfowd+8IB68ADNKamEOZPWik/TWQEa0FMeGIEWMIIN4j4h808UaD+GZViy
Kz//ND8xnEPI5QM08CqDXKpqcIWLCSYGpMhJiAYJ3SG7igZdMINESIRKcIZfgIU7
0II+aN0wOAI2sAU4wgM1oNma/YI7gFVZ1dmdfUG4iyH/KzCFWcMGccAvLEoA5M1R
2jxaz7sAXkiFVaCDVcDFtgBGt5C0tGmL4lTSIkRKt7k5K+jW/3lCMXDK7ESIbDRX
dBWGcFhX90XTtY3fIQGleEXPul0SCEgYfKXTgwmhg7mNaCOBOaSBETCCxzmBIEMp
OlwB97u/AX3LAh1U14ABGqAYwXMOV8AmV0A3SpSFaMChkmimRBvdRFgFU7gFXJgD
PDjVUSAFeogHduiDTVCLO6Ddm0VRkHvBF1yQIxKE1CsipEoO4XOESZgFc8gZhYvN
os1RH10eYTiEUVMEHbjWXMzBOkiEtkCDVaAWatGfujADOQBfbtGo65w1qZyFUdkF
/0UxW3Vt33WFX/mNY17TBwcogM+533lYklC62zOpDd0oHQ/Iw9nIgBVoAU5IgxFg
4EK1R5qqqRyDARTgATAYAYLlgXi8xyF7ARpYhaQaL+fwk1ZglT6pSFmQjhAW4Ul4
pjpYhYwRhDq4AzUIA2QYBXZghxhgh1FAhk1QBDtYVU+TwTlAPaQihB0uojkANfCC
G6exGCLOBXPlBewYAoljSbeKybZaOAYYtGKAPThykaHAAtmr3rQ5NRv5Yum0i24d
II2SNVmIQnJFY5N5D2g2W3FwX3aVY3xOjAayY8/xnDyeBwfggMFZEs5ck9baDYAJ
ZN2CNtz4tSdwgXwZARSAAv84CUvFfQLSeRNIHgEW+FeAHVgagAEMqD4+6IKcuBMS
m4RseidTyZ27iYVryCGfeSfRXYVEoANcMIVLqEVb4CekQAagRgZ5IAU2iBpeLuZj
9gGkOgXwotVj3r87SdCLcYRSmATrMZlwgOZeyBmJS96iTV5pbgBV8AJffD0HcREf
fAtrSdZH+OLoDGMlHIRCYMp2jsIpjIVROZmyNduttmeOyGfARpJey1/OHEWBPmyC
Lqm8XceGEWRXioEO6GcMgAEXsOT2exMlW0/7K7+13D4a4IEdCFwWQAFmy4BHTKoC
ESv0cqd42oY0OIRcuCEcsi5PlQObvgRTYOoXtANbqF3/ZXHEMHiHTViFncYfQeC4
IH6FrhpIQYA7LFMiPBkDU3AOq7Ye7eoOaEhXiBhB5AVWcbKiaUYFOxjnJ13Gqq25
c0ZC6dQfzxqEXH1Cn0MFCHW3RDkJsy0Je/brwN5vwEgSDkCAeSgAkuQA/1YXkixo
Nvkp4/ItV2poyoiAxnW/0bk/CoeThp2TOVkBHmiBNNgB7vNPHeCCOymQT1a3dkIF
X2ABRECFayiHmb4GT9UFm6YDORCES7jx6X0jNZBd2ZUESVAEryIEZA3ErjqFwBwD
QFAiJM+JZd0J5oAuEmsVd8Zrc12Jg8gPSNiF4h207k7BBGgELT1nL37S6KwLZU3K
/5vb0ppY5+N7M6lE35PpDmh244Z434+AY/4O7H0mcAIv8FEsgHnI3zltreRq8Mc+
Q8pwJQ/oAALgSioDLrTEbGnLACiwNkV/ghIIbYl2PxjIA3NjZlbxE3VDiEIAA0ZA
hEl4KusKI1kYhFXYsD88hUuQ9RyHvS8oXdlNhEeoJiO/WAUbPHujJ4zJaVgoyEEA
BMuKcqqu62iYSqqsNVQIhMsKhFko3tj07mnehUFQ1kdQDriRuzPXVm29kZsD37kG
WqeUb3LF66oqWzrv6/z+iGHI8/1uIAey9z23MaSjDEJ3JX+vqQq4tsjeh+TagH2Q
PnqIDUGuBym4P9do3C+xy/9ApofJPoGYqoAY8IAMyARzk+5Qz6ZQSS9ZQIQgS4NU
V/UwygZXX4MeeIFEeAWYl/XdXWWnLd1VGK9qAoQEBQSeZ9Bg2mA1WhWmMYX/EBAM
dsp2VvcpbPalX5mZcARUaARrn7jZTIAhQAVd0AUd2fodkYO2NgMcQUIcuYuxp6hZ
sx7rmQVRiXNoYOO+rud69us7x3N6j2N8x3c+H8VA59/eIpgFJ51ww4AOkL4OcCU1
gU92bFixgwFGrTZFF5M8zAASoCncoIcnUIS4uZhQJ6uy8jse+K08kAXDgydW1wU6
yILW+gKYh3kcJ+4bv4RnNYPoMgVY4PlKtaZSqIZV6ZP/qgaGUhAQVnEFMdiT43uJ
6iGju77rMMoFvoptiKgviqMERyAxmtCRue7WMEZnHRn7HNkRSzh7vEbjkwGik8jq
LYp3v+6ISal7fL77u9d7QaeM34I/+Gtw/43swneNgad4DAAIeh327ZPg4eATEiVK
oFCipAQOJTBIYMBAT4oUCRc9VLTYoQOCUYnKVDKFyxWwXNaesWyVywuJDk/AWLJm
k+WzVq4GdZkxb18mWEJhvTp16RKhS4906Xo0SFepUrhMUQVkSoyYqKWqASsFLGXK
Sa4mTSoVSBZasqhyrc0V7W2uWCxnPQt2LZjda9eeWcuV6xmlcOKCoXIlK5ArR5Yc
/ynWVUjOoMdyHskhE3kQ5siFLFkKhCpWLLzBsGGDZppXOMHieolb7boXbG+yvQ2j
HeA27ty6d/Pu7fs38ODChxMvbvx4bn3K9SVfro9DAQ7zIMz7ua/DhhgdMaTA8OIF
hg3zEOyjl6HChoEdDnr4+FEKvYsVXpCov7DEChQlYgjssJGjB/AR0EEU9ICzylOm
GAZMNSvx1YolLFDA0SKFtGLTStYA44ouaOBADwR6VCIULrgQVckpr4yIC1MoOTMV
VVSdFBWDX7XiUi6tREMWWbJM4qNfbAUZDVvRgHZkXaLNQhdLsbhFZFqo/CjLjoad
pVghkmG2GWeWZJlKIJ6BFv8MJZSYEw40jfCyJi+wwbaam25608tswwxTDHJ56rkn
n336medyuDm3HAeFSrfPT9a51wFGHsQQQ31SDHTdExW09xF7EvgX30cCSbGBFBxV
BAMKKFjEDz38iBoqRq0yAQYhlehyUjbA3GRTLohQ9MQLWRxi660bVnJFDQMxYYaJ
zrw4FInZZDNONq04E5UYCmr1FTAuXahtLpMQ6dda34IWZFx+GXkkus+Myxa6QTrp
lrmxEInKjj6OEyZnm20WJpiofBbLLGSellqbb7IWp5yz0WZnMXj++TDEEUs8MW/M
DcrBcz8xGqB7/XX8UQUlVDBpBxhQ1OlBn4qKQQwYxSf/6UfX0QNDCCQ0elGrrGIU
AyOJPLJirQ3yZQ2EYHxXHw1mRIuhNZPowsUaLzzBsiSz4qKssiXiUquG2HZViiuu
eJUt0yyppKNafjl5pFvoug2augA/M4u8ayN599t5x4IKWofhG6a/RwbcCDQEF9wa
4gjHNqdsdt7ZMMWRSz455b1ZTGjG0q0HAwxLeP4deC1POo8HMLww6T5SgIdqpy9j
MN9822EgRRQE7YOBfhgE+OmincokCR0/KxhtNRfaJIsXOLwQSgYvHJMHGdU0aE01
pQxyxQwkvLAECUvkUYqyXEn/1fQ2iQ/Mj2SRjZPZOZL7mbp0ofsv3HUlKRr+SwaM
//9deNF9ZDDU1aQA/s9t/jogaJa0izJBAzXheJM4IuEmOCXMG2dwHMMwwYrKcbCD
HtSTxQJwsXkcah70eIJDSkUDGiShVDhYwgZsJ4UM2Mw9UqgI6zyGs4v8xzsY6EAB
flI6GEwtZfE5okDmMYo1cEFWJ/lKX/oCjG2woAQZuOITUoADL5TiF0TLBhnQkIUS
wKAENZhIDfKAi1vcgmkZwlCOboS+lPzlGXvBid1aga78BVBu+CMgXq5BmtKYxhyD
PKRo5BKMJeVvf/ujxC5msUBGBmMXkdSfJdUUjsO9SYIIm80ZLug4TBiCFoi4wgdT
qcpVJuc2F9OHxt6jOhisIP8/K+QBLnmAgxSgzmTtKchGNuCBqekOI/4hwIDcs4HX
xZA89Hgdy1gWKvZUhHah+EKsdIESBlHvK8irARS+Q80kIMISk3CEHPKQhSXch3MZ
mB0ffqWMeTqIJW4kml/YZz+54A1gZMJGmchUpjL1zy6iwcZoCGmawqUGGgAlzSIp
6T/8QRIdloRkmTJJiUY0YqMX3UUjzLGmXjxQcYuzYCjtpApIlNILadABTJnDypnS
VHKXI1R1ZNaoYb4gA5yDgRJOkMuakcxkP2ydBG5IH/o0bzsCIQCiPGAz6/Cjdx1I
as4q8gI9oGFFY4titwqhAxzAQHeo4ocUnrACFuQhEzT/ICs7yWi6J3iAHhLAAB98
kYpYzFMZ+sRJPXGyF/yh46DNYAZiE6tYZjTDodjYBZkOSgmFhqMZll0oNCaLUD5W
spKWTBM0zGGaBZqjtLswR0jNIQxLCkMYbGpTweR0BguiVBgrrQUt0nAFmPJWBzX9
LXD9JNNBwZIjT5jacZP7hA984AXNTcIIFsEDGpCAHtdZTwaeIJD+eEoK2okB6I52
un2QpwPggU+oOEWPDXDqI1FglMkkwQWrXI18UgzEFVa4ArryQ1UR8IBP21lGzn1H
dwHyQASaywgwSGOvennwHQP4x9FMFhqWTSwlIKHBInBiD9/YwQ44oQlWqAKxliWN
/2YHaZrUsLihpkHHIPGywIxC1pIgTdNpQ5vaRpy2EcLwMS983NqR9oJNFuSFN1xr
W1Ka8qW91QELsMCC4FK5ysQZrnM09wQoQEEItVxBEmoZTgN7QAlgiC4PSiCF63oA
PP/xLnyQiLNQlRED47lOBYopuxiM4lHG1BikwCAIWNQ3JX2pnhdqEAFaluDAGGCu
T4HqEIl8JwYHrgcGrrgCJLRgD0bwhTSKYIgxCdKypj7sYpmxC0iwQhrfEMUGNKAB
4jKHAzEYAS0gYWIUL7TFqREHizObWRQvsDSTvShoF8rR0KLWxs7exZCVvCbaupYX
qiBlEaThhRY8GaYsYAEQvv9t5XGTu2JZ5sB1N7JlL58ACVv4xglegOB+QEEJKwwB
Dtqz3QDR4wNl1F7oWuWx26FgZATBGaiiyTJeeedk5CHdC+RboqDZpBWTgAlBJMCQ
DHzgipzLTxJoIFQaEJE9B+k4DNwxgj1oogguf7nLc2sEI6TBF7SgRRFYQQtfcIIT
O6DBCzRwGwc4AAEIKIDRC4B0BzxgHxCAgHI2gARNNKIZm/w14rLu4oWiFrPIJhxo
OWqOHNtYkvpTxS5UgfYztLYXoVxTI65dhDQY4cksgPK3w633cJe77+S+HLqv65+N
IeS4UHABJ4zQ6OX+FwO8stRHqgofjtBHIQupz0RmR57/ffDDdB0ggF2PuKmXtUqq
4yUPRxhxhUF4pXh9mcQhZjCBo3cgAyvgnJdVeIIThHwEOxACmT3wASiswAVb2AMn
fKH8lsNcEy3IQAcgMAENRKH6E8AYlguAqJwG8ekQcPr3tR+z5/BA11k/f0PHTrhl
e92iz36/syEBiVnIX/5qv3+1z6D2WhTBF3XvNkwBgZR9W94BgQH6HQJSmXM803F9
wHFJTXINk0V8APKhQD10HF3RQ3u0RzJ1QH+pSqtYWqb1FA6gQAoQhH/Uh1aBjjTd
UF3FzO3AgAeg4DNhwBJIghfIwWIUAiLoQAgwAUiUBwbAQPP8FAyIgigoAcetwA6c
/4Du1MNyZYAQGN/xGUELjMAIGAHzvRwnoEB2Od4HVMQM2g4ZliF5jYfSWYfgJRU9
TAAKGAJDARuwrQlqiZZI2SGbONvYwd+z0V/9/WH9rdS18Z8m+F8LHCIi6gC3gQEB
gpsBPmIWsEAWJCAl0hROrUc9+JQQOIELuEAO8F4oeEA9CB/y8QCkoVwGeABUbUAG
mBF4PMHNgB7HbAAMnAAJ2A4BPBrlVV59aA/31BBBzNAPXceBqcoTLAEKvFUM0CIM
xNADaGDzfMcSQAEMHEMowOI+eEAOIEEqLleXOcEnuBsWuoAQZEAO+ALMcRg3Ltco
rtdAJAqixKMaTof2aZ/tdP/AA6DMEJIACxTBLIQWL6jWkL0WL1RbQUIba7WWQtpW
2i0J2i2J/KECJPhL/RkCIfJczyXezHXCzHHbIjbiI+pdFoRAFkxiJZ6kBzlHTqWb
KPrbCuTAHuyBEzLXB+SAz2UAl0GBE4xAzYSHFKwADYRAqejHQkzECwiITJxACeBj
qhyYd1macYFOCZ7gwXWcdihXeM3OQBxABJTACxDAMLFTCa4QH/DAIgDdPhwAPQjB
CUBBpsGAEIACKCQBXcolDDAXE/ZcTBrBDrjAB4ziL5mhYBLEw5Fhx8QHeAXVDnCb
FmKCmryWm7DJQk4mZa4W2qndLKyUhpESJmACS/FcTMb/ZIclnqdZ4SFmwmIy4t7p
HUmWZEmGAErGZuVkzD1uSqMcV119w01CGuLtAQxwmRB4WfOkjFaRQBkNJQ3wQAi8
AArWAwqsgOOFF3jIgzwInAdoBAlQ1wMcwHrQx30shBLggHgG5QvY1e2Q0RPAQBKY
JRgsZidIVwvswAvwAwJ0Hjm6pFwiwTRswSeAgihAAcoJwYDVEhEeBOoY3WCSIXVs
XrrZpsmgAA+0gBHkARhkwRHwgCZgAmwgmWsl2UKeQUHa1odS5mVq5h+GEit02A6E
JovO3B50wg6gZguAwSKwAA9kwY26Jg8AwUhmwQzMgB7IppBSjHKw2TANHxQ0z9TU
/0ME0EMOTMEerMDwSWHPoQAVUAFzzdUo0BV8oMpBbOmW8cAO4IAHHkQZvQBQlaCa
3gf3YIBGyIR+SAEB8IN38CLnlIASrEAJ8AAYoMB1aiBQJQESLEKMzhxfJoEo5MA3
wECq8AMVcKJcTsMibEGI+cI3OAEVCEGSvhM/SICnSkCnwmCCmiF5UAcNdkqoPMGe
7kBH2ugKiScYZKgwzMasysa0WdAwsF1KCcMF6d/9CaLaFYMqhNIZaMIegFhMdlqy
ghizglh7SteN0sAMhMC0zkCPZsFbieeQbuvDqGR5CJ89bGIO5EASPEGCZQA+9JwL
dFmXIZ9fPsEGQAEurVBDlP+A51yjPHCERiTBz2GAqgxTdvEKDXHOQyQjD1SRpNBD
PZQAddUpfSxBKEBBKITCEvzmB5TACJzAE2SiEiBBe3IkMaSBS2VCEhDRCmxBEowi
FLgbiHWCy+7AInBCiroAPmjqFdWVy/THqCbo9wleqvjHDYUCCiyChM6oJPDBCiVn
FujBDMRqLahCwShMkmEQ1WKQsKrCnajC1RZDLfgcpVIqiH3D1+6A2G4BmiEBDyAt
DeiBeOoB07ItkK6teNYAt9btnpybxmzEB3zCHmyBlOZkz51ApgZnDozAO2mV7uXS
UCmPRZTZDixncx1XRWys4z0gDTEBv4ZADPADFJYAvon/pxLQZdLiEh/8ZgaIgu+h
ACiwKjEonxf4QhqkQfJ1ghBQARSIwhb4rRMgwQ5w5MxlAhjwwclqAifkgBOUY5J2
HJdxzD48486SIQJ8n+/0h0EMIe/+7iIgbRIg7Y2a5SJIAhCAgS9oQi3UxsJY7eMU
A9Wqb8MUAybUAvyygi9sARIgwQjk7n7mrrtNQ+Gibf3SAB/wAV2CrnjObQHPbQ3Q
rd0u8JXhlBoCrUBQAQhcqj1wmT2AgCZswSYer5IOE24eF05CAZ5CaHyaigf0AwyM
AA8A5XQlAdtGBCPUAPdIzajsAA9AAQjTUqnowS0RKhhIqBGEWaTOXOsqXxoQAxK/
/+cWdBgSuAPhbsGkLsI5nEOMwuw2eiInTAE1BCfyHt4IOIF2WRdU7cMYP6/MaOCn
YESmJQHRWiEYTBcLBXAAS9ci0CgYMCIYdIIvsEItsG/7/jEg+0Mx+EMtsMI9aAIi
+0ILuICgIsEnhCMk168jP/IjMzJdJsGkKUEMJ7AMc7LnyPASMLAoB4dyQEfeimJd
aaAHXPAe5ECX1e4IGCsHYwBQPudEkIByNeA7wcBikhyXSRqphEDShoDi4pLy9BQM
iCkKoKlchacSlGV73vEOIDHK6ifrGmoLdMI5SNcneCLybUE7zOWgLsIiSOqk8oAj
I0EOdOI3Hy8MDK4TOAEUVP/VRzwj6jzvz7oMRvibmLrxjfJw0sqxWXpvFGeCQXdC
6yIyIfuDP9zDPTA0Qzs0IieyERvBCIDDCsxlJ3ZiEnTzJSfBXNYlKOSpEiQhGXkO
Sqf0EmzPd4yyS1tOKctMS+JwS9oDNezBCHDxFEKpFQ0TdI1Ae9rodDWE6YhTBiyC
EfAAEV6RdG7PnS4ECvwwGFhRCYgC79JAeCaj2uKSJDAiObMqJ7znpO7ANpOzdEkq
f4LCI3+Dh/WnMdTvNEwDD0wDEry1JH9CmFEDJ3wDOep0KtLDnH5ezGzX4JXxPSLR
TmUAdDmrJMitCyctAMtxWZo1FU9xJkzxObhshyGxiCH/8hRgJDG8qMtmwha4ABLW
klyOdGqvNihk9AqUtEMgIedQ7ErXNvesNBMwwQvk9kv3dnPA0sGBK5fVQz8wF0x+
wwpssBOcQFlBmk8VbA8vpg0vAQbUw8ry5Qm4AAowAg4sRG0/bMV2Dw/wJVnV0nrm
EjnfcR2DWCaQ8ze8LMzKNS4hQQDTpTHENV5/Qg7o7ycYwyfwgTHwAX3btTpXsguA
ggvsAQgYLz5g6gfUFT/kY1XRgz0HNj9ch2G+DM6qMQzQgA8PdUQ0BF3qwUcHeADH
tVmneFmfg6Seg25yAgjE5Ht/w4dR8VkqwRIgoRCctpeddi0l4Y6LwhH+FJeFwvKE
/5du77aSj0KfxYBvP7krPUd8gKvtLlcF44OCu0A8B6fEXuMTYNEVXZEIw0AoLGYL
AF1wnoAN8+kOtCezQutbOQRc0sBi8oAlJ2NyluV04VIWEG0nvBtbQ3Ha1rdIq/Yn
TMMj54BHG4N9G4OjJ4F/66eiu0A3H68T0Dg1bPmDewCqpIqnVxU9CwQ9o8zu5AwK
udsbx3kmg4NDpLYSgMMlqwOkP3Jc17qtSypb07jYngMU6yd9YzLnCLmQw6WwB7ls
D3tO5qSRg84TgGmzNzuTNzlGQPmTLwfngaumMlcFU0FM5oCmYoATgJgKY7USdHnn
+BQUjMIJhDUP5KkLvHZE5P8HnuOS73UkGLDQ9vbuImAyDkB2AOc592Y22W7BNAQw
Xof0q4MDq8dlOCK6E4x0EsB6SMtlR0PyJzx8PB+vEMAkNeSDENjDX9ZDPajKB36g
pzvvpoBgyrQKFICCpCJBnA85SSNhEjqEEICDKCj8aqsDzzu6oz+yOkwDNQw9NSC6
gTM6Jhu5mOdkCP+y0ye7kU8sDufycTX5o0RTy7QKtb/0Tc0D536APcCDEIC9PWTq
BEtpdonCCdxv784ciEkXyaEpDLjAzO27C0jET4HnpGFy6O5BGnQCH7gA2oItHZMz
LsF9WQbwFvz5pAowJrt6q4O0O6R2N/tnzSvBSL/6XFL/cuWDtFyuwPHudw64Q06+
gwP2A2CyR3zwg1rq1DRV5+SlZyPzPeegtLD/FM3nfs7r/Go/fGq3w6EDvayDAyiw
OquLQjRG4wsk75EvP/MU+fLwyjsErHLVgzzMTtZLAeznzLRvvUtnmcJ+wOBCQdlz
OccxF5ehqRJ4WSdOw4oSA19+mQt0Aie0AKXyadq6sB6kEAoARBI9SZJ0MmKEB5It
fPjwcPjQ4aKIEhVu2YIkCTglG0UpgSEKRkhw4FYIAQVqBSiQID8K6agEVJJPn04m
OXnTSU4nLpyoFPITij17H4jWM+rBAz9+HfbRo4fUqBQp8qTUe6EECUYlS5aE8roE
/wrLJTCgfFwZVpTLn+7cgWKrkm1bdWzBuRR1F2+oJ3v3vvjAl689wIMJ743hQQoG
qYsZS3HawWkAyZMpV7Z8GXNmzZs5d/b8GXRozfpIl+Ywr4OHD/Co2IMC5e+H1zAy
ZHgNRUhIJaJC8TDCyQgNFzmQLNrCY9GOFgYPNt+xQ+IJhTsO7thCgyAN7En40NDj
XUmSrNMUTkuycffKj2TLrv2ZG0qosmVDfrx5/+SKlCvc7ex5kq334HltqHf2qgcp
p57yYC+k5EHsCRhiOo+lUDKQT7744svwNvbw+tAdvOwK8cO7QprvhScwUBGDFfdy
sTC+XFyxRcQQa2wxyHTsYP9H0Xz8EcgghRwStNL04aAACOaBYB8eF/QAiqxoQMKF
JFBYQZQV0NMPChf2AG6REUbACAUUwiszCRd4GIGFLYwgxojnLPqmk04W6Y6PrPhI
YjuCzhNvPJte0shEUebDTS0hbvPqNQ7Tumk/lIRwZ1JQdALnUVBMcus9Q187ECkP
6nnxxqoiJMgj2zjM4IUXQnkhPlhve20d9m6DRwh4dIVHgF0HnFXD+FT04LDDnqin
RgSRavEJUUWtEanFSkWMHqno4XHHKDrQdp955iES3HDFHVdcIzlwADUdr+VHVFhX
kKmi555bJIm0hPCSkzS2GFO6JIzxkyAXwBEIq+aM2+H/m3mRW0SihBjakyBQZnLh
pLTuys1Wi4FttFWi+MrQ4vdEfi8lJ/TbKCX8KLWXrL9G/etYeaJKDIqUPHoN1lb9
egLDC3PGML53CIRCgNuEGjqoYF+10MAnqJIi2lCjhloqqUOlWtocr8XWyW237bZb
bzkgl+yyzT57MiP1KWAefhC8dsFR9yKqrBX4yGGLPeKkeKZvgFuuzk7mbRgJPoxh
qDi9BbcII2NoMBxgPzGySZ2TlHDpNllte8E2YIV6IkXA3slAaCh+fe3iREf+SYmU
8eOPZcGeIPDYo6SKsHVDLeSZ5w/eecHApZ8Q7B2YDfT9nXeEWp555ZuO8UGoS21s
//rpcVSQ66235tHbsOcBmwPS0B6f/PJDU5uDJq8NVe7YZt/4G723wHuEfUdI7rnm
DtLbCDuR22IRBhEcDwAGDlCMRAmY0o0LjHGSntQnc69yFc8meBuYxeh9G5sNDFzC
QZZYTBT5uclIUBIiRXXuNb6LyoMiJIQVwKBVT3ge6ADjPgw+wYa+02HxCjMqBDnG
KdZ6ioIe4yQgqkt7XNsR177XPW8pSWwFCJ8+zFdFK14xAGpb0vfoMapbqQckwNoC
J/ZwkYtgJCZV8pMLtIMEHnwpTsbZwjfiWDjE+UkjHHmUE2ACn0NlwDVQKF4odggz
BCHoWIP5S/GKp0FbzUYtu/9pHabqkiUsJQ03VAgKqLwYFhi8aoY3HIxR5EbKuc2N
lD5MpbOihT0lKhFu2ZPlKzuQLm+hpolbXNKR1IZFX/6SbOiT4j6awiB7wCMlLvhE
VqgUEiE4YRpw+sYWyJMVF6iRYhEDxVZ2oDfrbME61gkTM/MEsG3ypyQdBFYM5waF
FPGQk8dylin58oEUkU6Gt1EUsE5klhCq5WKemg2BXFYPeWRQZ6I8kFFqR0oGpbKh
qTyKsq62mCJ2LYm01GgtuQe2XHp0HhwQaUjDV4BeYkYLWohCAPqgBTxwRgsstcxK
gfmjJghJC2rQDBWosI8A+JQfRVKbkogJmaeMyjbPrIj/ppS6hz0I7qlOrZOcFlG4
iCUhb3ESZ58mdJ7dmIQmWCoJez6gl74oEgqndKjMPPAgmSGSMDrE4W1sI8PZcWhW
ZGnJPlE3IAEMpaFPsE0GBkMjFR2WWBioR1VEdRQWIguyUJGoVH54o2pdlAD7yGyT
mILLbtWySU0E6WhFexolQUCkECjAapGkNipqxg+xle0cxEeZPuCBprF1Q20lc4eX
BuAOf/iDTslHU8k0IQpzuMMdKtMELfTBuWp4w29/dIfYviEKr62MP/yRj31wdwq8
5Yy5RGtUtzF0L5+wCE+cMBO8IQFvzwmcU/cAp07wYCZZ6cQerEPAmOSndXoMyznx
/wKFC8EmFIA90Chrh5jouRUxBoUKBj9AWMIES4O3Kd2smkbKDyiYRg5q64ghHL3F
imoqV2Plg6wGtcsSEXvbw6UTPUpaGhM1fablwGlPgyQphm+KUyzNZvTRBtnG9g77
qG1yY9uGZHAgtnZQsnbf4Ic5RMG6fmDCPLRrtjfMgQ1sqLI+rmvSyWjhyLE9Apd9
1IQjz8HMkqHCFKjB3XtMgbsgULJQ9fE9zjrlvC97Qj/cQY0tUKy9FHNdTq6ZlYSM
kRg7yMr94gedquoJYFoqVMUumSG73pCUlH3aZaH2IGRRhX3oRS8Gj7cXe3Quhp2r
a+0SGTqDVg3Ch0RxqarVVv/HeKBaT/M1P+QBY0A/xpXErLFoSxtSHu8Y2lAcqUh7
HFIuA7mkrhVvZsjshy/oQQlfyAI/9hyAORzZyLFVA7lfq48/+KEN8rBuG/jxgC6X
rcqy/UMHkMyPOLs5zYywt4/wcOR9a5cK3FU4nv0BAnZjBgQgCG/aeMnFo34YsPX4
sBAM/YlEU0wdOTkJxZT5CReswAlf2sGYqAlOi1hkEdU0RlYaaC8XsmRDoeOLxnc+
WXo8zTHSgrD0qCIPVPsQaokc1UFPecEavs/ptAbMUSJM4qlcnVpVcXHQiciPYxsb
blsjAI+UHbZld6vHphVbtdmOWim+nZdANqlptO2ZHqT/2Q/jLneUsyxbIUSg3GyI
LR4iYN039MPf91aKZvDRj8n0AwSjyfd1+xHbLzw8AAXA+wf4webQVPkNfIgt4F+b
cIU3/B4N1/O95YznKUw5i+QtZj06NxTXCCEH1MjBNOb4Dd8nbJrURIIxKAYKF8Sv
E8IfvkwihxID+mubNxfoqww5UYlWtGpBTxCwcS0VqijL6COW8A8PCVGFLpShH1ir
r72ftSH+Goi9VhAQ42/srkGmScq+pdnTLtIkSfHajuTtkIQA1ybueMm1hMy1PkML
7qANJs8PoODh0MwPYEAR4O3c2sAe6qHczu0N7KEfPHAO1MABKiMfuCsfWE8y8OzO
/1Lv9VQwi95ttuwhtiShH8oNyqzMDmKLCvgBATYjpipDH9zA26ggtvqBAF4LH07v
HkAg9bhr4AKAp/LBCacAzxyu3EqjANDle3ikHlzD9l6jUnLiE/BmTuiEvrbA48pw
C4ihE0aAPGbuqu4jRKBgYFTCRF5DaGClw44FaiaqrajixSzq2OKP66ol+xARa6iG
xRzKalREbtDv+mSm1G6EWoII2OYviMDO/mLp/jLrlvZPbLbo/1jLpFpr7rSNNBSQ
7lTRSLIIFjtjB/+gytxAEb4A8QpAMmTgutLtunpQFwMA4D6wHyZvE8otAPjh9KiB
9fSB4RROz+JMCP+gDizvDf/yTQlu8LXCILaEAB9iyx74YWzOzA2W6w7eoA1oq8uK
zMok4Qj5gYr0AR9YMPWWUOE8YM9Or+Gu0Lvi0TSS5Hsy6wth48NMR1f2qCfaweTg
K2/24BtyYCbU66lebhp4jzw+IWICalOwRJ1SCDYMhJRKTFo4URPBrv6cAtgyURHn
rzGKTlSOztRuLcKyD/4O0RDBzqhiDJZ2ZOyUrbM8Skl2bABbS6QQ8ACBzChdUSnF
Bwa5jQjxzsoggDQK4CnT7AP5oQQDYPIkIQKqUgk6oN1A4PReUAifUOGoQRsvQx/2
YQfdAB92EBzJ7cxiSxHWwA/egPO6jAKbzA/uwPMkQx//8s3I/iAvJeO7/AEfUq/O
/MEKtdEZl/EZxdFc+uw0iooeZKN4XIMKJsUJ4sJSdmImeoKOyij3psHQrCP4Wo6a
LhJT3qNiwqhRfkcSEcStSo3UOFECSNLYTnI3b5NqfO0lj8pG2K+LXqw3jfOikC3s
eGTsCIAecKmzQjEU024ApcgAWXEps9MVY1E09OEI2MAO6sANqjLJ4lEN0q0O+IAI
66AfHmBsBE+23qAeYmsOCDPxssgFXQ/zJCMCpiAfqMEJ/QEtkZEy1rLK2sAdzi0u
4+wIrNIeDmAcJWMvZUvvtEsfFDTKEO+1CiDPUu8E/YEKGs/eHnMKeIoKzPLhzAVs
/5rEbQpyLcgwImeiHUKuM0GhIatqGnYPDqspK2bCJmSCJtIjD4XFnQajsRysrd6P
EEnylWLJSZGIExkDOa0l65ATEw+RSa8lHrS0A+LhE7VFWzyre4iptFTLx7BTO1Ux
9tSUO4dkLfnBDt7NDcDgC/5g3OauA8KND3gqQ5MwANLtC+iTB1vjASBAMuyBu/Ch
zqYgLSfD9E6PCkhPLZNBthThGuGtB7MyAAoO3TSUMtCMFmVQEvZTHzZBttpgBW4w
GB2ACRez8TiQNPCMGniqH1wPBBpVCzkAAfwMMhjq9iylDA3N0OYn5NrBCXIgfqhp
9+CLOIZv+K7pJIRAJrbpQ/8eaXhA8igarJWm1EqhFNmgdOyeNOxIEkvhr0qxlIiM
akfCzku7lDk7gACiYB7idcaYzXuqjW2oraSQMk0xY9sKtN1gMR5/ZG2kwBfdgKck
cMr2gR/6oTXs0g/swDGPwA3aQAiIMN9aQ1KlMFHF8h4aNYseVeF60Kcwo+/+QAnc
8fDEETD7TrY+IAqziA02wUSJcFSRcS2zwA3+YBGEAA9oCzDNcgrEUkDbk4r2Ac/y
wR7w4US7iwpAdhWHaV6NqrGU5zVwxVJyb5ogUiE/wfdeDmzJQ+YAZOQqBqBm5S/S
ikFMra3q4ecuUTdzconURUfClW5hzFtNUjf3Vl3pwUv/23Vbxg41wPSzaqyWpBPH
kqQo5w5NX3FgC1RgIXdgm5JI9KHg3GAF3k0I+gFWAXMfDgAPpqsf9EASYHUtl6AO
qEAR5kBBnzYJlRC88sxo08b07qEFwzEYZ8rI0m0OAtUNCjOL7CAd7QAMFKEOPgAZ
uqwAGtZhq+xmW5YWr3Fnr4vL9MEBqMEFqSBA8+HhCsD16pG7qIDz9kwfIG9tzoVt
iAklPQwKqABXfgIe2sEicqAd2oE4DM33EOb3wHYRaAI/zulyTiRD7IGHADF6VDJd
k8g542Hs6pYAHtg5u6Y57XZ7sMUT83Zv01WJ/hYytKWBvXTsokBwb+lwo4C0dCyk
/+COcZWyTWtKM7ixDdbAyEb1ARDAQqtyDj4A8aZseeuhHzbiD4gwHJFRZBsOZANg
CZsQQBkVKzFDDejz3f5gBw8PQiWDFu9AErJ4dWnRASyUmJSiyvRuMlz2yN6AKUjj
AahgVqkgH1ojF+PRLAWUu/rBaKlIGUFUyZCESdTnvGToaHaFCpyg4+q3DHOUOKYB
Dt2oIhd5Gvw3PyoJ52AjdAzJWaInbh9DcJuTKRoYW+Y1IOH1XTXZbtWlgROYEy1Y
XbbUbzHKg8OUo7xFXsX0xraIAAeQ7hpXBSnXhQtABmNLCdhNu574yEIB89aSYZHh
DbCACvhgdifDAczyHkCQQP8XU+E+dh8itDKyTBF2UBJArx/AMouqMs3Kk+L0waVm
WC6ziIzj03T3AR8kjhoigI4BLyv1oZqtMHzTOQAW0x665Ui6xznPqyAHRJPc1x3s
lyZitCJ3ryJjVCbIwyboAoQ8xSsmaKFG7NcG0RPp4YGLKpOZ4id5tQs1C5TLK/8g
+IFBOnucVDmLyEu1xWteGbTmIZZD8XAP14lCCu1S2P/kDpfX0YVDAwKeoBbtAHcr
wwPt4d0qNG04AC69jXNxtgCa9h7aeD8dgGgX7ogpYx/QjA/c4Q+oQE5nNzChMmKL
2QFja6nT+UL1jQjn4MvSUh+IFh/qjUzbjTHbWHtREB7/AXPO4pkeeJioIINdvvCY
cuVqnyk0uxYil1VskcBHI7KB7gMk4MFWdmfqHmSIjM1LLxheP7nsmEL/DLdbRDm0
mQiUPZGD749HGJg5USNeNZl7ZHrGzI6Wb9tMezoV1XRyg1o0CmAf+sEeaDVmJcMD
xTrv+vpTO/U+0yaNQaCNmxkwn9HOthowlxcLhGINPiB6kTAezTpiN1Yr/aAqn9e4
3+AC34AI/2AOnpZ8Tc8eHmDKtAsB6JhWrRAE6pq+GzYCEm8Vx3R9CzJp3PeZGDsH
GJr3qOEiZ8IYGtwmbuJDFuVVjBTYvG4Tl8iDDxcUS3rZQpFMR9t7RjqkyRSmsaWz
/0G5gWW7lsIUlmlaOl/ctq3tiXj6x853FevucX2bYCGAHuR5h9dRmJ/yl6URuDAw
trJgH7rYMJWMYR32xwuUziLOP9GyuAt0H55AKbCcjul4z6JAt85tTutAinH1DWix
DepAEbCAredhndeAZOPRHt9YCBmWH/r7aZ8WHtuNzud7bRwgfalW45gHN+LCCbrW
vYjjExr6E4jvwS0nPcjCK8xKRhTDouJPXeW1Jws3l+zVz/TPXlfU0zs9bEB6al8Z
NfIPl2oapw931HM6xqlNSf7Pp6cyO1tYxwkWAcru3vSBCco4HA01baosdYkwC+gB
4RpuVpVCvvvZyiGPMZl2P/8to1SjrAPqXCn2LBnUIAskoS2ZlgpEoZivUb1p9T7X
cp1t0D39eo6VAgSooEDTh5hyXSlIdS13+8ZXdH3l5o/fty1yQh0+YUYdGhQq5zXt
YlEIAwNYrGqKaGtEuKRFu+z8jNM9nNNDXOL3b7RZvQu9xdRNXUxjnNlmfMe85ceo
reStk197KcdvXUhOqkDnAQfaIB15IBcLtMrmYAVq0N8cVR8hVbt8kB/E8lbl3F8p
EA/KLgvpId+Ey437O87cDfSe9hjsQMkDgM3xLlKR0R7xGTF5y7WUbduGbE1Lg6j4
uLEM+1YmZVLaAif+C8IjvFEo6EWGZXqqpW5BeMWbCKf/Kx7jP2rizy7UozO0btqj
onPTvce2pe22+6+WBbDWV57lx0cf+IEReEqa13Hp47Jk9eFDe94fMI8xJS6v3zkF
NYMCK9Tr96EWyV2+y026/CCKyzy2PE8f4lQRQpQH9VkfihgxCVQI/1Ut/zF91Sdu
RuVo0j4tKMUdSkJT8OIjFgV4CgvVlvSVPoumQYrvO9zaQrzaEH/TRSvGw//wRbHZ
glLkaVy3bzkpVT7yr+hNt/wB/lKdyxjxfjCLsrrn5drzUdD3ASKAwABH/Pjpx2+f
voED9b3x84ZKvwj7CuhbKPCOwY0b3TxQGEAfGw/2qFAxaI9fAYb5/Ll8iU8lRoY0
/2vaDHnxIgcI8+bt60CPHj9+9Yo++fDOnj0oTJmKegpDFAx4TUNZffcka1YpXOVJ
8cBVCr0OUoCa7dmhp9p9PnuynccB7jyedNvyZIs3Lt62bOu+/bu2rVrBbwfPPaw2
7twCHBg75tCYgz7JknNavhwy883NnDt7/gw6NEN9+/Z9nDdToD4pbgz+4fOBHwfV
1GrbBjHFZeyVVF76dokP5M2CflLus+nQjx17FC+O1shx45t6IPXNGxqhn8HYDhqC
8HdvCjV8Evl1F7154eUCeH8G5efBQ9F6We09Wbq0KVOroZ5g1SrPE/V4IA9YYHHV
AVkJLhhFWnsR5lNcDszDXv8BhsmVmGMUVhQZYmrVxcE+cd0V14iHhWgiXSXCBcFO
FEIGGVyMQWbRZTbaqBl6Ou7IY480YfbjPh7YsYZJ/QinDwL89GNSk/lMkZID+uDz
m2/5JJQaQ8TtFkUfPz5kRz8HSHFHFM9x9Icbf/jhxpHqOVDaPkwYhNBsquUDQpNU
2HOknT7+qNNkE/r0E1BB0RPfgPRpxWijAH4VVqRiJTjWggsKdiGGPbm4UwEQMMah
pxaq+OmnbFko6qcrKrbppmytmJhcqz42o2MWQabPrZPteqNz6qmW45/CDkssZw7Q
w2R5FqnmwAPY8ZNdP9KCRM0UIFxb2xT3+EMNljfhYdD/HHfY0YYWqSX3xxtvtOGH
c6o9NIcOTuBDHh9f9PMARpYRpwQ/M5GWHZ8R8PPAssWqZhljPLlV6KFByZeoUfTV
U2A9YR0oFj2TWsrxPGlB+OphKjpQgK2OlRqZySU3djKnjC326VyN8URjyjKrSmvK
kUWmk2SM8dqrZTgFe3DRRg+bq7MJCYdwaQjs87SzHy2kpEklNQnClcchBx1Hm6DW
UGvRdYDkJi9cLdGe02YZgBpqYMGIv6PtM9RHNR6N8GUIKBbngg5rLKmkf1fK8aUf
82Xiqi8+VnPNjk32M4w158ryyozDtbOMjtNo+c4w7uozZUGPnhnbeJ+OumgXiWq6
/7urN4ZRiEsOHK20MiFnR3R+sFFwQ7ofhCTd0g5M8FAVsV0AUQSv1FCSlZle9GU+
O8Bqe5aONbjDZjGYoMdRuIUWXyf2xLjOFj2e863o50q5dZ+D/nOtoc/YuOg+sx85
0PqTrh70qf8PwPT4Lz0NYU+cnka3qd0kOdHp19YCwIHfxUZfpIlTjYQGKLrRg2mj
CWDzLAO7nYTIMH0rHMcapJbDYYpmktOc40o2GfuBbob3a5/9zke589EIcqvjFQ4T
lhMZjm6IpdPMrzyIxCQSK2h3Q84b3GAHRYABC3UAR0IGooU/zEES9BLCnvL1wZw0
b4EccAACBpjE0d0KRYXJlPkb23iiGJWofD2kzA57iMM8so9nsNMhDXelq0DdT4ZC
HKIhS3dEoilxkYwUlrsWuI966EkiYBRIATqQrJJMhIM8QmMjcXIjHMaoRX1BXFsk
J0LFxfAx+BOd9IJGSCC6EpZBfKUhbyk0Mf7Kk5/spS+RRrfsLMl4/wrmUAh2vF/+
r38gxCNl6Oe59InuZ4KcIS6vic1sanOXQyuivoClzHCKs0dJilNpmoiTA7KPl+P8
k6+u+bxCBmqe26ynPbfpzXxys4Pt7Kc/Q3OjmmDwn3g712juidCEKrRX+ixisNhJ
0IhKdKL/bN1C+efNd170mhl1KGggSlG8BQQAOw==

--ufsnltbcmiqtetjk--



From fil@rezo.net  Fri Jun  8 09:55:47 2001
From: fil@rezo.net (Fil)
Date: Fri, 8 Jun 2001 10:55:47 +0200
Subject: [Mailman-Developers] admlogin.html missing in the current cvs (2.1a2) for i18n
Message-ID: <20010608105547.B15028@orwell.bok.net>

Just to mention that the admlogin.html template is missing in the languages
templates (I had to copy it from templates/en/admlogin.html to
templates/fr/admlogin.html). 

-- Fil



From darrell@grumblesmurf.net  Fri Jun  8 18:21:59 2001
From: darrell@grumblesmurf.net (Darrell Fuhriman)
Date: 08 Jun 2001 10:21:59 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <20815.991975466@kanga.nu>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com>
 <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu>
 <15135.35955.641425.315789@anthem.wooz.org> <6892.991931179@kanga.nu>
 <200106072132.f57LW3r27985@quill> <20815.991975466@kanga.nu>
Message-ID: <tsh66e6khu0.fsf@pickwick.pdx.osdl.net>

J C Lawrence <claw@kanga.nu> writes:

> baggage than I consider justifiable for an MLM or for sites which
> have no other reason (or wish) to run Zope.

I couldn't agree more.  Zope is a very complex piece of software
that I have no use for on my site, and no wish to maintain.  I'd
really rather see Mailman be able to run with nothing more than
python and the Mailman tar ball.

Darrell



From chuqui@plaidworks.com  Fri Jun  8 18:49:01 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 8 Jun 2001 10:49:01 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <tsh66e6khu0.fsf@pickwick.pdx.osdl.net>
Message-ID: <200106081748.KAA08934@scv1.apple.com>

On Friday, June 8, 2001, at 10:21 AM, Darrell Fuhriman wrote:

> J C Lawrence <claw@kanga.nu> writes:
>
>> baggage than I consider justifiable for an MLM or for sites which
>> have no other reason (or wish) to run Zope.
>
> I couldn't agree more.  Zope is a very complex piece of software
> that I have no use for on my site, and no wish to maintain.

There are very good reasons for doing someething like this, especially 
for those crazy people like me trying to integrate mailman into a 
larger, integrated environment.  But the point is a good one -- this 
stuff should be optional, so people running "lake-witchita-
friends@witchita.org" don't need to hire someone like me to install 
mailman..

The default should be simple and straightforward -- and the key is to 
build interfaces and APIs that allow users to plug in replacement 
modules for functionality...




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

When an agnostic dies, does he go to the "great perhaps"?



From claw@kanga.nu  Fri Jun  8 19:48:52 2001
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 08 Jun 2001 11:48:52 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Fri, 08 Jun 2001 10:49:01 PDT." <200106081748.KAA08934@scv1.apple.com>
References: <200106081748.KAA08934@scv1.apple.com>
Message-ID: <32082.992026132@kanga.nu>

On Fri, 8 Jun 2001 10:49:01 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Friday, June 8, 2001, at 10:21 AM, Darrell Fuhriman wrote:
>> J C Lawrence <claw@kanga.nu> writes:

>>> baggage than I consider justifiable for an MLM or for sites
>>> which have no other reason (or wish) to run Zope.

>> I couldn't agree more.  Zope is a very complex piece of software
>> that I have no use for on my site, and no wish to maintain.

> There are very good reasons for doing someething like this,
> especially for those crazy people like me trying to integrate
> mailman into a larger, integrated environment.  But the point is a
> good one -- this stuff should be optional, so people running
> "lake-witchita- friends@witchita.org" don't need to hire someone
> like me to install mailman..

There's also the small fact that the environment one is integrating
into may be (is in my case) Zope unfriendly.  Requiring Zope would
require me to move away from other designs I'd much rather not.

> The default should be simple and straightforward -- and the key is
> to build interfaces and APIs that allow users to plug in
> replacement modules for functionality...

Quite.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From barry@digicool.com  Sat Jun  9 05:30:48 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sat, 9 Jun 2001 00:30:48 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <tsh66e6khu0.fsf@pickwick.pdx.osdl.net>
 <200106081748.KAA08934@scv1.apple.com>
Message-ID: <15137.42616.946686.509801@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> The default should be simple and straightforward -- and the
    CVR> key is to build interfaces and APIs that allow users to plug
    CVR> in replacement modules for functionality...

I couldn't agree more.

-Barry


From extacyhigh152@webtv.net  Sat Jun  9 08:28:33 2001
From: extacyhigh152@webtv.net (calexico ca.)
Date: Sat, 9 Jun 2001 00:28:33 -0700 (PDT)
Subject: [Mailman-Developers] thank you guys for showing me the way.
Message-ID: <15009-3B21D021-2026@storefull-106.iap.bryant.webtv.net>


From nb@thinkcoach.com  Sat Jun  9 12:54:58 2001
From: nb@thinkcoach.com (Norbert Bollow)
Date: Sat, 9 Jun 2001 13:54:58 +0200
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <32082.992026132@kanga.nu> (message from J C Lawrence on Fri, 08
 Jun 2001 11:48:52 -0700)
References: <200106081748.KAA08934@scv1.apple.com> <32082.992026132@kanga.nu>
Message-ID: <200106091154.f59Bswt05724@quill>

J C Lawrence <claw@kanga.nu> wrote:
> There's also the small fact that the environment one is integrating
> into may be (is in my case) Zope unfriendly.  Requiring Zope would
> require me to move away from other designs I'd much rather not.

Yes.  Zope should not be _required_, but I think it is not a
problem if some changes like e.g. replacing template texts
require shell access unless you have Zope.

BTW I don't think that Mailman should be married to Zope in any
way.  When another (Free Software) application server framework
becomes very popular, I think it would be good for Mailman to be
compatible with framework, too.  The choice of application
server framework (if any) would be an installation-time
configuration option.

Chuq Von Rospach <chuqui@plaidworks.com> had written:
> > The default should be simple and straightforward -- and the key is
> > to build interfaces and APIs that allow users to plug in
> > replacement modules for functionality...

Greetings, Norbert.

-- 
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59     Fax +41 1 972 20 69      nb@freedevelopers.net


From linuxsoftlandindia@hotpop.com  Mon Jun 11 13:25:21 2001
From: linuxsoftlandindia@hotpop.com (Murali Kumar)
Date: Mon, 11 Jun 2001 17:55:21 +0530
Subject: [Mailman-Developers] Mailman v2.0.5
Message-ID: <5.1.0.14.2.20010611175434.00a01ec0@pop.hotpop.com>

--=====================_3143919==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


Dear Sir,

Congratulations for Your Excellent Software ( Mailman v2.0.5     )
Your software has been selected in the category "Email ------> Email List 
Management" by our editorial team. Come to 
http://www.softlandindia.com/Linux/    Onestop site for Softwares; See the 
Winners.

Our Home Page: http://www.softlandindia.com/Linux/

Your Excellent Software Located 
at:  http://www.softlandindia.com/Linux/EmailList.htm

Editors Pick Logo at:

http://www.softlandindia.com/editorspick.gif

Please inform us of updates and trial versions. We would like to review
them early for our readers.


Thanking You,

With Kind Regards,

K.Murali Kumar
Webmaster
www.softlandindia.com
Email Ids: info.softlandindia@hotpop.com and softlandindia@hotpop.com
----------------------------------------------------------------------------------------------------------------
To unsubscribe, send email to: softlandindia@hotpop.com
SubJect: Unsubscribe


--=====================_3143919==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
Dear Sir, <br><br>
Congratulations for Your Excellent Software ( <b>Mailman v2.0.5
&nbsp;&nbsp;&nbsp; </b>) <br>
Your software has been selected in the category &quot;<b>Email ------&gt;
Email List Management&quot; </b>by our editorial team. Come to
<a href="http://www.softlandindia.com/Linux/" eudora="autourl"><font color="#0000FF">http://www.softlandindia.com/Linux/</a></font>&nbsp;&nbsp;&nbsp;
Onestop site for Softwares; See the Winners. <br><br>
<b>Our Home Page</b>:
<a href="http://www.softlandindia.com/Linux/" eudora="autourl"><font color="#0000FF">http://www.softlandindia.com/Linux/</a><br><br>
</font><b>Your Excellent Software Located at: </b>
<a href="http://www.softlandindia.com/Linux/EmailList.htm" eudora="autourl">http://www.softlandindia.com/Linux/EmailList.htm</a><br><br>
Editors Pick Logo at: <br><br>
<font color="#0000FF"><a href="http://www.softlandindia.com/editorspick.gif" eudora="autourl">http://www.softlandindia.com/editorspick.gif</a></font>
<br><br>
Please inform us of updates and trial versions. We would like to review <br>
them early for our readers.<br><br>
<br>
<font face="arial">Thanking You,<br><br>
With Kind Regards,<br><br>
K.Murali Kumar <br>
Webmaster <br>
</font><font color="#0000FF"><u><a href="http://www.softlandindia.com/" eudora="autourl">www.softlandindia.com</a></u></font><font face="arial"> <br>
Email Ids: info.softlandindia@hotpop.com and softlandindia@hotpop.com<br>
----------------------------------------------------------------------------------------------------------------<br>
To unsubscribe, send email to: softlandindia@hotpop.com <br>
SubJect: Unsubscribe<br><br>
</font></html>

--=====================_3143919==_.ALT--




From marc_news@valinux.com  Tue Jun 12 05:52:48 2001
From: marc_news@valinux.com (Marc MERLIN)
Date: Mon, 11 Jun 2001 21:52:48 -0700
Subject: [Mailman-Developers] site-wide list configuration...
In-Reply-To: <200105251716.f4PHGaq17092@lists.apple.com>; from chuqui@plaidworks.com on Fri, May 25, 2001 at 10:18:16AM -0700
References: <200105251716.f4PHGaq17092@lists.apple.com>
Message-ID: <20010611215248.A7594@moremagic.merlins.org>

On Fri, May 25, 2001 at 10:18:16AM -0700, Chuq Von Rospach wrote:
> But take this as a real-world case where splitting out content admin 
> from list admin from site admin and allowing the folks higher up in the 
> hierarchy to delegate or freeze what sub-admins can do. Because while 
> it's nice to think everyone will play nice and follow instructions, in 
> the real world, it doesn't always happen.

While built in support  in mailman would be nice, in  the meantime, it's not
very hard to reset  all the settings to the approved  defaults every 10mn or
so with config_list

Marc
-- 
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger marc_f@merlins.org for PGP key


From yanuar-n@unisosdem.org  Tue Jun 12 11:41:14 2001
From: yanuar-n@unisosdem.org (Yanuar Nugroho)
Date: Tue, 12 Jun 2001 11:41:14 +0100
Subject: [Mailman-Developers] adding anonymity features?
Message-ID: <054101c0f32c$344c4c60$1fa95882@halls.umist.ac.uk>

Hi there!

A short introduction: I am a MSc student in Information Systems Engineering
at UMIST, Manchester, UK, who is now doing my dissertation on applying
anonymity in mailing list communication to examine the communication
behaviour among participants.

The idea is basically hiding the identity of the sender so that the
communication will be based on what is being communicated and not who is
communicating in the group. The possible usage in the future might range
from decision making within organisation (or network/group) to conflict
resolution.

I am interested in Mailman (GNU milist mgt system) to be developed or
equipped with anonymity features. Is it possible to add "anonym feature" in
Mailman? Can you give me a clue from where should I start? I have with me
now the source-code of Mailman (written in Python) together with its
documentation.



Cheers,
Yanuar
ps. I am an NGO activist in Indonesia, where the possible advantageous usage
of this feature might be huge among many NGO/non-governmental/non-commercial
group that exist.

Yanuar Nugroho
http://yanuar-nugroho.mainpage.net
http://www.yanuar-n.net
----------------------------------------
PG. Stud. MSc. Information Systems Engineering,
Dept. of Computation, UMIST, Manchester - UK




From marc_news@valinux.com  Wed Jun 13 07:42:25 2001
From: marc_news@valinux.com (Marc MERLIN)
Date: Tue, 12 Jun 2001 23:42:25 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010601120743.64585@scfn.thpl.lib.fl.us>; from jra@baylink.com on Fri, Jun 01, 2001 at 12:07:43PM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us>
Message-ID: <20010612234225.F7594@moremagic.merlins.org>

On Fri, Jun 01, 2001 at 12:07:43PM -0400, Jay R. Ashworth wrote:
> On Fri, Jun 01, 2001 at 11:54:15AM -0400, Barry A. Warsaw wrote:
> > Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
> > support user-disabling of reminder messages, on a per-list, or
> > per-virtual domain basis.
> 
> Well, damnit Barry, what took you so long?

BTW, at sourceforge, every month, we get mail from users asking who we dared
sending them their mailman password in cleartext by mail.

I've gotten tired to answer them, and wrote this:
http://marc.merlins.org/netrants/mailman-password.txt

Feel free to steal and re-use while you're still running mm 2.0.

This also goes for the other fine stuff available here:
http://marc.merlins.org/netrants/

:-)

Marc
-- 
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger marc_f@merlins.org for PGP key


From thomas@xs4all.net  Wed Jun 13 09:51:08 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 13 Jun 2001 10:51:08 +0200
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010612234225.F7594@moremagic.merlins.org>
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <20010612234225.F7594@moremagic.merlins.org>
Message-ID: <20010613105108.A1659@xs4all.nl>

On Tue, Jun 12, 2001 at 11:42:25PM -0700, Marc MERLIN wrote:

> BTW, at sourceforge, every month, we get mail from users asking who we dared
> sending them their mailman password in cleartext by mail.

> I've gotten tired to answer them, and wrote this:
> http://marc.merlins.org/netrants/mailman-password.txt

You missed the other aspect of the monthly reminders: informing people what
lists they're subscribed to. I don't care about getting my most-insecure
password mailed to me, but I do very much care about the overview of lists
I'm subscribed to, lest I forget some.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From jra@baylink.com  Wed Jun 13 17:16:41 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Wed, 13 Jun 2001 12:16:41 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010612234225.F7594@moremagic.merlins.org>; from Marc MERLIN <marc_news@valinux.com> on Tue, Jun 12, 2001 at 11:42:25PM -0700
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <20010612234225.F7594@moremagic.merlins.org>
Message-ID: <20010613121641.35557@scfn.thpl.lib.fl.us>

On Tue, Jun 12, 2001 at 11:42:25PM -0700, Marc MERLIN wrote:
> BTW, at sourceforge, every month, we get mail from users asking who we dared
> sending them their mailman password in cleartext by mail.

Well, alas, merely telling them "do not use a valuable password" isn't
really good enough, and I'm on the "ask a reminder question" side of 
this fence, myself.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Thu Jun 14 19:27:42 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 14 Jun 2001 14:27:42 -0400
Subject: [Mailman-Developers] forwarded message from Guido van Rossum
Message-ID: <15145.542.502856.11584@anthem.wooz.org>

--OwxX7sxeZ1
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit


For those of you concerned in these sorts of issues, this is great
news.  I've done some limited testing of MM2.0.5 and MM2.1alpha
against Python 2.0.1 and it all seems to work.  I think we can finally
put the GPL-compatibility issue to bed.

-Barry


--OwxX7sxeZ1
Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 7bit

Return-Path: <python-dev-admin@python.org>
Delivered-To: barry@wooz.org
Received: from mail.python.org (mail.python.org [63.102.49.29])
	by mail.wooz.org (Postfix) with ESMTP id 54D47D35F0
	for <barry@wooz.org>; Thu, 14 Jun 2001 13:34:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 3.21 #1)
	id 15AazQ-0004gd-00; Thu, 14 Jun 2001 13:33:04 -0400
Received: from [208.184.249.89] (helo=odiug.digicool.com)
	by mail.python.org with esmtp (Exim 3.21 #1)
	id 15AazJ-0004gC-00; Thu, 14 Jun 2001 13:32:57 -0400
Received: from odiug.digicool.com (guido@localhost)
	by odiug.digicool.com (8.11.0/8.11.0) with ESMTP id f5EHUgX03621;
	Thu, 14 Jun 2001 13:30:42 -0400
Message-Id: <200106141730.f5EHUgX03621@odiug.digicool.com>
Errors-To: python-dev-admin@python.org
Precedence: bulk
List-Help: <mailto:python-dev-request@python.org?subject=help>
List-Post: <mailto:python-dev@python.org>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
	<mailto:python-dev-request@python.org?subject=subscribe>
List-Id: Python core developers <python-dev.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
	<mailto:python-dev-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-dev/>
From: Guido van Rossum <guido@digicool.com>
Sender: python-dev-admin@python.org
To: python-announce@python.org, python-list@python.org,
	python-dev@python.org
Subject: [Python-Dev] Python 2.0.1c1 - GPL-compatible release candidate
Date: Thu, 14 Jun 2001 13:30:42 -0400
X-BeenThere: python-dev@python.org
X-Mailman-Version: 2.0.5 (101270)

With a sigh of relief I announce Python 2.0.1c1 -- the first Python
release in a long time whose license is fully compatible with the GPL:

    http://www.python.org/2.0.1/

I thank Moshe Zadka who did almost all of the work to make this a
useful bugfix release, and then went incommunicado for several weeks.
(I hope you're OK, Moshe!)

Note that this is a release candidate.  We don't expect any problems,
but we're being careful nevertheless.  We're planning to do the final
release of 2.0.1 a week from now; expect it to be identical to the
release candidate except for some dotted i's and crossed t's.

Python 2.0 users should be able to replace their 2.0 installation with
the 2.0.1 release without any ill effects; apart from the license
change, we've only fixed bugs that didn't require us to make feature
changes.  The SRE package (regular expression matching, used by the
"re" module) was brought in line with the version distributed with
Python 2.1; this is stable feature-wise but much improved bug-wise.

For the full scoop, see the release notes on SourceForge:

    http://sourceforge.net/project/shownotes.php?release_id=39267

Python 2.1 users can ignore this release, unless they have an urgent
need for a GPL-compatible Python version and are willing to downgrade.
Rest assured that we're planning a bugfix release there too: I expect
that Python 2.1.1 will be released within a month, with the same
GPL-compatible license.  (Right, Thomas?)

We don't intend to build RPMs for 2.0.1.  If someone else is
interested in doing so, we can link to them.

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev

--OwxX7sxeZ1--


From mtearle@tearle.com  Fri Jun 15 04:16:05 2001
From: mtearle@tearle.com (Mark Tearle)
Date: Fri, 15 Jun 2001 11:16:05 +0800 (WST)
Subject: [Mailman-Developers] Re: auto aprroval
In-Reply-To: <E159m5D-0006Gk-00@usw-sf-web2.sourceforge.net>
Message-ID: <Pine.LNX.4.31.0106151103560.6241-100000@tartarus.uwa.edu.au>

On Tue, 12 Jun 2001, Marcin Bujak wrote:

> hi
> i'm having a problem with your patch "Auto Approval of
> subscriptions for certain domains"
>
> cd mailman-2.0.5/Mailman
> patch < None.txt
> cd ..
> make clean
> make install
>
> if i choose a privace options from privacy options section
> mailman send a bug in ....
>
> can you help me ?
>

Hiya

The patch is buggy and I should really get around to updating the
Sourceforge web page about it.  It works OK if you create a new list
but doesn't detect if the field is missing in an existing list
and add it unfortunately.

I'm CC'ing mailman-developers to ask for advice, I know it goes
somewhere in the versioning code, but where?  And how do I do it such
that future upgrades etc don't break?

Yours
Mark
-- 
Mark Tearle - mark@tearle.com

 "The only good is knowledge and the only evil is ignorance." - Socrates



From barry@digicool.com  Fri Jun 15 05:46:56 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 15 Jun 2001 00:46:56 -0400
Subject: [Mailman-Developers] Re: auto aprroval
References: <E159m5D-0006Gk-00@usw-sf-web2.sourceforge.net>
 <Pine.LNX.4.31.0106151103560.6241-100000@tartarus.uwa.edu.au>
Message-ID: <15145.37696.227562.505393@anthem.wooz.org>

>>>>> "MT" == Mark Tearle <mtearle@tearle.com> writes:

    MT> The patch is buggy and I should really get around to updating
    MT> the Sourceforge web page about it.  It works OK if you create
    MT> a new list but doesn't detect if the field is missing in an
    MT> existing list and add it unfortunately.

    MT> I'm CC'ing mailman-developers to ask for advice, I know it
    MT> goes somewhere in the versioning code, but where?  And how do
    MT> I do it such that future upgrades etc don't break?

The trick is to bump the DATA_FILE_VERSION in Mailman/Version.py and
to add a little bit of code to Mailman/versions.py.

versions.py is the file that essentially updates the (logical)
database schema when it changes.  In the past there has been radical
surgery in the schema, but these days it's mostly just adding new
attributes to older lists.  Look for function NewVars() in versions.py
to see where you can add default settings for your new attributes.

When a MailList object is instantiated, its database -- which is kept
as a marshaled dictionary on disk -- contains an attribute
data_version which is compared against DATA_FILE_VERSION.  If the
latter is greater, then versions.py's Update() function is called.

This works fairly well in practice, but it breaks down when you have
multiple patches each bumping DATA_FILE_VERSION, e.g. your patch
cranks it to 23 while I make changes to the CVS to bump it to 27.
It's probably not enough of a pain to fix, since it's quite likely
that the whole mechanism will be overhauled for Mailman 3.0.

Cheers,
-Barry


From y.nugroho@student.umist.ac.uk  Fri Jun 15 14:52:36 2001
From: y.nugroho@student.umist.ac.uk (Yanuar Nugroho)
Date: Fri, 15 Jun 2001 14:52:36 +0100
Subject: [Mailman-Developers] anonymity features
References: <053701c0f32b$daf4e640$1fa95882@halls.umist.ac.uk> <15142.9927.869879.114118@anthem.wooz.org>
Message-ID: <01c001c0f5a2$6fc59260$1fa95882@halls.umist.ac.uk>

Dear folks,

I'm doing a research on "how anonymity in CMC influences communication
behaviour among participants/communicators". This will be done in
asynchronous mode, and I have chosen to use GNU Mailman rather than any
other systems.

This is the list of the "anonymity feature" requirements that should be
ideally able to include.
1. Removing the sender identities (it has been solved, i think. in "privacy"
setting and cleanse.py, right?)
2. Archiving sent message (how is actually a message archived in Mailman?)
3. Adding additional text from a database into a message before being
distributed (is it possible to create text-based database and include a
particular data to the message? how can Mailman query and retrieve a data to
be included -- how can Mailman "scan" a message and find a "keyword" and use
the keyword to retrieve relevant data?
4. Other idea for the no.3 above, using "phantom messages" as the database.
The problem is how can Mailman automatically add a phantom message to a
message?
5. How to customise the text-wrapping (text area in the email) in Mailman?
How to set, for example, the LEFT Margin to be 5 characters?

I think I have to stop. It has been too much. Sorry-sorry-sorry very much if
this realy bothers you. I am desperate in doing this research ... :) I don't
know how to do this. Not even a clue. I'm totally a new comer in Mailman,
Python and this GNU environment, but I want to learn. Anyone can help me?
(thanks to Barry Warsaw who encouraged me to join this milist. also for
Yaron Zarfati, Detlef Neubauer & JC Lawrence who tried to solve my previous
problems in handling the header. thanks!:)).

Cheers /Yanuar.
PS. If any of you need further info, I can send my preliminary works/report
via your individual emails. This probably helps you to know the context of
my research.


Yanuar Nugroho
http://yanuar-nugroho.mainpage.net
http://www.yanuar-n.net
----------------------------------------
PG. Stud. MSc. Information Systems Engineering,
Dept. of Computation, UMIST, Manchester - UK



From dang@mindsqueeze.net  Fri Jun 15 19:56:37 2001
From: dang@mindsqueeze.net (Danny Graham)
Date: Fri, 15 Jun 2001 11:56:37 -0700
Subject: [Mailman-Developers] Configuring mailman without the scripts?
Message-ID: <002c01c0f5cc$fa42f700$6401a8c0@cx199427a>

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01C0F592.3B4609D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I am unable to find the config files on the server that is hosting me.  =
They would probably not appreciate it if I changed them anyways :)  Is =
there anyway for me to customize and change the welcome message to =
subscribers?  Basically I just want to give them a URL to unsubscribe at =
and remove the info about how to post to the list...  Help would be =
TOTALLY appreciated.

-- Cheers

- Danny Graham

-------------------------------------------------------------------------=
-------=20

//liberate possibility::.
     --MIND SQUEEZE INTERACTIVE

     //::




------=_NextPart_000_0029_01C0F592.3B4609D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>I am unable to find the config files =
on the=20
server that is hosting me.&nbsp; They would probably not appreciate it =
if I=20
changed them anyways :)&nbsp; Is there anyway for me to customize and =
change the=20
welcome message to subscribers?&nbsp; Basically I just want to give them =
a URL=20
to unsubscribe at and remove the info about how to post to the =
list...&nbsp;=20
Help would be TOTALLY appreciated.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>-- Cheers</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>- Danny Graham</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana=20
size=3D2>----------------------------------------------------------------=
----------------=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>//liberate=20
possibility::.<BR>&nbsp;&nbsp;&nbsp;&nbsp; --MIND SQUEEZE=20
INTERACTIVE</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
//::</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2><BR></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0029_01C0F592.3B4609D0--



From dang@mindsqueeze.net  Fri Jun 15 20:01:24 2001
From: dang@mindsqueeze.net (Danny Graham)
Date: Fri, 15 Jun 2001 12:01:24 -0700
Subject: [Mailman-Developers] Configuring mailman with the scripts?
Message-ID: <003c01c0f5cd$a57edf30$6401a8c0@cx199427a>

I am unable to find the config files on the server that is hosting me.  They
would probably not appreciate it if I changed them anyways :)  Is there
anyway for me to customize and change the welcome message to subscribers?
Basically I just want to give them a URL to unsubscribe at and remove the
info about how to post to the list...  Help would be TOTALLY appreciated.

-- Cheers

- Danny Graham

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

//liberate possibility::.
     --MIND SQUEEZE INTERACTIVE

     //::






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

//liberate possibility::.
     --MIND SQUEEZE INTERACTIVE

     //::



From carson@taltos.org  Fri Jun 15 23:55:59 2001
From: carson@taltos.org (Carson Gaspar)
Date: Fri, 15 Jun 2001 15:55:59 -0700
Subject: [Mailman-Developers] Postfix DSN handling
Message-ID: <483113867.992620559@ZATHROS>

mailman 2.0.5 does not handle Postfix DSN messages for delayed mail. Has 
this been fixed in the development tree, or should I attempt to patch the 
code myself?

-- 
Carson Gaspar - carson@taltos.org
Queen trapped in a butch body


From thomas@xs4all.net  Sat Jun 16 00:15:45 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 16 Jun 2001 01:15:45 +0200
Subject: [Mailman-Developers] Braindump on new archiver
Message-ID: <20010616011545.B8098@xs4all.nl>

I've been thinking about re-doing the whole archiver thing in Mailman for a
while now, and I need to start writing these things down before I forget
about them. What follows is basically a braindump, for your amusement and
free to comment on.

First off, I have a couple of handicaps. Some are severe. The first one is
that I have very little time, which is one of the reasons I'm writing this
braindump: I don't have time to implement it right now :P The other is that,
for a living, I build and maintain large to very large, high-performance
internet servers (mostly Apache webservers with bells 'n whistles.) This
means I am usually too performance oriented. And lastly: I like the
'Maildir' mailbox format very much. This is a handicap because,
unfortunately, not all mail programs support it. 'Pine', specifically, is
boycotting the Maildir format (don't ask me why, I gave up on them.)

The good thing about the Maildir format is that it's very NFS secure. All of
our customers (except a handful who refuse to upgrade from 'elm' to 'mutt')
have a maildir mailbox, and we have 6 SMTP delivery boxes, 5 POP retrieval
boxes, one IMAP retrieval box (used only for our webmail server, which is
why it's only one right now) and several shell servers that have all kinds
of UNIX mail clients running. The mailspool itself is a dedicated NFS server
(a NetApp Filer.) We have a patched version of Pine that works with maildir
whether it likes it or not :)

Maildir works by making every message a file on its own. A mailbox is a
directory with three subdirectories, 'cur', 'new' and 'tmp'. Messages in
'new' are unread, messages in 'cur' are read, and messages in 'tmp' are in
transit. Message-metadata and state is maintained using the name of the
message-file itself. Delivery is done by creating a new file in
mailbox/tmp/, writing all data to it, and when it's done, moving it to
'new'. Writing data to a file is not trustworthy, over NFS, but renaming and
moving files are.

What I'm thinking for a Mailman archiver (or just any email-webarchiver, in
fact) is something like the following:

- Mail delivery can happen on any host. The Mailman process, after doing its
normal pre-delivery stuff, 'delivers' the message by dropping it in a
Maildir folder (rather than appending it to an 'mbox' mailbox) _and_
cgi-escaping/header-cleaning the message and dropping it in a
monthly/weekly/daily archive directory. The names are generated from uniq
data, like the time of day, the machine name and the process-id, possibly
hashed for obscurity. No locking is necessary. The URL to that _specific_
message is known as soon as Mailman calculates that name, and so it can be
inserted into the message that will be sent out to the list. (A common
feature request :)

- Non-text attachements could be saved as separate files, and replaced by
URLs to them in the archives. This should be possible to do both based on
type and on size, of course.

- The web archives are indexed once every [X] minutes, by looking at all the
new messages and processing them. Processing them consists of creating
indexes based on threads, subjects, author, etc, exactly like now. State
data could be stored in a .db (berkeley db, marshall, pickle, whatever) and
need not even be protected by a lock, if done properly: When started, the
indexing process should compare the mtime of the .db file with the current
time, as well as the last added new message. If the .db file is too new, it
should not run. If the .db file is old, and the newest message is newer, it
should touch the .db file (leaving it exactly as it is, just updating mtime)
and start working, keeping in mind to touch the file every now and then. The
new .db file should be written to a temporary name, and rename()'d when it's
done.

- The individual archive message URL's would actually call a CGI script that
looks up state data from the .db file, grab the cgi-escaped file, prepend
and append standard header and footer containing 'next in thread', 'next in
subject' and the like generated from the .db file, and feed that to the
browser. If state data is absent, but the message itself is there, teh
standard header and footer are added with a note saying that the message is
too new to have links to other messages -- but at least the message will be
visible.

Mail delivery and the Web-interface can be run on multitudes of servers, all
sharing data over NFS, and still be able to communicate in a sane way,
without waiting for eachother's locks forever. The only thing that can go
wrong is for a message to be archived and sent out, and then read and looked
up in the archives before the actual NFS data (the content of the message)
is visible on the web-interface machine(s). Given the average speed of SMTP,
I do not consider this a serious problem :)

One thing should run on a single server, however, and that's the
archive-indexing process. Given that news-feeding and mailing out passwords
should also be done on a single server, I don't see that as a problem either.
And all of the above should work just as fine on a single machine doing
everything on a local disk.

While under the 'the filesystem as the database' spell (hell, I'm still
under that one) I also considered using the filesystem to index messages
based on thread, subject, author, etc: a directory for each category, in
which symlinks point to messages. To go from message 'X' to the next message
in the thread, check where the symlink 'next-threads/X' points. The same for
previous-thread, next-author, etc. I'm not sure if it will managable without
adding a lockfile, nor how efficient it would be to generate overviews from
such data.

Another thing for consideration is the 'downloadable mailbox' link. Should
it download the maildir mailbox, or generate an mbox one on demand ? The
maildir mailbox is *very* useful for incremental updates, since all that
takes is checking which files you've already read. But, like I said, it's
not as widely supported as the crappy ol' mbox format. 

End-of-rant--we-will-now-return-to-your-regular-scheduled-static-ly y'rs,
 ;)
-- 
Thomas Wouters <thomas@xs4all.net>

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


From barry@digicool.com  Sat Jun 16 00:21:49 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 15 Jun 2001 19:21:49 -0400
Subject: [Mailman-Developers] Postfix DSN handling
References: <483113867.992620559@ZATHROS>
Message-ID: <15146.39053.54807.220914@anthem.wooz.org>

>>>>> "CG" == Carson Gaspar <carson@taltos.org> writes:

    CG> mailman 2.0.5 does not handle Postfix DSN messages for delayed
    CG> mail. Has this been fixed in the development tree, or should I
    CG> attempt to patch the code myself?

I didn't think Postfix /did/ DSN.  Hmm, maybe the new version does.

In any event MM2.0.5 does have a DSN bounce detector /and/ a Postfix
bounce detector.  Do you have an example of a message that's getting
through?  Can you forward it to me with full headers intact?

-Barry


From carson@gnac.com  Sat Jun 16 00:38:37 2001
From: carson@gnac.com (Carson Gaspar)
Date: Fri, 15 Jun 2001 16:38:37 -0700
Subject: [Mailman-Developers] Delayed Mail (still being retried) (fwd)
Message-ID: <188222687.992623117@ZATHROS>

--==========188240297==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Attached is one of the postfix messages that the bounce handler misses.

-- 
Carson Gaspar - carson@gnac.com
Security Architect - Global Networking and Computing, Inc.
--==========188240297==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is the Postfix program at host mail.knoware.nl.

####################################################################
# THIS IS A WARNING ONLY.  YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################

Your message could not be delivered for 4 hours.
It will be retried until it is 5 days old.

For further assistance, please contact <postmaster@knoware.nl>

			The Postfix program

	--- Delivery error report follows ---

<bashakst@knoware.nl>: temporary failure. Command output: bashakst: Over quota
    _

	--- Undelivered message follows ---

Received: from imail.ision.nl (imail.ision.nl [195.64.48.18])
	by mail.knoware.nl (Postfix) with ESMTP id 8B71E39740
	for <bashakst@knoware.nl>; Fri, 15 Jun 2001 20:44:19 +0200 (CEST)
Received: from lists.gnac.net (pluto.gnac.com [209.182.195.144])
	by imail.ision.nl (Postfix) with ESMTP id 4913626632
	for <bashakst@knoware.nl>; Fri, 15 Jun 2001 20:44:19 +0200 (CEST)
Received: from lists.gnac.net (localhost [127.0.0.1])
	by lists.gnac.net (Postfix) with ESMTP
	id 8F270106E4; Fri, 15 Jun 2001 11:40:00 -0700 (PDT)
Delivered-To: firewalls@lists.gnac.net
Received: from femail3.rdc1.on.home.com (femail3.rdc1.on.home.com [24.2.9.90])
	by lists.gnac.net (Postfix) with ESMTP id 11BDD106AD
	for <firewalls@lists.gnac.net>; Fri, 15 Jun 2001 11:30:28 -0700 (PDT)
Received: from Jason ([24.42.170.206]) by femail3.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010615183025.FVHI15293.femail3.rdc1.on.home.com@Jason>
          for <firewalls@lists.gnac.net>; Fri, 15 Jun 2001 11:30:25 -0700
From: "Jason Brown" <jason@onsidekick.com>
To: <firewalls@lists.gnac.net>
Subject: Network Sniffers
Message-ID: <000f01c0f5c9$ab247a20$6500a8c0@onside.tor>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: firewalls-admin@lists.gnac.net
Errors-To: firewalls-admin@lists.gnac.net
X-BeenThere: firewalls@lists.gnac.net
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:firewalls-request@lists.gnac.net?subject=help>
List-Post: <mailto:firewalls@lists.gnac.net>
List-Subscribe: <http://lists.gnac.net/mailman/listinfo/firewalls>,
	<mailto:firewalls-request@lists.gnac.net?subject=subscribe>
List-Id: Firewalls <firewalls.lists.gnac.net>
List-Unsubscribe: <http://lists.gnac.net/mailman/listinfo/firewalls>,
	<mailto:firewalls-request@lists.gnac.net?subject=unsubscribe>
List-Archive: <http://lists.gnac.net/pipermail/firewalls/>
Date: Fri, 15 Jun 2001 14:33:26 -0400

--==========188240297==========--



From Dale Newfield <Dale@Newfield.org>  Sat Jun 16 18:34:02 2001
From: Dale Newfield <Dale@Newfield.org> (Dale Newfield)
Date: Sat, 16 Jun 2001 13:34:02 -0400 (EDT)
Subject: [Mailman-Developers] Braindump on new archiver
In-Reply-To: <20010616011545.B8098@xs4all.nl>
Message-ID: <Pine.SUN.4.33.0106161327070.5110-100000@adder.cs.Virginia.EDU>

On Sat, 16 Jun 2001, Thomas Wouters wrote:
> Maildir works by making every message a file on its own. A mailbox is
> a directory with three subdirectories, 'cur', 'new' and 'tmp'.
> Messages in 'new' are unread, messages in 'cur' are read, and messages
> in 'tmp' are in transit.

What about file system limitations to the maximum number of files in a
directory?

I've not been a student at CMU for a long time, now, but while their mail
system also does a file per message it is on a special FS--AFS.

-Dale



From claw@kanga.nu  Sat Jun 16 20:35:08 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sat, 16 Jun 2001 12:35:08 -0700
Subject: [Mailman-Developers] Braindump on new archiver
In-Reply-To: Message from Dale Newfield <Dale@Newfield.org>
 of "Sat, 16 Jun 2001 13:34:02 EDT." <Pine.SUN.4.33.0106161327070.5110-100000@adder.cs.Virginia.EDU>
References: <Pine.SUN.4.33.0106161327070.5110-100000@adder.cs.Virginia.EDU>
Message-ID: <16575.992720108@kanga.nu>

On Sat, 16 Jun 2001 13:34:02 -0400 (EDT) 
Dale Newfield <Dale@Newfield.org> wrote:

> On Sat, 16 Jun 2001, Thomas Wouters wrote:
>> Maildir works by making every message a file on its own. A
>> mailbox is a directory with three subdirectories, 'cur', 'new'
>> and 'tmp'.  Messages in 'new' are unread, messages in 'cur' are
>> read, and messages in 'tmp' are in transit.

> What about file system limitations to the maximum number of files
> in a directory?

Typically this is an inode limit for the whole filesystem, not a
directory size issue.  Directory size is a performance issue that
different filesystems handle variously well (eg Ext2FS badly,
ReiserFS fairly well).  

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From thomas@xs4all.net  Sat Jun 16 22:05:48 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 16 Jun 2001 23:05:48 +0200
Subject: [Mailman-Developers] Braindump on new archiver
In-Reply-To: <16575.992720108@kanga.nu>
Message-ID: <20010616230548.C8098@xs4all.nl>

On Sat, Jun 16, 2001 at 12:35:08PM -0700, J C Lawrence wrote:
> On Sat, 16 Jun 2001 13:34:02 -0400 (EDT) 
> Dale Newfield <Dale@Newfield.org> wrote:
> 
> > On Sat, 16 Jun 2001, Thomas Wouters wrote:
> >> Maildir works by making every message a file on its own. A
> >> mailbox is a directory with three subdirectories, 'cur', 'new'
> >> and 'tmp'.  Messages in 'new' are unread, messages in 'cur' are
> >> read, and messages in 'tmp' are in transit.
> 
> > What about file system limitations to the maximum number of files
> > in a directory?

> Typically this is an inode limit for the whole filesystem, not a
> directory size issue.  Directory size is a performance issue that
> different filesystems handle variously well (eg Ext2FS badly,
> ReiserFS fairly well).  

Exactly. The NetApps we use have their own filesystem, which doesn't have an
inode limit (the WAFL filesystem is a very cool thing). They also use btree
directory indexes, so large directories are not a problem. I believe
ReiserFS and XFS (SGI's journalling filesystem, which is also ported to the
Linux kernel) also use btree directories.

That said, yes, for lists with a lot of small messages, inodes could become
a problem. I think most UNIX filesystems default to around
8k-bytes-per-inode nowadays, whereas the median size in my mailbox is about
2k. (Trust me.. it's a big enough sample size :-) I forgot to mention this,
but the number of files was one of the reasons not to go for the
directories-with-symlinks for archive data. Still, the problem can be
avoided by removing the maildir mailbox (converting it to an mbox one) when
the month (or week, or year, or whatever) ends and the archive is up to
date. If it turns out to be a problem.

Don't forget that the current system is also pretty inode-heavy, since every
archived message is already a file on its own. And don't think I'm
forgetting about non-Linux, non-NetApp-attached systems :) Our listservers
run BSDI and FreeBSD, both not brilliant in filesystem performance.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From chuqui@plaidworks.com  Sun Jun 17 08:46:47 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 00:46:47 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: <15146.28093.61335.281545@anthem.wooz.org>
Message-ID: <200106170738.f5H7cah28586@plaidworks.com>

On Friday, June 15, 2001, at 01:19 PM, Barry A. Warsaw wrote:

>     CVR> points. but we need to quantify what those points are and
>     CVR> what the impact is, so we can decide just how to move forward
>     CVR> on this.

> I'd love to see any statistic you (or anybody) gathers on this
> subject.  It's definitely intriguing, but right now I don't have the
> time or systems to do this kind of data gathering.
>

Okay, here's a first cut at some data.

I'm going to assume the following:

1000 subscribers -- no digest subscribers to simplify this. Assume just 
individual messages.

The message size is 10K, including header.

The bandwidth needed to generate a connection to send a message is 1K 
(which is pretty close)

The bandwidth needed to add an address to an existing message is about 
1/10 of a K (also pretty close).

The practical limit to the number of messages you can piggyback is 100, 
since this is specified in RFC2821 as the smallest number a site is 
REQUIRED to take. In practice, due to non-conformant sites, you have to 
be careful setting it beyond 50 these days, because sites set this 
number down because they think it slows down the spammers (I'm yet to be 
convinced it makes a damn bit a difference, especially since MTAs like 
postifx recognize the 452 and auto-adjust now. This is another place 
where sendmail seems behind the technology curve, FWIW)

How much bandwidth is used depends on these factors:

what your piggyback value is (in mailman, it's SMTP_MAX_RCPTS)

how many domains have > 1 subscriber.

Here's how plaidworks breaks down:

3101 subscribers across 1287 domains. that's an average of 2.3 
subscribers per domain, but the numbers skew wildly, so averages are 
meaningless.


Here's how my site breaks down:

# of subscribers			# of domains/# of users
---------------------			-----------------
1						263/263
2						142/284
3						40/120
4						19/76
5						16/80
6						10/60
7						7/49
8						3/24
9						6/54
10						2/20
11						2/22
12						2/24
13						1/
14						1/
16						1/
17						1/ (worldnet.att.net)
22						1/(juno.com)
29						1 (mindspring.com)
30						1 (pacbell.net)
35						1 (plaidworks.com)
43						1 (sympatico.ca)
53						1 (earthlink.net)
150						1 (home.com)
173						1 (yahoo.com)
228						1 (hotmail.com)
441						1 (aol.com)

if you're scoring at home, 37% of subscribers come from that last 4 
domains: 5% for home and yahoo, 7% for hotmail, and 14% for aol. those 
are your 500 pound gorillas (AOL is 800 pounds), and piss them off at 
your own risk.

At the other end, 8% of your users are the only subscriber from a 
domain. 16% are 1 or 2 per domain. 26% are on sites with 5 or fewer 
subscribers.

Time for some numbers.

Back to the 1000 member list for simplicity. The subscriber list breaks 
down to:

85	- 	1/85
45	-	2/90
12	-	3/36
6	-	4/24
[...]
48	-	1
55	-	1
73	-	1
142	-	1

That's 553, or 55% of the subscribers, wedged tightly on both ends of 
the curve. We can extrapolate what they'll do to bandwidth from the end 
cases if we need to.

Extreme case: SMTP_MAX_RCPTS = 1.

1000 subscribers * (10K message size + 1K overhead) = 11,000K bytes 
bandwidth.

Extreme case: SMTP_MAX_RCPTS = 100

These get sent  down the line this way:

85 * 11K
45 * (1 * 11K + 1 * .1K)
12 * (1 * 11K + 2 * .1K
6 * (1 * 11K + 3 * .1K)
[...]
1 * 11K + 47 * .1K
1 * 11K + 54 * .1K
1 * 11K + 72 * .1K
2 * 11K + 140 * .1K

Do you see how I got these numbers? In the case of the 12 domains with 
three subscribers, you have to make an 11K connection for the first 
message, and piggy back on the other two addresses at .01K each. You 
don't really see huge savings until the big domains, and you'll see AOL 
goes over the 100 address limit so gets split into two different 
messages.

For this 55%, the SMTP=1 is 6050K. For 100, it's 1711K bytes. That's 28% 
of the first number, so we're cutting 72% of the bandwidth by chunking 
at 100. The tradeoff is performance, though -- it takes a lot longer to 
deliver those AOL addresses, because if you split it into two batches, 
you can't parallelize the delivery. Package up 100 AOL addresses in one 
batch, none of them get delivered until all 100 addresses are sent to 
AOL and accepted. It's much faster to send them as ten batches of ten in 
parallel -- but that's the trade off here. Cut network bandwidth but 
slow delivery to the larger domains.

Okay, let's look at a case in the middle. SMTP_MAX = 5. The ones with 
less than 5 don't change, but the big domains do

85 * 11K
45 * (1 * 11K + 1 * .1K)
12 * (1 * 11K + 2 * .1K
6 * (1 * 11K + 3 * .1K)
[...]
1 * (10 * 11K + 38 * .1k)
1 * (11 * 11K + 44 * .1K)
1 * (15 * 11K + 58 * .1K)
1* (29 * 11K + 113 * .1K)

that works out to (trust me) about 2378K, or about a 60% reduction.

Let's try SMTP_MAX = 2.

85 * 11K
45 * (1 * 11K + 1 * .1K)
12 * (2 * 11K + 1 * .1K
6 * (2 * 11K + 2 * .1K)
[...]
1 * (10 * 11K + 38 * .1k)
1 * (11 * 11K + 44 * .1K)
1 * (15 * 11K + 58 * .1K)
1* (29 * 11K + 113 * .1K)

that works out to 2575K, or about a 57% cut.

By a rough look at those domains in the middle, I'd say these numbers 
are good +-10%.

What's this mean? Here's the executive summary:

The network penalty between SMTP_MAX = 1 (effectively VERP) and any kind 
of batching (SMTP > 1) is roughly 50%. To get VERP or customized footers 
or customized anything, you double your network bandwidth.

There is very little advantage to setting SMTP_MAX > 5, UNLESS your 
subscriber base is heavily stratified onto very few sites. If you have 
really large groups of subscribers on AOL or Hotmail, it can help cut 
network bandwidth, but at best, it seems to be about a 10% improvement. 
If you plot the numbers I did on a curve, you can see just how little 
advantage you get by increasing the number. You get almost all of the 
advantage by going to 2, and the line past 5 is very flat....

Interesting -- I honestly didn't expect to see THIS big a difference -- 
I was expecting more like 25-30% increase in bandwidth for a VERP-type 
delivery.

My thoughts on what this means to future directions:

Customized messages (VERPing, or encoded unsub URLs, or all of that...) 
should definitely be an option in Mailman 2.1.

I would set Mailman's 2.1 default to have this turned ON, giving us the 
customized unsub links and etc, but to document this for users so they 
know to turn it off on slow networks.

If users turn it off, I recommend that SMTP_MAX be set by default to 5, 
and that we document that it makes little sense to change it unless a 
site is horribly network limited, because even setting to the max only 
gains them another 10% (and if they're THAT network limited, they're 
seriously asking for trouble anyway), and only if their subscriber base 
fits a profile that lends itself to the compression. Setting it large 
also leaves them open to spamblocking by systems that don't necessarily 
follow the standards or act right, too.

We should ALSO note here that some MTAs (postfix, for instance) might 
override SMTP_MAX anyway -- you could set it to 100, but postfix might 
be configured smaller, so they have to be aware of those potential 
interactions. you then get into the issues of tuning all this, with few 
delivery threads with lots of addresses vs many threads in parallel.. 
and all that fun -- I guess I'm trying to say that you can't tune 
mailman in isolation from the MTA (and down that road lies a huge 
rathole of attempting to document this stuff...)

But from these numbers, any 2.0.x version of mailman should set SMTP_MAX 
to between 2 and 5, unless they're horribly network limited. it makes no 
sense to be larger than 5, and it makes no sense to be 1 unless you've 
done some kind of VERPing patch.

for 2.1, we want to implement these customizations and default them on, 
but with a 50% network hit, we definitely want to make it clear what's 
going on and make it possible for them to turn it off and return to a 
generic URL and non-customized e-mail.

Barry's mileage may vary on his preferences for default, of course, and 
it's his show. I think the advantages of the customized URL/email 
capability is a huge one and most sites will benefit from it -- but the 
network hit might kill some sites, so we have to give them an easy 
ability to turn the feature off.

What do y'all think? I've included mailman-developers on this reply, 
since while this started on mm-users, it really ought to be discussed on 
the developers list...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Yes, I am an agent of Satan, but my duties
are largely ceremonial.




From fil@rezo.net  Sun Jun 17 11:20:03 2001
From: fil@rezo.net (Fil)
Date: Sun, 17 Jun 2001 12:20:03 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106170738.f5H7cah28586@plaidworks.com>; from chuqui@plaidworks.com on Sun, Jun 17, 2001 at 12:46:47AM -0700
References: <15146.28093.61335.281545@anthem.wooz.org> <200106170738.f5H7cah28586@plaidworks.com>
Message-ID: <20010617122003.C3895@orwell.bok.net>

@ Chuq Von Rospach (chuqui@plaidworks.com) :
> Okay, here's a first cut at some data.

Very interesting! Doubling the bandwith needed might or not be a problem. My
systems delivers 10K messages at the mean rate of 18000 per hour. When I
send a message down a 130 000 subscribers' list, well, I have to wait quite
long befoore it's gone ; maybe I should buy some more bandwith. I'm ready to
take up the VERP approach, even if it means twice longer sends.

However there's another performance issue: how does postfix react when it's
got sent 130 000 emails to store and forward? Currently I send it about
10000 messages that it breaks up one by one using. I don't know about memory
or disk issues there, but 130 000 * 10k = 1.3 Gbytes on disk: there might be
more to consider than speed issues. I'd love to see it working that way
though. Would spare a lot users' and admin's nerves.

(By the way currently my larger lists aare not handled by Mailman but by
sympa, 'coz I needed to keep a copy of the subscribers' names in order to
spot them easier in the list when they want to unsubscribe and don't know
what their address was...)

> What do y'all think? I've included mailman-developers on this reply, 
> since while this started on mm-users, it really ought to be discussed on 
> the developers list...


-- Fil



From alex@phred.org  Sun Jun 17 14:21:32 2001
From: alex@phred.org (alex wetmore)
Date: Sun, 17 Jun 2001 06:21:32 -0700 (PDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas
 swords
In-Reply-To: <200106170738.f5H7cah28586@plaidworks.com>
Message-ID: <20010617061400.S4983-100000@phred.org>

On Sun, 17 Jun 2001, Chuq Von Rospach wrote:
> For this 55%, the SMTP=1 is 6050K. For 100, it's 1711K bytes. That's 28%
> of the first number, so we're cutting 72% of the bandwidth by chunking
> at 100. The tradeoff is performance, though -- it takes a lot longer to
> deliver those AOL addresses, because if you split it into two batches,
> you can't parallelize the delivery.

Please don't make this assumption.  It is true for the commonly used
Unix MTAs, but it is not true for all MTAs.  My MTA has no problems
with parallelizing delivery out of a single recieved message.

I agree that a smaller number would make sense for the default though,
as I'm probably the only one here who isn't using a Unix-based MTA to
do their deliveries.  As long as it is still configurable I am happy.

Your method for figuring out bandwidth usage is interesting, and I
think I'll do something similar for the recipient base and message
sizes on my system.  10k is much larger than my average message size,
but doing the same thing for digests (30k, and 65% of my readers are
in digest mode) would be interesting.  I'll report back to the list
with my results if anyone else is interested.

> I would set Mailman's 2.1 default to have this turned ON, giving us the
> customized unsub links and etc, but to document this for users so they
> know to turn it off on slow networks.

I would argue that it should default to OFF, as this is how Mailman
has behaved for a couple of years.  As long as I can easily turn it
off before completing the install (by changing mm_cfg.py for instance)
I am happy.

alex



From chuqui@plaidworks.com  Sun Jun 17 16:29:50 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 08:29:50 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: <20010617061400.S4983-100000@phred.org>
Message-ID: <200106171521.f5HFLdh06227@plaidworks.com>

On Sunday, June 17, 2001, at 06:21 AM, alex wetmore wrote:

> Please don't make this assumption.  It is true for the commonly used
> Unix MTAs, but it is not true for all MTAs.

you're misreading what I was doing here -- I'm looking at this based on 
how it goes over the wire, not how it's delivered to the MTA. So it 
doesn't matter if your MTA repackages it going over the wire or not -- 
I'm assuming it doesn't for simplicity, but if it does, you simply have 
to change the values to take that into consideration (and, for what it's 
worth, I did point out that postfix CAN do this, although I didn't 
clearly tie that back to this, because I thought the message was too 
long and opaque already...)

> Your method for figuring out bandwidth usage is interesting, and I
> think I'll do something similar for the recipient base and message
> sizes on my system.

It's just a rough attempt to get in the ballpark, but I think the 
numbers are going to be fairly good for the general SMTP protocol.

> 10k is much larger than my average message size,

true. It was convenient (especially for me, since I needed that data for 
my big emarketing machine anyway, and our messages are 10-14K and 
35-45K). If you go to smaller messages, the advantages of the 
buddying-up drops (for a 1K message, instead of  N * 11K + M * .1K, it's 
N*2K + M * .1K) and the protocol overhead becomes more important. For 
larger messages, the advantage grows completely. For 1-2K messages, you 
might see the advantage drop to 30% or less, I haven't done the math.

This also ignores the MTA's ability to cache connections, by the way. 
But that's really a random process and impossible to model this way.

> I would argue that it should default to OFF

I'm not surprised. It's Barry's call, but I think the customized URL is 
useful enough we want people to use it unless they have to turn it off, 
we don't want to have to try to convince the people who install stuff 
and leave everything defaulted to turn it on.


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

It's not the pace of life that concerns me, it's the sudden stop at the 
end.



From chuqui@plaidworks.com  Sun Jun 17 16:41:56 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 08:41:56 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <20010617122003.C3895@orwell.bok.net>
Message-ID: <200106171533.f5HFXjh06371@plaidworks.com>

On Sunday, June 17, 2001, at 03:20 AM, Fil wrote:

>  My
> systems delivers 10K messages at the mean rate of 18000 per hour. When I
> send a message down a 130 000 subscribers' list, well, I have to wait 
> quite
> long befoore it's gone ; maybe I should buy some more bandwith.

It depends on how time sensitive the stuff is and when you send it. If 
you send out at 10PM and expect people to read it when they wake up, 
does it matter if they actually get it at 3AM or 6AM? But if it's time 
sensitive -- you have to worry about that issue. If the delay adds a few 
minutes, no big deal (but if it adds a few minutes * 100 messages a day; 
big deal, especially for the messages at the end of the day where you 
can get the "bad weather over O'hare" problem...)

> However there's another performance issue: how does postfix react when 
> it's
> got sent 130 000 emails to store and forward?

Disk I/O. That's the other issue here. You're adding to yoru network 
usage, you're also adding to your Disk I/O problem.

>  Currently I send it about
> 10000 messages that it breaks up one by one using. I don't know about 
> memory
> or disk issues there, but 130 000 * 10k = 1.3 Gbytes on disk:

It's a problem. network and disk are (IMHO) the two big performance 
issues in delivering e-mail (at least the two under your control. The 
third is the speed at which receiving machines will accept messages, but 
you can't buy everyone in the universe faster e-mail servers...)

the amount of disk it takes isn't an issue (within reason) -- remember, 
it's going to start sending right away, so message will be gone out of 
the queue. You don't queue it all up and then start delivery. But this 
generates disk IO, and that can start bogging you down if you don't tune 
things properly. That means taking advantage of sub-folders in your mail 
queue for any MTA that allows them (the #1 performance death for a 
typical sendmail system: write-locks on /var/spool/mqueue, since every 
sendmail process has to create files in that directory. If you haven't 
set up subfolders, you are (I say this in a nice way) an idiot. if you 
aren't using a version of sendmail that allows for them, I'll call you 
an idiot in a not-nice way. Anyone not running at least 8.10 is hosed, 
so forget them...

Most MTAs are sensitive to this and work to minimize the impact. Even 
sendmail finally figured it out. But you still need, in large e-mail 
environments, to look at splitting this across heads and spindles. My 
experiments have indicated you're better off having mail on separate 
spindles than you are building a RAID using those same spindles, for 
whatever that's worth. And if you have lots of RAM, you can start using 
ram disks, and then you have lots of fun... (yes, I've done that. It's 
amazing how much faster sendmail is when you remove the disk I/O on 
those directory inodes...)


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

95% of being a net.god is sounding persuasive
and convincing people you know what you're talking about, even when 
you're
making it up as you go along. (chuq von rospach, 1992)





From claw@kanga.nu  Sun Jun 17 17:22:40 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 09:22:40 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 00:46:47 PDT." <200106170738.f5H7cah28586@plaidworks.com>
References: <200106170738.f5H7cah28586@plaidworks.com>
Message-ID: <1411.992794960@kanga.nu>

On Sun, 17 Jun 2001 00:46:47 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Friday, June 15, 2001, at 01:19 PM, Barry A. Warsaw wrote:

> I would set Mailman's 2.1 default to have this turned ON...

Agreed.

> Barry's mileage may vary on his preferences for default, of
> course, and it's his show. I think the advantages of the
> customized URL/email capability is a huge one and most sites will
> benefit from it -- but the network hit might kill some sites, so
> we have to give them an easy ability to turn the feature off.

You also ignore local physical resource consumption.  Network
bandwidth and expense are not always the only constraining factors.
Mail systems tend to be disk IO constrained in addition to network
bound with file creat()/open() being the biggies.  Given a busy box
that tends to maintain a significant backlog, under VERP/RCPT_TO=1
inode exhaustion becomes a more probable case than with larger
envelopes (similar/identical curves to above).

  Yes, real mail admins know to mkfs /var/spool with a higher inode
  count than the rest of their systems.  I'll let you guess what
  percentage of mail admins actually do.

There are quite a few lists out there running off i486 boxes with
small disks.  Some of them have nice bandwidth but have horrible
disk IO.

  ObExample: Up until fairly recently svlug.org (which runs mailman)
  was an i486.  Excellent outbound bandwidth.  Lousy local physical
  resources.  Subscriber base there is in the low/middle single
  digit thousands IIRC.  (Thanks to VA things are much better now)

The README should enclude notes on these factors as well.

> What do y'all think? 

I suspect Nigel Metherington is going to chime in here,

I'm interested in also seeing the percentage case, if only for
better bounce handling.

> I've included mailman-developers on this reply, since while this
> started on mm-users, it really ought to be discussed on the
> developers list...

Damned right.

> Yes, I am an agent of Satan, but my duties are largely ceremonial.

How topical.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Sun Jun 17 17:32:33 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 09:32:33 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 08:29:50 PDT." <200106171521.f5HFLdh06227@plaidworks.com>
References: <200106171521.f5HFLdh06227@plaidworks.com>
Message-ID: <17409.992795553@kanga.nu>

On Sun, 17 Jun 2001 08:29:50 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Sunday, June 17, 2001, at 06:21 AM, alex wetmore wrote:

>> I would argue that it should default to OFF

> I'm not surprised. It's Barry's call, but I think the customized
> URL is useful enough we want people to use it unless they have to
> turn it off, we don't want to have to try to convince the people
> who install stuff and leave everything defaulted to turn it on.

I spent some time on both sides of the fence as to which way to
default it.  I came out out on the ON side.

Reasons:

  There's a significant feature gain.

  Most of those new features help list members.

  All of them help the list owners.

  With VERP they also help the system over the longer term.

  Mailman becomes even more user friendly (by default).


The default to OFF case has the biggie:

  For most people, nothing will break and they'll have no surprises.

This is caveated by the fact that the only people that things will
break for are those that didn't read the README.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Sun Jun 17 17:39:47 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 09:39:47 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 08:41:56 PDT." <200106171533.f5HFXjh06371@plaidworks.com>
References: <200106171533.f5HFXjh06371@plaidworks.com>
Message-ID: <30333.992795987@kanga.nu>

On Sun, 17 Jun 2001 08:41:56 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> the amount of disk it takes isn't an issue (within reason) --
> remember, it's going to start sending right away, so message will
> be gone out of the queue. 

This is not a safe assumption.  Exim for instance will defer
deliveries if more than N messages are received in a single
connection.  As a result, you typically get no outbound deliveries
going on during a qrunner broadcast.

> You don't queue it all up and then start delivery.

Uhh.

> But this generates disk IO, and that can start bogging you down if
> you don't tune things properly. That means taking advantage of
> sub-folders in your mail queue for any MTA that allows them (the
> #1 performance death for a typical sendmail system: write-locks on
> /var/spool/mqueue, since every sendmail process has to create
> files in that directory. If you haven't set up subfolders, you are
> (I say this in a nice way) an idiot. if you aren't using a version
> of sendmail that allows for them, I'll call you an idiot in a
> not-nice way. Anyone not running at least 8.10 is hosed, so forget
> them...

Great READ/FAQ topic.

> Most MTAs are sensitive to this and work to minimize the
> impact. Even sendmail finally figured it out. But you still need,
> in large e-mail environments, to look at splitting this across
> heads and spindles. My experiments have indicated you're better
> off having mail on separate spindles than you are building a RAID
> using those same spindles, for whatever that's worth. 

I've done similar experiments with news spools.  The values are
incredibly subjective to RAID stripe size.  Bob Mende IIRC did some
interesting work here which I think he presented at LISA.  

  FWIW We ended up with a 1Meg strip size as the sweet spot, much
  bigger than we'd expected.

> And if you have lots of RAM, you can start using ram disks, and
> then you have lots of fun... (yes, I've done that. It's amazing
> how much faster sendmail is when you remove the disk I/O on those
> directory inodes...)

Silicon disks are another one.  At Critical Path we used solid state
disks for /var/spool and Qmail fairly, umm, whirred.  

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun 17 17:53:28 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 09:53:28 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <30333.992795987@kanga.nu>
Message-ID: <200106171645.f5HGjGh07300@plaidworks.com>

On Sunday, June 17, 2001, at 09:39 AM, J C Lawrence wrote:

> Exim for instance will defer
> deliveries if more than N messages are received in a single
> connection.  As a result, you typically get no outbound deliveries
> going on during a qrunner broadcast.

IMHO, I consider that seriously broken.

> I've done similar experiments with news spools.  The values are
> incredibly subjective to RAID stripe size.  Bob Mende IIRC did some
> interesting work here which I think he presented at LISA.
>
>   FWIW We ended up with a 1Meg strip size as the sweet spot, much
>   bigger than we'd expected.

I know someone who did the same, and found the best perforamnce iwth (I 
kid you not) 32 meg strip sizes.

> Silicon disks are another one.  At Critical Path we used solid state
> disks for /var/spool and Qmail fairly, umm, whirred.

But what I've found, for really large e-mail installations, there's 
always another bottleneck. The bigger/faster machine paradigm just 
doesn't scale after a while, so what I'm working on now is a new setup 
that I'm calling the "army of smurfs" design. I'm going to be buying 
lots of small/fast/cheap boxes, and not going to try to try to keep 
making that single monolithic machine do incrementally more.


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Funny, I don't remember being absent minded.




From jra@baylink.com  Sun Jun 17 17:57:20 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Sun, 17 Jun 2001 12:57:20 -0400
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106171645.f5HGjGh07300@plaidworks.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Sun, Jun 17, 2001 at 09:53:28AM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <20010617125720.47842@scfn.thpl.lib.fl.us>

On Sun, Jun 17, 2001 at 09:53:28AM -0700, Chuq Von Rospach wrote:
> But what I've found, for really large e-mail installations, there's 
> always another bottleneck. The bigger/faster machine paradigm just 
> doesn't scale after a while, so what I'm working on now is a new setup 
> that I'm calling the "army of smurfs" design. I'm going to be buying 
> lots of small/fast/cheap boxes, and not going to try to try to keep 
> making that single monolithic machine do incrementally more.

If you're talking about generic large mail farms, Chuq, you *really*
need to go find the Earthlink white paper on that and read it, if you
haven't already.  They have one on news, too.  Don't recall the URL;
Ask The Web<tm>.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From nb@thinkcoach.com  Sun Jun 17 19:45:53 2001
From: nb@thinkcoach.com (Norbert Bollow)
Date: Sun, 17 Jun 2001 20:45:53 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106171645.f5HGjGh07300@plaidworks.com> (message from Chuq Von
 Rospach on Sun, 17 Jun 2001 09:53:28 -0700)
References: <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <200106171845.f5HIjr916255@quill>

Chuq Von Rospach <chuqui@plaidworks.com> wrote (in two different
messages):

> >  Currently I send it about
> > 10000 messages that it breaks up one by one using. I don't know about 
> > memory
> > or disk issues there, but 130 000 * 10k = 1.3 Gbytes on disk:
> 
> It's a problem. network and disk are (IMHO) the two big performance 
> issues in delivering e-mail (at least the two under your control. The 
> third is the speed at which receiving machines will accept messages, but 
> you can't buy everyone in the universe faster e-mail servers...)
> 
> the amount of disk it takes isn't an issue (within reason) -- remember, 
> it's going to start sending right away, so message will be gone out of 
> the queue. You don't queue it all up and then start delivery.

I think it is certainly an issue - the disk partition with the
mailqueue must be big enough that even if there are network
problems at the time when all your digests are mailed out, all
the digests can be stored without problem.

This is not a problem with the qmail trick which I've explained
at http://mailman.cis.to/qmail-verh/ because there only one copy
of the message is stored in the mailqueue, which is then
customized by means of pattern substitutions on-the-fly when
qmail talks SMTP with the receiving mailservers.

But if Mailman customizes messages and passes one message per
recipient to the MTA, then you had better make sure that you
have a big enough mailqueue partition.

> that I'm calling the "army of smurfs" design. I'm going to be buying 
> lots of small/fast/cheap boxes, and not going to try to try to keep 
> making that single monolithic machine do incrementally more.

Ezmlm-idx has some really neat features for that, which I'd love
to see implemented in Mailman.

Greetings, Norbert.

-- 
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59     Fax +41 1 972 20 69      nb@freedevelopers.net


From fil@rezo.net  Sun Jun 17 19:58:58 2001
From: fil@rezo.net (Fil)
Date: Sun, 17 Jun 2001 20:58:58 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106171645.f5HGjGh07300@plaidworks.com>; from chuqui@plaidworks.com on Sun, Jun 17, 2001 at 09:53:28AM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <20010617205858.A7580@orwell.bok.net>

@ Chuq Von Rospach (chuqui@plaidworks.com) :
> But what I've found, for really large e-mail installations, there's 
> always another bottleneck. The bigger/faster machine paradigm just 
> doesn't scale after a while, so what I'm working on now is a new setup 
> that I'm calling the "army of smurfs" design. I'm going to be buying 
> lots of small/fast/cheap boxes, and not going to try to try to keep 
> making that single monolithic machine do incrementally more.

On my setup (postfix) there's a heavy use of the /etc/postfix/transport
feature, that redirects all domains with which I have a problem (like those
that are not always accepting mail I send) to a slave machine that is very
near (in terms of bandwidth) the first one. It reduces A LOT the disk
problems (mostly mailqueue becoming very heavy) -- maybe I should continue
this way with more domains being handled to slave machine(s). Is that the
option you're describing?

-- Fil



From claw@kanga.nu  Sun Jun 17 21:23:48 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 13:23:48 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 09:53:28 PDT." <200106171645.f5HGjGh07300@plaidworks.com>
References: <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <7111.992809428@kanga.nu>

On Sun, 17 Jun 2001 09:53:28 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Sunday, June 17, 2001, at 09:39 AM, J C Lawrence wrote:

>> Exim for instance will defer deliveries if more than N messages
>> are received in a single connection.  As a result, you typically
>> get no outbound deliveries going on during a qrunner broadcast.

> IMHO, I consider that seriously broken.

Its configurable.

>> I've done similar experiments with news spools.  The values are
>> incredibly subjective to RAID stripe size.  Bob Mende IIRC did
>> some interesting work here which I think he presented at LISA.
>> 
>> FWIW We ended up with a 1Meg strip size as the sweet spot, much
>> bigger than we'd expected.

> I know someone who did the same, and found the best perforamnce
> iwth (I kid you not) 32 meg strip sizes.

Not surprised.  Among other things its going to be sensitive to
number of spindles, RAID type, and feed characteristics.

>> Silicon disks are another one.  At Critical Path we used solid
>> state disks for /var/spool and Qmail fairly, umm, whirred.

> But what I've found, for really large e-mail installations,
> there's always another bottleneck. The bigger/faster machine
> paradigm just doesn't scale after a while, so what I'm working on
> now is a new setup that I'm calling the "army of smurfs"
> design. I'm going to be buying lots of small/fast/cheap boxes, and
> not going to try to try to keep making that single monolithic
> machine do incrementally more.

I've noticed that E-Machines are getting popular for precisely that
use/need.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun 17 22:23:32 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 14:23:32 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <20010617205858.A7580@orwell.bok.net>
Message-ID: <200106172115.f5HLFJh10888@plaidworks.com>

On Sunday, June 17, 2001, at 11:58 AM, Fil wrote:

> On my setup (postfix) there's a heavy use of the /etc/postfix/transport
> feature, that redirects all domains with which I have a problem

what's known as the "bog" (a term I ripped off from Infobeat's 
architecture). Try to deliver it once, exile it to the bog for non-real 
time delivery.

Infobeat's actually kinda nice, if you want ot get really hard-core 
about it. They deliver right out of the database into the client SMTP 
port, effectively sucking up the outgoing MTA into the application 
system. I've looked hard at doing that as well, but you start getting 
into the grimy details of dealing with all the MX weirdness and the 
like, and I've decided not to right an MTA right now, but instead to let 
the MTA writers figure out how to best do that. )

> problems (mostly mailqueue becoming very heavy) -- maybe I should 
> continue
> this way with more domains being handled to slave machine(s). Is that 
> the
> option you're describing?
>

Not really, but it's a good, legitimate option. When I was under 
sendmail 9, I implemented special slow queues as bogs and moved things 
there after 3 delivery tries. Under sendmail 8.11, I don't, because the 
sub-directory stuff allowed me to do away with having to deal with that 
from a performance standpoint.

What I'm designing is a system that will cause a daemon on a central 
server to connect to a bunch of machines in a farm and use them to 
simultaneously generate messages out into multiple SMTP queues -- you 
effectively hand a remote machine (an smtp smurf) a message template, 
then feed it data as fast as it can send. You get a very compact 
protocol between the two (since all you send over is the data to fill 
the template), and each one is noting but a mail-creation process 
feeding an MTA on a dedicated machine. And the rest, as they say, is 
simply tuning for maximum perforamnce without thrashing.

This isn't a discussion-list system, but the delivery setup could be 
adapted to that fairly easily. If you were going to do something similar 
on Mailman, you could do it by having a farm of SMTP outgoing machines 
under a round-robin with a short time-out, and making sure qrunner 
re-looks up the IP after every message. Do that, and then extend to 
allow for parallel qrunners, and you can buidl a heck of a mail list 
farm. 2.1 will do most of that fairly easily, the rest is figuring out 
and configuring the SMTP smurf farm and its round-robin.

In my case, I need to be able to take 40K length messages, and be able 
to build a system that'll ship out ~1,000,000 addresses an hour, with 
full customization (i.e. no piggybacking of adresses). Which might 
explain why I did 3+ hours of math last night on the bandwidth question; 
I needed it anyway, I'd been meaning to get to it, and as long as we 
were talking about it, it was a great excuse to build a model for my 
'real' work. My current system only does ~350-400,000 an hour with 
limited piggybacking of addresses, and doesn't do the full 
customization. But it also depends on a monolithic machine architecture, 
which simply can't scale infinitely. Right now, my big bottleneck on 
that machine is that my 100BaseT is full. I'm going to be bringing up a 
quad ethernet soon, but from there, unless you start talking about fiber 
and or trunking solutions, you're done. So rather than trying to eek out 
another 2% at ever greater engineering cost, we're moving to a smurf 
model, because you can buy a bunch of small, fast machines for the cost 
of a big honker with gigabit ethernet and a trunking system.

The downside is you add administrative complexity, plus you need to 
engineer getting the data where it needs to be (and the security of 
making sure nobody else uses your smurfs...). But those seem to be 
manageable. My current design includes three flavors of smurfs 
(smtp-out, smtp-in, and web), and I'm actually working on whether it 
makes sense take over a delegated sub-domain and run my own DNS, so I 
can dynamically move the smufts into whatever function I need -- it'd 
make a LOT of sense, from machine-usage terms, to be able to dedicate 
all but one or two smurfs to SMTP-out during the early delivery, and 
then start shunting them off one at a time into SMTP-in role or web-role 
to handle returned bounces, postmaster mail and user unsubscription 
requests. And once the bulge is done, take them offline and turn them 
into bounce-processing smurfs.... I could do more with fewer machines, 
but my office would end up looking like the Johnson Space center at 
launch time... (grin).





--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

USENET is a lot better after two or three eggnogs. We shouldn't allow
anyone on the net without a bottle of brandy. (chuq von rospach, 1992)



From claw@kanga.nu  Mon Jun 18 05:46:02 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 21:46:02 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 09:53:28 PDT." <200106171645.f5HGjGh07300@plaidworks.com>
References: <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <18598.992839562@kanga.nu>

On Sun, 17 Jun 2001 09:53:28 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Sunday, June 17, 2001, at 09:39 AM, J C Lawrence wrote:

>> Exim for instance will defer deliveries if more than N messages
>> are received in a single connection.  As a result, you typically
>> get no outbound deliveries going on during a qrunner broadcast.

> IMHO, I consider that seriously broken.

It can also be viewed as an advantage.  Given a large inbound mail
load, Exim throttles itself to try and be maximally
available/responsive for any other large mail events that might
happen synchronously.  This is a seemingly fairly standard
philosophy of Exim's: Make sure you can always play nice.  

> Funny, I don't remember being absent minded.

Neither did I.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Mon Jun 18 05:50:23 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 21:50:23 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Fil <fil@rezo.net>
 of "Sun, 17 Jun 2001 20:58:58 +0200." <20010617205858.A7580@orwell.bok.net>
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>  <20010617205858.A7580@orwell.bok.net>
Message-ID: <22952.992839823@kanga.nu>

On Sun, 17 Jun 2001 20:58:58 +0200 
fil  <fil@rezo.net> wrote:

> On my setup (postfix) there's a heavy use of the
> /etc/postfix/transport feature, that redirects all domains with
> which I have a problem (like those that are not always accepting
> mail I send) to a slave machine that is very near (in terms of
> bandwidth) the first one. 

Back when I used to do this under Exim by parsing the mainlog for
messages which arrived long before their delivery time.  Given a
frequent high enough score on this, I'd then do a domain route to a
similar Bad Mail box.

It was nice to automate it.  No attention required.

> It reduces A LOT the disk problems (mostly mailqueue becoming very
> heavy) -- maybe I should continue this way with more domains being
> handled to slave machine(s). 

Did you have any automated way to collect and maintain the slow MX
list?  One thing I never did was to implement a system to rescind
the "slow" verdict on MXes should they come back to life for a
reasonable period.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Mon Jun 18 05:59:08 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 21:59:08 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 14:23:32 PDT." <200106172115.f5HLFJh10888@plaidworks.com>
References: <200106172115.f5HLFJh10888@plaidworks.com>
Message-ID: <31789.992840348@kanga.nu>

On Sun, 17 Jun 2001 14:23:32 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> This isn't a discussion-list system, but the delivery setup could
> be adapted to that fairly easily. If you were going to do
> something similar on Mailman, you could do it by having a farm of
> SMTP outgoing machines under a round-robin with a short time-out,
> and making sure qrunner re-looks up the IP after every message. Do
> that, and then extend to allow for parallel qrunners, and you can
> buidl a heck of a mail list farm. 2.1 will do most of that fairly
> easily, the rest is figuring out and configuring the SMTP smurf
> farm and its round-robin.

Its arguably cheaper/easier to instead us a load balancer box as the
SMTP target which then does a per-transaction round-robin to the
target nodes in the farm.  Fairly easy to do, just a little proxy,
and then let rip.  Mailman never knows any different, you've got
management abstraction in the proxy box, and can add, remove, and
fail out nodes transparently without any cacheing problems torquing
the queues.

> The downside is you add administrative complexity, plus you need
> to engineer getting the data where it needs to be (and the
> security of making sure nobody else uses your smurfs...). 

Sit the smurf farm behind a router that redirects all inbound port
25 connections to <where-ever>.  At that point the only access to
the smurfs is from the inside via your proxy box as above.  

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From Nigel.Metheringham@InTechnology.co.uk  Mon Jun 18 10:11:59 2001
From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham)
Date: 18 Jun 2001 10:11:59 +0100
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join
 without specifying pas swords
In-Reply-To: <1411.992794960@kanga.nu>
References: <200106170738.f5H7cah28586@plaidworks.com>
 <1411.992794960@kanga.nu>
Message-ID: <992855524.19134.1.camel@gaspode.localnet>

On 17 Jun 2001 09:22:40 -0700, J C Lawrence wrote:
> I suspect Nigel Metherington is going to chime in here,

Definitely - you mispelt my name - I *hate* that :-)

Seriously, I've just come back to this fresh and its a big chunk to
take in at one reading.  What I will do is take a weeks logs from
the exim.org lists - which have a few lists of verious sizes, and
run the figures on deliveries and bandwidth uses.

	Nigel.

--
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ ----- Security is not an add-on -- security is a way of life ----- ]



From fil@rezo.net  Mon Jun 18 10:49:42 2001
From: fil@rezo.net (Fil)
Date: Mon, 18 Jun 2001 11:49:42 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <22952.992839823@kanga.nu>; from claw@kanga.nu on Sun, Jun 17, 2001 at 09:50:23PM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com> <20010617205858.A7580@orwell.bok.net> <fil@rezo.net> <22952.992839823@kanga.nu>
Message-ID: <20010618114942.E16222@orwell.bok.net>

> > It reduces A LOT the disk problems (mostly mailqueue becoming very
> > heavy) -- maybe I should continue this way with more domains being
> > handled to slave machine(s). 
> 
> Did you have any automated way to collect and maintain the slow MX
> list?  One thing I never did was to implement a system to rescind
> the "slow" verdict on MXes should they come back to life for a
> reasonable period.

Nope, I just eye-scan the postfix statistics and pick up some domains that
appear as painful. I wish I had an automatic pilot on this ;)

-- Fil



From claw@kanga.nu  Mon Jun 18 17:48:52 2001
From: claw@kanga.nu (J C Lawrence)
Date: Mon, 18 Jun 2001 09:48:52 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from "Jay R. Ashworth" <jra@baylink.com>
 of "Sun, 17 Jun 2001 12:57:20 EDT." <20010617125720.47842@scfn.thpl.lib.fl.us>
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>  <20010617125720.47842@scfn.thpl.lib.fl.us>
Message-ID: <23241.992882932@kanga.nu>

On Sun, 17 Jun 2001 12:57:20 -0400 
Jay R Ashworth <jra@baylink.com> wrote:

> On Sun, Jun 17, 2001 at 09:53:28AM -0700, Chuq Von Rospach wrote:
>> But what I've found, for really large e-mail installations,
>> there's always another bottleneck. The bigger/faster machine
>> paradigm just doesn't scale after a while, so what I'm working on
>> now is a new setup that I'm calling the "army of smurfs"
>> design. I'm going to be buying lots of small/fast/cheap boxes,
>> and not going to try to try to keep making that single monolithic
>> machine do incrementally more.

> If you're talking about generic large mail farms, Chuq, you
> *really* need to go find the Earthlink white paper on that and
> read it, if you haven't already.  They have one on news, too.
> Don't recall the URL; Ask The Web<tm>.

http://www.earthlink.net/about/papers/mailarch.html
http://www.earthlink.net/about/papers/scalenews.html

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jra@baylink.com  Mon Jun 18 18:34:18 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Mon, 18 Jun 2001 13:34:18 -0400
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <23241.992882932@kanga.nu>; from J C Lawrence <claw@kanga.nu> on Mon, Jun 18, 2001 at 09:48:52AM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com> <20010617125720.47842@scfn.thpl.lib.fl.us> <jra@baylink.com> <23241.992882932@kanga.nu>
Message-ID: <20010618133418.43542@scfn.thpl.lib.fl.us>

On Mon, Jun 18, 2001 at 09:48:52AM -0700, J C Lawrence wrote:
> > If you're talking about generic large mail farms, Chuq, you
> > *really* need to go find the Earthlink white paper on that and
> > read it, if you haven't already.  They have one on news, too.
> > Don't recall the URL; Ask The Web<tm>.
> 
> http://www.earthlink.net/about/papers/mailarch.html
> http://www.earthlink.net/about/papers/scalenews.html

Them was the ones; thanks, Joe.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From carson@taltos.org  Mon Jun 18 22:09:06 2001
From: carson@taltos.org (Carson Gaspar)
Date: Mon, 18 Jun 2001 14:09:06 -0700
Subject: [Mailman-Developers] Handling non-fatal "bounces"
Message-ID: <438450968.992873346@ZATHROS>

So we converted the firewalls mailing list to mailman, and we're now being 
inundated by bounce messages that mailman isn't handling. I'm going to 
write bounce modules for the actual bounces, but I can't figure out how to 
handle non-fatal errors (message could not be delivered, will retry soon, 
etc.).

What I want to do is ignore the bounce (don't flag the list member), but 
_not_ forward the message to the list admins. The current API seems 
incapable of doing this. Am I missing something?

-- 
Carson Gaspar - carson@taltos.org
Queen trapped in a butch body


From barry@digicool.com  Mon Jun 18 22:21:19 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 18 Jun 2001 17:21:19 -0400
Subject: [Mailman-Developers] Handling non-fatal "bounces"
References: <438450968.992873346@ZATHROS>
Message-ID: <15150.28879.872996.317919@anthem.wooz.org>

>>>>> "CG" == Carson Gaspar <carson@taltos.org> writes:

    CG> So we converted the firewalls mailing list to mailman, and
    CG> we're now being inundated by bounce messages that mailman
    CG> isn't handling. I'm going to write bounce modules for the
    CG> actual bounces, but I can't figure out how to handle non-fatal
    CG> errors (message could not be delivered, will retry soon,
    CG> etc.).

    CG> What I want to do is ignore the bounce (don't flag the list
    CG> member), but _not_ forward the message to the list admins. The
    CG> current API seems incapable of doing this. Am I missing
    CG> something?

First off, I consider it very bad manners for a side to send non-fatal
warnings (i.e. retries) for messages coming from a list.  IOW, if the
message has "Precedence: bulk" a site should /not/ send a try
notification.  Most MTAs I believe either suppress these by default,
or can be configured to do so.  I seem to remember a discussion
concerning an Exim configuration variable to control this a while back
(perhaps Nigel can elaborate).

In general, I haven't added bounce handlers to detect these kinds of
messages, and you're correct that the interface in BouncerAPI.py
doesn't really support an "ignore this, they're bogus" return value.
Usually when I'm bombarded by these, I send a, er, nicely worded
message to the postmaster and the warnings usually stop.

It'd be fairly easy to extend BouncerAPI.py to handle ignorable
bounces, so I'll try to add something for 2.1.

One question: should Mailman support doing an (optional) auto-kvetch
back to the site's postmaster?

-Barry


From jra@baylink.com  Mon Jun 18 22:42:31 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Mon, 18 Jun 2001 17:42:31 -0400
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: <15150.28879.872996.317919@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Mon, Jun 18, 2001 at 05:21:19PM -0400
References: <438450968.992873346@ZATHROS> <15150.28879.872996.317919@anthem.wooz.org>
Message-ID: <20010618174231.05757@scfn.thpl.lib.fl.us>

On Mon, Jun 18, 2001 at 05:21:19PM -0400, Barry A. Warsaw wrote:
> One question: should Mailman support doing an (optional) auto-kvetch
> back to the site's postmaster?

Two words: "Sorcerer's Apprentice".

Cheers,
-- jr 'IE: "no" :-)' a
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From chuqui@plaidworks.com  Mon Jun 18 23:37:14 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Mon, 18 Jun 2001 15:37:14 -0700
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: <20010618174231.05757@scfn.thpl.lib.fl.us>
Message-ID: <200106182235.f5IMZV414826@lists.apple.com>

On Monday, June 18, 2001, at 02:42 PM, Jay R. Ashworth wrote:

> On Mon, Jun 18, 2001 at 05:21:19PM -0400, Barry A. Warsaw wrote:
>> One question: should Mailman support doing an (optional) auto-kvetch
>> back to the site's postmaster?
>
> Two words: "Sorcerer's Apprentice".
>

treat them as hard bounces and if someone gets unsubscribed, encourage 
them to whine at their admin.

sending stuff to the admin directly from the outside will only piss off 
the admin. it won't solve anything, and you're kvetching on a point that 
is arguable depending on who's side of the argument you're on (if you 
want to kvetch at things, kvetch at places that send stupid vacation 
messages to the entire universe, endlessly, or places that send 
"confirming we read your message" messages to mail lists. Those are a 
LOT less ambiguously screwed up than the not-delivered-yet 
pain-in-the-necks...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

I'm really easy to get along with once you
people learn to worship me.



From claw@2wire.com  Tue Jun 19 01:04:15 2001
From: claw@2wire.com (J C Lawrence)
Date: Mon, 18 Jun 2001 17:04:15 -0700
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: Message from "Jay R. Ashworth" <jra@baylink.com>
 of "Mon, 18 Jun 2001 17:42:31 EDT." <20010618174231.05757@scfn.thpl.lib.fl.us>
References: <438450968.992873346@ZATHROS> <15150.28879.872996.317919@anthem.wooz.org>  <20010618174231.05757@scfn.thpl.lib.fl.us>
Message-ID: <26230.992909055@2wire.com>

On Mon, 18 Jun 2001 17:42:31 -0400 
Jay R Ashworth <jra@baylink.com> wrote:

> On Mon, Jun 18, 2001 at 05:21:19PM -0400, Barry A. Warsaw wrote:
>> One question: should Mailman support doing an (optional)
>> auto-kvetch back to the site's postmaster?

> Two words: "Sorcerer's Apprentice".

Limit one per day.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From admin@xpertindexing.com  Tue Jun 19 08:18:21 2001
From: admin@xpertindexing.com (admin@xpertindexing.com)
Date: 19 Jun 2001 07:18:21 -0000
Subject: [Mailman-Developers] search engine indexing is crucial to success!
Message-ID: <20010619071821.17140.qmail@ns2.differentworlds.victoria.bc.ca>

	Search engines can account for up to 80% of website
traffic. Having a beautiful site is important but without
the traffic there is no one to appreciate it and
consequently NO BUSINESS.
	Indexing with the search engines seems as simple as filling
in the blanks but getting good positions is NOT as easy! Our
staff can research your site and get you serious shoppers by
getting your site up in the top 15 positions with keyword
strings that work.
	Please visit our site to see how we can help you get the
exposure you need to be successful.

	http://www.xpertindexing.com

	Thank you for your time and attention

Kind Regards,
Graeme Skinner - Administration
admin@xpertindexing.com

To be removed from our email list please click here http://www.xpertindexing.com/X/remove.html?email=mailman-developers@python.org


From Nigel.Metheringham@InTechnology.co.uk  Tue Jun 19 09:42:06 2001
From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham)
Date: 19 Jun 2001 09:42:06 +0100
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: <15150.28879.872996.317919@anthem.wooz.org>
References: <438450968.992873346@ZATHROS>
 <15150.28879.872996.317919@anthem.wooz.org>
Message-ID: <992940131.11387.1.camel@gaspode.localnet>

On 18 Jun 2001 17:21:19 -0400, Barry A. Warsaw wrote:
> First off, I consider it very bad manners for a side to send non-fatal
> warnings (i.e. retries) for messages coming from a list.  IOW, if the
> message has "Precedence: bulk" a site should /not/ send a try
> notification.  Most MTAs I believe either suppress these by default,
> or can be configured to do so.  I seem to remember a discussion
> concerning an Exim configuration variable to control this a while back
> (perhaps Nigel can elaborate).

Sure.

Exim can send delay warning messages out at configurable intervals - see
  http://www.exim.org/exim-html-3.20/doc/html/spec_11.html#SEC201

A condition variable also controls what types of messages do get delay
warnings sent out.  By default this does not send warnings out in
response to messages with Precedence: set to bulk, list or junk.

Older versions of exim (I guess pre-3.x - which are prehistoric now) did
not have the defaults appropriately set.  If you are using a version of
exim that old then you should upgrade, or if this is impossible then set
delay_warning_condition appropriately - documentation for this (from the
3.2x documentation - but this hasn't changed since its original
introduction) is at
  http://www.exim.org/exim-html-3.20/doc/html/spec_11.html#SEC202

> It'd be fairly easy to extend BouncerAPI.py to handle ignorable
> bounces, so I'll try to add something for 2.1.

That would be good.  Is there a way of hacking it now?  [return an
impossible address for example]

> One question: should Mailman support doing an (optional) auto-kvetch
> back to the site's postmaster?

My evil twin says yes to this... however since those people that have
their systems so badly configured that they send bounce messages for
list mail also don't respond to postmaster mail - one site that is
causing me particular problems in that respect currently I now blacklist
completely.  Autoresponses in error conditions are a good way of
building serious mail loops.

	Nigel.

--
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ ----- Security is not an add-on -- security is a way of life ----- ]



From Dale Newfield <Dale@Newfield.org>  Tue Jun 19 12:45:47 2001
From: Dale Newfield <Dale@Newfield.org> (Dale Newfield)
Date: Tue, 19 Jun 2001 07:45:47 -0400 (EDT)
Subject: [Mailman-Developers] searching is crucial to success
In-Reply-To: <20010619071821.17140.qmail@ns2.differentworlds.victoria.bc.ca>
Message-ID: <Pine.SUN.4.33.0106190738380.3715-100000@adder.cs.Virginia.EDU>

While I know this was spam, the subject points to something I've been
thinking of bringing up.  I've only just started using a mailman
installation that has archiving turned on, and pipermail seems reasonable
enough, but what it really seems it needs is a search engine.  Has anyone
integrated some "grep -l" style script to give it one?

-Dale



From Nigel.Metheringham@InTechnology.co.uk  Tue Jun 19 13:12:00 2001
From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham)
Date: 19 Jun 2001 13:12:00 +0100
Subject: [Mailman-Developers] searching is crucial to success
In-Reply-To: <Pine.SUN.4.33.0106190738380.3715-100000@adder.cs.Virginia.EDU>
References: <Pine.SUN.4.33.0106190738380.3715-100000@adder.cs.Virginia.EDU>
Message-ID: <992952725.11629.2.camel@gaspode.localnet>

On 19 Jun 2001 07:45:47 -0400, Dale Newfield wrote:
> 
> While I know this was spam, the subject points to something I've been
> thinking of bringing up.  I've only just started using a mailman
> installation that has archiving turned on, and pipermail seems reasonable
> enough, but what it really seems it needs is a search engine.  Has anyone
> integrated some "grep -l" style script to give it one?

There are some patches in the patch
archive at sourceforge to add htdig
indexing to pipermail.

Have a look at
	http://www.exim.org/pipermail/exim-users/

for a demo

	Nigel.

--
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ ----- Security is not an add-on -- security is a way of life ----- ]



From etoffi@users.sourceforge.net  Wed Jun 20 16:20:03 2001
From: etoffi@users.sourceforge.net (Aluo Nowu)
Date: Wed, 20 Jun 2001 08:20:03 -0700
Subject: [Mailman-Developers] (no subject)
Message-ID: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>

From: etoffi jones <etoffi@bigfoot.com>
To: mailman-developers@python.org
Reply-To: etoffi@bigfoot.com
Organization: my company
Date: Wed, 20 Jun 2001 08:12:13
Subject: bounce with me
X-Priority: 3 (Normal)
Cc: etoffi jones <etoffi@softhome.net>
X-Mailer: Foobar 1.0 (Foobar Enterprises Inc Ltd Pty GmbH)
Content-Type: text/plain; charset="us-ascii"

please keep me on cc:

wouldn't it be just great if Mailman lists could tell you what messages you 
have bounced (and provide a way to get them of course =P), just like ezmlm?

wouldn't it?

for example, the Return-Path could be modified like so:

<foobar-return-500-lazyman=mailserver.org@lists.baz.quux>

(somebody should create a quux tld)

1) list name
2) 'return'
3) msg num
4) email addr (with = instead of @)

if any experts might be able to tell me that this is not to much to 
implement, i might be obliged to look into it myself. hehe.
-or-
for the ones where the latter doesnt apply, is this a good idea?  has there 
been any problems with this type of feature that you are aware of?


--
etoffi <http://oluworld.sourceforge.net/>



From claw@kanga.nu  Wed Jun 20 17:18:26 2001
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 20 Jun 2001 09:18:26 -0700
Subject: [Mailman-Developers] (no subject)
In-Reply-To: Message from Aluo Nowu <etoffi@users.sourceforge.net>
 of "Wed, 20 Jun 2001 08:20:03 PDT." <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
Message-ID: <29278.993053906@kanga.nu>

On Wed, 20 Jun 2001 08:20:03 -0700 
Aluo Nowu <etoffi@users.sourceforge.net> wrote:

> wouldn't it be just great if Mailman lists could tell you what
> messages you have bounced (and provide a way to get them of course
> =P), just like ezmlm?

Sure.

> <foobar-return-500-lazyman=mailserver.org@lists.baz.quux>

Message numbers are the relatively uninteresting case as they are an
arbitrary value that Mailman may not (usually doesn't) actually know
at the time of broadcast, and which further, doesn't actually apply
or necessarily exist for those using external archivers.

Message-IDs would be a better and more guaranteed portable route and
in the general case don't need to be embedded as you can already
find them in the bounce.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From etoffi@softhome.net  Thu Jun 21 06:33:36 2001
From: etoffi@softhome.net (etoffi@softhome.net)
Date: Thu, 21 Jun 2001 05:33:36 GMT
Subject: [Mailman-Developers] (no subject)
In-Reply-To: <29278.993053906@kanga.nu>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
 <29278.993053906@kanga.nu>
Message-ID: <20010621053337.24065.qmail@softhome.net>

please keep me on cc: etoffi@bigfoot.com

J C Lawrence writes:

> On Wed, 20 Jun 2001 08:20:03 -0700 
> Aluo Nowu <etoffi@users.sourceforge.net> wrote:
> 

[snip]

> Message numbers are the relatively uninteresting case as they are an
> arbitrary value that Mailman may not (usually doesn't) actually know
> at the time of broadcast, and which further, doesn't actually apply
> or necessarily exist for those using external archivers.

so mailman does _no_ storage of messages after they are sent?
if so, i applaud task separation.

> Message-IDs would be a better and more guaranteed portable route and
> in the general case don't need to be embedded as you can already
> find them in the bounce.

given that mailman does _not_ hold onto messages, a separate
program/component/thingydoodle would be the best way to go, or modifing the
code directly?  

maybe a separate, "virtual" list?

ps: i'm quite sure i should start looking at the code now.

> -- 
> J C Lawrence                                       claw@kanga.nu
> ---------(*)                          http://www.kanga.nu/~claw/
> The pressure to survive and rhetoric may make strange bedfellows


--
etoffi <http://oluworld.sourceforge.net/>



From claw@kanga.nu  Thu Jun 21 08:31:40 2001
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 21 Jun 2001 00:31:40 -0700
Subject: [Mailman-Developers] (no subject)
In-Reply-To: Message from etoffi@softhome.net
 of "Thu, 21 Jun 2001 05:33:36 GMT." <20010621053337.24065.qmail@softhome.net>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net> <29278.993053906@kanga.nu>  <20010621053337.24065.qmail@softhome.net>
Message-ID: <28562.993108700@kanga.nu>

On Thu, 21 Jun 2001 05:33:36 GMT 
etoffi  <etoffi@softhome.net> wrote:

> J C Lawrence writes:

>> On Wed, 20 Jun 2001 08:20:03 -0700 Aluo Nowu
>> <etoffi@users.sourceforge.net> wrote:

>> Message numbers are the relatively uninteresting case as they are
>> an arbitrary value that Mailman may not (usually doesn't)
>> actually know at the time of broadcast, and which further,
>> doesn't actually apply or necessarily exist for those using
>> external archivers.

> so mailman does _no_ storage of messages after they are sent?  if
> so, i applaud task separation.

Mailman has an internal archiver which may or may not be enabled for
a given list.  By default it is enabled.  In my case it is disabled
as I use an external archiver (MHonArc) which operated asynchroously
with regard to the list.  

Archiving using the internal pipermail archiver takes place under
the qrunner context when the message is broadcast.

>> Message-IDs would be a better and more guaranteed portable route
>> and in the general case don't need to be embedded as you can
>> already find them in the bounce.

> given that mailman does _not_ hold onto messages...

It *may* not.  More specifically it does not (when using the
internal archiver) in a format friendly to re-access/sending (web
and mbox).

> a separate program/component/thingydoodle would be the best way to
> go, or modifing the code directly?

> maybe a separate, "virtual" list?

> ps: i'm quite sure i should start looking at the code now.

You're trying to solve the wrong problem.  MessageIDs effectively
uniquely identify messages.  They are what you are looking for:  A
way of identifying a message.  Don't try and re-invent a poor shadow
of something that is already there.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From etoffi@softhome.net  Fri Jun 22 02:35:22 2001
From: etoffi@softhome.net (etoffi@softhome.net)
Date: Fri, 22 Jun 2001 01:35:22 GMT
Subject: [Mailman-Developers] (no subject)
In-Reply-To: <28562.993108700@kanga.nu>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
 <29278.993053906@kanga.nu>
 <20010621053337.24065.qmail@softhome.net>
 <28562.993108700@kanga.nu>
Message-ID: <20010622013522.1507.qmail@softhome.net>

(just in case any new people reply, please keep me on cc!)

J C Lawrence writes:

> You're trying to solve the wrong problem.  MessageIDs effectively
> uniquely identify messages.  They are what you are looking for:  A
> way of identifying a message.  Don't try and re-invent a poor shadow
> of something that is already there.

well i for one actually think message numbers are nice to say the least.
but the difference between [message numbers and message ids] id 
irrelevant in this context.  one thing i would like to say about message
numbers before leaving this part of the conversation is that i can create 
my own list archive, which is automatically synced with all others because 
i have a "master" number.  maybe this could be an option (for people
who like this point)

either way, my idea is to have a unique value that represents each 
message accepted to a list and a map of subscriber addresses and missed
message [unique values].  Mailman could then try for, let's say, two 
weeks, then automatically unsubscribe the bounced user or put them 
"on hold."

> -- 
> J C Lawrence                                       claw@kanga.nu
> ---------(*)                          http://www.kanga.nu/~claw/
> The pressure to survive and rhetoric may make strange bedfellows


--
etoffi <http://oluworld.sourceforge.net/>



From carson@taltos.org  Fri Jun 22 02:51:18 2001
From: carson@taltos.org (Carson Gaspar)
Date: Thu, 21 Jun 2001 18:51:18 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
Message-ID: <714582734.993149478@ZATHROS>

As I understand it, mailman operates by receiving mail to one of 3 
addresses (list, list-request, list-admin), flagging the message as a post, 
request, or bounce/admin message, and adding it to qfiles. qrunner then 
processes qfiles and handles everything.

This doesn't work for large lists. It has 2 major problems:

- large numbers of bounces prevent list mail and list requests from being 
processed
- a flat directory structure is a performance nightmare on non-btree dir 
filesystems

To be specific, the firewalls mailing list had accumulated over 20,000 
bounces in qfiles, which was preventing anything from getting done, and 
making the machine _very_ unhappy.

So I recommend a quick fix of splitting the queue into 3 parts, and a 
medium term fix of adopting one of the tiered directory structures 
(postfix, new sendmail, etc.).

-- 
Carson Gaspar - carson@taltos.org
Queen trapped in a butch body


From chuqui@plaidworks.com  Fri Jun 22 04:24:44 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 21 Jun 2001 20:24:44 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <714582734.993149478@ZATHROS>
Message-ID: <200106220316.f5M3GLh30327@plaidworks.com>

On Thursday, June 21, 2001, at 06:51 PM, Carson Gaspar wrote:

> So I recommend a quick fix of splitting the queue into 3 parts, and a 
> medium term fix of adopting one of the tiered directory structures 
> (postfix, new sendmail, etc.).
>

it's actually not a quick fix, but if you check the archives, you'll see 
it's already part of 2.1...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

The first rule of holes: If you are in one, stop digging.



From claw@kanga.nu  Fri Jun 22 05:57:13 2001
From: claw@kanga.nu (claw@kanga.nu)
Date: Thu, 21 Jun 2001 21:57:13 -0700
Subject: [Mailman-Developers] (no subject)
In-Reply-To: Message from etoffi@softhome.net
 of "Fri, 22 Jun 2001 01:35:22 GMT." <20010622013522.1507.qmail@softhome.net>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net> <29278.993053906@kanga.nu> <20010621053337.24065.qmail@softhome.net> <28562.993108700@kanga.nu>  <20010622013522.1507.qmail@softhome.net>
Message-ID: <12002.993185833@2wire.com>

On Fri, 22 Jun 2001 01:35:22 GMT 
etoffi  <etoffi@softhome.net> wrote:

> J C Lawrence writes:

> one thing i would like to say about message numbers before leaving
> this part of the conversation is that i can create my own list
> archive, which is automatically synced with all others because i
> have a "master" number.  maybe this could be an option (for people
> who like this point)

There is little preventing you from using MessageIDs to and for the
same purpose.  The only difference is that literal numbers are a bit
more human friendly than MessageIDs.  I argue that this is a false
economy as, handled properly the MessageID's would never have to be
human processed but could be embedded in URLs and pre-canned
commands ready to email.

> either way, my idea is to have a unique value that represents each
> message accepted to a list and a map of subscriber addresses and
> missed message [unique values].  

Not a bad idea.  I've got a CGI that does MessageID based lookups on
MHonArc archives (give it the MessageId it returns the archive
page).  It wouldn't be difficult to ad a mapping back to the
original message.

  In fact I'm about to be doing precisely this by adding a function
  to my archives such that you can have the original copy of any
  list post emailed to you.

As for the tracking of missed messages by subscribers this requires
VERP support as you can't guarantee taht the MessageID is available
in a bouce.  VERP support is currently under discussion as a
possible future optional feature -- it comes with a number of other
fairly chunky disadvantages.

> Mailman could then try for, let's say, two weeks, then
> automatically unsubscribe the bounced user or put them "on hold."

Automatic resends of bounced/missed posts my the MLM is an
interesting idea.  I don't like it from an abstraction/layering
model, but I can see why the interest.  Given a VERP supporting MLM
I'd prefer a pattern ala:

  -- Member bounces N messages
  -- Member successfully receives M messages as determined by the
  fact that no bounces for them is received for Q days.
  -- Mailman emails a list of the missed MessageIDs to the member
  along with instructions on how to retrieve/read the missed
  messages.  

The contents of the "how to retrieve X message" would have to be
tailored fairly heavily depending on the configuration of the list
in question (eg archiver turned on or off, use of an external
archiver, use of a subscribed archiver, external retrieval methods,
etc).

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From barry@digicool.com  Fri Jun 22 06:59:28 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 01:59:28 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
References: <714582734.993149478@ZATHROS>
Message-ID: <15154.57024.617224.686817@anthem.wooz.org>

>>>>> "CG" == Carson Gaspar <carson@taltos.org> writes:

    CG> So I recommend a quick fix of splitting the queue into 3
    CG> parts, and a medium term fix of adopting one of the tiered
    CG> directory structures (postfix, new sendmail, etc.).

Mailman 2.1's queue is split into at least 7 subdirectories,
specifically for:

- incoming posts from the MTA

- incoming commands (i.e. bounces, -request, -owner, -admin, -join, -leave)

- outgoing mail to the MTA

- outgoing mail to the archiver

- outgoing to the nntpd

- the "shunt" queue (for uncaught system errors)

- the "virgin" queue (for messages crafted by Mailman)

It's fairly easy to add more queues, although I'm not sure what else
would be useful.  Some other features of the 2.1 queue system:

1) FIFO order is guaranteed

2) Files are "randomly" distributed in a 120 bit hash space for
   no-lock cooperative multiprocessing.

3) Different qrunners can be assigned different priorities (i.e. you
   can run your incoming posts and MTA-bound queues more often then
   your archiver, nntpd, or command processing queues).

4) The qrunners are long running processes, monitored by a cron
   spawned watchdog.  Pros: on a warmed up system, delivery occurs
   almost immediately, with start up delays amortized over the life of
   the qrunner (Python 2.0's cyclic garbage collector helps keep
   memory usage under control).  Cons: debugging is, er, more
   challenging because you have to kill the master qrunner whenever
   you (really, I ;) make a change to the code.

All in all, while I have field tested it yet, I think the 2.1 queue
runner is miles ahead of what's in 2.0.

Cheers,
-Barry


From chuqui@plaidworks.com  Fri Jun 22 07:22:04 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 21 Jun 2001 23:22:04 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <200106220613.f5M6Dfh32559@plaidworks.com>

On Thursday, June 21, 2001, at 10:59 PM, Barry A. Warsaw wrote:

> It's fairly easy to add more queues, although I'm not sure what else
> would be useful.

Here's one -- multiple outqueuess to the MTA. Why?

Take a really large mailman system, one that's outgrown a single 
machine. Add a dedicated delivery machine. Now, outgrow that. So add a 
second. Right now, you'd have to do that with some DNS round-robin 
magic, or hacking the code. Instead, allow defining 1-N outgoing queues 
to different MTAs, and have mailman place every outgoing message in one 
of them either in sequence or random (or make it configurable. Maybe 
nthe best way to do this is to do it randomly, but assign a percentage 
to each queue, so you could weight towards faster/bigger machines and 
away from smaller/slower ones.

Then, each one has a qrunner tihng delivering into that SMTP port. And 
for redundancy, if the server it's supposed to send to is down, that 
qrunner could requeue to the other outgoing queue(s), so a down machine 
wouldn't affect you.

Run it one weird step further out, and you could define outgoing queues 
that are NEVER used, unless the main SMTP queue is down. Sort of like a 
fallback MX.

All of this is possible outside of mailman -- but it seems like it ought 
to be fairly easy to build into mailman, so you don't have to fall into 
DNS magic or proxies or any of the stuff we talked about last week...

> 3) Different qrunners can be assigned different priorities (i.e. you
>    can run your incoming posts and MTA-bound queues more often then
>    your archiver, nntpd, or command processing queues).

Can you define bounce processing to time the server is otherwise idle?


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Always look away from the obvious answers, because if you don't find
a better one, you can always go back to them on short notice.




From vizisz@freemail.hu  Fri Jun 22 11:42:29 2001
From: vizisz@freemail.hu (Vizi Szilard)
Date: Fri, 22 Jun 2001 12:42:29 +0200
Subject: [Mailman-Developers] Two versions on the same host
Message-ID: <20010622124228.C1844@freemail.hu>

Hy Everyone,

Previosly I asked Barry, but he could not answer yet.

I have installed to my machine the latest version from the CVS beside 
to the perfectly working 2.0.5. I want to play with the newest version,
but I do not want to bust up the working version. So I used the following
options in the configure:
./configure --prefix=/home/mailman2 --with-username=mailman2 --with-groupname=
mailman2 --with-cgi-gid=233 --with-mail-gid=12

In the Apache conf for the ScriptAlias I gave /mailman2 since /mailman is
for the version 2.0.5. I changed the crontab to prevent 2 different
versions running in the same time.

Mailman in the new directory working almost perfectly, but when I click
to a link the url would be like this (eg. in the listinfo page):
   http://tatooin.sol.vein.hu/mailman/admin
But it have to be like this for the proper working:
   http://tatooin.sol.vein.hu/mailman2/admin  

So I could not play with the beta version.
Any suggestion how can I solve this problem?
(You can take a look at this problem in the above URLs, if our net
is working. The bad weathers ruined our network early on this week.)

Bye,.

Szilard Vizi
-------------
mailto:vizisz@freemail.hu             UIN:10676592


From thomas@xs4all.net  Fri Jun 22 12:14:08 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 22 Jun 2001 13:14:08 +0200
Subject: [Mailman-Developers] Two versions on the same host
In-Reply-To: <20010622124228.C1844@freemail.hu>
References: <20010622124228.C1844@freemail.hu>
Message-ID: <20010622131408.L8098@xs4all.nl>

On Fri, Jun 22, 2001 at 12:42:29PM +0200, Vizi Szilard wrote:

> Previosly I asked Barry, but he could not answer yet.

> I have installed to my machine the latest version from the CVS beside 
> to the perfectly working 2.0.5. I want to play with the newest version,
> but I do not want to bust up the working version. So I used the following
> options in the configure:
> ./configure --prefix=/home/mailman2 --with-username=mailman2 --with-groupname=
> mailman2 --with-cgi-gid=233 --with-mail-gid=12
> 
> In the Apache conf for the ScriptAlias I gave /mailman2 since /mailman is
> for the version 2.0.5. I changed the crontab to prevent 2 different
> versions running in the same time.
> 
> Mailman in the new directory working almost perfectly, but when I click
> to a link the url would be like this (eg. in the listinfo page):
>    http://tatooin.sol.vein.hu/mailman/admin
> But it have to be like this for the proper working:
>    http://tatooin.sol.vein.hu/mailman2/admin  
> 
> So I could not play with the beta version.
> Any suggestion how can I solve this problem?
> (You can take a look at this problem in the above URLs, if our net
> is working. The bad weathers ruined our network early on this week.)

Try editing 'DEFAULT_URL' in Mailman/Defaults.py.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From vizisz@freemail.hu  Fri Jun 22 12:45:35 2001
From: vizisz@freemail.hu (Vizi Szilard)
Date: Fri, 22 Jun 2001 13:45:35 +0200
Subject: [Mailman-Developers] Re: Two versions on the same host
In-Reply-To: <20010622131408.L8098@xs4all.nl>; from thomas@xs4all.net on Fri, Jun 22, 2001 at 01:14:08PM +0200
References: <20010622124228.C1844@freemail.hu> <20010622131408.L8098@xs4all.nl>
Message-ID: <20010622134534.D1844@freemail.hu>

Thomas Wouters wrote:
> On Fri, Jun 22, 2001 at 12:42:29PM +0200, Vizi Szilard wrote:
> > Mailman in the new directory working almost perfectly, but when I click
> > to a link the url would be like this (eg. in the listinfo page):
> >    http://tatooin.sol.vein.hu/mailman/admin
> > But it have to be like this for the proper working:
> >    http://tatooin.sol.vein.hu/mailman2/admin  
> > 
> 
> Try editing 'DEFAULT_URL' in Mailman/Defaults.py.
Nop, still does not work.
Even with DEFAULT_URL='http://tatooin.sol.vein.hu/mailman2/' in mm_cfg.py

It is still searching my test list under 
http://tatooin.sol.vein.hu/mailman/listinfo/testing

The version is 2.1a2 
bin/check_perms says no trouble
 
Szilard Vizi
-------------
mailto:vizisz@freemail.hu             UIN:10676592


From thomas@xs4all.net  Fri Jun 22 13:11:41 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 22 Jun 2001 14:11:41 +0200
Subject: [Mailman-Developers] Re: Two versions on the same host
In-Reply-To: <20010622134534.D1844@freemail.hu>
References: <20010622124228.C1844@freemail.hu> <20010622131408.L8098@xs4all.nl> <20010622134534.D1844@freemail.hu>
Message-ID: <20010622141141.M8098@xs4all.nl>

On Fri, Jun 22, 2001 at 01:45:35PM +0200, Vizi Szilard wrote:
> Thomas Wouters wrote:
> > On Fri, Jun 22, 2001 at 12:42:29PM +0200, Vizi Szilard wrote:
> > > Mailman in the new directory working almost perfectly, but when I click
> > > to a link the url would be like this (eg. in the listinfo page):
> > >    http://tatooin.sol.vein.hu/mailman/admin
> > > But it have to be like this for the proper working:
> > >    http://tatooin.sol.vein.hu/mailman2/admin  
> > > 
> > 
> > Try editing 'DEFAULT_URL' in Mailman/Defaults.py.
> Nop, still does not work.
> Even with DEFAULT_URL='http://tatooin.sol.vein.hu/mailman2/' in mm_cfg.py

> It is still searching my test list under 
> http://tatooin.sol.vein.hu/mailman/listinfo/testing

That should work. Have you tried looking for /mailman/ yourself ? How about
looking at the script that generates those messages ? I don't have time to
haunt it down myself right now, but if you want to run 2.1-CVS, you better
get used to editing and fixing problems yourself, because the tree is pretty
unstable, still ;)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From jra@baylink.com  Fri Jun 22 14:29:02 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 22 Jun 2001 09:29:02 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 22, 2001 at 01:59:28AM -0400
References: <714582734.993149478@ZATHROS> <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <20010622092902.62487@scfn.thpl.lib.fl.us>

On Fri, Jun 22, 2001 at 01:59:28AM -0400, Barry A. Warsaw wrote:
> 4) The qrunners are long running processes, monitored by a cron
>    spawned watchdog.  Pros: on a warmed up system, delivery occurs
>    almost immediately, with start up delays amortized over the life of
>    the qrunner (Python 2.0's cyclic garbage collector helps keep
>    memory usage under control).  Cons: debugging is, er, more
>    challenging because you have to kill the master qrunner whenever
>    you (really, I ;) make a change to the code.

With just a little caution on locking, that's going to make my rate
limit throttling stuff much easier to implement, isn't it?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Fri Jun 22 16:26:40 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 11:26:40 -0400
Subject: [Mailman-Developers] Two versions on the same host
References: <20010622124228.C1844@freemail.hu>
Message-ID: <15155.25520.471194.240368@anthem.wooz.org>

>>>>> "VS" == Vizi Szilard <vizisz@freemail.hu> writes:

    VS> Mailman in the new directory working almost perfectly, but
    VS> when I click to a link the url would be like this (eg. in the
    VS> listinfo page): http://tatooin.sol.vein.hu/mailman/admin But
    VS> it have to be like this for the proper working:
    VS> http://tatooin.sol.vein.hu/mailman2/admin

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Try editing 'DEFAULT_URL' in Mailman/Defaults.py.

Oh Thomas, you're so close you should be able to smell it! :)

Changing DEFAULT_URL in mm_cfg.py fixes the problem for any new lists
you create, but won't fix it for lists you created before changing
that variable.  Once a list is created, that variable is stuffed into
the MailList object's m.web_page_url attribute.  (Note that
m.host_name comes from DEFAULT_HOST_NAME which might also have to be
changed.)

To fix this, run bin/withlist like so:

% python -i bin/withlist -l mylist
Loading list mylist (locked)
>>> m.web_page_url
'http://www.mysite.com/mailman/'
>>> m.web_page_url = 'http://www.mysite.com/mailman2/'
>>> m.Save()
>>> ^D
Unlocking (but not saving) list: mylist
Finalizing

Cheers,
-Barry


From barry@digicool.com  Fri Jun 22 16:54:11 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 11:54:11 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
References: <15154.57024.617224.686817@anthem.wooz.org>
 <200106220613.f5M6Dfh32559@plaidworks.com>
Message-ID: <15155.27171.371284.205447@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> Take a really large mailman system, one that's outgrown a
    CVR> single machine. Add a dedicated delivery machine. Now,
    CVR> outgrow that. So add a second. Right now, you'd have to do
    CVR> that with some DNS round-robin magic, or hacking the
    CVR> code. Instead, allow defining 1-N outgoing queues to
    CVR> different MTAs, and have mailman place every outgoing message
    CVR> in one of them either in sequence or random (or make it
    CVR> configurable. Maybe nthe best way to do this is to do it
    CVR> randomly, but assign a percentage to each queue, so you could
    CVR> weight towards faster/bigger machines and away from
    CVR> smaller/slower ones.

I /think/ this could all be accomplished with the current setup
without having to create a separate qfiles subdirectory.  Here's how:

Remember that every file in a qfile subdirectory is assigned a sha1
hash value, based currently on the message's content, the list name
and time.time().  Because of sha1's hashing properties the
distribution of files into the hash space should be effectively random
(I'm sure Tim Peters, if he were a member of this list, would chime in
with all the mathematical rigor I'm glossing over here. :)

Now, when a Runner asks its Switchboard for the list of files it
should process, it will receive the files sitting in some slice of
this hash space.  Currently, the code splits the hash space up evenly,
but there is no reason why someone couldn't subclass Switchboard to
allow for weighted hash space slices.

    CVR> Then, each one has a qrunner tihng delivering into that SMTP
    CVR> port. And for redundancy, if the server it's supposed to send
    CVR> to is down, that qrunner could requeue to the other outgoing
    CVR> queue(s), so a down machine wouldn't affect you.

So now what you do is subclass OutgoingRunner so that it knows about
all the parallelism and redundancy you want to build in, i.e.  the
assignments of hash space slices to SMTP ports.  Because each
OutgoingRunner will only process the files in its hash space slice,
you don't have to worry about any locking access to the files in
qfiles/out.

    CVR> Run it one weird step further out, and you could define
    CVR> outgoing queues that are NEVER used, unless the main SMTP
    CVR> queue is down. Sort of like a fallback MX.

If you really wanted to do this, then you /would/ have to define a
separate queue.  I'm not sure it's worthwhile (since the same goal
can probably be accomplish in other ways), but it's easy to do
something like:

- subclass OutgoingRunner so that if the SMTPDirect delivery failed
  due to non-responsiveness of the SMTP host, requeue the message to a
  `backoff' queue.  New queues (i.e. qfiles/subdirs) are trivial to
  define.

- Run a low-grade OutgoingRunner that only looks in qfiles/backoff for
  files to deliver.

    CVR> All of this is possible outside of mailman -- but it seems
    CVR> like it ought to be fairly easy to build into mailman, so you
    CVR> don't have to fall into DNS magic or proxies or any of the
    CVR> stuff we talked about last week...

I agree that it should be easy to do, and claim that the current
architecture could support it, if the sufficiently motivated Python
hacker were willing to spend a couple of hours on it.  I don't think
it's of general use to the majority of Mailman sites, so I don't
intend to implement it myself.  As always, patches are welcome. :)

    >> 3) Different qrunners can be assigned different priorities
    >> (i.e. you can run your incoming posts and MTA-bound queues more
    >> often then your archiver, nntpd, or command processing queues).

    CVR> Can you define bounce processing to time the server is
    CVR> otherwise idle?

Currently, bounce processing is tied in with the CommandRunner, but it
probably makes a lot more sense to split these into separate queues.
Given the current semantics (that bounces go to -admin, which may also
receive legitimate correspondence) some non-bounce email might get
delayed delivery, but I'm trying to sanitize the return addresses for
Mailman generated messages, so that responses from users go to the
-owner address (which doesn't do bounce processing), while errors go
to the -admin address (which does).

As far as delaying bounce processing for system idle periods, once the
bounce runner is split from the command runner, a strategy would be to
override the default BounceRunner's _doperiodic() and _snooze()
methods so that it only wakes up and starts processing during idle
times (however that's calculated for your particular OS).

I'm convinced almost all the nuts and bolts are there for you to build
whatever erector set frankenstein you want. :)

-Barry


From barry@digicool.com  Fri Jun 22 17:02:29 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 12:02:29 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
References: <714582734.993149478@ZATHROS>
 <15154.57024.617224.686817@anthem.wooz.org>
 <20010622092902.62487@scfn.thpl.lib.fl.us>
Message-ID: <15155.27669.599549.319832@anthem.wooz.org>

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    >> 4) The qrunners are long running processes, monitored by a cron
    >> spawned watchdog.  Pros: on a warmed up system, delivery occurs
    >> almost immediately, with start up delays amortized over the
    >> life of the qrunner (Python 2.0's cyclic garbage collector
    >> helps keep memory usage under control).  Cons: debugging is,
    >> er, more challenging because you have to kill the master
    >> qrunner whenever you (really, I ;) make a change to the code.

    JRA> With just a little caution on locking, that's going to make
    JRA> my rate limit throttling stuff much easier to implement,
    JRA> isn't it?

I believe so, but I can think of one refinement that would help you.
The Runner base class calls _doperiodic() after each file is
processed.  In here you could do the rate limit calculation, but
currently there's no protocol for _doperiodic() to tell the for loop
in __oneloop() to break out early.  I think I can easily add one.

-Barry


From chuqui@plaidworks.com  Fri Jun 22 17:53:12 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 22 Jun 2001 09:53:12 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15155.27171.371284.205447@anthem.wooz.org>
Message-ID: <200106221651.f5MGpVf02456@lists.apple.com>

On Friday, June 22, 2001, at 08:54 AM, Barry A. Warsaw wrote:

> I /think/ this could all be accomplished with the current setup
> without having to create a separate qfiles subdirectory.  Here's how:
>

Kewl. It's great to see that whenever I come up with one of these 
weird-ass boundary cases, Mailman at least has the capability to be 
kicked into shape to deal with it... that's great!

chuq

--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

"When his IQ reaches 50, he should sell."




From barry@digicool.com  Fri Jun 22 17:59:46 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 12:59:46 -0400
Subject: [Mailman-Developers] Splitting -owner and -admin handling
Message-ID: <15155.31106.81604.326952@anthem.wooz.org>

Mail destined for the -owner and -admin addresses for a list are
handled differently because -admin mail flows through the bounce
detector, and only if that fails is it forwarded on to the list
owners.  Mail for -owner goes directly to the list owners.

For historical reasons, Mailman conflates these two addresses by
having the same script (mailowner) deal with both.  In MM2.0.5, I
parsed the incoming message to see if it was destined for -admin or
-owner, and I added an appropriate bit message metadata before queuing
the message.

In MM2.1, I don't parse the message in mailowner.  This has the
advantage of reducing the amount of time the MTA program has to
consume, which I think is a good thing.  The problem is that the
determination of -owner vs. -admin doesn't happen until the qrunner
processes the message.  If I want to split bounce processing into a
separate queue, the best place to do this is as early as possible,
i.e. in the MTA program script.

There are two options:

1) Parse the message in mailowner, or at the very least, look for the
   To: field to see if it was destined for -owner or -admin, and then
   put the message in the proper queue.  We can mitigate the parsing
   costs by storing the message as a pickle instead of plain text, so
   the qrunner slurping messages out of the queue doesn't need to
   reparse it.  Pros: backwards compatibility with existing alias
   files.  Cons: mailowner has to do more work, has a higher
   opportunity for uncaught exceptions (exposed as MTA bounces), and
   can be fooled by Bcc's.

2) Add a new script, maybe called `mailadmin' which gets associated
   only with -admin messages.  The mailowner script would thus only
   accept messages for -owner.  Pros: keeps things simple, and splits
   bounce processing into a separate queue early on, with minimal
   chance of problems.  Cons: breaks backwards compatibility with
   existing alias files, since they'd have to be changed to point the
   -admin addresses at mailadmin instead of what they currently point
   to (mailowner).  Mitigate this with the auto-alias-file
   regeneration scripts already in Mailman (i.e. bin/genaliases).

Thoughts?  Preferences?  Other suggestions?

-Barry


From Dan Mick <dmick@utopia.West.Sun.COM>  Fri Jun 22 19:19:30 2001
From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick)
Date: Fri, 22 Jun 2001 11:19:30 -0700 (PDT)
Subject: [Mailman-Developers] Splitting -owner and -admin handling
Message-ID: <200106221819.LAA18137@utopia.West.Sun.COM>

I like 2) better, as anything that helps bounce processing be
more efficient is a big win for low-end machines, especially if
it can avoid the relatively-huge Python startup time.

> Mail destined for the -owner and -admin addresses for a list are
> handled differently because -admin mail flows through the bounce
> detector, and only if that fails is it forwarded on to the list
> owners.  Mail for -owner goes directly to the list owners.
> 
> For historical reasons, Mailman conflates these two addresses by
> having the same script (mailowner) deal with both.  In MM2.0.5, I
> parsed the incoming message to see if it was destined for -admin or
> -owner, and I added an appropriate bit message metadata before queuing
> the message.
> 
> In MM2.1, I don't parse the message in mailowner.  This has the
> advantage of reducing the amount of time the MTA program has to
> consume, which I think is a good thing.  The problem is that the
> determination of -owner vs. -admin doesn't happen until the qrunner
> processes the message.  If I want to split bounce processing into a
> separate queue, the best place to do this is as early as possible,
> i.e. in the MTA program script.
> 
> There are two options:
> 
> 1) Parse the message in mailowner, or at the very least, look for the
>    To: field to see if it was destined for -owner or -admin, and then
>    put the message in the proper queue.  We can mitigate the parsing
>    costs by storing the message as a pickle instead of plain text, so
>    the qrunner slurping messages out of the queue doesn't need to
>    reparse it.  Pros: backwards compatibility with existing alias
>    files.  Cons: mailowner has to do more work, has a higher
>    opportunity for uncaught exceptions (exposed as MTA bounces), and
>    can be fooled by Bcc's.
> 
> 2) Add a new script, maybe called `mailadmin' which gets associated
>    only with -admin messages.  The mailowner script would thus only
>    accept messages for -owner.  Pros: keeps things simple, and splits
>    bounce processing into a separate queue early on, with minimal
>    chance of problems.  Cons: breaks backwards compatibility with
>    existing alias files, since they'd have to be changed to point the
>    -admin addresses at mailadmin instead of what they currently point
>    to (mailowner).  Mitigate this with the auto-alias-file
>    regeneration scripts already in Mailman (i.e. bin/genaliases).
> 
> Thoughts?  Preferences?  Other suggestions?
> 
> -Barry
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers



From claw@kanga.nu  Fri Jun 22 21:41:32 2001
From: claw@kanga.nu (claw@kanga.nu)
Date: Fri, 22 Jun 2001 13:41:32 -0700
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw)
 of "Fri, 22 Jun 2001 12:59:46 EDT." <15155.31106.81604.326952@anthem.wooz.org>
References: <15155.31106.81604.326952@anthem.wooz.org>
Message-ID: <2315.993242492@2wire.com>

On Fri, 22 Jun 2001 12:59:46 -0400 
Barry A Warsaw <barry@digicool.com> wrote:

> Mail destined for the -owner and -admin addresses for a list are
> handled differently because -admin mail flows through the bounce
> detector, and only if that fails is it forwarded on to the list
> owners.  Mail for -owner goes directly to the list owners.

Why not split those functions?

> In MM2.1, I don't parse the message in mailowner.  This has the
> advantage of reducing the amount of time the MTA program has to
> consume, which I think is a good thing.  The problem is that the
> determination of -owner vs. -admin doesn't happen until the
> qrunner processes the message.  If I want to split bounce
> processing into a separate queue, the best place to do this is as
> early as possible, i.e. in the MTA program script.

> There are two options:

And a third: 

  3) Remove bounce processing from -admin and move it to its own
  -bounce address.

I prefer this approach.  The insertion of a management point (via
the new address) adds all sorts of new capabilities (eg process
deferment, dedicated bounce processor nodes, customised bounce
processing (eg integration with other external systems such as CRM
or billing), etc etc.  The pain is that extant installations would
have to add the new alias/MTA config as part of their upgrade.  

That's an acceptable upgrade cost.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jra@baylink.com  Fri Jun 22 22:02:57 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 22 Jun 2001 17:02:57 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15155.27669.599549.319832@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 22, 2001 at 12:02:29PM -0400
References: <714582734.993149478@ZATHROS> <15154.57024.617224.686817@anthem.wooz.org> <20010622092902.62487@scfn.thpl.lib.fl.us> <15155.27669.599549.319832@anthem.wooz.org>
Message-ID: <20010622170257.53564@scfn.thpl.lib.fl.us>

On Fri, Jun 22, 2001 at 12:02:29PM -0400, Barry A. Warsaw wrote:
>     JRA> With just a little caution on locking, that's going to make
>     JRA> my rate limit throttling stuff much easier to implement,
>     JRA> isn't it?
> 
> I believe so, but I can think of one refinement that would help you.
> The Runner base class calls _doperiodic() after each file is
> processed.  In here you could do the rate limit calculation, but
> currently there's no protocol for _doperiodic() to tell the for loop
> in __oneloop() to break out early.  I think I can easily add one.

It would be oh, so nice if I could get *you* to write this code instead
of me having to do it.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From carson@taltos.org  Fri Jun 22 23:52:55 2001
From: carson@taltos.org (Carson Gaspar)
Date: Fri, 22 Jun 2001 15:52:55 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>
References: <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <69573828.993225175@athyra>


--On Friday, June 22, 2001 1:59 AM -0400 "Barry A. Warsaw" 
<barry@digicool.com> wrote:

> - incoming commands (i.e. bounces, -request, -owner, -admin, -join,
> -leave)

> It's fairly easy to add more queues, although I'm not sure what else
> would be useful.  Some other features of the 2.1 queue system:

I _really_ want bounces and commands in 2 different queues. The firewalls 
mailing list gets _tons_ of bounces, and it clogs up everything else.

-- 
Carson



From chuqui@plaidworks.com  Sat Jun 23 00:02:47 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 22 Jun 2001 16:02:47 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <69573828.993225175@athyra>
Message-ID: <200106222301.f5MN15512753@lists.apple.com>

--Apple-Mail-499853444-1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	format=flowed;
	charset=us-ascii


On Friday, June 22, 2001, at 03:52 PM, Carson Gaspar wrote:

>
> I _really_ want bounces and commands in 2 different queues. The 
> firewalls mailing list gets _tons_ of bounces, and it clogs up 
> everything else.


Have you looked at why? Is it just that large a list -- or do you have a 
continuing problem with bounces floating through the system that you 
think mailman is handling but mailman isn't?

Mailman doesn't handle all bounces. Unfortunately, it's not good at 
telling you this right now (and we haven't really figured out a good way 
to deal with this, since it seems there are two modes: silently dropping 
this stuff or inundating the admin with it). I had this problem until I 
started analyzing the system and realized I had a bunch of stuff that 
was going to bounce forever -- and when I cleaned that stuff up (by 
tracking down the addresses that had changed enough to not be 
recognized, the stuff being forwarded (and forwarded.. and forwarded) 
and etc), a huge part of my bounce 'problem' went away.

start by taking the bounce log, and grepping for "not a member", and 
clean up as much of that as you can. You may find a huge difference in 
your performance and backlogs....




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

You know, I Remember When I Used To Speak In Capitals, Too. It's 
addictive.
It also encourages people to poke sticks at you. Justifiably. (chuq, 
1992)

--Apple-Mail-499853444-1
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=us-ascii


On Friday, June 22, 2001, at 03:52 PM, Carson Gaspar wrote:


<excerpt>

I _really_ want bounces and commands in 2 different queues. The
firewalls mailing list gets _tons_ of bounces, and it clogs up
everything else.

</excerpt>


Have you looked at why? Is it just that large a list -- or do you have
a continuing problem with bounces floating through the system that you
think mailman is handling but mailman isn't?


Mailman doesn't handle all bounces. Unfortunately, it's not good at
telling you this right now (and we haven't really figured out a good
way to deal with this, since it seems there are two modes: silently
dropping this stuff or inundating the admin with it). I had this
problem until I started analyzing the system and realized I had a
bunch of stuff that was going to bounce forever -- and when I cleaned
that stuff up (by tracking down the addresses that had changed enough
to not be recognized, the stuff being forwarded (and forwarded.. and
forwarded) and etc), a huge part of my bounce 'problem' went away.


start by taking the bounce log, and grepping for "not a member", and
clean up as much of that as you can. You may find a huge difference in
your performance and backlogs....




<color><param>0000,0000,DEB7</param>

</color>-- 

Chuq Von Rospach, Internet Gnome <<http://www.chuqui.com>

[<<chuqui@plaidworks.com> = <<me@chuqui.com> = <<chuq@apple.com>]

Yes, yes, I've finally finished my home page. Lucky you. 


You know, I Remember When I Used To Speak In Capitals, Too. It's
addictive.

It also encourages people to poke sticks at you. Justifiably. (chuq,
1992)


--Apple-Mail-499853444-1--


From thomas@xs4all.net  Sat Jun 23 09:51:47 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 23 Jun 2001 10:51:47 +0200
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: <2315.993242492@2wire.com>
References: <15155.31106.81604.326952@anthem.wooz.org> <2315.993242492@2wire.com>
Message-ID: <20010623105147.P8098@xs4all.nl>

On Fri, Jun 22, 2001 at 01:41:32PM -0700, claw@kanga.nu wrote:

> And a third: 

>   3) Remove bounce processing from -admin and move it to its own
>   -bounce address.

> I prefer this approach.  The insertion of a management point (via
> the new address) adds all sorts of new capabilities (eg process
> deferment, dedicated bounce processor nodes, customised bounce
> processing (eg integration with other external systems such as CRM
> or billing), etc etc.  The pain is that extant installations would
> have to add the new alias/MTA config as part of their upgrade.  

> That's an acceptable upgrade cost.

No.... Currently, the Sender and Return-Path headers (or the 'From ' header,
if you wish) get set to list-admin, not list-bounce. Changing it to
list-bounce will screw up every one of my mailman-list-filters, and I'm not
the only one doing that ;P 

-- 
Thomas Wouters <thomas@xs4all.net>

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


From claw@kanga.nu  Sat Jun 23 10:38:19 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sat, 23 Jun 2001 02:38:19 -0700
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: Message from Thomas Wouters <thomas@xs4all.net>
 of "Sat, 23 Jun 2001 10:51:47 +0200." <20010623105147.P8098@xs4all.nl>
References: <15155.31106.81604.326952@anthem.wooz.org> <2315.993242492@2wire.com>  <20010623105147.P8098@xs4all.nl>
Message-ID: <11492.993289099@kanga.nu>

On Sat, 23 Jun 2001 10:51:47 +0200 
Thomas Wouters <thomas@xs4all.net> wrote:

> No.... Currently, the Sender and Return-Path headers (or the 'From
> ' header, if you wish) get set to list-admin, not
> list-bounce. 

Correct.  I'm suggesting that be changed.

> Changing it to list-bounce will screw up every one of my
> mailman-list-filters, and I'm not the only one doing that ;P

Might I suggest that List-ID: is a far better field to filter on,
asides from actually being intended for that purpose?

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jeb@ocha.net  Sat Jun 23 16:33:24 2001
From: jeb@ocha.net (Jeb Bateman)
Date: Sat, 23 Jun 2001 08:33:24 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>; from barry@digicool.com on Fri, Jun 22, 2001 at 01:59:28AM -0400
References: <714582734.993149478@ZATHROS> <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <20010623083324.A8703@ocha.net>

On Fri, Jun 22, 2001 at 01:59:28AM -0400, Barry A. Warsaw wrote:
> 4) The qrunners are long running processes, monitored by a cron
>    spawned watchdog.  Pros: on a warmed up system, delivery occurs
>    almost immediately, with start up delays amortized over the life of
>    the qrunner (Python 2.0's cyclic garbage collector helps keep
>    memory usage under control).  Cons: debugging is, er, more
>    challenging because you have to kill the master qrunner whenever
>    you (really, I ;) make a change to the code.

I'm curious, would it be possible to make the delivery pipeline fork a
qrunner (after checking that one is NOT already running) ??

The advantage would be no cron, and qrunner could start immediately
whenever it's needed, (if one is not already running), and then die
naturally (freeing the processor and memory) when it's not.  (There
could be a configurable amount of time for it to 'sleep' before it
exits after it's work is finished, and it finds no new work to do...)

I remember reading that Postfix kills programs it starts if they run
too long, but does that also apply to forked processes?

Thanks,
-jeb


From jeb@ocha.net  Sat Jun 23 19:22:45 2001
From: jeb@ocha.net (Jeb Bateman)
Date: Sat, 23 Jun 2001 12:22:45 -0600
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: <11492.993289099@kanga.nu>; from claw@kanga.nu on Sat, Jun 23, 2001 at 02:38:19AM -0700
References: <15155.31106.81604.326952@anthem.wooz.org> <2315.993242492@2wire.com> <20010623105147.P8098@xs4all.nl> <thomas@xs4all.net> <11492.993289099@kanga.nu>
Message-ID: <20010623122245.A82107@buyorganic.org>

I support option 1) with backward compatability and To: parsing (with
Bcc's being processed in the admin queue, since the current system
works), plus an optional feature for enabling # 3) as J C pointed out
to turn off parsing and tune performance; especially since having a
-bounce alias would also be natural for reliable bounce handling
sender addresses sometime... <list-bounce-foo=bar.com@lists.net>

Thus, no alias changes are necessary, but -bounce aliases *can* be
added site-wide for performance.  Existing installations could have
the -bounce alias option turned off by default, and new installations
can have it turned on in Defaults.py.

I think it's too confusing to do option 2) since it makes a technical
distinction between two things which were understood by users and
admins to be exactly the same for a long time, and I think the
necessary alias changes would be more confusing as well.

Regards,
-jeb

PS: This method would not break existing users setups by default, but
would allow a site admin to do so, and deal with the complaints ;-)

On Sat, Jun 23, 2001 at 02:38:19AM -0700, J C Lawrence wrote:
> Thomas Wouters <thomas@xs4all.net> wrote:
> > No.... Currently, the Sender and Return-Path headers (or the 'From
> > ' header, if you wish) get set to list-admin, not list-bounce.
> 
> Correct.  I'm suggesting that be changed.
> 
> > Changing it to list-bounce will screw up every one of my
> > mailman-list-filters, and I'm not the only one doing that ;P
> 
> Might I suggest that List-ID: is a far better field to filter on,
> asides from actually being intended for that purpose?



From friends@openxxx.net  Sun Jun 24 04:19:48 2001
From: friends@openxxx.net (friends@openxxx.net)
Date: 23 Jun 2001 22:19:48 -0500
Subject: [Mailman-Developers] Hello, your friend recommended openxxx to you
Message-ID: <FRENCHYV1qdiixjnzi900000023@frenchy>


You have been invited to check out this adult site
by one of your friends who visited us.

our URL is http://www.openxxx.net/
enjoy,
OpenXXX TEAM 2001




From dvschalk@ing.sun.ac.za  Mon Jun 25 14:35:26 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Mon, 25 Jun 2001 15:35:26 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
Message-ID: <3B373E1E.6C966C95@ing.sun.ac.za>

Hi

It is 6:02 AM Sat. and I'm fairly fed-up.

I have the following situation : 

Mailman 2.0.5 
Python 2.0
MTA : postfix

I set Mailman up, created a test list and played with it for a while.
Then I send it a big "whopper" 5MB e-mail. I watched the logs and saw
postfix running the wrapper. The cron started qrunner and all hell broke
lose (over dramatizing a bit). It started running at 100% CPU, where it
stayed until I killed it. The message was queued in $prefix/qfiles, it
and its little .db file. I had to remove those as well as the locks in
$prefix/locks before I could successfully use the list again.

So I thought, "well maybe the pipermail thingy can't handle the huge
mime thingies I'm sending it". So I send a smaller attachment <150kb.
Things went fine (except for the ugly html page:) ) Send it a 1MB
attachment. qrunner started spinning it's wheels again. Had to seek and
destroy again.

So I replaced pipermail with MHonArc (With PUBLIC_EXTERNAL_ARCHIVER ,
PRIVATE_EXTERNAL_ARCHIVER , PUBLIC_ARCHIVE_URL in mm_cfg.py and the
appropriate thingies in httpd.conf). Small messages worked fine. Big 
whoppers = no joy i.e. still the same with big messages. So at least it
is not the archiving bit that messes up.

So I upgraded my Python ;) Ermm, to version 2.0. Still the same.

Has anyone had the same problem? Can anyone confirm this as a bug by
sending a 2MB file to a 2.0.5 testlist? 

How do I do a trace in Python? (i.e. it is as familiar to me as the
bacteria in my stomach (I runs on my machine and there endeth the
relationship))

Any pointers? Anything? I need to get this list running before monday
(yes this is for a business). Please!!!??

Sorry if this e-mail was not formal enough, the 48 hours strait is
getting to me.

Greets

Dirko

Lab E352
E&E Engineering
Univ. of Stellenbosch
South Africa


From james@gilbertwalker.com  Mon Jun 25 18:49:27 2001
From: james@gilbertwalker.com (James Dinan)
Date: Mon, 25 Jun 2001 10:49:27 -0700
Subject: [Mailman-Developers] HTML Issue
Message-ID: <004101c0fd9f$3d913dd0$3202a8c0@station12>

This is a multi-part message in MIME format.

------=_NextPart_000_003C_01C0FD64.8168A650
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I posted this message to mailman-users, and then the more I was thinking =
about it, the more I began to think this was a question for developers.  =
Please tell me what you think:

I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with =
the Subscribe Results Page (/mailman/subscribe/listname).  More =
specifically, I have edited the HTML and whenever I view the page, =
mailman appears to be prepending the following to the source:

<HTML>
<HEAD>
</HEAD>
<BODY
<BODY bgcolor=3D"#ffffff">

which I'm sure you can imagine is wreaking havoc on the rest of my HTML. =
 Has anyone else had this problem, or is this fixed in future releases?  =
Since I am not an admin on the server I am configuring it will be =
difficult (Redhat installs mailman in /var/mailman) to recompile =
mailman.

I have just checked =
http://mail.python.org/mailman/subscribe/mailman-users and you can see =
for yourself that this is also happening with the version of mailman =
that serves this list.

- jim dinan.
-----------------------------------------------------------------------
James Dinan <james@gilbertwalker.com>
Gilbert Walker Group: Lenox, MA  U.S.A
Available:  http://www.gilbertwalker.com

------=_NextPart_000_003C_01C0FD64.8168A650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I posted this message to mailman-users, =
and then=20
the more I was thinking about it, the more I began to think this was a =
question=20
for developers.&nbsp; Please tell me what you think:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>I am running Mailman 2.0.1 on Redhat =
6.2 and I am=20
having difficulty with the Subscribe Results Page=20
(/mailman/subscribe/listname).&nbsp; More specifically, I have edited =
the HTML=20
and whenever I view the page, mailman appears to be prepending the =
following to=20
the source:</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><BR>&lt;HTML&gt;<BR>&lt;HEAD&gt;<BR>&lt;/HEAD&gt;<BR>&lt;BODY<BR=
>&lt;BODY=20
bgcolor=3D"#ffffff"&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>which I'm sure you can imagine is =
wreaking havoc on=20
the rest of my HTML.&nbsp; Has anyone else had this problem, or is this =
fixed in=20
future releases?&nbsp; Since I am not an admin on the server I am =
configuring it=20
will be difficult (Redhat installs mailman in /var/mailman) to recompile =

mailman.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have just checked <A=20
href=3D"http://mail.python.org/mailman/subscribe/mailman-users">http://ma=
il.python.org/mailman/subscribe/mailman-users</A>&nbsp;and=20
you can see for yourself that this is also happening with the version of =
mailman=20
that serves this list.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>- jim dinan.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>----------------------------------------------------------------=
-------<BR>James=20
Dinan &lt;<A=20
href=3D"mailto:james@gilbertwalker.com">james@gilbertwalker.com</A>&gt;<B=
R>Gilbert=20
Walker Group: Lenox, MA&nbsp; U.S.A<BR>Available:&nbsp; <A=20
href=3D"http://www.gilbertwalker.com">http://www.gilbertwalker.com</A></F=
ONT></FONT></DIV></DIV></BODY></HTML>

------=_NextPart_000_003C_01C0FD64.8168A650--



From thomas@xs4all.net  Mon Jun 25 16:47:58 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 25 Jun 2001 17:47:58 +0200
Subject: [Mailman-Developers] HTML Issue
In-Reply-To: <004101c0fd9f$3d913dd0$3202a8c0@station12>
References: <004101c0fd9f$3d913dd0$3202a8c0@station12>
Message-ID: <20010625174758.V8098@xs4all.nl>

On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:

> I posted this message to mailman-users, and then the more I was thinking
> about it, the more I began to think this was a question for developers. 
> Please tell me what you think:

> I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with
> the Subscribe Results Page (/mailman/subscribe/listname).  More
> specifically, I have edited the HTML and whenever I view the page, mailman
> appears to be prepending the following to the source:
> 
> <HTML>
> <HEAD>
> </HEAD>
> <BODY
> <BODY bgcolor="#ffffff">

Yes. This is an open bug, and an old one. It still requires a Pronouncement
from Barry. The problem is that Mailman creates a HTMLgen Document instead
of a HeadlessDocument, for the list page. From the top of my head the fix is
to change 

    doc = Document()

into

    doc = HeadlessDocument()

in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
is reluctant to fix it because of possible breakage (people might have made
template files with the (Headfull)Document in mind.) Barry ? :)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From tollef@add.no  Mon Jun 25 20:07:35 2001
From: tollef@add.no (Tollef Fog Heen)
Date: 25 Jun 2001 21:07:35 +0200
Subject: [Mailman-Developers] HTML Issue
In-Reply-To: <20010625174758.V8098@xs4all.nl>
References: <004101c0fd9f$3d913dd0$3202a8c0@station12>
 <20010625174758.V8098@xs4all.nl>
Message-ID: <8766dk2xag.fsf@arabella.dep.no>

* Thomas Wouters 

| in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
| is reluctant to fix it because of possible breakage (people might have made
| template files with the (Headfull)Document in mind.) Barry ? :)

Actually, the fix is in htmlformat.py, around line 281:

        output.append('%s</HEAD>' % tab)
        output.append('%s<BODY' % tab)
	quals = []
	for k, v in kws.items():
	    quals.append('%s="%s"' % (k, v))
        output.append('%s<BODY %s>' % (tab, string.join(quals, ' ')))
        output.append(Container.Format(self, indent))

ok, first, we append '<body' to the output.  then we run in a little
loop, before we append another <body> with any arguments.  I raised
the problem on April 16th, and you told me about the headless problem,
but just commenting out

        output.append('%s<BODY' % tab)

has worked fine for me (and any users of Mailman on Debian).

-- 

Tollef Fog Heen
You Can't Win


From barry@digicool.com  Mon Jun 25 21:03:17 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 25 Jun 2001 16:03:17 -0400
Subject: [Mailman-Developers] HTML Issue
References: <20010625174758.V8098@xs4all.nl>
Message-ID: <15159.39173.331416.882488@yyz.digicool.com>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:

    TW> Yes. This is an open bug, and an old one. It still requires a
    TW> Pronouncement from Barry. The problem is that Mailman creates
    TW> a HTMLgen Document instead of a HeadlessDocument, for the list
    TW> page. From the top of my head the fix is to change

    TW> doc = Document()

    TW> into

    TW> doc = HeadlessDocument()

    TW> in Mailman/Cgi/listinfo.py, function listinfo_overview(). I
    TW> believe Barry is reluctant to fix it because of possible
    TW> breakage (people might have made template files with the
    TW> (Headfull)Document in mind.) Barry ? :)

Well, with MM2.1 I'm certainly less concerned about any theoretical
breakages, especially since changing this will probably accomplish
exactly the opposite! :)

>>>>> "TFH" == Tollef Fog Heen <tollef@add.no> writes:

    TFH> ok, first, we append '<body' to the output.  then we run in a
    TFH> little loop, before we append another <body> with any
    TFH> arguments.  I raised the problem on April 16th, and you told
    TFH> me about the headless problem, but just commenting out

    TFH> output.append('%s<BODY' % tab)

    TFH> has worked fine for me (and any users of Mailman on Debian).

This is certainly one of the problems, which will affect any
Document()-based web page.  However, Thomas is also right that any
page that is generated from a template (e.g. subscribe.html) either
must not include the header stuff, or must use a HeadlessDocument().
Fixing this is going to take a bit of grunt work, especially if we
want to allow the html templates to go either way.

Let's make our lives simple and say that any templated html file must
include its own html armor (and thus will be HeadlessDocument()
based), while all non-templated script-generated ones will be
Document() based to get the standard header and footers.

If you agree, I can start fixing the web ui to conform to this rule.

The more I think about the web ui, the more certain I am that we need

1) api's so sites can supply any web ui they want, with adaptors for
   the Mailman "classic" ui.

2) Mailman's classic ui should be based on something like Zope's
   Presentation Templates (ZPT).  My understanding is that these will
   /not/ require sucking in all of Zope (i.e. they can be used
   standalone), they are quite powerful, and allow for html editing to
   live nicely with script specialization.  There's the little matter
   of ZPL/GPL incompatibility that's currently holding me back from
   investigating this avenue further.

-Barry


From james@gilbertwalker.com  Tue Jun 26 00:20:19 2001
From: james@gilbertwalker.com (James Dinan)
Date: Mon, 25 Jun 2001 16:20:19 -0700
Subject: [Mailman-Developers] HTML Issue
References: <20010625174758.V8098@xs4all.nl> <15159.39173.331416.882488@yyz.digicool.com>
Message-ID: <010e01c0fdcd$79373c80$3202a8c0@station12>

> Let's make our lives simple and say that any templated html file must
> include its own html armor (and thus will be HeadlessDocument()
> based), while all non-templated script-generated ones will be
> Document() based to get the standard header and footers.
>
> If you agree, I can start fixing the web ui to conform to this rule.

I certainly agree with that.  In fact, right now I am in the process of
hacking together a custom ui for MM2 which, I am surprised to find, is much
harder than I imagined.  One problem that I have is that somtimes funny
things will happen inside the <MM-...> tags.  Some tags leave white space
after themselves, and I can't really control the presentation of the content
inside of the tags (i.e. font, size, etc) directly, often I have to wrap
them in a container.

I wonder if there might be some way to pull these <MM-...> tags out of the
source and stick them into a library of some sort that you can sustomize for
each list.  I know this would probabbly mean quite a lot of work, but think
of how cool that would be.  ;)  You could have the configuration program
modify the text in the libraries for less advanced users and for more
hardcore hackers they can edit the XML/HTML themselves.

If you're interested to see how far I've gotten, the mailing list I'm
working on (for my summer job) is available at
http://www.gilbertwalker.com/mailman/listinfo/advisorbits.  Assuming I
haven't broken it again it should still be up.  But, you will notice that
there are still many error messages which I cannot touch the HTML for.  :/

Oh yeah, one other idea I had (this really pertains to my particular site
architecture) is that it would be incredibly convenient to have a
customizable page header and footer that could be called via an <MM-...> tag
that you could wrap any sort of content in.  Sort of like making
HeadlessDocument() customizable I guess.

Thanks for all your help!

- jim.

-----------------------------------------------------------------------
James Dinan <james@gilbertwalker.com>
Gilbert Walker Group: Lenox, MA  U.S.A
Available:  http://www.gilbertwalker.com


> This is certainly one of the problems, which will affect any
> Document()-based web page.  However, Thomas is also right that any
> page that is generated from a template (e.g. subscribe.html) either
> must not include the header stuff, or must use a HeadlessDocument().
> Fixing this is going to take a bit of grunt work, especially if we
> want to allow the html templates to go either way.
>
>
> The more I think about the web ui, the more certain I am that we need
>
> 1) api's so sites can supply any web ui they want, with adaptors for
>    the Mailman "classic" ui.
>
> 2) Mailman's classic ui should be based on something like Zope's
>    Presentation Templates (ZPT).  My understanding is that these will
>    /not/ require sucking in all of Zope (i.e. they can be used
>    standalone), they are quite powerful, and allow for html editing to
>    live nicely with script specialization.  There's the little matter
>    of ZPL/GPL incompatibility that's currently holding me back from
>    investigating this avenue further.
>
> -Barry



From Samuel" <coudrayf@noos.fr  Mon Jun 25 21:29:25 2001
From: Samuel" <coudrayf@noos.fr (Samuel)
Date: Mon, 25 Jun 2001 22:29:25 +0200
Subject: [Mailman-Developers] Re: Mailman-Developers digest, Vol 1 #917 - 3 msgs
References: <E15EYnW-0008AP-00@mail.python.org>
Message-ID: <037a01c0fdb5$870789e0$e23d84c3@cybercable.fr>

unsubscribe
----- Original Message -----
From: <mailman-developers-request@python.org>
To: <mailman-developers@python.org>
Sent: Monday, June 25, 2001 6:01 PM
Subject: Mailman-Developers digest, Vol 1 #917 - 3 msgs


> Send Mailman-Developers mailing list submissions to
> mailman-developers@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/mailman-developers
> or, via email, send a message with subject or body 'help' to
> mailman-developers-request@python.org
>
> You can reach the person managing the list at
> mailman-developers-admin@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mailman-Developers digest..."
>
>
> Today's Topics:
>
>    1. qrunner -- problem with huge mail messages (Dirko van Schalkwyk)
>    2. HTML Issue (James Dinan)
>    3. Re: HTML Issue (Thomas Wouters)
>
> --__--__--
>
> Message: 1
> Date: Mon, 25 Jun 2001 15:35:26 +0200
> From: Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
> Reply-To: dvschalk@ing.sun.ac.za
> To: mailman-developers@python.org
> Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
>
> Hi
>
> It is 6:02 AM Sat. and I'm fairly fed-up.
>
> I have the following situation :
>
> Mailman 2.0.5
> Python 2.0
> MTA : postfix
>
> I set Mailman up, created a test list and played with it for a while.
> Then I send it a big "whopper" 5MB e-mail. I watched the logs and saw
> postfix running the wrapper. The cron started qrunner and all hell broke
> lose (over dramatizing a bit). It started running at 100% CPU, where it
> stayed until I killed it. The message was queued in $prefix/qfiles, it
> and its little .db file. I had to remove those as well as the locks in
> $prefix/locks before I could successfully use the list again.
>
> So I thought, "well maybe the pipermail thingy can't handle the huge
> mime thingies I'm sending it". So I send a smaller attachment <150kb.
> Things went fine (except for the ugly html page:) ) Send it a 1MB
> attachment. qrunner started spinning it's wheels again. Had to seek and
> destroy again.
>
> So I replaced pipermail with MHonArc (With PUBLIC_EXTERNAL_ARCHIVER ,
> PRIVATE_EXTERNAL_ARCHIVER , PUBLIC_ARCHIVE_URL in mm_cfg.py and the
> appropriate thingies in httpd.conf). Small messages worked fine. Big
> whoppers = no joy i.e. still the same with big messages. So at least it
> is not the archiving bit that messes up.
>
> So I upgraded my Python ;) Ermm, to version 2.0. Still the same.
>
> Has anyone had the same problem? Can anyone confirm this as a bug by
> sending a 2MB file to a 2.0.5 testlist?
>
> How do I do a trace in Python? (i.e. it is as familiar to me as the
> bacteria in my stomach (I runs on my machine and there endeth the
> relationship))
>
> Any pointers? Anything? I need to get this list running before monday
> (yes this is for a business). Please!!!??
>
> Sorry if this e-mail was not formal enough, the 48 hours strait is
> getting to me.
>
> Greets
>
> Dirko
>
> Lab E352
> E&E Engineering
> Univ. of Stellenbosch
> South Africa
>
>
> --__--__--
>
> Message: 2
> From: "James Dinan" <james@gilbertwalker.com>
> To: <mailman-developers@python.org>
> Date: Mon, 25 Jun 2001 10:49:27 -0700
> Subject: [Mailman-Developers] HTML Issue
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> I posted this message to mailman-users, and then the more I was thinking =
> about it, the more I began to think this was a question for developers.  =
> Please tell me what you think:
>
> I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with =
> the Subscribe Results Page (/mailman/subscribe/listname).  More =
> specifically, I have edited the HTML and whenever I view the page, =
> mailman appears to be prepending the following to the source:
>
> <HTML>
> <HEAD>
> </HEAD>
> <BODY
> <BODY bgcolor=3D"#ffffff">
>
> which I'm sure you can imagine is wreaking havoc on the rest of my HTML. =
>  Has anyone else had this problem, or is this fixed in future releases?  =
> Since I am not an admin on the server I am configuring it will be =
> difficult (Redhat installs mailman in /var/mailman) to recompile =
> mailman.
>
> I have just checked =
> http://mail.python.org/mailman/subscribe/mailman-users and you can see =
> for yourself that this is also happening with the version of mailman =
> that serves this list.
>
> - jim dinan.
> -----------------------------------------------------------------------
> James Dinan <james@gilbertwalker.com>
> Gilbert Walker Group: Lenox, MA  U.S.A
> Available:  http://www.gilbertwalker.com
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META content=3D"text/html; charset=3Diso-8859-1" =
> http-equiv=3DContent-Type>
> <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>I posted this message to mailman-users, =
> and then=20
> the more I was thinking about it, the more I began to think this was a =
> question=20
> for developers.&nbsp; Please tell me what you think:</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>
> <DIV><FONT face=3DArial size=3D2>I am running Mailman 2.0.1 on Redhat =
> 6.2 and I am=20
> having difficulty with the Subscribe Results Page=20
> (/mailman/subscribe/listname).&nbsp; More specifically, I have edited =
> the HTML=20
> and whenever I view the page, mailman appears to be prepending the =
> following to=20
> the source:</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2><BR>&lt;HTML&gt;<BR>&lt;HEAD&gt;<BR>&lt;/HEAD&gt;<BR>&lt;BODY<BR=
> >&lt;BODY=20
> bgcolor=3D"#ffffff"&gt;</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>which I'm sure you can imagine is =
> wreaking havoc on=20
> the rest of my HTML.&nbsp; Has anyone else had this problem, or is this =
> fixed in=20
> future releases?&nbsp; Since I am not an admin on the server I am =
> configuring it=20
> will be difficult (Redhat installs mailman in /var/mailman) to recompile =
>
> mailman.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>I have just checked <A=20
> href=3D"http://mail.python.org/mailman/subscribe/mailman-users">http://ma=
> il.python.org/mailman/subscribe/mailman-users</A>&nbsp;and=20
> you can see for yourself that this is also happening with the version of =
> mailman=20
> that serves this list.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>- jim dinan.</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>----------------------------------------------------------------=
> -------<BR>James=20
> Dinan &lt;<A=20
> href=3D"mailto:james@gilbertwalker.com">james@gilbertwalker.com</A>&gt;<B=
> R>Gilbert=20
> Walker Group: Lenox, MA&nbsp; U.S.A<BR>Available:&nbsp; <A=20
> href=3D"http://www.gilbertwalker.com">http://www.gilbertwalker.com</A></F=
> ONT></FONT></DIV></DIV></BODY></HTML>
>
> ------=_NextPart_000_003C_01C0FD64.8168A650--
>
>
>
> --__--__--
>
> Message: 3
> Date: Mon, 25 Jun 2001 17:47:58 +0200
> From: Thomas Wouters <thomas@xs4all.net>
> To: James Dinan <james@gilbertwalker.com>
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] HTML Issue
>
> On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:
>
> > I posted this message to mailman-users, and then the more I was thinking
> > about it, the more I began to think this was a question for developers.
> > Please tell me what you think:
>
> > I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with
> > the Subscribe Results Page (/mailman/subscribe/listname).  More
> > specifically, I have edited the HTML and whenever I view the page,
mailman
> > appears to be prepending the following to the source:
> >
> > <HTML>
> > <HEAD>
> > </HEAD>
> > <BODY
> > <BODY bgcolor="#ffffff">
>
> Yes. This is an open bug, and an old one. It still requires a
Pronouncement
> from Barry. The problem is that Mailman creates a HTMLgen Document instead
> of a HeadlessDocument, for the list page. From the top of my head the fix
is
> to change
>
>     doc = Document()
>
> into
>
>     doc = HeadlessDocument()
>
> in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
> is reluctant to fix it because of possible breakage (people might have
made
> template files with the (Headfull)Document in mind.) Barry ? :)
>
> --
> Thomas Wouters <thomas@xs4all.net>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
>
>
>
> --__--__--
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
>
>
> End of Mailman-Developers Digest
>



From Samuel" <coudrayf@noos.fr  Mon Jun 25 21:29:31 2001
From: Samuel" <coudrayf@noos.fr (Samuel)
Date: Mon, 25 Jun 2001 22:29:31 +0200
Subject: [Mailman-Developers] Re: Mailman-Developers digest, Vol 1 #917 - 3 msgs
References: <E15EYnW-0008AP-00@mail.python.org>
Message-ID: <038101c0fdb5$8a459de0$e23d84c3@cybercable.fr>

unsubscribe
----- Original Message -----
From: <mailman-developers-request@python.org>
To: <mailman-developers@python.org>
Sent: Monday, June 25, 2001 6:01 PM
Subject: Mailman-Developers digest, Vol 1 #917 - 3 msgs


> Send Mailman-Developers mailing list submissions to
> mailman-developers@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/mailman-developers
> or, via email, send a message with subject or body 'help' to
> mailman-developers-request@python.org
>
> You can reach the person managing the list at
> mailman-developers-admin@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mailman-Developers digest..."
>
>
> Today's Topics:
>
>    1. qrunner -- problem with huge mail messages (Dirko van Schalkwyk)
>    2. HTML Issue (James Dinan)
>    3. Re: HTML Issue (Thomas Wouters)
>
> --__--__--
>
> Message: 1
> Date: Mon, 25 Jun 2001 15:35:26 +0200
> From: Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
> Reply-To: dvschalk@ing.sun.ac.za
> To: mailman-developers@python.org
> Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
>
> Hi
>
> It is 6:02 AM Sat. and I'm fairly fed-up.
>
> I have the following situation :
>
> Mailman 2.0.5
> Python 2.0
> MTA : postfix
>
> I set Mailman up, created a test list and played with it for a while.
> Then I send it a big "whopper" 5MB e-mail. I watched the logs and saw
> postfix running the wrapper. The cron started qrunner and all hell broke
> lose (over dramatizing a bit). It started running at 100% CPU, where it
> stayed until I killed it. The message was queued in $prefix/qfiles, it
> and its little .db file. I had to remove those as well as the locks in
> $prefix/locks before I could successfully use the list again.
>
> So I thought, "well maybe the pipermail thingy can't handle the huge
> mime thingies I'm sending it". So I send a smaller attachment <150kb.
> Things went fine (except for the ugly html page:) ) Send it a 1MB
> attachment. qrunner started spinning it's wheels again. Had to seek and
> destroy again.
>
> So I replaced pipermail with MHonArc (With PUBLIC_EXTERNAL_ARCHIVER ,
> PRIVATE_EXTERNAL_ARCHIVER , PUBLIC_ARCHIVE_URL in mm_cfg.py and the
> appropriate thingies in httpd.conf). Small messages worked fine. Big
> whoppers = no joy i.e. still the same with big messages. So at least it
> is not the archiving bit that messes up.
>
> So I upgraded my Python ;) Ermm, to version 2.0. Still the same.
>
> Has anyone had the same problem? Can anyone confirm this as a bug by
> sending a 2MB file to a 2.0.5 testlist?
>
> How do I do a trace in Python? (i.e. it is as familiar to me as the
> bacteria in my stomach (I runs on my machine and there endeth the
> relationship))
>
> Any pointers? Anything? I need to get this list running before monday
> (yes this is for a business). Please!!!??
>
> Sorry if this e-mail was not formal enough, the 48 hours strait is
> getting to me.
>
> Greets
>
> Dirko
>
> Lab E352
> E&E Engineering
> Univ. of Stellenbosch
> South Africa
>
>
> --__--__--
>
> Message: 2
> From: "James Dinan" <james@gilbertwalker.com>
> To: <mailman-developers@python.org>
> Date: Mon, 25 Jun 2001 10:49:27 -0700
> Subject: [Mailman-Developers] HTML Issue
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> I posted this message to mailman-users, and then the more I was thinking =
> about it, the more I began to think this was a question for developers.  =
> Please tell me what you think:
>
> I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with =
> the Subscribe Results Page (/mailman/subscribe/listname).  More =
> specifically, I have edited the HTML and whenever I view the page, =
> mailman appears to be prepending the following to the source:
>
> <HTML>
> <HEAD>
> </HEAD>
> <BODY
> <BODY bgcolor=3D"#ffffff">
>
> which I'm sure you can imagine is wreaking havoc on the rest of my HTML. =
>  Has anyone else had this problem, or is this fixed in future releases?  =
> Since I am not an admin on the server I am configuring it will be =
> difficult (Redhat installs mailman in /var/mailman) to recompile =
> mailman.
>
> I have just checked =
> http://mail.python.org/mailman/subscribe/mailman-users and you can see =
> for yourself that this is also happening with the version of mailman =
> that serves this list.
>
> - jim dinan.
> -----------------------------------------------------------------------
> James Dinan <james@gilbertwalker.com>
> Gilbert Walker Group: Lenox, MA  U.S.A
> Available:  http://www.gilbertwalker.com
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META content=3D"text/html; charset=3Diso-8859-1" =
> http-equiv=3DContent-Type>
> <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>I posted this message to mailman-users, =
> and then=20
> the more I was thinking about it, the more I began to think this was a =
> question=20
> for developers.&nbsp; Please tell me what you think:</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>
> <DIV><FONT face=3DArial size=3D2>I am running Mailman 2.0.1 on Redhat =
> 6.2 and I am=20
> having difficulty with the Subscribe Results Page=20
> (/mailman/subscribe/listname).&nbsp; More specifically, I have edited =
> the HTML=20
> and whenever I view the page, mailman appears to be prepending the =
> following to=20
> the source:</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2><BR>&lt;HTML&gt;<BR>&lt;HEAD&gt;<BR>&lt;/HEAD&gt;<BR>&lt;BODY<BR=
> >&lt;BODY=20
> bgcolor=3D"#ffffff"&gt;</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>which I'm sure you can imagine is =
> wreaking havoc on=20
> the rest of my HTML.&nbsp; Has anyone else had this problem, or is this =
> fixed in=20
> future releases?&nbsp; Since I am not an admin on the server I am =
> configuring it=20
> will be difficult (Redhat installs mailman in /var/mailman) to recompile =
>
> mailman.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>I have just checked <A=20
> href=3D"http://mail.python.org/mailman/subscribe/mailman-users">http://ma=
> il.python.org/mailman/subscribe/mailman-users</A>&nbsp;and=20
> you can see for yourself that this is also happening with the version of =
> mailman=20
> that serves this list.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>- jim dinan.</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>----------------------------------------------------------------=
> -------<BR>James=20
> Dinan &lt;<A=20
> href=3D"mailto:james@gilbertwalker.com">james@gilbertwalker.com</A>&gt;<B=
> R>Gilbert=20
> Walker Group: Lenox, MA&nbsp; U.S.A<BR>Available:&nbsp; <A=20
> href=3D"http://www.gilbertwalker.com">http://www.gilbertwalker.com</A></F=
> ONT></FONT></DIV></DIV></BODY></HTML>
>
> ------=_NextPart_000_003C_01C0FD64.8168A650--
>
>
>
> --__--__--
>
> Message: 3
> Date: Mon, 25 Jun 2001 17:47:58 +0200
> From: Thomas Wouters <thomas@xs4all.net>
> To: James Dinan <james@gilbertwalker.com>
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] HTML Issue
>
> On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:
>
> > I posted this message to mailman-users, and then the more I was thinking
> > about it, the more I began to think this was a question for developers.
> > Please tell me what you think:
>
> > I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with
> > the Subscribe Results Page (/mailman/subscribe/listname).  More
> > specifically, I have edited the HTML and whenever I view the page,
mailman
> > appears to be prepending the following to the source:
> >
> > <HTML>
> > <HEAD>
> > </HEAD>
> > <BODY
> > <BODY bgcolor="#ffffff">
>
> Yes. This is an open bug, and an old one. It still requires a
Pronouncement
> from Barry. The problem is that Mailman creates a HTMLgen Document instead
> of a HeadlessDocument, for the list page. From the top of my head the fix
is
> to change
>
>     doc = Document()
>
> into
>
>     doc = HeadlessDocument()
>
> in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
> is reluctant to fix it because of possible breakage (people might have
made
> template files with the (Headfull)Document in mind.) Barry ? :)
>
> --
> Thomas Wouters <thomas@xs4all.net>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
>
>
>
> --__--__--
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
>
>
> End of Mailman-Developers Digest
>



From barry@digicool.com  Mon Jun 25 21:34:37 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 25 Jun 2001 16:34:37 -0400
Subject: [Mailman-Developers] HTML Issue
References: <20010625174758.V8098@xs4all.nl>
 <15159.39173.331416.882488@yyz.digicool.com>
 <010e01c0fdcd$79373c80$3202a8c0@station12>
Message-ID: <15159.41053.297672.574049@anthem.wooz.org>

>>>>> "JD" == James Dinan <james@gilbertwalker.com> writes:

    JD> One problem that I have is that somtimes funny things will
    JD> happen inside the <MM-...> tags.

Have I mentioned how much I dislike the <mm-> tags?  Or how much I
reaaally hate having both those and normal Python %()s string
substitutions? ;)

    JD> If you're interested to see how far I've gotten, the mailing
    JD> list I'm working on (for my summer job) is available at
    JD> http://www.gilbertwalker.com/mailman/listinfo/advisorbits.
    JD> Assuming I haven't broken it again it should still be up.
    JD> But, you will notice that there are still many error messages
    JD> which I cannot touch the HTML for.  :/

I'll have to check this out when I get home.  I don't have an easy way
to do Javascript here.

    JD> Oh yeah, one other idea I had (this really pertains to my
    JD> particular site architecture) is that it would be incredibly
    JD> convenient to have a customizable page header and footer that
    JD> could be called via an <MM-...> tag that you could wrap any
    JD> sort of content in.  Sort of like making HeadlessDocument()
    JD> customizable I guess.

I agree.  At this point though, I just want to get the basics of the
web ui fixed.  I don't think I'll have the cycles to completely revamp
the whole thing.

-Barry


From claw@2wire.com  Tue Jun 26 06:22:17 2001
From: claw@2wire.com (J C Lawrence)
Date: Mon, 25 Jun 2001 22:22:17 -0700
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
In-Reply-To: Message from Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
 of "Mon, 25 Jun 2001 15:35:26 +0200." <3B373E1E.6C966C95@ing.sun.ac.za>
References: <3B373E1E.6C966C95@ing.sun.ac.za>
Message-ID: <16417.993532937@2wire.com>

On Mon, 25 Jun 2001 15:35:26 +0200 
Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> wrote:

> I set Mailman up, created a test list and played with it for a
> while.  Then I send it a big "whopper" 5MB e-mail. I watched the
> logs and saw postfix running the wrapper. The cron started qrunner
> and all hell broke lose (over dramatizing a bit). It started
> running at 100% CPU, where it stayed until I killed it. The
> message was queued in $prefix/qfiles, it and its little .db
> file. I had to remove those as well as the locks in $prefix/locks
> before I could successfully use the list again.

> So I thought, "well maybe the pipermail thingy can't handle the
> huge mime thingies I'm sending it". So I send a smaller attachment
> <150kb.  Things went fine (except for the ugly html page:) ) Send
> it a 1MB attachment. qrunner started spinning it's wheels
> again. Had to seek and destroy again.

Having run lists which had posts with attachments in the 100Meg+
range (some people use mail as a file transfer protocol), and had
them work (admittedly more than a year ago) I'm fairly certain that
this is not a Mailman problem.  Its likely to be an MTA problem or a
system problem (eg spool space).  

Try sending such a post with such a large attachment to yourself
through that same mail server.  Now try the same thing, but with say
50 copies of the same message being sent to yourself in very rapid
succession.  What your system closely.  What happens?

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jarrell@vt.edu  Tue Jun 26 15:16:31 2001
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 26 Jun 2001 10:16:31 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
Message-ID: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>

I thought 2.0.5 was safe under python 2.1?  I just copied my mailman installation over to
a new machine, which had 2.1 installed on it.  Most stuff works, although cron is giving me
a slew of warnings about deprecated things and syntax warnings.  But admin passwords are
failing entirely.. I'm getting:

admin(25762):     if not self.ValidAdminPassword(pw):
admin(25762):   File "/home/mailman/Mailman/SecurityManager.py", line 47, in ValidAdminPassword
admin(25762):     return type(pw) == StringType and \
admin(25762): TypeError: argument 2 must be string without null bytes, not string
admin(25762): [----- Python Information -----]
admin(25762): sys.version    = 2.1 (#1, Jun 12 2001, 07:59:49) 
[GCC 2.95.2 19991024 (release)]



From barry@digicool.com  Tue Jun 26 15:36:38 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 26 Jun 2001 10:36:38 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <15160.40438.191682.907698@anthem.wooz.org>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> I thought 2.0.5 was safe under python 2.1?  I just copied my
    RJ> mailman installation over to a new machine, which had 2.1
    RJ> installed on it.  Most stuff works, although cron is giving me
    RJ> a slew of warnings about deprecated things and syntax
    RJ> warnings.  But admin passwords are failing entirely.. I'm
    RJ> getting:

Be sure you re-run configure; make install and that Python 2.1 is
first on your path, or that you use --with-python.  I run MM2.0.5
under Py2.1 so I know it works.

-Barry


From barry@digicool.com  Tue Jun 26 15:38:51 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 26 Jun 2001 10:38:51 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <15160.40571.661124.156912@anthem.wooz.org>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> Python Information -----] admin(25762): sys.version = 2.1 (#1,

Oops, should have looked closer at your output.  I bet something's
messed up with your crypt library.  Like, your older Python
installation didn't have crypt, but your new installation does?

Try setting USE_CRYPT.
-Barry


From jarrell@vt.edu  Tue Jun 26 15:49:13 2001
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 26 Jun 2001 10:49:13 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
In-Reply-To: <15160.40438.191682.907698@anthem.wooz.org>
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <5.1.0.14.2.20010626103834.05d7ca30@lennier.cc.vt.edu>

At 10:36 AM 6/26/01 -0400, Barry A. Warsaw wrote:

>>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:
>
>    RJ> I thought 2.0.5 was safe under python 2.1?  I just copied my
>    RJ> mailman installation over to a new machine, which had 2.1
>    RJ> installed on it.  Most stuff works, although cron is giving me
>    RJ> a slew of warnings about deprecated things and syntax
>    RJ> warnings.  But admin passwords are failing entirely.. I'm
>    RJ> getting:
>
>Be sure you re-run configure; make install and that Python 2.1 is
>first on your path, or that you use --with-python.  I run MM2.0.5
>under Py2.1 so I know it works.

Downloaded a clean 2.0.5 tarball, did the configure, make, make install.
*Then* complained that it still wasn't working :-).

There's only ever *been* one python on this machine, and that's the
2.1.   Perms are all correct.



From jarrell@vt.edu  Tue Jun 26 16:03:52 2001
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 26 Jun 2001 11:03:52 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
In-Reply-To: <15160.40571.661124.156912@anthem.wooz.org>
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <5.1.0.14.2.20010626105034.06af5c00@lennier.cc.vt.edu>

At 10:38 AM 6/26/01 -0400, Barry A. Warsaw wrote:

> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:
>
>     RJ> Python Information -----] admin(25762): sys.version = 2.1 (#1,
>
>Oops, should have looked closer at your output.  I bet something's
>messed up with your crypt library.  Like, your older Python
>installation didn't have crypt, but your new installation does?
>
>Try setting USE_CRYPT.

Ok, my USE_CRYPT has always been set to 1 (as advised in the comments, I 
just let configure set it.)

My old machine was running 1.5.2, and I thought I'd turned everything on, 
but given the module config file has about 174,000 poorly documented bits 
to flip on or off, apparently I didn't.  I just went back to that machine 
and did a "from crypt import crypt", and sure enough, got an 
ImportError.  However, on my new machine, which also has the USE_CRYPT set 
to 1, it turns out that yes, I can import crypt.  So I guess I got screwed 
by the fact that python actually has half a clue now as to what it's doing 
when it builds itself.

However, I suspect the comments are wrong.  I ignored it back then because 
I didn't know, and the comment suggested that configure would do the right 
thing.  Obviously it didn't.  In fact, looking at the Defaults.py.in, it's 
just hard coded to *1*.

 From looking at the code, what's doing the right thing is the Crypt.py 
module, which, if mm_cfg.USE_CRYPT is set, tries to import it, traps the 
error, and resets it on the fly.

The comment in Defaults should probably be changed to "If you don't know, 
leave it at 1, and Crypt.py will do the right thing.  But if you don't have 
crypt, then upgrade python to include crypt, admin.py will start blowing up 
in strange and mysterious ways until you change this back to 0"...




From barry@digicool.com  Tue Jun 26 16:59:24 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 26 Jun 2001 11:59:24 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
 <5.1.0.14.2.20010626105034.06af5c00@lennier.cc.vt.edu>
Message-ID: <15160.45404.945128.378299@anthem.wooz.org>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> My old machine was running 1.5.2, and I thought I'd turned
    RJ> everything on, but given the module config file has about
    RJ> 174,000 poorly documented bits to flip on or off, apparently I
    RJ> didn't.  I just went back to that machine and did a "from
    RJ> crypt import crypt", and sure enough, got an ImportError.
    RJ> However, on my new machine, which also has the USE_CRYPT set
    RJ> to 1, it turns out that yes, I can import crypt.  So I guess I
    RJ> got screwed by the fact that python actually has half a clue
    RJ> now as to what it's doing when it builds itself.

Yes.  By default, Python 2.1 will compile in everything it can find.
This wasn't the case for 1.5.2.

    RJ> However, I suspect the comments are wrong.  I ignored it back
    RJ> then because I didn't know, and the comment suggested that
    RJ> configure would do the right thing.  Obviously it didn't.  In
    RJ> fact, looking at the Defaults.py.in, it's just hard coded to
    RJ> *1*.

    RJ>  From looking at the code, what's doing the right thing is the
    RJ> Crypt.py module, which, if mm_cfg.USE_CRYPT is set, tries to
    RJ> import it, traps the error, and resets it on the fly.

    RJ> The comment in Defaults should probably be changed to "If you
    RJ> don't know, leave it at 1, and Crypt.py will do the right
    RJ> thing.  But if you don't have crypt, then upgrade python to
    RJ> include crypt, admin.py will start blowing up in strange and
    RJ> mysterious ways until you change this back to 0"...

A good explanation for why MM2.1 doesn't use crypt at all.  I'd add
this to the FAQ but I don't think there will be a MM 2.0.6 release.

-Barry


From ricardo.kustner@adcore.com  Tue Jun 26 22:42:12 2001
From: ricardo.kustner@adcore.com (Ricardo Kustner)
Date: Tue, 26 Jun 2001 23:42:12 +0200
Subject: [Mailman-Developers] hotmail & MIME-digests
Message-ID: <20010626234212.H21483@localhost>

I don't know if this has been discussed before, but am I correct to assume
that hotmail.com (and maybe other webmail services too?) doesn't correctly
handle MIME digests send by Mailman? I always thought some people just 
didn't "see" the attached messages, but now I test it myself in hotmail 
i noticed it only shows the footer of the digest and something that looks
like a lost MIME seperator (--212.206.25.241.1015.180.993549624.729.13400--)
I'm sure the digests are send correctly cause when I read them with Mutt as
the client they are ok...
Any ideas? I couldn't really find something in the bug database...

Regards,

Ricardo



From rtyuio@korea.com  Wed Jun 27 03:19:01 2001
From: rtyuio@korea.com (rtyuio@korea.com)
Date: ¼ö, 27 6 2001 15:23:36
Subject: [Mailman-Developers] pc°ü·ÃÁ¤º¸ÀÔ´Ï´Ù
Message-ID: <263.386743.235@korea.com>

ÃÖ½ÅÇüPC
CPU¡¦¡¦¡¦.933 (ÀÎÅÚ)
RAM¡¦¡¦¡¦128 (»ï¼ºÁ¤Ç°133)
HDD¡¦¡¦¡¦30 G
MONITER.17"(»ï¼º77E)

¸ðµÎ43¸¸¿ø

°ü½ÉÀÖÀ¸¼¼¿ä

 http://comzon.atozpia.com/news/news.html

À̸®·Î ¿À¼¼¿ä


From dvschalk@ing.sun.ac.za  Wed Jun 27 15:42:56 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Wed, 27 Jun 2001 16:42:56 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com>
Message-ID: <3B39F0F0.A632C944@ing.sun.ac.za>

J C Lawrence wrote:

> > again. Had to seek and destroy again.
> 
> Having run lists which had posts with attachments in the 100Meg+
> range (some people use mail as a file transfer protocol), and had
> them work (admittedly more than a year ago) I'm fairly certain that
> this is not a Mailman problem.  Its likely to be an MTA problem or a
> system problem (eg spool space).
> 
> Try sending such a post with such a large attachment to yourself
> through that same mail server.  Now try the same thing, but with say
> 50 copies of the same message being sent to yourself in very rapid
> succession.  What your system closely.  What happens?

My MTA (postfix) works fine.


I humbly apologize. It seems that I was to hasty in my definition of
qrunner "spinning" its wheels. 

I made some time measurements :

1 236 202 bytes took 2 minutes to process
4 053 188 bytes took 19 minutes to process

I this normal? Am I missing some option that I can turn of.
What is qrunner doing all this time?

Greets

Dirko


From jra@baylink.com  Wed Jun 27 16:37:07 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Wed, 27 Jun 2001 11:37:07 -0400
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
In-Reply-To: <3B39F0F0.A632C944@ing.sun.ac.za>; from Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> on Wed, Jun 27, 2001 at 04:42:56PM +0200
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com> <3B39F0F0.A632C944@ing.sun.ac.za>
Message-ID: <20010627113707.06527@scfn.thpl.lib.fl.us>

On Wed, Jun 27, 2001 at 04:42:56PM +0200, Dirko van Schalkwyk wrote:
> I humbly apologize. It seems that I was to hasty in my definition of
> qrunner "spinning" its wheels. 
> 
> I made some time measurements :
> 
> 1 236 202 bytes took 2 minutes to process
> 4 053 188 bytes took 19 minutes to process
> 
> I this normal? Am I missing some option that I can turn of.
> What is qrunner doing all this time?

I might guess "swapping", if I knew how much RAM you had.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From dvschalk@ing.sun.ac.za  Wed Jun 27 18:04:34 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Wed, 27 Jun 2001 19:04:34 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com> <3B39F0F0.A632C944@ing.sun.ac.za> <20010627113707.06527@scfn.thpl.lib.fl.us>
Message-ID: <3B3A1222.BDC0A69C@ing.sun.ac.za>

"Jay R. Ashworth" wrote:

> > I this normal? Am I missing some option that I can turn of.
> > What is qrunner doing all this time?
> 
> I might guess "swapping", if I knew how much RAM you had.  :-)
> 

Got plenty :*)

I would appreciate it if anyone can do similar time tests?


Greets 

Dirko

--------
cat /proc/cpuinfo

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 3
model name      : AMD Athlon(tm) Processor
stepping        : 0
cpu MHz         : 600.046
cache size      : 64 KB
bogomips        : 1196.03

cat /proc/meminfo

        total:    used:    free:  shared: buffers:  cached:
Mem:  402161664 233144320 169017344        0 123678720 43839488
Swap: 262103040        0 262103040
MemTotal:    392736 kB
MemFree:     165056 kB
MemShared:        0 kB
Buffers:     120780 kB
Cached:       42812 kB
BigTotal:         0 kB
BigFree:          0 kB
SwapTotal:   255960 kB
SwapFree:    255960 kB

-----


From claw@kanga.nu  Wed Jun 27 18:50:37 2001
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 27 Jun 2001 10:50:37 -0700
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
In-Reply-To: Message from Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
 of "Wed, 27 Jun 2001 16:42:56 +0200." <3B39F0F0.A632C944@ing.sun.ac.za>
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com>  <3B39F0F0.A632C944@ing.sun.ac.za>
Message-ID: <6771.993664237@kanga.nu>

On Wed, 27 Jun 2001 16:42:56 +0200 
Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> wrote:

> I made some time measurements :

> 1 236 202 bytes took 2 minutes to process 4 053 188 bytes took 19
> minutes to process

> I this normal? Am I missing some option that I can turn of.  What
> is qrunner doing all this time?

Are you swapping?

Aside: Qrunner is written in Python and operates by loading the
entire subject message into memory before processing.  This also may
be at the core of the problem.  

-- 
J C Lawrence                                             claw@kanga.nu
---------(*)                                http://www.kanga.nu/~claw/
I never claimed to be human.


From dvschalk@ing.sun.ac.za  Wed Jun 27 19:08:24 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Wed, 27 Jun 2001 20:08:24 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com>  <3B39F0F0.A632C944@ing.sun.ac.za> <6771.993664237@kanga.nu>
Message-ID: <3B3A2118.D60060A0@ing.sun.ac.za>

J C Lawrence wrote:

> Are you swapping?
> 
> Aside: Qrunner is written in Python and operates by loading the
> entire subject message into memory before processing.  This also may
> be at the core of the problem.

No.
I got +-340 MB RAM and 40MB/s fast and wide SCSI DISKS.

Greets

Dirko


From barry@digicool.com  Wed Jun 27 19:11:00 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Wed, 27 Jun 2001 14:11:00 -0400
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za>
 <16417.993532937@2wire.com>
 <3B39F0F0.A632C944@ing.sun.ac.za>
 <6771.993664237@kanga.nu>
 <3B3A2118.D60060A0@ing.sun.ac.za>
Message-ID: <15162.8628.903466.326444@anthem.wooz.org>

>>>>> "DvS" == Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> writes:

    DvS> No.
    DvS> I got +-340 MB RAM and 40MB/s fast and wide SCSI DISKS.

You may have to do more digging then.  Start by adding syslog() calls
to print debugging information to e.g. logs/debug.

-Barry


From y.nugroho@student.umist.ac.uk  Thu Jun 28 16:58:33 2001
From: y.nugroho@student.umist.ac.uk (Yanuar Nugroho)
Date: Thu, 28 Jun 2001 16:58:33 +0100
Subject: [Mailman-Developers] archive
Message-ID: <00b601c0ffeb$2eedaea0$9baa5882@halls.umist.ac.uk>

Hi,

How is the principle of archiving in Mailman? Is it related to storing and
retrieving data when the archives are accessed thru the website?
Can mailman take a particular message in the archive and stick it to new
message to be distributed?


Yanuar



From barry@digicool.com  Thu Jun 28 17:27:03 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 28 Jun 2001 12:27:03 -0400
Subject: [Mailman-Developers] archive
References: <00b601c0ffeb$2eedaea0$9baa5882@halls.umist.ac.uk>
Message-ID: <15163.23255.104834.675174@anthem.wooz.org>

>>>>> "YN" == Yanuar Nugroho <y.nugroho@student.umist.ac.uk> writes:

    YN> How is the principle of archiving in Mailman? Is it related to
    YN> storing and retrieving data when the archives are accessed
    YN> thru the website?  Can mailman take a particular message in
    YN> the archive and stick it to new message to be distributed?

Mailman is designed so that either its internal Pipermail archiver, or
an external archiver of the site's choice, can be used.  Pipermail is
pretty braindead simple: it simply creates the indices and html-ifies
the message.  It has the advantage that it's written in Python and
easily bundled for the one-stop-shopping crowd.  It has several
disadvantages though, and many serious Mailman sites use a separate
3rd party archiver instead.

IOW, it would be the backend archiver's responsibility to implement
things like thru-the-web replies.  Mailman supports direct injection
of messages from any external source (and MM2.1 will be even better in
this regard).  I'd love to see something like this added so its On The
List, but who knows when there will be time to devote to it?

Cheers,
-Barry


From y.nugroho@student.umist.ac.uk  Fri Jun 29 03:36:09 2001
From: y.nugroho@student.umist.ac.uk (Yanuar Nugroho)
Date: Fri, 29 Jun 2001 03:36:09 +0100
Subject: [Mailman-Developers] layout
Message-ID: <026f01c10044$414806a0$9baa5882@halls.umist.ac.uk>

Hi folks,

Is it possible to change the layout of the message body in Mailman? (e.g.
changing the left & right margin of the body message)
Is it also possible to insert certain text into the body but _not_ header or
footer?

Currently my Mailman 2.1 is running on my unix-apache-sendmail configuration
very very well ...:)

-Yanuar-



From davek@mail.commercedata.com  Fri Jun  1 05:46:06 2001
From: davek@mail.commercedata.com (Dave Klingler)
Date: Thu, 31 May 2001 22:46:06 -0600 (MDT)
Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or
In-Reply-To: <15125.56302.501876.382172@anthem.wooz.org> from "Barry A. Warsaw" at May 31, 2001 01:51:42 AM
Message-ID: <200106010446.WAA07646@mail.commercedata.com>

> I've completely rewritten the user options page (more on this later,
> tomorrow is checkin day :), and have taken the opportunity to do
> exactly this.  I may have missed some, but the idea is that the colors
> are now overridable in mm_cfg.py.

Wonderful!
  
> Which makes me think more about having a better support for virtual
> domains by having something akin to a different mm_cfg.py per domain.

This would be very cool.  My favorite implementation of virtual domains
is Apache's, and it strikes me that adding the <virtualhost domain> 
directive might be an easy and intuitive way of accomplishing virtual domain 
directives now that you have overridable colors in mm_cfg.py.

Just a thought.  If you did key admin messages in mm_cfg.py you could put
them here this way.

Thanks for all the improvements!  Some day if I could consolidate all my
mailman virtual implementations, all in their separate chrooted environments,
back into one virtual mailman environment, I would die happy and will Barry 
my Star Trek hologram trading cards AND my wool Canadian Army cap.

Dave Klingler


> That's rumbling around in the back of my head.
> 
>     CVR> The other key one for me are some of the admin messages
>     CVR> (Mailman/Handlers/Hold.py). I've modified some of the
>     CVR> messages for various reasons, and it'd be nice if I could
>     CVR> simply override their definitions in the mm_cfg.py file
> 
> I'll have to think about this.  One hackish idea (untested) is to try
> to import Mailman.Hold from mm_cfg.py, and then set the class's
> __doc__ attribute with the message you want.  The fact that
> Mailman/Hold.py imports mm_cfg.py means you might have to play games
> with the importer to get this to work.  Not a great solution, but it
> might help localize your customizations for now.
> 
>     CVR> And the third place I've made custom changes are in some of
>     CVR> the list templates (most radically templates/listinfo.html)
>     CVR> -- but that's why they're template; you simply keep a copy
>     CVR> somewhere and watch out for additions to the updated copy...
> 
> Exactly, and the new template lookup scheme should be much more
> friendly to this approach.
> 
>     CVR> It took me about three days and a couple of exchanges with
>     CVR> the author of mod_layout to get it going the way I wanted
>     CVR> (the documentation is still being fleshed out), but it's a
>     CVR> nice improvement to the old way of doing things -- and since
>     CVR> I know others build custom skins around their installations,
>     CVR> I'd thought I'd pass this one along.
> 
> Yes, thanks!
> 
> -Barry
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> 



From chuqui@plaidworks.com  Fri Jun  1 06:20:01 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 31 May 2001 22:20:01 -0700
Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or
In-Reply-To: <200106010446.WAA07646@mail.commercedata.com>
Message-ID: <200106010518.f515I8c03498@lists.apple.com>

On Thursday, May 31, 2001, at 09:46 PM, Dave Klingler wrote:

> This would be very cool.  My favorite implementation of virtual domains
> is Apache's, and it strikes me that adding the <virtualhost domain>
> directive might be an easy and intuitive way of accomplishing virtual 
> domain
> directives now that you have overridable colors in mm_cfg.py.

The downside is that you have a single point of administration. In an 
ISP environment, it'd be nice to export that administration to the owner 
of the domain, so you don't have a support guy going crazy with "can you 
make this change?" requests.

But you could deal with that by extending it to allow included files>

<virtualhost domain>
<include /page/to/file>
</virtualhost>

so you have the option of handing it off. But that gets you into issues 
of whether those users can screw things up for everyone else with 
typoes, etc. It'd be nice if an included file has a typo that it only 
destroy the current virthost...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Always look away from the obvious answers, because if you don't find
a better one, you can always go back to them on short notice.




From ricardo@rixhq.nu  Fri Jun  1 07:12:36 2001
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Fri, 1 Jun 2001 08:12:36 +0200
Subject: [Mailman-Developers] subscriber profiler patch for mailman-2.0.5
In-Reply-To: <Pine.LNX.4.21.0105301930560.30384-100000@marakani.srikant.org>; from sh@srikant.org on Wed, May 30, 2001 at 07:56:40PM +0800
References: <Pine.LNX.4.21.0105301930560.30384-100000@marakani.srikant.org>
Message-ID: <20010601081236.B4058@rix.rixhq.nu>

Hi,

On Wed, May 30, 2001 at 07:56:40PM +0800, Swee Heng wrote:
> i've written a patch to mailman-2.0.5 that lets it handle subscribers'
> profiles. (is this the "member profiles" feature on the wishlist?)
> this is my first serious attempt at python. so please be warned. :)
> feel free to comment.

looks great to me... maybe this would be a good solution for this much
requested feature for this version of mailman untill we get the database
stuff in mailman 3.0... maybe some of the mailman developers can comment on
this? I can't comment that much on the contents of the patch though it seems
not to have a huge impact on the rest of the code base as far as I can
tell...

my comments:
1) the subscribers list on the right could be usefull but if you have a list
with 10k subscribers maybe that's not such a great idea :)
2) am I correct to assume that you can use the MM tags in the templates to
'dynamically' invent the profile field names used? 

Regards,

Ricardo



From Swee Heng <sh@srikant.org>  Fri Jun  1 08:07:00 2001
From: Swee Heng <sh@srikant.org> (Swee Heng)
Date: Fri, 1 Jun 2001 15:07:00 +0800 (SGT)
Subject: [Mailman-Developers] subscriber profiler patch for mailman-2.0.5
In-Reply-To: <20010601081236.B4058@rix.rixhq.nu>
Message-ID: <Pine.LNX.4.21.0106011452340.24819-100000@marakani.srikant.org>

| looks great to me... maybe this would be a good solution for this much
thank you. that's very encouraging. :)

| this? I can't comment that much on the contents of the patch though it seems
| not to have a huge impact on the rest of the code base as far as I can
| tell...
i've tried to minimize the impact to the original code. the only original
files modified are src/Makefile (i added " profile") and edithtml.py (i
extended the list of edittable pages).

| 1) the subscribers list on the right could be usefull but if you have a list
| with 10k subscribers maybe that's not such a great idea :)
indeed. :) actually i simply copied the idea from roster.py. each member
adds about 0.1kb. so 1000 members gives a file size of about 100kb. 10k
members gives a file size of 1Mb. ouch! :)

| 2) am I correct to assume that you can use the MM tags in the templates to
| 'dynamically' invent the profile field names used? 
yes. <MM-P--tags> are used by profile.py internally while <MM-P-tags> are
for the profile field names. the "database" entry for joe@random.org is a
pickle of the dictionary : { '<mm-p-realname>' : 'Joe Random', ... }

regards,
sweeheng



From mmd@laubster.org  Fri Jun  1 16:29:42 2001
From: mmd@laubster.org (J.D. Laub)
Date: Fri, 01 Jun 2001 09:29:42 -0600
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
Message-ID: <3B17B4E6.4871098F@laubster.org>

Please CC me on replies as I'm not a mailman-developer subscriber...

In my inbox this morning I found several monthly reminders for various
lists to which I'm subscribed.  I'm responsible enough to save off a
list's "Welcome" message, and I need no monthly reminder.  Why does
Mailman penalize me with setting up & maintaining filter rules to
clobber the unnecessary reminders?  Is adding a user level configuration
of this option in the works?  If not, here's a request for one.


From barry@digicool.com  Fri Jun  1 16:54:15 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 11:54:15 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
Message-ID: <15127.47783.269611.179914@anthem.wooz.org>

>>>>> "JDL" == J D Laub <mmd@laubster.org> writes:

    JDL> In my inbox this morning I found several monthly reminders
    JDL> for various lists to which I'm subscribed.  I'm responsible
    JDL> enough to save off a list's "Welcome" message, and I need no
    JDL> monthly reminder.  Why does Mailman penalize me with setting
    JDL> up & maintaining filter rules to clobber the unnecessary
    JDL> reminders?  Is adding a user level configuration of this
    JDL> option in the works?  If not, here's a request for one.

Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
support user-disabling of reminder messages, on a per-list, or
per-virtual domain basis.

-Barry


From jra@baylink.com  Fri Jun  1 17:07:43 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 1 Jun 2001 12:07:43 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.47783.269611.179914@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 01, 2001 at 11:54:15AM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org>
Message-ID: <20010601120743.64585@scfn.thpl.lib.fl.us>

On Fri, Jun 01, 2001 at 11:54:15AM -0400, Barry A. Warsaw wrote:
> Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
> support user-disabling of reminder messages, on a per-list, or
> per-virtual domain basis.

Well, damnit Barry, what took you so long?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Fri Jun  1 17:15:27 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 12:15:27 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <15127.47783.269611.179914@anthem.wooz.org>
 <20010601120743.64585@scfn.thpl.lib.fl.us>
Message-ID: <15127.49055.164063.874312@anthem.wooz.org>

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    >> Yes.  Just yesterday I checked in changes to the MM2.1alpha
    >> tree to support user-disabling of reminder messages, on a
    >> per-list, or per-virtual domain basis.

    JRA> Well, damnit Barry, what took you so long?

Well, it takes a long time to check in stuff over a pokie little DSL
line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
house, it would go a long way toward faster checkins of cool new
features. :)

-Barry


From jra@baylink.com  Fri Jun  1 17:48:43 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 1 Jun 2001 12:48:43 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.49055.164063.874312@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 01, 2001 at 12:15:27PM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <15127.49055.164063.874312@anthem.wooz.org>
Message-ID: <20010601124843.48860@scfn.thpl.lib.fl.us>

On Fri, Jun 01, 2001 at 12:15:27PM -0400, Barry A. Warsaw wrote:
>     JRA> Well, damnit Barry, what took you so long?
> 
> Well, it takes a long time to check in stuff over a pokie little DSL
> line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
> house, it would go a long way toward faster checkins of cool new
> features. :)

OC48.

Shyeah, right.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From chuqui@plaidworks.com  Fri Jun  1 17:52:14 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 1 Jun 2001 09:52:14 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010601124843.48860@scfn.thpl.lib.fl.us>
Message-ID: <200106011650.f51GoJc26582@lists.apple.com>

On Friday, June 1, 2001, at 09:48 AM, Jay R. Ashworth wrote:

> OC48.
>
> Shyeah, right.
>

hey, don't put it down until you try it. I love mine.

you wouldn't believe how quickly you can download movies from 
www.nudgewink.com


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Some days you're the dog, some days you're the hydrant.



From barry@digicool.com  Fri Jun  1 17:58:39 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 12:58:39 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <15127.47783.269611.179914@anthem.wooz.org>
 <20010601120743.64585@scfn.thpl.lib.fl.us>
 <15127.49055.164063.874312@anthem.wooz.org>
 <20010601124843.48860@scfn.thpl.lib.fl.us>
Message-ID: <15127.51647.715092.998526@anthem.wooz.org>

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    JRA> OC48.

    JRA> Shyeah, right.

Hey, I worked for the gubmint for 10 years.  Trust me, it never hurts
to ask.

waiting-for-that-t3-from-fla-l y'rs,
-Barry


From adamj@dumpshock.com  Fri Jun  1 18:04:09 2001
From: adamj@dumpshock.com (Adam J)
Date: Fri, 01 Jun 2001 11:04:09 -0600
Subject: [Mailman-Developers] why no user disable of the monthly
 reminder?
In-Reply-To: <15127.47783.269611.179914@anthem.wooz.org>
References: <3B17B4E6.4871098F@laubster.org>
Message-ID: <4.3.2.7.2.20010601105931.00d09538@fastjack.dumpshock.com>

At 09:54 01/06/2001, Barry A. Warsaw wrote:

 >Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
 >support user-disabling of reminder messages, on a per-list, or
 >per-virtual domain basis.

Is the default setting configurable by the list-admin, or is it hard-coded 
to a certain setting?

Adam
< http://tss.dumpshock.com / http://www.jillted.org / adamj@dumpshock.com >



From chuqui@plaidworks.com  Fri Jun  1 18:07:00 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 1 Jun 2001 10:07:00 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.51647.715092.998526@anthem.wooz.org>
Message-ID: <200106011705.f51H55W27228@lists.apple.com>

On Friday, June 1, 2001, at 09:58 AM, Barry A. Warsaw wrote:

> Hey, I worked for the gubmint for 10 years.  Trust me, it never hurts
> to ask.
>

tell you what, Barry -- I'll hook up a modem to my network at home, and 
you can dial in and share mine that way.

chuq (a typical gubmint solution to the problem...)



--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

USENET is a lot better after two or three eggnogs. We shouldn't allow
anyone on the net without a bottle of brandy. (chuq von rospach, 1992)



From jra@baylink.com  Fri Jun  1 18:07:02 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 1 Jun 2001 13:07:02 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <200106011650.f51GoJc26582@lists.apple.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Fri, Jun 01, 2001 at 09:52:14AM -0700
References: <20010601124843.48860@scfn.thpl.lib.fl.us> <200106011650.f51GoJc26582@lists.apple.com>
Message-ID: <20010601130702.59546@scfn.thpl.lib.fl.us>

On Fri, Jun 01, 2001 at 09:52:14AM -0700, Chuq Von Rospach wrote:
> > OC48.
> > Shyeah, right.
> 
> hey, don't put it down until you try it. I love mine.
> you wouldn't believe how quickly you can download movies from 
> www.nudgewink.com

Rugger bastard.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Fri Jun  1 18:13:12 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 13:13:12 -0400
Subject: [Mailman-Developers] why no user disable of the monthly
 reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <4.3.2.7.2.20010601105931.00d09538@fastjack.dumpshock.com>
Message-ID: <15127.52520.82101.167530@anthem.wooz.org>

>>>>> "AJ" == Adam J <adamj@dumpshock.com> writes:

    AJ> Is the default setting configurable by the list-admin, or is
    AJ> it hard-coded to a certain setting?

The list owner can say that password reminders are never sent for his
list, but the ability for a user to suppress passwords globally across
all lists is always available.

-Barry


From barry@digicool.com  Fri Jun  1 18:15:03 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 13:15:03 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <15127.51647.715092.998526@anthem.wooz.org>
 <200106011705.f51H55W27228@lists.apple.com>
Message-ID: <15127.52631.12204.165364@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> tell you what, Barry -- I'll hook up a modem to my network at
    CVR> home, and you can dial in and share mine that way.

    CVR> chuq (a typical gubmint solution to the problem...)

Actually, a TGS would involve going through all the expense of putting
that in place, using it once, and then letting it rot for 30 years.

-Barry


From thomas@xs4all.net  Fri Jun  1 20:41:28 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 1 Jun 2001 21:41:28 +0200
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <15127.49055.164063.874312@anthem.wooz.org>; from barry@digicool.com on Fri, Jun 01, 2001 at 12:15:27PM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <15127.49055.164063.874312@anthem.wooz.org>
Message-ID: <20010601214128.P690@xs4all.nl>

On Fri, Jun 01, 2001 at 12:15:27PM -0400, Barry A. Warsaw wrote:

> >>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

>     >> Yes.  Just yesterday I checked in changes to the MM2.1alpha
>     >> tree to support user-disabling of reminder messages, on a
>     >> per-list, or per-virtual domain basis.

>     JRA> Well, damnit Barry, what took you so long?

> Well, it takes a long time to check in stuff over a pokie little DSL
> line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
> house, it would go a long way toward faster checkins of cool new
> features. :)

Weeeelll... If you want to move to Amsterdam, Barry, I'm pretty sure I can
find you a nice li'l sysadmin spot at a certain ISP, and an apt. within
sight of office, so you can use a 2Mbit wireless connection to leach off of
the 1Gbit (ethernet over dark fiber) links we have connected to our uplinks
and multitude of peers ;)

Unfortunately for me, there's a big appartement building smack in the middle
of *my* line of sight to the office.... so I'll have to make do with a puny
33k6 analogue leased line until they either tear down the building or get me
a decent ADSL service :P

-- 
Thomas Wouters <thomas@xs4all.net>

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


From barry@digicool.com  Fri Jun  1 20:53:20 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 15:53:20 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
 <15127.47783.269611.179914@anthem.wooz.org>
 <20010601120743.64585@scfn.thpl.lib.fl.us>
 <15127.49055.164063.874312@anthem.wooz.org>
 <20010601214128.P690@xs4all.nl>
Message-ID: <15127.62128.598176.238796@anthem.wooz.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Weeeelll... If you want to move to Amsterdam, Barry, I'm
    TW> pretty sure I can find you a nice li'l sysadmin spot at a
    TW> certain ISP, and an apt. within sight of office, so you can
    TW> use a 2Mbit wireless connection to leach off of the 1Gbit
    TW> (ethernet over dark fiber) links we have connected to our
    TW> uplinks and multitude of peers ;)

Don't tempt me!  There's already been a Netherlands->US imbalance in
The Force for the last 6 years.  And if we can't tip the scales for
good by /us/ hiring /you/, I might just have to help balance the
scales in the other direction.

Not that my brain can compare to Guido's, no, but Max sure is cuter,
so that evens things.  I've got a cousin just an hour or so away from
you in Germany, and if Guido can learn to speak like a
"Warshingtonian", I'm sure I can pick up enough Dutch to get by.
'Course, it /is/ a long sea voyage away. :)

i'd-just-be-coming-for-the-hash-bars-and-hookers-anyway-ly y'rs,
-Barry


From gmourani@openna.com  Fri Jun  1 21:35:18 2001
From: gmourani@openna.com (Gerhard Mourani)
Date: Fri, 1 Jun 2001 16:35:18 -0400
Subject: [Mailman-Developers] Bug under link (Tend to pending administrative requests)
Message-ID: <013e01c0eada$5eef8720$1401a8c0@openna.com>

OS      = RH Linux 7.1
Python  = 2.1
mailman = 2.0.5

clicking on the link (Tend to pending administrative requests) under the
administration web interface will return the following
error message into the mailman error log file:


admin(18366): [----- Traceback ------]
admin(18366): Traceback (most recent call last):
admin(18366):   File "/var/lib/mailman/scripts/driver", line 96, in run_main
admin(18366):     main()
admin(18366):   File "/var/lib/mailman/Mailman/Cgi/admindb.py", line 108, in
main
admin(18366):     if len(cgidata.keys()):
admin(18366): UnboundLocalError: local variable 'cgidata' referenced before
assignment
admin(18366): [----- Python Information -----]
admin(18366): sys.version    = 2.1 (#1, May 31 2001, 18:30:14)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)]
admin(18366): sys.executable = /usr/bin/python
admin(18366): sys.prefix     = /usr
admin(18366): sys.exec_prefix= /usr
admin(18366): sys.path       = /usr
admin(18366): sys.platform   = linux-i386

Any suggestion??

--
Gerhard Mourani - gmourani@openna.com
Operation & Development Manager
OpenNA.com - http://www.openna.com/
--



From barry@digicool.com  Fri Jun  1 22:01:14 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 1 Jun 2001 17:01:14 -0400
Subject: [Mailman-Developers] Bug under link (Tend to pending administrative requests)
References: <013e01c0eada$5eef8720$1401a8c0@openna.com>
Message-ID: <15128.666.576627.730090@anthem.wooz.org>

>>>>> "GM" == Gerhard Mourani <gmourani@openna.com> writes:

    | OS      = RH Linux 7.1
    | Python  = 2.1
    | mailman = 2.0.5

    GM> clicking on the link (Tend to pending administrative requests)
    GM> under the administration web interface will return the
    GM> following error message into the mailman error log file:

Are you sure you really installed 2.0.5?  This bug was fixed in 2.0.5.

-Barry


From wilane@MINT.SN  Sat Jun  2 05:57:33 2001
From: wilane@MINT.SN (Ousmane Wilane)
Date: Sat, 2 Jun 2001 04:57:33 +0000 (GMT)
Subject: [Mailman-Developers] Missed _()
Message-ID: <Pine.LNX.4.33.0106020453080.10171-100000@NS.MINT.SN>

File: Mailman/Cgi/options.py
Line: 450
String: "<em>Yes, I realy want to unsubscribe</em>"

Cheers
-- 
-- Ousmane Wilane
-- "The best laid plans sometimes go awry..."



From barry@digicool.com  Sat Jun  2 05:49:23 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sat, 2 Jun 2001 00:49:23 -0400
Subject: [Mailman-Developers] Missed _()
References: <Pine.LNX.4.33.0106020453080.10171-100000@NS.MINT.SN>
Message-ID: <15128.28755.704021.811604@anthem.wooz.org>

>>>>> "OW" == Ousmane Wilane <wilane@MINT.SN> writes:

    | File: Mailman/Cgi/options.py
    | Line: 450
    | String: "<em>Yes, I realy want to unsubscribe</em>"

Awesome, thanks!

I love open source. :)

-Barry


From barry@digicool.com  Sat Jun  2 06:31:43 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sat, 2 Jun 2001 01:31:43 -0400
Subject: [Mailman-Developers] minor qrunner bug.
References: <200105310715.f4V7Fmh05534@plaidworks.com>
Message-ID: <15128.31295.781320.220845@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> Just noticed a minor bug in qrunner. when qrunner starts up,
    CVR> it opens the log files, and leaves them open.

    CVR> while open/write/close is expensive, given all of the other
    CVR> stuff qrunner's doing and the relative lack of logging, I
    CVR> don't think it's significant. Alternatively, it can notice
    CVR> the files have been moved/zeroed, or perhaps accept a HUP
    CVR> like syslog...

>>>>> "JS" == Jon Stevens <jon@latchkey.com> writes:

    JS> The way that Apache HTTPd works (as well as many other
    JS> daemons) is that you move the log files out of the way and
    JS> then you HUP Apache which will re-create the log
    JS> files. Accepting HUP's (or a graceful restart) is
    JS> functionality that should be added to qrunner if it isn't
    JS> there already.

This turned out to fairly easy to add, so I have. :)

SIGHUP on the qrunner master process now closes all the log files.
They will be reopened on the next write.

-Barry


From chuqui@plaidworks.com  Sat Jun  2 07:37:05 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 1 Jun 2001 23:37:05 -0700
Subject: [Mailman-Developers] minor qrunner bug.
In-Reply-To: <15128.31295.781320.220845@anthem.wooz.org>
Message-ID: <200106020628.f526Srh01518@plaidworks.com>

--Apple-Mail-286235841-4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	format=flowed;
	charset=us-ascii


On Friday, June 1, 2001, at 10:31 PM, Barry A. Warsaw wrote:

> This turned out to fairly easy to add, so I have. :)
>
> SIGHUP on the qrunner master process now closes all the log files.
> They will be reopened on the next write.

by the way, another app susceptible to this is mailpasswd.

It'd be nice if there were some way to tell these tools to shut down 
conveniently, and if possible, snapshot and restart where they left off. 
But that's probably asking for gold leaf instead of gold paint...




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Stress is when you wake up screaming and you realize you haven't fallen 
asleep yet.




--Apple-Mail-286235841-4
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=us-ascii


On Friday, June 1, 2001, at 10:31 PM, Barry A. Warsaw wrote:


<excerpt>This turned out to fairly easy to add, so I have. :)


SIGHUP on the qrunner master process now closes all the log files.

They will be reopened on the next write.

</excerpt>

by the way, another app susceptible to this is mailpasswd. 


It'd be nice if there were some way to tell these tools to shut down
conveniently, and if possible, snapshot and restart where they left
off. But that's probably asking for gold leaf instead of gold paint...



<color><param>0000,0000,DEB7</param>

</color>

-- 

Chuq Von Rospach, Internet Gnome <<http://www.chuqui.com>

[<<chuqui@plaidworks.com> = <<me@chuqui.com> = <<chuq@apple.com>]

Yes, yes, I've finally finished my home page. Lucky you. 


Stress is when you wake up screaming and you realize you haven't
fallen asleep yet.





--Apple-Mail-286235841-4--


From timpye@inbiworld.com  Sun Jun  3 01:24:22 2001
From: timpye@inbiworld.com (INBI-MATRIX)
Date: Sat, 2 Jun 2001 17:24:22 -0700
Subject: [Mailman-Developers] pyethon required
Message-ID: <000501c0ebc3$89f0bea0$f80686cb@venus>

To all,
Anyone interested in setting up mailman on our Linux server so we can run a
discussion forum for our members?
thanks,

Tim Pye
INBI-MATRIX
PO Box 3003
TAMARAMA NSW 2026
Australia
timpye@inbiworld.com
Tel/Fax 61-2-9365 3455
www.inbiworld.com



From thomas@xs4all.net  Sat Jun  2 15:17:45 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 2 Jun 2001 16:17:45 +0200
Subject: [Mailman-Developers] pyethon required
In-Reply-To: <000501c0ebc3$89f0bea0$f80686cb@venus>; from timpye@inbiworld.com on Sat, Jun 02, 2001 at 05:24:22PM -0700
References: <000501c0ebc3$89f0bea0$f80686cb@venus>
Message-ID: <20010602161744.S690@xs4all.nl>

On Sat, Jun 02, 2001 at 05:24:22PM -0700, INBI-MATRIX wrote:

> Anyone interested in setting up mailman on our Linux server so we can run a
> discussion forum for our members?

Setting up Mailman is a breeze. Anyone who ever installed a program using
'./configure' and 'make install', and configured/installed Apache and
Sendmail (or whatever MTA you use) will make sense of the installation
instructions.

If you really  need someone to set it up, I'd be willing to, but you have to
consider maintenance issues -- it's a lot more convenient, for you, if the
normal sysadmin does it.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From ricardo@rixhq.nu  Sat Jun  2 22:30:14 2001
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Sat, 2 Jun 2001 23:30:14 +0200
Subject: [Mailman-Developers] [rather offtopic] DSL lines
In-Reply-To: <20010601214128.P690@xs4all.nl>; from thomas@xs4all.net on Fri, Jun 01, 2001 at 09:41:28PM +0200
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <15127.49055.164063.874312@anthem.wooz.org> <20010601214128.P690@xs4all.nl>
Message-ID: <20010602233014.A1560@rix.rixhq.nu>

On Fri, Jun 01, 2001 at 09:41:28PM +0200, Thomas Wouters wrote:
> > Well, it takes a long time to check in stuff over a pokie little DSL
> > line.  I mean, if anybody wants to donate a nice T3 or OC48 to my
> > house, it would go a long way toward faster checkins of cool new
> > features. :)
> Weeeelll... If you want to move to Amsterdam, Barry, I'm pretty sure I can
> find you a nice li'l sysadmin spot at a certain ISP, and an apt. within
> sight of office, so you can use a 2Mbit wireless connection to leach off of
> the 1Gbit (ethernet over dark fiber) 

Hey, I happen to live one subway stop from that certain ISP... is that offer
open for other people too? ;-) Hmmm unfortunately my appartment isn't in the
line of sight either... oh well, i'm quite happy with the ADSL line
from that same ISP... :)

Regards,

Ricardo



From wilane@MINT.SN  Sat Jun  2 22:34:21 2001
From: wilane@MINT.SN (Ousmane Wilane)
Date: Sat, 2 Jun 2001 21:34:21 +0000 (GMT)
Subject: [Mailman-Developers] Missin )!
Message-ID: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>

		From mailman  Sat Jun  2 17:00:00 2001
[snip]
		  File "/home/mailman/cron/checkdbs", line 57
		    admin = mlist.GetAdminEmail()
		        ^
		SyntaxError: invalid syntax

missing ")" at line 55 in cron/checkdbs
    subject = _('%d %s moderator request(s) waiting' % (
           count, mlist.real_name)
Barry and i18n it's realy love at first sight :)
Cheers!


-- 
-- Ousmane Wilane
-- "The best laid plans sometimes go awry..."



From wilane@MINT.SN  Sat Jun  2 23:14:45 2001
From: wilane@MINT.SN (Ousmane Wilane)
Date: Sat, 2 Jun 2001 22:14:45 +0000 (GMT)
Subject: [Mailman-Developers] -S pb!
Message-ID: <Pine.LNX.4.33.0106022205120.3243-100000@NS.MINT.SN>

	Subject: Cron <mailman@NS> /usr/bin/python -S
	[snip]
	Traceback (most recent call last):
	  File "/home/mailman/cron/senddigests", line 25, in ?
	    from Mailman import MailList
	  File "/home/mailman/Mailman/MailList.py", line 34, in ?
	    from mimelib.address import getaddresses
	ImportError: No module named mimelib.address

mimelib is under site-packages!
Why -S?
Cheers!

-- 
-- Ousmane Wilane
-- "The best laid plans sometimes go awry..."



From dmick@utopia.West.Sun.COM  Sun Jun  3 01:50:20 2001
From: dmick@utopia.West.Sun.COM (Dan Mick)
Date: Sat, 02 Jun 2001 17:50:20 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
References: <3B17B4E6.4871098F@laubster.org>
Message-ID: <3B1989CC.8D8FEA78@utopia.west.sun.com>


"J.D. Laub" wrote:
> 
> Please CC me on replies as I'm not a mailman-developer subscriber...
> 
> In my inbox this morning I found several monthly reminders for various
> lists to which I'm subscribed.  I'm responsible enough to save off a
> list's "Welcome" message, and I need no monthly reminder.  Why does
> Mailman penalize me with setting up & maintaining filter rules to
> clobber the unnecessary reminders?  

You would go to the trouble of setting up a filter for a *monthly*
message?

Man, I thought I was anal-retentive, but the Internet shows me how much
of a slacker I really am.


From claw@kanga.nu  Sun Jun  3 07:20:04 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sat, 02 Jun 2001 23:20:04 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: Message from Dan Mick <dmick@utopia.West.Sun.COM>
 of "Sat, 02 Jun 2001 17:50:20 PDT." <3B1989CC.8D8FEA78@utopia.west.sun.com>
References: <3B17B4E6.4871098F@laubster.org>  <3B1989CC.8D8FEA78@utopia.west.sun.com>
Message-ID: <9901.991549204@kanga.nu>

On Sat, 02 Jun 2001 17:50:20 -0700 
Dan Mick <dmick@utopia.West.Sun.COM> wrote:

> You would go to the trouble of setting up a filter for a *monthly*
> message?

When I was only on a couple Mailman-run lists I didn't bother.  Now
I get twenty or password reminder messages a month.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun  3 15:22:36 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 07:22:36 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <9901.991549204@kanga.nu>
Message-ID: <200106031414.f53EEMh02825@plaidworks.com>

On Saturday, June 2, 2001, at 11:20 PM, J C Lawrence wrote:

> When I was only on a couple Mailman-run lists I didn't bother.  Now
> I get twenty or password reminder messages a month.
>

A good reason, by the way, to be able to set things up so these messages 
are spread out across the month, not everyone sending them out from 
every installation on the same day for every list. (I realize people can 
tweak the crontab. nobody does).

I'd really prefer these things be per-list, not per-site. And 
customizable, so I can, for instance, include pointers to the FAQ, 
archives, list rules, or whatever. And then be able to configure when 
they go out for each list.

I also really wish mailpasswd had checkpoints, so if it dies, it'd 
restart where it left off -- my big mailman box has been mailing out 
password notices since friday night, for instance, and while I expect it 
to finish sometime today, this is a situation just fraught with 
potential problems. What I'd *really* like, if we must do this on a 
site-wide basis is to run mailpasswd every night, and tell it, say, to 
send out 5,000 per night, and keep track of where it left off. Having to 
run it manually because on a site as big as this one it has to happen on 
a weekend kinda bites.

Oh, and one more thing (thanks for reminding me). the password reminders 
aren't really hooked into the bounce-processed setup, since they get 
sent back to a list admin address, and not necessarily one the user is 
actually subscribed to. We're losing a major opportunity to clean up the 
mail lists here, especially when it comes to non-standard mailers and 
forwarded addresses. These really ought to be sent from a special 
address with a special envelope, so returns can be processed for 
site-wide removal (IMHO, if the password reminder bounces for any 
reason, that qualifies as removal. I'm going to have to pull the data 
out of bounce files monday and manually hack something up...




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Q: Did God really create the world in seven days?
A: He did it in six days and nights while living on cola and candy
    bars.  On the seventh day he went home and found out his girlfriend
    had left him.





From jra@baylink.com  Sun Jun  3 15:27:10 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Sun, 3 Jun 2001 10:27:10 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <200106031414.f53EEMh02825@plaidworks.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Sun, Jun 03, 2001 at 07:22:36AM -0700
References: <9901.991549204@kanga.nu> <200106031414.f53EEMh02825@plaidworks.com>
Message-ID: <20010603102710.25833@scfn.thpl.lib.fl.us>

On Sun, Jun 03, 2001 at 07:22:36AM -0700, Chuq Von Rospach wrote:
> potential problems. What I'd *really* like, if we must do this on a 
> site-wide basis is to run mailpasswd every night, and tell it, say, to 
> send out 5,000 per night, and keep track of where it left off. Having to 
> run it manually because on a site as big as this one it has to happen on 
> a weekend kinda bites.

Hey, Chuq?

I asked this before, but I don't remember you weighing in, and I
suspect you might have something useful to say...

I'm trying to get Mailman to behave itself as a *broadcast* list
manager (rather than for discussion), and I need to throttle the
*actual mail* that way (x thousand per day).

Where might be the best place to put something like that? 

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From chuqui@plaidworks.com  Sun Jun  3 15:39:32 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 07:39:32 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010603102710.25833@scfn.thpl.lib.fl.us>
Message-ID: <200106031431.f53EVHh03030@plaidworks.com>

On Sunday, June 3, 2001, at 07:27 AM, Jay R. Ashworth wrote:

> I asked this before, but I don't remember you weighing in, and I
> suspect you might have something useful to say...
>
> I'm trying to get Mailman to behave itself as a *broadcast* list
> manager (rather than for discussion), and I need to throttle the
> *actual mail* that way (x thousand per day).
>
> Where might be the best place to put something like that?
>

Good question -- I don't use mailman for this, all of my broadcast work 
is with a custom front-end, and it usually talks to bulk_mailer on the 
back end, and I build the rate limiting into a custom version of 
bulk_mailer.

I'm not sure how I'd do this with mailman; you really need to be able to 
pull subsets of subscriber data out in a reproducible format, and keep 
track of a highwater mark so you can restart delivery from the next 
address. I'm sure you could do something with the cli scripting, but you 
end up doing most of the work outside of mailman, including delivery, so 
you end up with basically a custom setup.

What I'd do in this case is add a uniq id flag to the database, so I 
could teach mailman to "mail 4000 messages in list foo starting with id 
1", and then track what the last one did, and iterate nightly until 
everyone's delivery. Something like that. It isn't too complicated, but 
it requires keeping a lot more state than mailman is set up to keep. 
but -- thinking about it -- if this were set up as a generalized 
functionality for lists, then password reminders then becomes an 
instance of this functionality, not a specialty mailing or a custom 
program like mailpasswd. you simply schedule a password reminder into 
this subsystem via cron then....


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Any connection between your reality and mine
is purely coincidental.




From jra@baylink.com  Sun Jun  3 15:44:22 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Sun, 3 Jun 2001 10:44:22 -0400
Subject: [Mailman-Developers] Maybe OT: Back to Broadcast Mail
In-Reply-To: <200106031431.f53EVHh03030@plaidworks.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Sun, Jun 03, 2001 at 07:39:32AM -0700
References: <20010603102710.25833@scfn.thpl.lib.fl.us> <200106031431.f53EVHh03030@plaidworks.com>
Message-ID: <20010603104422.11401@scfn.thpl.lib.fl.us>

On Sun, Jun 03, 2001 at 07:39:32AM -0700, Chuq Von Rospach wrote:
> > I'm trying to get Mailman to behave itself as a *broadcast* list
> > manager (rather than for discussion), and I need to throttle the
> > *actual mail* that way (x thousand per day).
> > Where might be the best place to put something like that?
> 
> Good question -- I don't use mailman for this, all of my broadcast work 
> is with a custom front-end, and it usually talks to bulk_mailer on the 
> back end, and I build the rate limiting into a custom version of 
> bulk_mailer.

Um... should I know about that, instead?  I'm not married to mailman
for this...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS/X: Because making Unix user-friendly was easier than debugging Windows


From claw@kanga.nu  Sun Jun  3 18:46:13 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 03 Jun 2001 10:46:13 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 03 Jun 2001 07:22:36 PDT." <200106031414.f53EEMh02825@plaidworks.com>
References: <200106031414.f53EEMh02825@plaidworks.com>
Message-ID: <8834.991590373@kanga.nu>

On Sun, 3 Jun 2001 07:22:36 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> Oh, and one more thing (thanks for reminding me). the password
> reminders aren't really hooked into the bounce-processed setup,
> since they get sent back to a list admin address, and not
> necessarily one the user is actually subscribed to. We're losing a
> major opportunity to clean up the mail lists here, especially when
> it comes to non-standard mailers and forwarded addresses. These
> really ought to be sent from a special address with a special
> envelope, so returns can be processed for site-wide removal (IMHO,
> if the password reminder bounces for any reason, that qualifies as
> removal. I'm going to have to pull the data out of bounce files
> monday and manually hack something up...

Agreed, and I'll add that the password reminders really need to be
VERPed.  Of course this will have to be optional for those MTAs
which are not VERP happy, but the password reminders are just too
cherry an opportunity to overlook for removing addresses which you
*CAN'T* deduce from bounce message processing (mail forwards etc).

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun  3 18:55:38 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 10:55:38 -0700
Subject: [Mailman-Developers] Maybe OT: Back to Broadcast Mail
In-Reply-To: <20010603104422.11401@scfn.thpl.lib.fl.us>
Message-ID: <200106031747.f53HlNh05907@plaidworks.com>

On Sunday, June 3, 2001, at 07:44 AM, Jay R. Ashworth wrote:



>> Good question -- I don't use mailman for this, all of my broadcast work
>> is with a custom front-end, and it usually talks to bulk_mailer on the
>> back end, and I build the rate limiting into a custom version of
>> bulk_mailer.
>
> Um... should I know about that, instead?  I'm not married to mailman
> for this...

Not necessarily. Bulk_mailer is a tool written for majordomo 
installations that splits up deliveries into small batches. postfix can 
do this using the default_destination_concurrency_limit option, so if 
you're using postfix, you don't really need it. Once I finish migration, 
I'll rewrite my sending tools to take advantage of that isntead of using 
bulk_mailer, and phase it out (bulk_mailer also does some other stuff, 
like set up some headers, but my custom tools can easily do that as well)

my front ends are just custom perl scripts that take pieces of content 
and address lists and puts it together. Nothing fancy (and not 
distributable), and all really stop-gap stuff while I write a real 
publishing tool for this stuff, which is the project I'm designing now 
(we want to be able to send out fully-customized e-mail using a template 
system with volume up to about 500K an hour, with full versioning 
control of the content and automatic access of the user data from the 
corporate database. A fun summer project)

I have to keep reminding people in my company that want to borrow my 
tools that the tolls I'm currently using are very stupid; it's the 
person hacking them that is doing most of the work. Once I finish this 
new mail publishing system, the tools will be smart, but since it's 
designed for corporate use, they won't need to borrow the tools, just 
have an account on them...



--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Any connection between your reality and mine
is purely coincidental.




From chuqui@plaidworks.com  Sun Jun  3 18:59:24 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 3 Jun 2001 10:59:24 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <8834.991590373@kanga.nu>
Message-ID: <200106031751.f53Hp9h05954@plaidworks.com>

On Sunday, June 3, 2001, at 10:46 AM, J C Lawrence wrote:

> Agreed, and I'll add that the password reminders really need to be
> VERPed.  Of course this will have to be optional for those MTAs
> which are not VERP happy, but the password reminders are just too
> cherry an opportunity to overlook for removing addresses which you
> *CAN'T* deduce from bounce message processing (mail forwards etc).


Definitely. and I've sent the lsat few days immersed in postfix 
documentation, and it has some real interesting stuff that can be used 
for optimizing some of what I do. I really like the idea of a direct 
mysql interface, since it means I can load most of my configuration data 
into a central server and not have to worry about migrating it out to 
the farm anymore. It also makes doiing thigns like a distributed list 
server possible, since you can have two or three boxes out in round 
robin, and you can tweak the aliases data in the database to have them 
route list info to processing boxes on the fly, so you can load balance 
across multiple machines.

Lots of fun stuff here, although it might not be approppriate for a 
general mailman release, since it can't depend on these functions, I'm 
guessing.


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Any connection between your reality and mine
is purely coincidental.




From claw@kanga.nu  Sun Jun  3 19:06:29 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 03 Jun 2001 11:06:29 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: Message from "Jay R. Ashworth" <jra@baylink.com>
 of "Sun, 03 Jun 2001 10:27:10 EDT." <20010603102710.25833@scfn.thpl.lib.fl.us>
References: <9901.991549204@kanga.nu> <200106031414.f53EEMh02825@plaidworks.com>  <20010603102710.25833@scfn.thpl.lib.fl.us>
Message-ID: <13291.991591589@kanga.nu>

On Sun, 3 Jun 2001 10:27:10 -0400 
Jay R Ashworth <jra@baylink.com> wrote:

> I'm trying to get Mailman to behave itself as a *broadcast* list
> manager (rather than for discussion), and I need to throttle the
> *actual mail* that way (x thousand per day).

> Where might be the best place to put something like that?

While it gets fiddly, its not too difiicult to do this at the MTA
level with a sufficiently configurable MTA (ie Exim).  Essentially,
just have an Exim filter that rewrites all broacast mail actually
being addressed to a local user, spool it off locally, and then have
a cronjob which sucks N thousand out per day from the top of the
mbox and re-slaps them into the MTA with a custom header added
(which causes them to skip the prior filter).

You could also use a double ganged MTA approach (second MTA running
on a high port -- I used to tdo this with SMail/UUCP) but without
thinking about it ore than I want to now, I'm not sure that this
would be easier.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From listmgr@perilpoint.com  Sun Jun  3 19:36:04 2001
From: listmgr@perilpoint.com (Bradford Shaw)
Date: Sun, 03 Jun 2001 13:36:04 -0500
Subject: [Mailman-Developers] Cleaning up digests
Message-ID: <4.2.0.58.20010603132250.00cb4860@perilpoint.com>

Hello,

I need to modify the way that digests are being sent out. Can you tell me 
where I can make the following changes?

1. Remove all headers, except the From, Date and Subject from the 
individual messages in the digest
2. Create a separator line between messages in the digest
3. Strip out message footers from the messages in the digest

I would also like to know how to not have both the plain text and mime 
print to the same message in the archives.

Many thanks.

Best wishes,
Bradford "Biff" Shaw
List Administrator
PerilPoint Communications Inc.
http://www.perilpoint.com



From thomas@xs4all.net  Mon Jun  4 01:03:46 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 4 Jun 2001 02:03:46 +0200
Subject: [Mailman-Developers] -S pb!
In-Reply-To: <Pine.LNX.4.33.0106022205120.3243-100000@NS.MINT.SN>; from wilane@MINT.SN on Sat, Jun 02, 2001 at 10:14:45PM +0000
References: <Pine.LNX.4.33.0106022205120.3243-100000@NS.MINT.SN>
Message-ID: <20010604020346.U690@xs4all.nl>

On Sat, Jun 02, 2001 at 10:14:45PM +0000, Ousmane Wilane wrote:
> 	Subject: Cron <mailman@NS> /usr/bin/python -S
> 	[snip]
> 	Traceback (most recent call last):
> 	  File "/home/mailman/cron/senddigests", line 25, in ?
> 	    from Mailman import MailList
> 	  File "/home/mailman/Mailman/MailList.py", line 34, in ?
> 	    from mimelib.address import getaddresses
> 	ImportError: No module named mimelib.address
> 
> mimelib is under site-packages!
> Why -S?

Barry likes using -S to speed up the load process... loading site.py can be
a slow process. He cheats by adding the site-packages directory to his
sys.path directly, and I cheat by adding a symlink to site-packages/mimelib
from directly in my module directory. Barry'll probably add the former to
Mailman, or remove the -S, when making a real (read: functional) release. My
cheat is easier, especially when running multiple Mailmans on the same
machine :)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From thomas@xs4all.net  Mon Jun  4 01:11:04 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 4 Jun 2001 02:11:04 +0200
Subject: [Mailman-Developers] Missin )!
In-Reply-To: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>; from wilane@MINT.SN on Sat, Jun 02, 2001 at 09:34:21PM +0000
References: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>
Message-ID: <20010604021104.V690@xs4all.nl>

On Sat, Jun 02, 2001 at 09:34:21PM +0000, Ousmane Wilane wrote:
> 		From mailman  Sat Jun  2 17:00:00 2001
> [snip]
> 		  File "/home/mailman/cron/checkdbs", line 57
> 		    admin = mlist.GetAdminEmail()
> 		        ^
> 		SyntaxError: invalid syntax
> 
> missing ")" at line 55 in cron/checkdbs
>     subject = _('%d %s moderator request(s) waiting' % (
>            count, mlist.real_name)

Indeedy! Fixed in CVS, thanx.

> Barry and i18n it's realy love at first sight :)

Well, what do you expect from a guy who speaks no foreign (to him)
languages, and whose idea of l10n is microbrew and a special kind of crab...
I think it's admirable that he hasn't given up in despair, yet ;)

I-would-have-and-I-speak-and-write-4-foreign-languages-ly y'rs ;)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From barry@digicool.com  Mon Jun  4 18:22:04 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 4 Jun 2001 13:22:04 -0400
Subject: [Mailman-Developers] Missin )!
References: <Pine.LNX.4.33.0106022127490.3243-100000@NS.MINT.SN>
 <20010604021104.V690@xs4all.nl>
Message-ID: <15131.50108.34538.896434@anthem.wooz.org>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Indeedy! Fixed in CVS, thanx.

Yes, thanks Ousmane!  I'm glad some folks are taking the cvs snapshot
out for a spin.

Unfortunately, there were a few more problems w/checkdbs, mostly it
was just out-of-date in a few places.  I'll check in a fixed script in
a few moments.

    >> Barry and i18n it's realy love at first sight :)

    TW> Well, what do you expect from a guy who speaks no foreign (to
    TW> him) languages, and whose idea of l10n is microbrew and a
    TW> special kind of crab...  I think it's admirable that he hasn't
    TW> given up in despair, yet ;)

Well, I took Spanish and Hebrew in high school, but that was so many
years ago, I think the only thing I retained was that /one/ of those
languages is written right to left. ;) And no, I won't give up, as
long as I have plenty of Dog Fish Head beer and Maryland blue crabs
(no Louisiana imports allowed!) to keep me going.

    TW> I-would-have-and-I-speak-and-write-4-foreign-languages-ly y'rs
    TW> ;)

You and Guido too.  Could Tim be right? :)

-Barry


From pisTon@iwr.ru.ac.za  Tue Jun  5 16:05:27 2001
From: pisTon@iwr.ru.ac.za (David A. Forsyth)
Date: Tue, 5 Jun 2001 15:05:27 GMT+2
Subject: [Mailman-Developers] filtering extensions?
Message-ID: <2275BE83E1E@iwr.ru.ac.za>

Hiya all

I've just joined in order to make a suggestion for futer development 
of mailman.

Let me fill you in a bit...
I'm a programmer working in Delphi, and a network admin (Novell), AND 
I have a hobby....   

In the interests of the hobby (railways) I run a list using mailman 
on a machine administered by someone else (a Unix guru of note).

My immediate problem is that multipart MIME encoded messages on the 
list I run pose a huge virus infection threat to all the members 
(apart form being just downright annoying to those who use mailers 
that don't interpret them). I'm a member of some Yahoo groups and I 
see that their list software trims off 'non text portions' of the 
messages.  In other words, it only sends on the plain text and dumps 
all the rich text, text/html, ms-tnef etc bits of junk that arrive in 
multipart MIME format.

So, I'm wondering if such filtering can be done by mailman so that 
list members need not be troubled to reset the default encoding 
schemes on their various flavours of PC, and yet be safe from 
receiving virus's via the list.

(note my list does not accept images either, so filtering out ALL 
attachments would not bother *me* in this application, yetis a 
consideration for other lists)

For now, I've done a fiddle in the list settings by putting a check 
for multipart MIME in the headers so I get to veto them as moderator.
Unfortunatly, the message sent back to offenders is a bit misleading 
in that it says 'message contained a suspicous header' no matter what 
rule triggered it.   A possible extension to mailman is to allow 
pattern specific messages and actions at this point.

thanks
--
   Living in South Africa
      Flying power Kites
         Chasing 3'6" gauge trains
http://terrapin.ru.ac.za/satrain


From Joaquim Homrighausen" <joho@webbplatsen.se  Tue Jun  5 14:49:38 2001
From: Joaquim Homrighausen" <joho@webbplatsen.se (Joaquim Homrighausen)
Date: Tue, 05 Jun 2001 15:49:38 +0200
Subject: [Mailman-Developers] Multi-lingual, translations, templates, etc.
Message-ID: <E157HDI-0006oP-00@mail.python.org>

Where is a good place to start for multi-lingual resources for
Mailman? If I find the time, etc. how do I best contribute with
translations of templates, language data, etc?

Regards,
Joaquim



:: Who dares wins ::




From barry@digicool.com  Tue Jun  5 15:04:44 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 5 Jun 2001 10:04:44 -0400
Subject: [Mailman-Developers] Multi-lingual, translations, templates, etc.
References: <E157HDI-0006oP-00@mail.python.org>
Message-ID: <15132.59132.482592.38892@anthem.wooz.org>

>>>>> "JH" == Joaquim Homrighausen <joho@webbplatsen.se> writes:

    JH> Where is a good place to start for multi-lingual resources for
    JH> Mailman? If I find the time, etc. how do I best contribute
    JH> with translations of templates, language data, etc?

The mailman-i18n@python.org list is the place to congregate with other
translators.  You'll want to check out the latest CVS snapshot of
MM2.1 for the most up-to-date templates and catalogs.

Cheers,
-Barry


From barry@digicool.com  Wed Jun  6 23:29:23 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Wed, 6 Jun 2001 18:29:23 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com>
Message-ID: <15134.44739.463393.527457@anthem.wooz.org>

[I've moved this discussion over to mailman-developers.  -BAW]

>>>>> "JCL" == J C Lawrence <claw@2wire.com> writes:

    JCL>   Ability to unroll quoted printable.

    JCL>   Ability to unroll base64 encoded plain text.

    JCL>   Ability to strip blocks from message parts that match
    JCL> stated patterns (eg Yahoo/MSN/Hotmail ads, corporate CYA
    JCL> statements, etc).

    JCL>   Ability to filter on line length (eg hold for moderation or
    JCL>   auto-discard/reject).  

Some of this will be added to mimelib when I get a chance.  On the
plus side, Python 2.1 and the future 2.2 has some nice support for all
this via its unicode codecs.  I.e. in the Python CVS there's now a
codec for quoted printable so you can essentially say something like:

    subject = msg['subject'].decode('quopri')

if your subject header is quoted as per RFC 2047.  I've only played
around with this stuff a little bit, to get a feel for what you can
do, so I haven't thought about APIs or doing the actual coding yet.

The downside is that I'm still targetting Mailman 2.1 at Python 2.0,
so some of these features may not be available.

Also, just some quick thoughts on de-mime-ing, which also address some
things that Chuq has brought up, re: regexp filtering,
auto-discarding, etc.

I'm of the opinion that regular expression predicates alone aren't
going to cut it, and that anything more complex is just way way too
complicated to attempt to expose through an email or web interface.
Complexity is already our enemy, IMHO.

So what I'm envisioning is an extensible architecture, a la the
message pipelines, where each filter is implemented in a separate
Python module, conforming to a particular, yet-to-be-defined API.
Mailman will provide a bunch of canned defaults, like
"strip-mime-leaving-only-text/plain" or "match-vbs-attachments".
There will probably be some kind of mix-in model for describing the
action to take when a filter module matches.

Then the admins can choose which filters they want, and what order
they want to run them in.  I'd actually envisioned something like this
for the delivery pipeline, but that (giving admins control) has turned
out to be not as necessary.

Even this may turn out to be too complex, so there may be yet another
level of abstraction that a site admin can glom together, so that a
list admin would be presented with a limited set of `rhythms',
`themes', or `styles' that they can pick and choose from.  I've
thought about a similar mechanism for list themes, like "announce-only
list" or "read-only mirror list".

The point is that there's a lot we can do very cleanly at the Python
level, but that the more configurability we expose at the web/email
interface, the less usable it becomes, IMHO.  So, I'm thinking
seriously about ways to preserve the power Mailman can provide to the
Python hacker while employing abstractions to reduce the cognitive
load on the list administrators and users.

-Barry


From claw@kanga.nu  Thu Jun  7 04:12:03 2001
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 06 Jun 2001 20:12:03 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw)
 of "Wed, 06 Jun 2001 18:29:23 EDT." <15134.44739.463393.527457@anthem.wooz.org>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com>  <15134.44739.463393.527457@anthem.wooz.org>
Message-ID: <18118.991883523@kanga.nu>

On Wed, 6 Jun 2001 18:29:23 -0400 
Barry A Warsaw <barry@digicool.com> wrote:

> The point is that there's a lot we can do very cleanly at the
> Python level, but that the more configurability we expose at the
> web/email interface, the less usable it becomes, IMHO.  So, I'm
> thinking seriously about ways to preserve the power Mailman can
> provide to the Python hacker while employing abstractions to
> reduce the cognitive load on the list administrators and users.

One problem with this approach is that you tend to require list
admins to have shell access.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From les@2pi.org  Thu Jun  7 06:55:54 2001
From: les@2pi.org (Les Niles)
Date: Wed, 6 Jun 2001 22:55:54 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <15134.44739.463393.527457@anthem.wooz.org> (barry@digicool.com)
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org>
Message-ID: <200106070555.WAA12753@mutiny.2pi.org>

On Wed, 6 Jun 2001 18:29:23 -0400 barry@digicool.com (Barry A. Warsaw) wrote:
>
>[I've moved this discussion over to mailman-developers.  -BAW]
>
>>>>>> "JCL" == J C Lawrence <claw@2wire.com> writes:
>
>    JCL>   Ability to unroll quoted printable.
>
>    JCL>   Ability to unroll base64 encoded plain text.
>
>    JCL>   Ability to strip blocks from message parts that match
>    JCL> stated patterns (eg Yahoo/MSN/Hotmail ads, corporate CYA
>    JCL> statements, etc).
>
>    JCL>   Ability to filter on line length (eg hold for moderation or
>    JCL>   auto-discard/reject).  
>
>Some of this will be added to mimelib when I get a chance.  On the
>...
>
>Also, just some quick thoughts on de-mime-ing, which also address some
>things that Chuq has brought up, re: regexp filtering,
>auto-discarding, etc.
>
>I'm of the opinion that regular expression predicates alone aren't
>going to cut it, and that anything more complex is just way way too
>complicated to attempt to expose through an email or web interface.
>Complexity is already our enemy, IMHO.
>
>So what I'm envisioning is an extensible architecture, a la the
>message pipelines, where each filter is implemented in a separate
>Python module, conforming to a particular, yet-to-be-defined API.
>Mailman will provide a bunch of canned defaults, like
>"strip-mime-leaving-only-text/plain" or "match-vbs-attachments".
>There will probably be some kind of mix-in model for describing the
>action to take when a filter module matches.
>...

While a general and powerful mime handler would be nice, and is
probably the right thing to do in terms of the long-term
development, I think that one can get most of the benefit from a
much simpler solution.  A few months ago I hacked together a mime
handler with the goal of making the stuff that comes from Outhouse,
AOL, etc. look like plain-text mail, as well as enforcing
prohibitions on postings images and other binaries.  The handler is
based on the mimetools library; it discards sections with certain
mime types specified by per-list regexps, and removes multipart/*
wrappers that become redundant after the stripping.  Nothing fancy,
but it has cleaned up 95% of the crap on our lists -- mostly
text/html but also the occassional image/* or application/*.
(Ripping out text/html works because so far it's always accompanied
by corresponding text/plain, except for contributions from
spammers, the deletion of which is a feature.)

I was going to post the patch, but haven't gotten around to
upgrading from 2.0beta6 and porting the code.

I agree that the UI for list admins to define what to do with what,
is likely to be the most challenging part of good general-purpose
solution.  The simple mime handler is useful, I think, because
although there's an awful lot that can be done with mime encoding,
the vast majority of email traffic these days comes from just a few
MUAs and is very pedestrian, mime-wise.  Having a good set of
canned defaults corresponding to these common cases should work
pretty well.

  -les  les@2pi.org


From pisTon@iwr.ru.ac.za  Thu Jun  7 10:13:34 2001
From: pisTon@iwr.ru.ac.za (David A. Forsyth)
Date: Thu, 7 Jun 2001 09:13:34 GMT+2
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <200106070555.WAA12753@mutiny.2pi.org>
References: <15134.44739.463393.527457@anthem.wooz.org> (barry@digicool.com)
Message-ID: <2517EE44938@iwr.ru.ac.za>

On  6 Jun 01 at 22:55, Les Niles is alleged to have scribbled:

> On Wed, 6 Jun 2001 18:29:23 -0400 barry@digicool.com (Barry A. Warsaw) wrote:
> >
> >[I've moved this discussion over to mailman-developers.  -BAW]
[]
> >So what I'm envisioning is an extensible architecture, a la the
> >message pipelines, where each filter is implemented in a separate
> >Python module, conforming to a particular, yet-to-be-defined API.
> >Mailman will provide a bunch of canned defaults, like
> >"strip-mime-leaving-only-text/plain" or "match-vbs-attachments".
> >There will probably be some kind of mix-in model for describing the
> >action to take when a filter module matches.
> >...
> 
> While a general and powerful mime handler would be nice, and is
> probably the right thing to do in terms of the long-term
> development, I think that one can get most of the benefit from a
> much simpler solution.  A few months ago I hacked together a mime
> handler with the goal of making the stuff that comes from Outhouse,
> AOL, etc. look like plain-text mail, as well as enforcing
> prohibitions on postings images and other binaries.  The handler is
> based on the mimetools library; it discards sections with certain
> mime types specified by per-list regexps, and removes multipart/*
> wrappers that become redundant after the stripping.  Nothing fancy,
> but it has cleaned up 95% of the crap on our lists -- mostly
> text/html but also the occassional image/* or application/*.
> (Ripping out text/html works because so far it's always accompanied
> by corresponding text/plain, except for contributions from
> spammers, the deletion of which is a feature.)

this is exactly what I'm looking for (as a user)!  (I started a 
thread on it yesterday)
as to the UI, I see a simple set of options like
( )  keep text/html
( )  keep image/*
( )  keep application/*
.
.

as a starting point at least.
the admin can select one or more of them.  with all of them off, only 
text/plain is kept.  if a message has no plain text portion, it is 
held for the moderator.

maybe some thought can also be given to filtering out hoax virus 
warnings?  I've put in a regexp on 'virus' in the subject which will 
stop postings for moderator approval, but as I said yesterday, the 
regexp matching is a bit limited in what it sends back to the user, 
being singularly uninformative.  some configurability would be nice 
there.... as in, when regexp x is matched, send message x, when Y is 
matched, send message Y etc.... instead of the blanket 'suspicious 
header' thing  (-:

>
[]
> pretty well.
> 
>   -les  les@2pi.org
> 
--
   Living in South Africa
      Flying power Kites
         Chasing 3'6" gauge trains
http://terrapin.ru.ac.za/satrain


From barry@digicool.com  Thu Jun  7 15:15:15 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 7 Jun 2001 10:15:15 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com>
 <15134.44739.463393.527457@anthem.wooz.org>
 <18118.991883523@kanga.nu>
Message-ID: <15135.35955.641425.315789@anthem.wooz.org>

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

    >> The point is that there's a lot we can do very cleanly at the
    >> Python level, but that the more configurability we expose at
    >> the web/email interface, the less usable it becomes, IMHO.  So,
    >> I'm thinking seriously about ways to preserve the power Mailman
    >> can provide to the Python hacker while employing abstractions
    >> to reduce the cognitive load on the list administrators and
    >> users.

    JCL> One problem with this approach is that you tend to require
    JCL> list admins to have shell access.

It does mean that list admins will be more dependent on the site admin
for customizations beyond the canned themes.  Maybe that won't be good
enough.

If not, then an approach would be an onion-type interface, where
normally the list admin is given a simplified UI, but can drill down
to a more complicated interface if necessary.  One thing I /don't/
think will be appropriate is to allow list admins to upload or write
Python code without vetting from the site admin, because then we're in
the realm of restricted execution, etc.  Going down that road has
serious security implications that will be difficult and time
consuming to get right.

Of course, we /could/ target Zope as the platform, in which case we'd
get a lot of that for free...

just-thinking-out-loud-ly y'rs,
-Barry


From barry@digicool.com  Thu Jun  7 15:42:09 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 7 Jun 2001 10:42:09 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <E157kPm-0005FE-00@mail.python.org>
 <18710.991865049@2wire.com>
 <15134.44739.463393.527457@anthem.wooz.org>
 <200106070555.WAA12753@mutiny.2pi.org>
Message-ID: <15135.37569.701158.69342@anthem.wooz.org>

>>>>> "LN" == Les Niles <les@2pi.org> writes:

    LN> I was going to post the patch, but haven't gotten around to
    LN> upgrading from 2.0beta6 and porting the code.

Please do!  I'm not quite ready to start addressing this issue in code
yet, but it'll be nice to have a couple of approaches in the patch
manager to look at when I do.

If we can get an 80/20 solution for MM2.1, I think that'd be a big win.

-Barry


From claw@kanga.nu  Thu Jun  7 17:26:19 2001
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 07 Jun 2001 09:26:19 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw)
 of "Thu, 07 Jun 2001 10:15:15 EDT." <15135.35955.641425.315789@anthem.wooz.org>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu>  <15135.35955.641425.315789@anthem.wooz.org>
Message-ID: <6892.991931179@kanga.nu>

On Thu, 7 Jun 2001 10:15:15 -0400 
Barry A Warsaw <barry@digicool.com> wrote:

>>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

>>> The point is that there's a lot we can do very cleanly at the
>>> Python level, but that the more configurability we expose at the
>>> web/email interface, the less usable it becomes, IMHO.  So, I'm
>>> thinking seriously about ways to preserve the power Mailman can
>>> provide to the Python hacker while employing abstractions to
>>> reduce the cognitive load on the list administrators and users.

JCL> One problem with this approach is that you tend to require list
JCL> admins to have shell access.

> It does mean that list admins will be more dependent on the site
> admin for customizations beyond the canned themes.  Maybe that
> won't be good enough.

I'd look at it the other way around:  Mailman then implicitly
requires site admins to be responsive to and handle list owner
requests in regard to MIME handling configs.  As a SiteAdmin, I'd
look at that as an unwelcome chore that some bloody software went
and created for me.

Consider a site like SourceForge: In one swell foop you've upped
their SysAdm expenses significant;y.

> If not, then an approach would be an onion-type interface, where
> normally the list admin is given a simplified UI, but can drill
> down to a more complicated interface if necessary.  

I'd be tempted to do the following:

  Mailman has a default set of configs that recognises various base
types of MIME objects, text/html, text/plain,
multiplart/alternative, etc etc etc.  It then presents a simple list
of these items each one with a set of four radio buttons:

  1) Ignore
  2) Strip from message 
  3) Discard message if present
  4) Reject message if present

You then have a small text field in which the list admin can hand
enter additional MIME types that he's interested in.  Upon such
entry they join the previously extant list of recognised MIME
objects list and also gain the above four radio buttons.

A seperate section would then have the following two controls:

  a) Flatten quoted printable?
  b) Flatten base64 encoded text/* parts?

> One thing I /don't/ think will be appropriate is to allow list
> admins to upload or write Python code without vetting from the
> site admin, because then we're in the realm of restricted
> execution, etc.  

Absolutely.  That would be bad.

> Of course, we /could/ target Zope as the platform, in which case
> we'd get a lot of that for free...

. o O ( <shudder>! )
-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From nb@thinkcoach.com  Thu Jun  7 22:32:03 2001
From: nb@thinkcoach.com (Norbert Bollow)
Date: Thu, 7 Jun 2001 23:32:03 +0200
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <6892.991931179@kanga.nu> (message from J C Lawrence on Thu, 07
 Jun 2001 09:26:19 -0700)
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu>  <15135.35955.641425.315789@anthem.wooz.org> <6892.991931179@kanga.nu>
Message-ID: <200106072132.f57LW3r27985@quill>

J C Lawrence <claw@kanga.nu> wrote:
> Barry A Warsaw <barry@digicool.com> wrote:
[..]
> > One thing I /don't/ think will be appropriate is to allow list
> > admins to upload or write Python code without vetting from the
> > site admin, because then we're in the realm of restricted
> > execution, etc.  
> 
> Absolutely.  That would be bad.
> 
> > Of course, we /could/ target Zope as the platform, in which case
> > we'd get a lot of that for free...
> 
> . o O ( <shudder>! )

Please explain... what is bad about Zope?

Greetings, Norbert.

-- 
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59     Fax +41 1 972 20 69      nb@freedevelopers.net


From claw@kanga.nu  Fri Jun  8 05:44:26 2001
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 07 Jun 2001 21:44:26 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from Norbert Bollow <nb@thinkcoach.com>
 of "Thu, 07 Jun 2001 23:32:03 +0200." <200106072132.f57LW3r27985@quill>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com> <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu> <15135.35955.641425.315789@anthem.wooz.org> <6892.991931179@kanga.nu>  <200106072132.f57LW3r27985@quill>
Message-ID: <20815.991975466@kanga.nu>

On Thu, 7 Jun 2001 23:32:03 +0200 
Norbert Bollow <nb@thinkcoach.com> wrote:

> Please explain... what is bad about Zope?

Zope is not inherently bad.  It is however a large and complex
product that comes with significant baggage, and especially more
baggage than I consider justifiable for an MLM or for sites which
have no other reason (or wish) to run Zope.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From webmaster@mrpcd.com  Fri Jun  8 06:28:32 2001
From: webmaster@mrpcd.com (webmaster@mrpcd.com)
Date: Fri, 08 Jun 2001 14:28:32 +0900
Subject: [Mailman-Developers] ¼ÒÇÁÆ®¿þ¾î, ÀÌÁ¨ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù...
Message-ID: <37050.603159074073600.144244@localhost>

--ufsnltbcmiqtetjk
Content-Type: text/html; charset=iso-2022-kr
Content-Transfer-Encoding: 8bit

<HTML><HEAD><TITLE>ÄÄÇ»ÅÍ ÇÁ·Î±×·¥ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù</TITLE>
<META http-equiv=Content-Type content="text/html; charset=ks_c_5601-1987">
<META content="ÄÄÇ»ÅÍ ÇÁ·Î±×·¥ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù,¼ÒÇÁÆ®¿þ¾î ±³À°¿ë CD" 
name="ÄÄÇ»ÅÍ ÇÁ·Î±×·¥ µ¿¿µ»óÀ¸·Î ¹è¿î´Ù,¼ÒÇÁÆ®¿þ¾î ±³À°¿ë CD">
<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY text=black vLink=purple aLink=red link=blue bgColor=white>
<TABLE cellSpacing=2 cellPadding=0 width=459 bgColor=navy border=0>
  <TBODY>
  <TR>
    <TD width=455 bgColor=white>
      <TABLE cellSpacing=0 cellPadding=0 width=454 border=0>
        <TBODY>
        <TR>
          <TD width=454 bgColor=white colSpan=2 height=4>
            <P><SPAN style="FONT-SIZE: 9pt"><FONT face=±¼¸² 
            color=gray><BR>
              &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><A target=_blank 
            href="http://www.mrpcd.com"><FONT face=±¼¸² 
            color=gray>http://www.mrpcd.com</FONT></A></SPAN></P>
          </TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=21>
            <P><IMG height=82 src=cid:head.gif width=453 
            border=0></P>
          </TD></TR>
        <TR>
          <TD vAlign=top width=454 colSpan=2 height=80>
            <TABLE cellSpacing=0 cellPadding=0 width=453 border=0>
              <TBODY>
              <TR>
                <TD vAlign=top width=76 height=126>
                  <P><SPAN style="FONT-SIZE: 9pt"><IMG height=92 
                  src=cid:head2-1.gif width=75 
                border=0></SPAN></P>
                </TD>
                <TD vAlign=top width=377 background=cid:head2-2.gif 
                height=126> 
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">Ã¥¸¸À¸·Î´Â <BR>ÄÄÇ»ÅÍ 
                  ÇÁ·Î±×·¥À» ¹è¿ì±â Èûµå½Ã´Ù±¸¿ä? <BR>ÀúÀÚÀÇ À½¼º Çؼ³°ú µ¿¿µ»óÀ» ÅëÇØ ¾ÆÁÖ ½±°Ô <BR>ÇÁ·Î±×·¥À» ÀÍÈú ¼ö 
                  ÀÖ´Â µ¿¿µ»óÀ¸·Î ¹è¿ì´Â <BR>±³À°¿ë CD ŸÀÌƲÀ» ÀÌ¿ëÇØ º¸¼¼¿ä.<BR>½±°í, »¡¸® ÇÁ·Î±×·¥À» ÀÍÈú ¼ö 
                  ÀÖ½À´Ï´Ù...</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD vAlign=top width=454 colSpan=2 height=21>
            <TABLE cellSpacing=0 cellPadding=0 width=449 border=0>
              <TBODY>
              <TR>
                <TD width=32 height=38 rowSpan=2>
                  <P>&nbsp;</P></TD>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=20>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã</FONT></P></TD>
                <TD vAlign=center align=left width=380 bgColor=#eeeeee 
height=20>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">¹Ì·¡±âȹÀº ¼ÒÇÁÆ®¿þ¾î ±³À°¿ë 
                  CD ŸÀÌƲ Á¦ÀÛ Àü¹®È¸»ç ÀÔ´Ï´Ù.<BR></SPAN></FONT></P></TD>
                <TD vAlign=top align=right width=15 bgColor=#eeeeee height=38 
                rowSpan=2>
                  <P>&nbsp;</P></TD></TR>
              <TR>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=18>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã</FONT></P></TD>
                <TD vAlign=center align=left width=380 bgColor=#eeeeee 
height=18>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">µ¿¿µ»óÀ¸·Î ¹è¿ì´Â ±³À°¿ë 
                  CDŸÀÌƲÀÇ Æ¯Â¡</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=57>
            <TABLE cellSpacing=0 cellPadding=0 width=451 border=0>
              <TBODY>
              <TR>
                <TD width=55>
                  <P>&nbsp;</P></TD>
                <TD width=396>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt"><BR>-ÅؽºÆ®¿Í ±×·¡ÇÈÀ» 
                  ÀÌ¿ëÇØ ÀÌ·Ð ¼³¸í<BR>-½ÇÁ¦·Î ÀÛ¾÷ÇÏ´Â °úÁ¤À» µ¿¿µ»óÀ¸·Î º¸¿©ÁÜ<BR>-ÇöÁ÷ ÄÄÇ»ÅÍ ¼­Àû ÀúÀÚµéÀÇ ¼öÁسôÀº 
                  Á÷°­ <BR>&nbsp;&nbsp;&nbsp;(ÀÛ¾÷ÇÏ´Â °úÁ¤À» µ¿¿µ»óÀ¸·Î º¸¿©Áָ鼭 À½¼ºÀ» ÅëÇØ ÇнÀ 
                  ½ÃÅ´)<BR>- È­¸é »çÀÌÁî°¡ Ä¿¼­ ÇнÀÇϴµ¥ ½Ã°¢ÀûÀÎ ¹æÇظ¦ ¹ÞÁö 
              ¾ÊÀ½</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=204>
            <TABLE cellSpacing=0 cellPadding=0 width=453 border=0>
              <TBODY>
              <TR>
                <TD width=68>
                  <P>&nbsp;</P></TD>
                <TD width=385>
                  <P><BR>
                    <IMG height=177 
                  src=cid:education-image.gif width=377 
                  border=0><BR>
                    &nbsp;</P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=18>
            <TABLE cellSpacing=0 cellPadding=0 width=454 border=0>
              <TBODY>
              <TR>
                <TD width=37 height=80 rowSpan=3>
                  <P>&nbsp;</P></TD>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=43>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã</FONT></P></TD>
                <TD vAlign=center width=381 bgColor=#eeeeee height=60 
                  rowSpan=2><P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt"><BR>ÇöÀç 
                  ¸¹Àº ´ëÇаú Áß°íµîÇб³, Çпø, µµ¼­°ü µî¿¡¼­ µ¿¿µ»óÀ¸·Î ¹è¿ì´Â ±³À°¿ë CD ŸÀÌƲÀ» ±³Àç ¶Ç´Â ´ë¿©¿ëÀ¸·Î 
                  äÅÃÇÏ°í ÀÖÀ¸¸ç, »õ·Î Ãâ½ÃµÇ´Â ½ÅÁ¦Ç°µéÀÇ Áö¼ÓÀûÀÎ °ø±Þ°è¾àµµ ü°á</SPAN></FONT></P></TD>
                <TD width=15 bgColor=#eeeeee height=60 rowSpan=2>
                  <P>&nbsp;</P></TD></TR>
              <TR>
                <TD width=21 bgColor=#eeeeee height=13>
                  <P>&nbsp;</P></TD></TR>
              <TR>
                <TD vAlign=center align=middle width=21 bgColor=#eeeeee 
                height=12>
                  <P><FONT face=±¼¸² color=red size=1>¢Ã<BR></FONT></P></TD>
                <TD vAlign=center width=381 bgColor=#eeeeee height=12>
                  <P><FONT face=±¼¸²><SPAN style="FONT-SIZE: 9pt">°¢ Á¦Ç° ¹× ´Ü°¡ ( ¹è¼Û·á 
                  ¹«·á )</SPAN></FONT></P></TD>
                <TD width=15 bgColor=#eeeeee height=18>
                  <P>&nbsp;</P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD align=middle width=454 colSpan=2 height=12>
            <P>&nbsp;</P></TD></TR>
        <TR>
          <TD align=middle width=72 height=199>
            <P><SPAN style="FONT-SIZE: 9pt"></SPAN>&nbsp;</P></TD>
          <TD align=left width=382 height=199>
            <TABLE cellSpacing=1 cellPadding=2 width=340 bgColor=#ff9900 
            border=0>
              <TBODY> 
              <TR> 
                <TD width=197 bgColor=#ffb445 height=23> 
                  <P align=center><FONT face=±¼¸²><B><SPAN 
                  style="FONT-SIZE: 9pt">½ÃÆÇÁßÀÎ CD ŸÀÌƲ</SPAN></B></FONT></P>
                </TD>
                <TD width=132 bgColor=#ffb445 height=23> 
                  <P align=center><FONT face=±¼¸²><B><SPAN 
                  style="FONT-SIZE: 9pt">¼ÒºñÀÚ °¡°Ý</SPAN></B></FONT></P>
                </TD>
              </TR>
              <TR>
                <TD width=197 bgColor=#edebeb height=18><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;1. ³ª¸ð 4.0°ú ÀÚ¹Ù½ºÅ©¸³Æ® 5.5</span></font></TD>
                <TD width=132 bgColor=#edebeb height=18>
                  <div align="center"><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">\25,000</span></font></div>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;2. Æ÷Åä¼¥ 6.0</span></font></TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <div align="center"><font face=±¼¸²><span 
                  style="FONT-SIZE: 9pt">\25,000</span></font></div>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;3. µå¸²À§¹ö 4.0</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000</SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=21> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;4. Ç÷¡½Ã 5.0</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=21> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;</SPAN><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">5. Æ÷Åä¼¥ 6.0 Å×Å©´Ð</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;6. µð·ºÅÍ 8</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;7. ÅøºÏ 7.2 </SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;8. ¿¢¼¿ 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;9. ¿öµå 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;10. ÆÄ¿öÆ÷ÀÎÆ® 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;11. ¾×¼¼½º 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              <TR> 
                <TD width=197 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;12. ÇÁ·ÐÆ®ÆäÀÌÁö 2000</SPAN></FONT></P>
                </TD>
                <TD width=132 bgColor=#edebeb height=18> 
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\15,000 </SPAN></FONT></P>
                </TD>
              </TR>
              </TBODY> 
            </TABLE>
          </TD></TR>
        <TR>
          <TD align=middle width=72 height=14>
            <P>&nbsp;</P></TD>
          <TD align=left width=382 height=14>
            <P><BR></P>
            <TABLE cellSpacing=1 cellPadding=2 width=340 bgColor=#0087ff 
            border=0>
              <TBODY>
              <TR>
                <TD align=right width=196 bgColor=#66b5fa height=23>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt"><B>±Ù°£ Ãâ½Ã¿¹Á¤ CD ŸÀÌƲ</B></SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#66b5fa height=23>
                  <P align=center><FONT face=±¼¸²><B><SPAN 
                  style="FONT-SIZE: 9pt">¼ÒºñÀÚ °¡°Ý</SPAN></B></FONT></P></TD></TR>
              <TR>
                <TD align=right width=196 bgColor=#edebeb height=18> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;1. µå¸²À§¹ö¿Í ASP 3.0</SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#edebeb height=18>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000</SPAN></FONT></P></TD></TR>
              <TR>
                <TD align=right width=196 bgColor=#edebeb height=21> 
                  <P align=left><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;2. PHP 4.0</SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#edebeb height=21>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 </SPAN></FONT></P></TD></TR>
              <TR>
                <TD align=right width=196 bgColor=#edebeb height=18>
                  <P align=left><SPAN 
                  style="FONT-SIZE: 9pt">&nbsp;&nbsp;</SPAN><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">3. ³ª¸ð À¥¿¡µðÅÍ 5.0</SPAN></FONT></P>
                </TD>
                <TD align=right width=133 bgColor=#edebeb height=18>
                  <P align=center><FONT face=±¼¸²><SPAN 
                  style="FONT-SIZE: 9pt">\25,000 
            </SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR>
        <TR>
          <TD width=72 height=66>
            <P><SPAN style="FONT-SIZE: 9pt"></SPAN>&nbsp;</P></TD>
          <TD width=382 height=66>
            <P align=left><FONT face=±¼¸² color=red><SPAN style="FONT-SIZE: 9pt">¢º 
              ȨÆäÀÌÁö¸¦ ¹æ¹®ÇÏ¿© 2°³ ÀÌ»óÀÇ Á¦Ç° ±¸ÀÔ ½ÅûÀ» ÇϽô ¸ðµç <BR>
              &nbsp;&nbsp;&nbsp;&nbsp;ºÐµéÀº</SPAN><SPAN 
            style="FONT-SIZE: 12pt"><B>&nbsp;¼ÒºñÀÚ °¡°Ýº¸´Ù 20% Àú·ÅÇÑ °¡°Ý</B></SPAN><SPAN 
            style="FONT-SIZE: 9pt">À¸·Î <BR>
              &nbsp;&nbsp;&nbsp;&nbsp;ŸÀÌƲÀ» ±¸¸Å ÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù</SPAN></FONT></P>
          </TD></TR>
        <TR>
          <TD width=72 height=15>
            <P>&nbsp;</P></TD>
          <TD width=382 height=15> 
            <P><FONT face=±¼¸² size=2>¢º ¹®ÀÇ
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;E-Mail 
              : <A 
            href="mailto:webmaster@mrpcd.com">webmaster@mrpcd.com</A><br>
              ¢º ¸ÞÀÏÀ» ´õÀÌ»ó ¿øÄ¡ ¾ÊÀ¸½Ã¸é, À§ ¸ÞÀÏÀ» Ŭ¸¯ÇÏ¿© ¹ÞÀ¸½Å ¸ÞÀÏÀ» ¹Ý¼ÛÇÏ½Ã¸é µË´Ï´Ù.</FONT></P>
          </TD></TR>
        <TR>
          <TD width=454 colSpan=2 height=11>
            <P><FONT face=±¼¸² size=2></FONT>&nbsp;</P></TD></TR>
        <TR>
          <TD width=72 height=8>
            <P>&nbsp;</P></TD>
          <TD width=382 height=8>
            <HR color=navy>
          </TD></TR>
        <TR>
          <TD width=72 height=13>
            <P>&nbsp;</P></TD>
          <TD width=382 height=13>
            <P><FONT face=±¼¸² color=gray><SPAN style="FONT-SIZE: 9pt">Copyrights 
              2001 </SPAN></FONT><A target=_blank 
            href="http://www.mrpcd.com/"><SPAN style="FONT-SIZE: 9pt"><FONT 
            face=±¼¸² color=gray>¹Ì·¡±âȹ</FONT></SPAN></A><FONT face=±¼¸² 
            color=gray><SPAN style="FONT-SIZE: 9pt"> All rights reserved.<BR>
              &nbsp;</SPAN></FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<P>&nbsp;</P></BODY></HTML>

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="head.gif"
Content-ID: <head.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="head.gif"

R0lGODlhxQFSAOYAAP////z49vf39/715Pr18vL09Pfx7930/PDu+PTt6e7u7uLu
8fLp5/vn2//nztDt+vHm4OXl5u7g2fndyf/epd7e3vzWvN7a7bfi+OXW0vnSuf/X
Y/bQtv/MzNbW1sva17zd5K3e9//Mmd7Qy+POxdbWnNLL6czMzM/I5pvV/tbGwPDE
UcPDw9O/uPW4kMa95JzG58O64de4qbu9vb+13YTG1vmseZy+xsmzq9Oum/SndLGx
q++ib96pKb+nnK+k1fCaYMilRfaWVpWqrMyZmaGfn8KeTIKjtaSW0bSXjfmGOfh7
KJeHzKWMY8aJAJCNf/t1G4OLjJyFWP1tDY16yP9mAIl2xYd0w5V5ZGOCkrB3DoNw
v5tyUY10M5lmmXV0bnxnwFp2eHlrS21WuZRSUktkb15gWGZaTIBMfGBGs2tNCE9N
SldKNlg8slM4rlE1rDVESlkouz4+O0gpqkg0IzovFSwtLTsbpSIiIzANoS8NoCIZ
FyUAnQgQDwAAAP4BAiH5BAUUAH8ALAAAAADFAVIAAAf/gACCg4SFhoeIiYqLjI2O
j5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubqHAgK7
v8DBwoq9w7sXTGNtaVQvhb2+xtLT1JRIVEwmhAgv3d7f3heC0NGVBcXViibdCADe
hghjfPP0fHPag+fl6fz9s9ziHrWZ50ZQjHoIE1qxNJBPm3EKFKADsA6ctx9UMmYM
6E6jR4/fOAK49vGHxXAU26hcqRKMxoANYwCgV8hEnoT09KAYFHGiv59AU73AWU8l
EkJuCAqiQRTnwkpJ+RQEICBChAIFBjVsWo+jFa4InwqKCpbewoNgZQKISmPmvG16
/+il2XkBDL07+XoG3ct3FJKyfJgQejPvzVKic9woXvxj0IUYkE8iOUo1WlTDVCtE
iDiIbNnBgOc1HkQ4NJ/GTMHuBDBnXluag5jQw9yZXlsACjYXCNC3t+9MX8veFlSa
tiB6ahWl5jq1XGkwggp40KyANwAwbu7My7O4+2JCKGjQuELeivnz2l0PfvMmPdjh
4sVDjtH67fF57WATt13oB70rgiig2Tm/FWggJBfEFx8T5tUzHADFFYIcIeaBsdph
YE2V1X58AAiAdJpFYB2Gc2hC1oWOuNdOIvWsNltpfIA2D4ojmSVIBB5s5tOB6ezI
YyL7IFLPGORtsUV6YxQSF/8fyZlAj0g03FEfH3ekcZ55lBGypIcKeJBjBBMtR8gF
abgBXT6IIDAfffRk6Ug9hIzB3htT0jMVUYRsQU+ShLiHD44VKLDbj8ZMYMGhg/gI
iqKpMDpOIo/9BZZYY83jjEH6EbIcpSzO81SXX161oZiDoNVcAQoIoidgU30okSII
0FOiICiA9ZBbCY25JB9WiPMDjLcCAOhVIxIKjBJVJHtIA4c2AIChFjgrwhTJOtuI
CM2OQ2AhzFpAgCFBSkKABYbogwg6CDBxRZnuAcZpaZcCgBaTMTy46SHjGWmkjbhN
Z9W/GMYY2zxpELLhqoANwsLCJ5zgZQUQpyovPcEul9D/HG2ciRNehEiK2IqC+Lut
sccmW8UhNiRrAwDIVqEDADqYLIQONOtgw804W8tysi+7SggBNkBhchVQuEBIOTgn
nTS2h5I7iAUmKwGRROFWFnBTeWR0Hj1UDIIADfWNQQV27doXcNfz/UAejGEF6O9m
VgVMyBWeHpIGQt6JrZHCDDvspZcS+zfPmQAIbk8MIhFCzwuyOWTIDzclBAbIgwxY
NcmzWICz0DzT/K0gMbu8cxUiACDC0KijrsEgLff8qiATcJ66Ep8P0kDquCc7BSEa
RD2OVSM/I8gFG08Z7H18dM1hWRxfbRqvblMX0Yaxmg0A3dAbAiOniSzMQsN/e7kh
//bJD0J+wWPig6s78xzfMXZujMGESCBb9Trmt6Scu9SDhP5yyxwAAAdylzqdtc4Q
E6AWAfk3iN4REHUMFKDvMqObYiWKNGC4AhJoEJB5uY9rpAlNqwBgsY3NiT0g7Bd1
fJIpeVDJDXogHIQmxIgI9C184hOEXeaRJfLdQSWRcxzy2CdERYSHQYqZR0Ai5ij8
uSJ0uAvgIHjAs9EFcIDJgoIStrhFHciOECbrGSGWYDIo6IADGqCiyUo3CAJwgAMu
qJkcdSCECQoCi1XgXwFWWLXLDcJjMsSV8maYmPhpbT6Jcx4fuKMYMDwIV6Pp0gol
xEMwvGFXs9HSnjLShu605v9WBWiY30JklQpEA0bJcSFRgkWToRQRAF9T2xiy05Tb
QOwqfnRiKzQgxzomK4IAUKMWFXjFMBqiZScbhMzeOAFBuCBqtXuWAoG5CAdWQQiE
wCM1zzWoRASnfIqbxyAd8ZgLLWecneLDpSSpI4OMoU5NGaEIowM+f0UkImBaHkfY
lpBWtbJ9g0BYWXQiiFsGT5euqBoydSYINapOEDI7pu7ACEFBtGwK0QSdyRgxAQ1o
AI5R05k2HYEqMGEFK/csBAIS1ybwiIckVFhJEKUyiHM2YnE3smc0vokYZiABRfP8
EPgCRbVebIs85CGEusiTESR0AzIX+mcRDYcQjLkEMoX/qECO7ofQhAbpmclagiEc
OrTVAWCC6GhZBGdn0V8ewpoMPesDyzoIPC7Bo29Eowaa1swA5UaronSYxBKBgtIk
53mtsqnXIIMESuFUWDrFFD3y0IYxWAFxkJrTSqZ0h/NkKQInsFwuKTGnlGSspnp4
Qxs0iNlFPIxqXX0FqgZLAAUmSwjRJKvJnGZH1rlVmRUdHTZvFA1rmhW4c02W0ySY
3Dz+7l9eEqWXIjC8K2FJQep73qxIeBeV4CScTCroLV93AQ3SgHKSUCX3CkqsTTQW
qVdgwpqSMzwjbXC+8ymEBxwWqG7GlhWoIgQyTbYEAybLBRYgYxWcNk1DKHitBz5U
/1/VeojTJSuaE0CdFrmohKSJtLmiE28pcTgdRSKET7iqxw/HkJ7t1jRhAVMLxKiz
oUaY4AdWcFMhiLedFT3GQ49AgdpGU4B/3fN1nvlungCjlv3yF7b/BXA5LEw0205h
wslaXcuc1jIoGEJmfZXrggvhyyrEFQAK9nI2e7sIPM5VjAAg5YwhVmLuckUsq71C
fYLVEPfZGSF3UAx5srQcGY93sIa4AI7TUKcRFoIKdwFDG4JIo5osuk5nKgDDwmcZ
sBRCoE0JiJO3Otooi6Ictd1tAxR84NGRi3Nc3ijMtsjqKqwMosotBJVp18Yyw5m5
zhXF2/5F7IDBV888NERU+P8M0B0PuhuLKLR4peeY8cySKy6GJQ0aO9OEPEjIVGA0
VzCj6e/5zQMbKs4VzuNCRyeIBmtiQkbgRE+H4dLUrChHmXkwRZMZbctixrKyxIy6
W4vZaTVGphk5wAPZQeFz0XAoFG4mBA4rgVrHXURHaaYEoQ3CniedrcRIVZvwFmLZ
g7hbESswieWsaMabGSxguANkAICaKNwRCWD0kAbKlLue6OZQzU3lCCfpJ5QiKzW+
P1FcAut6CsMFuKwBUGZcp87gu73RIBJIwCvzpKEgzngDNWADHnQ8dx/nIzSwIrc+
KTE6G4pK8yBdxBwxohe5aXucDx1CnJjpp4egO04yhgT/9YE3IW+4wg8Sp+l6QuyU
dRsE3ZXH9pGsqztl09CTm7j0RQmCAEBIVpht59sqrG7qUGxmzd4odjGbtQI1jh3u
ljB66gIg9M3NOBBsm9yP5yh46KjVPOarn6CvRT/BaV7Dbhnz3ERAqzjU+2s5s7w5
yI++wvuzPeQXr0RMaQ5gADwi9jjUf0GeD2NYkwspn+6yaJ7UnVfFPhrAxkSYXQnN
5GL/iIb/Rpjs9R7wMy5wdkugBEaDCEBgcQM2MzTDULiHO1tkAy6gAQxlb1xFFYPA
Fc1jfI2FVQZhHqMBACfgPeZGYtEHAOWVVCEzHfdkHUywBefFCEVGK20Ag+h1CDWW
/xGPNH4VUH731GlNoRZXsTyBthgeQWTTdYHxRwqO0gBzRDMi4FFSeGaPUDPW4gEs
EICZcDsThQhUNAVdNIEZZQgWGCTlwBXBcgI1dncjaG5AZ4IshwjTVx2NIABFhiNe
4gh2+Hz7tYZA8ldO5je6gRXWkWQIIYQbshWCoQjS8XtKt4SbIACCgghuRkAHiAgT
QGv840d2xwhu5AJAoAhlZnAa4AJSBABUuAjg004GMwjWZV1ZElp+mAg9KF0mSGK2
Vwh42F9Y0UclBX1/I1h/KCDAuF+wxwu/iEPS1V/kIAg49orn8XEHYyeQ4RGSlmnT
dVCQeGp/NWe2p1u503pr9v9bwnIIcXMIn2h2vHeK3DI0ZsdqwwU7FxdiRyOJxChd
rIgmjxBKWUhsz0dK/1KLozRn3hiQgeKPoJWEKIVPxEZnt7hfHnBk+DRnJCZKBfmP
D/k3fGQ1jxCRqlIWoJSEj7iNmCCJfChKtjeAHCY7dCUsgRWHBOB0inCOAmQDCch7
qcOOz8IBOjBgbFVXbGYI0ZWNQVJ5dwdagZWUSul4CGk/EjliSqmQWMGHGWmCUVmV
0ZWUWKmRuhEN0OAIoGV7N9dP0SGSJFkKdkiM0ZWLicBqH3dDyJVMMwl2ybUEQsCO
ILYEcDZSrsVf93Y0EhmYR4aUS1mYozSIIXdS5FBSWcn/lL2IKg5ZlRTZmOcGh5EZ
WIKSmI0Ic13plSInmBLZMLY3HkzlDWtiMGZ5lkx4h9B3jIowNG/phnGZVwzHA7YJ
BAeYkrmjRTogjgSnYR22XONYBWJlO7T5OX+jI2aYG1tpi1v5MJ0JDQEwndRJnckY
Pmq3h8WIncyHkNvJnQAZkH+DaAZDSkVVDtrZnCfAliRVhqqJliXFh6JyUsUSk+So
lHFJQPwWZ3dkMmCoAyIwhg7mnx0WoOfSn8klRdCpjen5nNNBkBDqjYLCeYdAjPnE
gwRpZNNzUhN5SxW6oQtZSozYi5eDd5mpmEaVmJ1IUu+5CmnpfIBli7ZnTQzknPmZ
/zv7GYcTgJupCJiDAAQ8epSCwIVzpaAs6F8GA4hYeWgM2ZQxZy6TEGA1pKEoSg5G
lVLjpw9WOhHwgz6gsEfEdqJTGZAn0KL5dqUn6XiCYE37KQBDBTE3SpwWd4BxKIPM
2Yd6eKda+Ju5Y6T9ZUHa0o0RKqGaqZlbagmzCBCGMD1Wyk1GWS5amk4CcwjcwA6V
8JKz2Ij7BSRfGQvv8Awj2SPXqZF3VHETNw7QSZOQoKqAiZHhs56zGKiu6mT9E4VN
41ECqlWBwigv6qROOaECUJ3CCqiL0DgPERzccwFjEER5MAYiEauN4Eomx6h+VA9f
s21YIlnhFQOvmAYn9K0fJ/9K0BpKDZOBkScJgvdoH8EEJ9EN+LAPL6Bye/KsxFqP
oXoLePePc5YIoEJU5NkI5Bem+nqLKCmwk6mMZSoJuioo9VoZhWqoFAoJwVEQwVFz
I9Ft23Eh91oqNGQ/I9MNDIIdmNQ2EzN81/M8g2CRNeWs+QA+5soHOvYIweFi1RMa
gXQdTeEm0YAEKwEGItGp1WCi/gitoDKI/wqq5FABJFiC6hlYDsqejACRf6oI1Lml
jfoI3WAShSBvVKAW2GMYLlRzHoMTepA4FfECN3gI83IbzycqgwBPXOEhy9EW5ANj
IphDHEJuy/eybfE1awIO13BBAOBCxlFCk1IIqkQUF7L/IYKXbPmwGw0LDCk6W8Cj
D9QJKluFUniokQT5qob5kBAaiJVJYhTpq+LZmCwYsZvAL0D4FF87Qx3iGLvyBj+w
bVPipZUCFrg7tyI2ibnLFXpAJLfBu+XlHkiFXx54t3W6HOiDdHHIu8wjuBEyCIWF
QmXhJlQ1BkgQA0hAFs0jMTwlGjwBZfxADoC4lCJzUlSJlVdpmeE5YqDbneLpnFiZ
j6bwHyc3Dx7yulEBZDsUu0hBD5RTNk6hKfyxd0SVcm4AT+2SB1BywLA7qapofAAg
rwGBdKPJH+6nj9P7CFNCX+6hY6q0GhuSIEggr80DPBurC/lKmaMErJDpoOCZoVQa
/3IwCqFheqITKcNJh5aDkB4WWxr7OzjHB8AR/DgQnGJNUXO8G2f2VCyqNAbtUBeR
g2J/diEw0ggQ6RiZ5HsZrB53ACM8B4vawiGOxgjucSE8xgc3iwCR4yGzSD4B4bGR
Kw1p+Z06tXbw676ciZASqaVWSrkaek+AjKZ4fIs0VseaUA6XUQhCLAjYsxBRkRwd
zLEmWwjxoX4t9WL4MW3KOQhLgrsA0DjN82cBbDbxaZC1OFiJOxzS8cUmhytn/Lhm
HAn0FjDDwcgEEx3sKXx8YEuWsxcmub7jZS5oaro5LKYhd7WgWqjMLKuD2sceu8KT
oMt8YBiEkVpbAsk4Qcnbgf/El7wIqkRfJAdzegFL9BCCwyPAnCzBZDG+gYkjDsPF
9ZAH9QPLh6UUOOiapdFZGaQwjqcZLyvB0vYhuRgVGmIIjcMHqzFe1JwLxxymUOqw
nwmaVUoO1PkI0jmdi9CrgyyYJGoK6IDQEcwvdUtDg0sPiygICDAlaats9GB4JAed
WLoc3YfOltLOpyzBiIAjrJwQuPu8KE0xUzORLNB+CME3lRmHvnw8y6HOb0vEH1II
SLAkeVA5TMQXk0vIE50oVvvVqssJk/uwh3oKI60UlmS92XPS4WwxvYIASOAeMhTQ
B50pNld89kR9NbvSguAxIENyR8wIdbrGUrLJGPhnHEH/1Jnxqke9PPpxQ9MVMMdT
s1YcMD73kQgxSAsLrf5gtdUwrKDdCmdNU+D1FP9bD92XuBeDXiM4VAP9aXgtPYOV
HnmgPjSwJC5mODISGOehL/oyx4OgSoU3WYkD2IotAMEorhzSBlrDNyx4P8sRSDDi
JrfdY1p310NCCK/F2WbqRKPtaOmcu2PwAvVx06ptJzfY2vz1su6DML5HVFJaI9sB
BmDQLurs3n33Hjt2F4Kw0Nlm3M0mAPKbi6WBTlONCEgwJzpmMdp7wvWQHGKZE5TS
r77b3VH23ZSkTrnbNQ1x0yNRJ3MgX0yAHXlgSyUYh2vc3nhttDstObBtPfxEFI9E
/z5ZshVMnCmKvQgFDglCti6JUQinnRB8bXvvRiOauqsWbmro0G4ZfilRweE5DQ8x
wGhugLEm7jcjtyfRgdmTKpVGiQDymhN8zeWEkNYs4QZpcGz0sySl7Mb0cCEeA15+
dghLYuBjwq1ykhClLAgYOw96QAgCnQiaCn9J/l/oMLOQoS7jvOHrMzxjc0ll4SEJ
yYLOyC/TSNoAIJJ4tw8xMEuKMT+H8G47GAkIo2Pzcgcrgt/IM0LX2liJLU6YvAV5
/hkZfhN5EDmtsof8ip1/yQohIAgYQAjB/uuEQOyFHgqHnha5Kxj6wdZ6zgwxsCIJ
qRnRQD6LKDGr0iqabpJ+xP+tV7IFtRsfifQICMDmh/C/fKLquMJII/vLL8sprBJ+
hoc8t5LjW47dmIHcy8iwvm4Iwx7swP4AD1AIIHDsnpDsXKEWk9zoJ7tKaGuOoWUV
1d6xmN0c215krmkI4ZsQ2KcICaJBle645RjVbEzmA11LLzvmBNwmlZbh9d5shrAq
euuDYb0Jxv7rvy7wISAAD4AAOw8AAD/shrAA66uR3G3w9SgIVlBIh7TQCm+y+iE4
VXJZKWQI086K8qoW2K7PyE1qV7rZnbrxhwgpeO4ZtHEB7aHduYgCedBD81DKZMse
GcQEIIPSHAJ+SKBKjODLdzBv26ESjibz9aaQHH0KNy//CL+OASHw779+AAIP9ABf
CA8wBGEAB3jQB32wB5qPB2uwA4ps8E2kJpCxIguvH4qmc7CepLUYWfJCHq1y6Rbv
9fm6neD79seWKQki6zFeD3++DYMAWo09PHOjz5AcX6O/CDQUDbVLIXYtidFgSe2u
ZII+VBOKCsSO8wBw/dmP/SEQAggg9Iif/QhwAEdgB5z/BUWwAziw/i2wA2FgB52P
9MRQ86VvPYaQQhiPupM0foLA5FSRmoAAUKAQUeFx6BEBAHDFx+e2GOnIFwlwN4mZ
yfd2Vel5csJy4hnZ+EiKmjoZs1iQajV5sVho6ArwppnriJDaeuJREVEg0FtsfByy
/5i8nAzwAJCcAp1ycKCsjLAQZfe1c1Kh4BlQsXMmt7ZzrL7O3u7+Dl8pUDAsYH8f
jurmyDpZPEmlFSJQvxIpOEiMFL1FuE4BEHAogoKEDwcVQqSIkSNIkUxsrNRQ0xww
SFCQumfPA0EWHlCZ4njMHiFJ/BZVsOWJyqQXsw6dsJVGl6M5bcBQQcILQAWFoIAp
KBAgXjwMkZotgzbtgbQQyw48CIGgGYAbeL5UCIC2yBMpXdo2iVKhwpM1a4pIvYs3
r96YBS4iwhghcISolmr6sxl36aI7bdogWaRAZdOIwgYdfEqP3k+GHx8Ck0ixIiFa
+UzNiYE6BhNHbUBOujOGCf+NYhEI2rb9N+PLVoIljjb0t+WiVYuCB1tkpXEbEzYl
29rCZ46bMVSYvODZi8WMGSxE4Qa9dx1VrNHIc4XGDEAKrldDPABRRg4BAAMaJJES
ZIN+/V2kLB1hhhzphEdggQYeY1FwCnqQ0BUOymKFFY8tYlsvChB0SDCV0XPRbZsB
gMQWVrDiWTATeWKPRRItYoouAUXywxY0JFVMX915h2FwoGREg4MTFhDKZAuqVMqD
xd0oSkaoVEBQPu9UoN2NuAUzzIHFtIeeelhtlV6XAhyQBR0+RFJEfvuduQIXCyi1
hh04WQlnnHkJQAhwQzKoTiiihBaJALVlGNhT9yQoGUH/b8rz2YknzfPUIkgIxceL
6swTWKE4FgRMYsAp6QmQ3Qm5YC8eSHmCMKgUIFki7TDKJKlCSgSVnJWIld4NYdx6
6w3n7aplCCkIkMwTcowiSB1nHrtBF3YBkAQeMxAma7TS8lWnpgpGwCcpTNqG0j21
/WIiPfYsQmkEOt500qaKojKPLRc4CG+E8soiSCoW2enTbYiYeFBghhzX6bagLshp
JObilkhmCqd6iJPkpmiZpoZ4+FdcCElLq61m4GFGCEOY8UXIZthRVhg1oMclABis
HIYcGSzyxApoynymFIvMIEcR2U7Lc8+MjtabYIYE7dtlAjflYY6wjtsnnf7iS7Rf
/1Tu3HQ7Ucd1p4JxBapwtRoGjbDEQXsAtGAM/5V0UxIzvLaCOW4tGEJUWwlDFnL0
YQcdWHzxBBZPEJHDDiMoUMTIe9hxwzVcHRACBmGc0YADAMiBJht2GLFC5slGxcIa
URzac+jTQnxZ6aPlm/bAhb4tKLuMBo110p9V2cs969RGatbGxY1Zt/eiHnZvpvc7
McWfPb36ZL0Vj6nugBZ9UD0YAxAG3nRIIUUTWGC/PRZceP9E+E98cXcYMJhXTRhr
DDAAAMZuIHMdduGhhRP2q1GcGWaALnr/snaLEsuYK3n6Op5fdke7VLSLHv3yS9ie
Ai17DW+CB1FJ7u6UGN7Vg/9pTatW8iiDmcwEsE4fTFQD8bWvoh3QeRn0zQZtJy0Q
yEEO22sC9rjwve5JAQs85OEX/PaEjeFBV9DAwAMeEAY2DMAAALDDmbrwhSLQoQdU
7AH+ADCCL6zBYf7rYv9eh8Ldlc5f+wrX3Jo2KBKKkYMSxJrujFcxuAUqetKrndMG
WDHf2AMtfOzj74ITGIXdS2LhYuAKM6UpovXujHG6ATdysMMmcOEJOdAeFyTZvRz2
MGTCwsMHkrEyDJRhfQ0AwBrgt58z7MEJNEuWTeZSMC/KkmdgJGQG5fa6oAmKkSdR
USKXFhM1Zi1HiJTjZRTGRmPQyWtb22UxatlCevixgRr/TGPUeGc6cfESTkfwQxFK
gEPvRXKHWJCkFC5pSe31MHwzhMY9oiCHD9ysC/vhQRrq54QebCAITyBXEeQgnFkK
lJYCjFr0AGgZOiZzHSmi5kF5CUbnPQ+bIkTJOxo6vDo+s6AujFXTMhPCPfKRgdlE
JgC7CII97GAG3ztnOHd4Qx5OEgBE4AIbJulDvuGhDNNAQOe+kA/K6ccLcUCD/VjZ
hRn4Uw6xHKhT4QQxQZoURSeVSlQryg5o2vKWdNSmRfFy1Q0ydIFYdV23FgVAAfRx
oAWwQxE8wIVzNkEFLCCCJNlABpg2gQ5mcAAFnrCHPsR1k1/wwxAW8ZUs7EEFAGiA
/wfouQGixgGfWrBLAwgQAWE19amcLRAfAchHWobWHT+7ZjVFihYD9TG17lgtaztr
IPJ5QKZJ2MEWAbADNvjhezYUgx9yIAIRUIAIcthDOffmNznYYWXV+IAZ6HBZAlTg
DGtIg3XRoAX5EaAB7TsBG77AP9iKd7y0JKtUK7pN8qpXKifog1x4WwE50KEJSehC
H8SASSzslgLCFa4EvnBf7Y0PwJ804gMcaYYRzKJzJIPDEypAAPaxDwd4GEJ614vh
DMPjs2kdrYY/rJcvmEEFOSQCgOPKhT2w4ZzlpAMb+NtfClDAAU/ogxxs6Lc9RMEr
RwzBDc7x1nDMhwB9nABaVP9gjs2CeMlMhq1rXUuAKEt5ylI2gJWvjGUDUHnLRH6y
l5/8VAXgIQp946EU+sAGG+5hD5fMnm5VQAEJUKAD/JWxA4ig4uwF0QwHsIdXAHAE
ONjBDOmQnIRLOQAGnCBAy2qyox8tUC9TOcsJqLSlL50ABlSaAZzGtKc/beksW5nL
Xf5yF1mAhyJw4QvZs8MesLfm7GVPDH0gggPkLGc6+3XGXHAxG777hC+lAAPAWtka
9mCXDDAgAPWpCA6Ue1hIS3vaPINylCl9aU5rGwLc7ra3vw3ub0eg29out7kvjeUt
fzmC0dLi+JrQBDYINt4qFsNNaY0FCTjg1jPWd27NQAT/O9BlDXezyzMOsB4AHGCU
E9GfDyBAgAnswAx7IPSFqY3xjK9jtVW2crbL3W0JiHzkI8+AyU+O8pSrfOUmh8C4
KxBuCGRa0+gW9bpfayA58M1v8r4kGezAhjYF1g9suLVf900BBQAYHaSo8Q3C8oCw
AOADcIhCACwnhzrYYet2yJmpNA72sLfD2tf+OANCXnKWn5wEbGf7CNoO9xHIXQVy
r7vd7X5yD6hcAjHvNM0TYHMvF0gAdkBD3+4mBizsQQ6MhZkfzNCHIuxb3/v+Ah5Y
EAkPmIFYuNUVAhAQdQzcwAxn+IIdhnCCIWQhCjvwxsXFDvtpc3zKZuc2yVkOdxKo
/2D3vO/97lsA/OALP/gqAL7vd38CutMd7yznu7fLXXMsu1YvEegD30wvBt+uQTG/
OEE/d2CHJOx73zVWzCKi4IcvVEIBUWhcCBA+BHnD4QjjecCaYo///APA2lieOadt
L3Iq13bHJwMFaIAHaIA4IAMKiAMN6IAPCIE4MAM4MHzC53tuRwIjsHcjR26dFn0G
gHNSoQDWFzI8lH6RUAF+sAeVsAN7UALjl2qeUAGfs359kDjQcAA3AAdyMAMHYEQC
MB/6J4QaN3tSZmnbBgEBKIC6t3sI6IQFmANRKIU+kAM+YIVXiIVZ6AM7YIVc6AM4
sIVgGIEyYIG8l3saiHIk12qBmRZqelEBfRAFZPYEHLN+AucJdvAEKhAye9AC6mAG
ZXAeGLAANwACCYEBfTaEiQhpZGcAR/h/SSgBS8h2TwiFUhiFRICJmaiJSUAEnJgE
nwiKoSiKooiFSZCFEHiAxNd7breBzgcB2hYIADs=

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="education-image.gif"
Content-ID: <education-image.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="education-image.gif"

R0lGODlheQGxANUAAAAAAPf39+PgjaK3XI6Ojv8AM1VdWA4OhjMzM+7u7sTExKam
nzt/t+Hh4ephdb29vZmZmdbW1kJGooOEnYiIiLW1ta2trczMzMTDp3V0df///5SV
s97cz8XAkb6/31dir/4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAACH5BAQUAP8ALAAAAAB5AbEAAAb/QIRwSCwaj8ikcslsOp/Q
qHRKrRI12Kx2y+16v+CweEwum7mAjHrNbrvf8Lh8TsnU73aKfs/v+/+AgYKDggSG
h4iJiouMjYkQkJGSk5QQCxUVlpAWFgsIZ6ChoqOkpVgIGBgdFBAEkKwEeq6RhLWy
jri5jJW8vb6+C5YLw8TFxsfIycOczM3Oz9DRzZjU1dQKEQoLagQPGZ6m4eLj5GII
A3cQfOp7hhSxtvG17rG69ri/+b/K/P3+0gADRrP2QB08AhZYfSrHsKHDUAiCbfBH
sSIygRgzatyo0RozayBDihxJMuSDkyhTqlzJ8uTFCgsfypxJ81Q2BQpQ4nyAc6fO
/5M9e/IM6hNozqAtiRZNKVSl0qdQo0qdSrWq1atYs0qFCQCAEK8xa4odGw7BhZMV
FnCqsBal2rUWMOFM+2AtJpTTqLmNy+lSXL05LTxgq5fn2rcfWypezLix48eQI0ue
rMBCVwQGEIAly7kzxAho4769e5Kv4EtD66IlzLMuJtMVeqodzDZ03J1/qwElrBZx
haFagwsfTry4VssADGTe7Lm58y8IFPxGOX366rvWWWZXSZrxdu7aSX+fTL68+fPo
I1vQ3PVy2OfwnZs1/tQoVOD36etvan+////GHQNTfATKBxpS+OUn1VlGJQgBW09d
cIFg9RkSVWkJysZJhjkNA/8VMxBwCOCIJC4o4YkRvFfgijSZxR0EgimmzgI5sYTT
BR7+ZBgFFtSo0gUKdLNSBBYQEJt2wdCoY04UKOnUBeooFtslNfqY3pVYZmmjiix2
2ZCLQD0QS4893YZbiFYy9cACTe5E1DY0LtWja0TRlklRZXZCZmqGbaimAhPGmWZl
mQB3m5aIJoreBVx66ag4YJb2W4w85WifU2Ua8o1P2qSVwSYLqGRBJKKm1QqMlJYm
GIyXdthJbHMJVg8FhaEESSzAqZWmorz2qhijjwZbTqQK2AFBBkztGiafChx77J4n
2VEPQgQIqoAB3xjZEwQI6JGBIWwO9Y4aYjaJ5lGjEmD/AASyfYvtA+/ogZQe4dbp
6734/tiosPyeQWyS3dQnYlBpLaDtUQrQG8lbQbUSDKyVGRAMO3Th9A6bQVb7IMGW
tImTBZ9CkvDEREFScYkop1wVsP22LEp0UnLkzEXMLOCAAwXkrPPOPPfs889ABy30
0EQXbfTRSN+MmMzRKLCvy1B7gUA2nODWoyV7AgroiVx37XXXFeR8c2xfl2322Win
rfbabLftdtsV3Cz2219jsgDLUecdhovvjHqqwQIIgEEDDSTgYQSINwAKzgVwoPfj
pCSAswOmjOw05Jhv4SKICRlJQOCDR5DAAxH8VvoDZ0ye+eqLF0A5KdrQ+DTr/cIM
/1UFHETQQAAJBOD77wn0/vvwxP9+geu/04558sUXj/MFzUdffAIFp6g85NHlJ+F+
rg9VejB2lVSd+OLnu5jKVenegJjD8DIMzu1T0szElBAz4PV6m1UBQqH2ivNvPVmO
Aab1h0O8Ax7yKMQ9GqGPfFjkHxqB0owqgLgKWrBZEOheAyyIuINYYIMcVF/hZoc/
R00NAgOslrLSo4CbMckCF8iAENZViQPSbxi3WOAjGli/B1pkI+QL4gXqMQEIJMAL
ETjAAXKmgC5kxgAb2EAE9lbCvJmFTcvoVffEVIELfEA5GZiAGMdIxjKa8YxoTKMa
18jGNkYxihN4oxznSMc62v9xAxCw4xglQADFdYEDoXpeFxoQRQ9sAHVgIGEVWTSf
oGyvJ0CiTwEghpMDCEGJSpQAJjfJyU56kpOa/KQoR0nKUprylKjc5CE3MMYPRNEA
9BpkBzAwxAJMkQsJ2IAHPDCBClBxkS5DgAcAKTrQPCABEQDSBzUgvWYSrwDD04DT
lHMACUjgA9i0ZjWtac0PXBOb2/ymN7WpTUxmM5vXTCc4U8nOdrrTlBuQjroMMIFY
YCsDFuhCADoQOAPYsgu5NOQEEAkdYAbzAh0gAE6CQYEGVIBHC7hlKQqwBQ8oxwDv
zKhGN8rRjV70ohLIAEZdccQuCGAAA/CnFxqQAQYwwAD/jkukQVuGAL/pjgPIDMAG
E7C7cFBUC4QkQBzfKMY7GvWoRZ3jUJEqx6Ue9alQjapUjQojP3YBoRjgADRliQEL
dMCqUptp7UCogQtsoAIBUB8BEtCjC0QgAKP4aRYSkLBNSKhasejimqqlFgmBrxMK
lSCPYsEuQBUDAkC6BDGEMQwVXiAThoBVkYyENdM9lGToo4+Y6pKNLOiUcA8AUgFO
AlctYKOCJS2oWIWFgAC4NQAP7aMFREeACOjqAaUNhVyxQD1XvMNisojNQ/Ugsoy1
okk8YcesYGUQS+DEHbdikzsowJPYIrcgfIAHDEG2h/E4JrMEo25ErepabMTGArbE
/+0W3KqT3HZBkauVj06DZzDoES4BFxBe8EixWw049FCqSkltmjIewuwKwKpC0EoG
fBLQ9CiZEqrgYKISya1Fxbu96iLv3MtM3wUvAVv9QvA4zAX4xtczrQXeLUeXuGOy
Sy64bYACciqG/q5vKa1Rk05w7CsfYWNrQ3nk1oTMqcBQEpJBMh91JBqG/r7sxI9K
MVyJFIBmZQC/2YjAN/Di2tBCr8ZbkPFZztuAXW5wJ9bZnyWMApouNgBIFSAc4RKX
TDnb+b7GVAtzWeUmNsnCIDleySsIG6KWKFTJ0rkAGZwMESibkHlHLAjqgre7wtlZ
A0f03Rhs/NgoDkMDu+TpA/8GMAzqqMMOc+JEtRr8G1hNqhOp5cL6MpGBeBaEAQP1
SSbqAAmDHYklnUBVQXCck0ObL9GLLoujvSRlTO/Ow77THU8nGuaciJETbI1zAwzm
CgF3IlSJA6EIN/hmwl2AcM1c36gosIFVMYBHCg6tUn41l6SIaYWKQvamlb1sRiYP
NNRTR+EA9WYSm8HG0mlL6dxaGWIky5Fdg7jXprKaqtkJUFhrUvxYYamUMPRUaHLK
vRHdxWSbwsT9rkmzeaeB0jWxcM7ksKa5YOMD1qPXPsy5zpeRsLSw4g+FVcnHjdQ/
kWt85w+UBJPBwGhQoDzlM2k2LgO3wcISiS0UeCxPq0z/pCbSfAsRKPSaHlBmDyDO
7LGGT5U/NqcG4btBSWGLWKhXpKV/oen+gnqBpF5a33EAdBEwUo63IZhkggZKC+hC
f22LmxmX3cwGd06N2sKXUHlXYE6Re00SMAu7ewHvZni63h3Cdy0kAAPH7HClCye8
DfPW4IsXVI86LL0Oxzq3pRUeQ45iMDXY3A5HzormaRJ2S3he8fwe/XNKX+XCBQ6n
OIFAm6UTeeRrgfELJfsud5nMuoxqOmw9LVG0vX3EVR8UNSpYk3iTKvIMfyY8Jeu+
T658+DA/zn+fJVttexZAobUMsdcTsYFMEeABhWN4EPZaEQYab+ZWojNnaEcOPnYf
/+fxfjJBgLNlcqUgevVHDqVHe1nlO7vTeqAQgNmnT2DwWYNkVb3jBTOHaanVd1hQ
XihTF3NXF7WlgaTAgU3mM1vQMzSXM1kgV0CoAbv1M0PIM1gAejLBfOeWAM9HJPBC
UGdggmP3eLsUAIakS1hoZga4fdvHU2YHeQUIhtx3hmboAQmAhp2iZnEBLnFhaG1y
Phb4EHS1P8f3dfRXhSWoBU7GhETohzrTZJ+3hM3hhA2QfxiQVjmRh4R4fXFSFwrw
WWPIO2W4htynO7xTZmeHOMFThh4AV+JmdppYZqZ4Z2lFOAZYLJzgLZogLS2hDuxC
h/m0efLkiH6YfAAohACYi/8/mIRKGIhDaIhMV4hGeIjJw0wzyEyemAAckIy89VaF
84hZgH1r4nVglXbwgS4hAkB2whj8kXm1SBN3mIPzt4EluDM6aIRKSI1HSIx3Z4xM
+BAfWFoFFzgdQFcNiDiT4nXxCIllogCqaIbaKHloMRve5x16Vmo2UocOUY64CIxI
M5FEY30/NY8/yIvHCI/sqJEd2Y56iJFfkowy6F/5FTgL0HzYQGkTgotWSCM8FX/k
dn6cgS56IDEEYAefsisJA0vj8mtM4ZANAZHr+GRVqI4WCY9BM4zEOIhFCIjWt5Gd
UY8zCFfItDsC4DhptZX+9Yn+NWe8A2JgF4mh0i9HsSb/CeEXBkMmSmEXY3c74wh/
t1iUjXaUoHeRHCmVeimVeFmMfvmLeTkWVNlhVRk4WWk4ESAx+BVaCyBjnkIoJlgZ
/hgsb3clQskQRHmOO9iHj0hR/YWEgiiM/2iMgBmYYjGYM+d3AtAB0JcAiDVfOUU4
2lBMkSkY/VJhX2MiRKYUZxGXFziXmjkKPNiZRfmOTMlfpckZqCmDCdAB0INM+hic
jNdezzaNz+ZhmVZ2FUSKchaWoEaKnfhW6IcX1OAnMsIwi3GZ5ZCZYLaH47CUo+mD
xvl5QLOEf4iMqbmMhMlMUBiFFKBlvtSe1UiW2geGWoiGYKhLaahTYFiACrpLUUQ4
/+NZGe9wanNoaMKAbwk3d8ApoJsZH1ApkUgZV/hZkn13ohzQAaypj/8pnWQ5iajI
U6JDacDTPPz5YR92Zz01oUXSGwb2dgAUjrvhm3bYodT4oR2IYiSpn/kJhc8InaLT
ciPIjOtTUrVJOjAngmRnbrfEdTLmWomVOA5xFGzRfxXGY3QiXAgZlET6kEb6l0ia
pMq5pMq4n8FjmBzQALV1Eg3ACtrwiSDjdS/ZRYEiGH2qV2uydpdQAVfWIRTwY2Na
Kd9yQCDnJCmRkygkixvDphyKh3TpdHKqpPlZp/mZoqzZlfsVWshkkuSWl9gnmdi5
XwIJgyOYoxagU7pDdizXEP/oAi7swFjhmCQPIhorsaG26KnBaZShShbLuYxOOjy9
03qbqFO+OKCxQnagRmm6VyBVUidagxXFqp7kwJ5HKpzLOqejeqIz2J9ZSSTOFRjM
QHZUaILftgFdqDsrgi7t020cRwknwQrFFXdtOpRvOppxeq4tQqfq2mGmOmfSRmms
Z2nVigXTiSHQuqMF0n/BJgvwMl2+RV2d4gpTIa7jQK5waq4Ie5oKW5XOmpXMw3qi
GH/A0wAFgA1kFypKUhu7Y4ByVpDO8QBK5VR5BAl2lEdUlXjHao4eirIpm7DpyrIw
iKcOJR081wCi0Vcyhl6hgk8SsyexMZDbB1Zq9wGnZAH/nxRKowQBnaq05aqsTduE
K7ufojhLq4ejsBmTVkmzB7hB1zgYPcJy0bQiAUC2mMRN1eRN2QQBoORNG3AAhPtJ
apu0EWmaoPq2URe3qRkAfycA2gpXoiiQdyNqqWeCENIvj/u4HbVJkUuOBUuaB2u5
DNGs/Imn1DMp0pcNkuZW6nBEVjh7/AK0FsBKbxS8nNBuxNsMRTUBwVtUz/Bpm4eD
k7uXbgu7sYu5ngtXHJAKigM8JcV6V9lZezmddHGbH6Mp7dBFUHEs6qKp9TGwDGFb
hhC9IvlL1DuST0t7z5eKOWqStpWHvUuFj1IjANM+VNISi8UWozIoJCsO2xYM8quL
//XrgXHbYfgYft7XmLMWUQbbckXnu8KSfhRiL+FxlrUypHMXCQ/snhEswffbgtm7
iDkqofwZpa7LwW02gDiawzpMozHXwz5MV5IKXTCyQkHyKetyQPCmE2nhw0w8PbyT
LtL3qXkHCrG6w1Z8xVicxVq8xVzcxVn8gllAlf35jBXAYsg0xBhMPWI7sS03Kmpx
E1iRFjo6x3Rcx3YsY5LaXCokI771fb7mY5lwx4I8yJZwaNggxaFHxV68yIzcyI78
yDvsXvWouaBDPRFAK//VCVl3NxkwmcnJwb1WmcCGwYNcyoLsI3eBJ/F2KXFnRKb8
ynZWyAySwuhYBmEJybicy/+6rMu59YG8Rbe7ansjaDw+u5d62gqzwEORMFsh1MzO
/MzQzHvxEgvaoHGo4iMTk81B9xMQIG7Q/M3QXBCWEEm0/LpfcMu7nM7qvM5YXFrM
N6NUlw13xplZ0MBId887NyfVXCR1oGrfYizY7Cy0EgxLwST4nHMZmKx1OQbs3NAO
7dBwVXqWvLkY4GATBsDSOWMP3dA86SfdoRhEnBYbvcOIg8hlAF8jndIq3cgaQJUB
gHrPVszSGb35uhrFKsLizJY8ZqxjkUwmTQaKhM5c3B5EnQAAkMNHHTxHndRK3RU4
ytRGTdTtscNOXdVG/dRVPdUfptVKncsB4IR3mpXlJtP/5erTUcN77BAvlroSF/N2
PC0WZr200+uCjwzVUH3VXX3XOqzXSG3FSb3UeP3Ugo3FfL3IX72ksBUBiqhunnxw
YKdo4kCT4pB+asEKa/F2CNaQ7usQcd22Cw0GkGzXfZ3XTS3VXU3Yfk3aei3aUW3a
gQ3Jkwym+gWNjn19U4Svy8gTlFbSIog4+SVjDdiqDzEoq4wpjfHWNdHZJzvXAFXX
g73V0F3Y0I3aVK3ao33a0Y3V0s3FzCeQp5dVE1LGZ+FWZ3YiOBF5i6c7iEMpbLWn
cFZeFDJbN6YO2QDZkVoZmHpAbWceyE189u3ZlRsGof3ceW3VW+3U003ghf3XV83U
/1Lt2g6e4LCN2GQHhQOAAYup3jgBGrgrIeoVlRQrjVe5QWn1Vjla4jtFOlJ6FlM6
3NUVC/Sz3+B4YZvdEMq9wcyNS44M2KXd1NmN3Q6O4Nj92oO91EKuxRE+5I/s0vrn
U4+dN1ZyIUmhypxKFjdewzm+Bc6d5KTd4AnO5RK+4NbdxVxN5I48yZsLfT8GKPV9
Wi32ZZ985R9cKU3Sr8WAY7fSMe7AJkPc3zMh53pYywLeyEku2gzO5WAO5Fd86Gau
5Iuuy2i+mriVaI81JQ1WZW4VUSS2eP/dMjYZL5oasB43I9xmQ5Lo5zIB6J+c5aZH
6NON6F6u6I6+3a8e60jN1/+0vuR0OoMrul/NLZ2dbpalYS3zNuU7Bsg1/r7BjuWf
LWKMfNc8HtiAbddHHuQPfuSnzeijvdoOzXykM8YTwilf24+OyOlQXl0Pwn5tcdNV
scDkoOpszOpztcvSHe2pncv2Xu3U/uCQjtjn1gCrOYkySjZPyFOndbLw7iXYnAd4
gGqirNmckfCUO8WDvtIWf/FYzOQz5lkken3LPufUMTGEwWAPV+xKnOzlIPHS2+xe
gPEu//Ifdn+K/XwcoBq0MYm1XY0fT5luESYhzGOlFipuHK4o/+47v+os39wwv/Qr
3d2Eo6ICKSHezIcef+4nkdZ5ANCC5i7LFeXuPg4qP7//MiUGde3apV3U+57o2l3m
YU7VEL72Er7IYowNn5WavYOxZX30jkKmqEIM3ybjLuGjp0H0Ea/3x2nOOv7se734
X17k907gQ57rDB75jt7Fk2y1fYUaJ8IMku2qht8lqCzlmIJ5Jmzln7/yAQ7arn7d
bU/5jW7m0G7k2F7d0u74Z76ysJUB9qXeclbS66jyNT0wpH/cXy8OYQ/BLb/jZv/j
tV/rfr38Xf76X27g2a7rTxsAgnO9xEP1Om/1g1Gst3XzkIHqD3H8Kuzs6yzk1N/a
aj/Uzv/4r13Ulc/dCkvJgmO18JrQvVj1Z20Y0vItQEDILAiLDAVJqSgeTefzqahY
/zRV6xWb1W6xkQsXWwCPrwiyJpFWr9lrwBseb8/pCcA8nr/b2fd9/62vLu1vkA4h
ILEqYDGgoaPjwrEhocEy4exK7Mor0/MT1IqpacHCopSCoKLiAeLU9EFBFoo2dioU
l/PrbDPXyozMULhOL3CwcDhZmXiZDVFRgxEtkYNDLSABGrS3qtP323f0gTV2XHb2
/NyCvNZJigoc1JuM2xd4rFmtGLmNXxCvGCA5xPII85fsmTRGCSxE4CBgwAIFEFZZ
2LWty8V4G88wUbDAAIFUC1JRgCASgrgHFIaopPWOo6d5Y+rlugcmH6F+bgIS2keH
X6GgQHf67Jkz4aJoDRJhWP9QwVGaCJhC1ZsZE2sWjxUgnISwoCsFsGChVCiVzqUt
eFnBXOVSE9dNLjn5/NPZ7OBQfUX57j1GN0HSaFWYBhAggGrURIsZS9tiVSNbyeLQ
skrXzmM7tZLbRn67Ue4WbPl+6jtKFKAegXCOFTR0UFgAwYwCNHwoAEODBbsrNIBV
ap1FMJA5F/dohMDXrmMfiFziBILYDCdFznJ3q7gWt49BnxkNGHx48eMHyV6sVAPT
BB0qcIg2On2iCJSyOdZCPDtbjxaQHIlekj8l0olOJCKiO+e6tfKzYrv7ujuDvAgl
nLAZDWYjLJHDKlHgggQiiCCRbDzBb8GYKPuoHHfSigL/rcoULLHBLOAKJTTRKLwR
RxwZuZAhhw7L7akpLFDAggciGDGjErHaT5UHSlmFSFesa8KCr7jaTZWvJJIFOyU1
iDGMB73LkcwyAZPmwmkC6OCBBhpJI0QReUnSy42Oy+CII1iyQIiUKGMplejwDJSC
c7pUEkxNxBzTzEYdrcOxNKdK4DBK5oPTkgsuUIAqmuisExxxppiiiCLHYccJWB4I
7okluHxxwUStmBGUGvF5FNdH7bswgAp8xC2BVsgxRZYh59TFl8aUXZbZZpsdBa1Y
ooWixWq5XMDZbJ3tNAtZq6D1E1vHiDPXciXU5pfzrqAkAAxy04Ixbj9DNpcGNthg
/wJpq3VilX79XSUKzaRVsUWBDW6CCQJa1PScTWVxmEOIIT7OPnrpWRTUjDUmIykP
E9kAqjQa+LABBeZzxAIPFRjZU4tDiWACAgxo05Kaa7ayX1N01nm3Jyf4+WcDgP75
gia4MssVJ80a8mDMuLLZEi8usJRkX6eOZeoIHrhgPq6crJhBz7iLR9yNwQHAbJvO
i8CCAFaawJGiqRzSAktSZiICBcBW1GVQGjgAcE79fWpI3qSASosEuDJlgwMkOOAD
xwGXQIKiicwTUCW+WrHpd5SlAIEHgqWg5iGmTqVDI2ie4qO9vxTbQbLTZgvt2Ws9
DxsNWlEAjTWYis8KxloO2/+XvwNvYNUiS5FoAS8y3TsBkkrZ4APq7/0A++pF/ZcV
VJum5VBHSGqzlA8jmM5kJFaGIAMjLWEC2y281QBcT8q2PZTa8c9kNsNw02A/vpLX
J0gUCuMdYGWagloDpgY185mPgbAw2QJrxgHqEACDGezKcjYIFi1t8CsiQUJyNkiA
lK1hPiN7oArNx7UPaaqBCkhO/LQDOxlhbH++0F8Ox9A/AWSAAAHImzmm5osC+g1w
CKSgJYCzMyeaghwVeeIUn0iWBKysARyI4VRsxqfl9AyMu3GFh5zHQpFdamQLtMAQ
aNgtG4ZJdjw8mxw5pi5GcAAD7gmRer5xxE8cEIvvWxX/BC6wgPpoC5HNQt46PmKB
2+RmHaX4yjqegxkm1G0D62iAB4pkiQ0YwFefXMACOfAhCLhufvXjHx1BsQ84sBIL
PuwAtipAgFXV0k258KMnAGkzsxDpAm1bUANS4SuSXOAwzaNSK2xRyVpIYTf20iQn
28QBkRhJJHWjYAROKb838g0c94MlF3Y4zjLY0TAYFN+m8jZAJPXtj0kMpAopwcBG
Ha5DXGOgAj9UiZqRbIkjY13JOCS1rLnQoAHtZg0zocoziNOcWShnRC1kRw1UQ4++
S089XTc24tUriQ8o5QNJWlKTnhSlKVXpSlna0pJeYKFubCgOKQqGiUbUhwLoQG0U
/8YbDwXnSO/8KC566VKjHhWpLB0ZDJnaVKaycIXcROU3Z0XTmm7hpub0oTojUAEP
XQAqQrwAAXI5U3jyUp4BVeta2dpWt7K1jFCFYNQMqdCpmjWcV81EVsd5ITy6xxLY
EGIuJ+EhNVBiXkM1YFrf2ljHPtat/ZSrCy8RgVEuUarexOs3IKpXz1ZBMNnAACQC
QKTmXHFIELAbV7hplgckthtU5UIvIVtb29ZWawcjkja3GdNPDY+znxVuD9HZgSEI
8UNtI5I9tcbAkmmNdx6NbfGS2MDbXhe7a7WctdKRwt7e9Vh5He54s8CrClAgRFb4
nS5/i8TjZRe+8ZVvZhka3v/gkhe/oD1PA6ASAQYgAHlPQh5YpxCLoNr3ddR9r3wZ
3GDI+vassRMvKMhlLguHB136VQQD3ZYKbDz3jHkzn1CnC9IFOxjFKV7gKCCs2OFY
FQzfufCMxbMrxnCAKcibit4yjItdZgKQ/lTxkFNMkq6A92JxzISMadxk8ETKbRd4
SAdw7D4KdFW2wE2wiQ8wJO5+GcxhFvOYyVzmAZmkxSVO8oTJwGQnvzknaBospQaA
gQR0KFj+jMePz0DQKX0P0IEW9KAJTa3o1nfN94UQnBl9pooqwgMMANGy7ryYQ5J4
y/nNbyphjIVGf5ouFa0A1z7AAA/4hizJ20/yptBROLr/WNPD5bSSY2wQN/BENf1Q
zR/ksAdeu0YojDbPfPwr6dHQJ7CUsK4lMD2yRD4b2tGW9rSpXW3GfGiz9mDUX/wC
CFvz2i9+uEtd7EJuJ5snEfbyQLqb20+9cahkrpYwYfRlZnvfG9/5znfyoDiqft2S
e/1iQpYdyrFFv+bW/4CNTsB9F3GT2x9COU25EDFqmOUrerthG1lTtpuJlDXbyCv0
yElecpNjxkkUMIArqoRmWWTzFBBohUkaMups2+Tg3B63HSTOjF8/HOjdTjioAxOV
BggBKjXLRtQmwWGMXOGK+pb61KlOdVK4ol+G222BWTEWX9kcwTgPhq2FjheIh7su
/w0v96efgYZOug15vqnARuqhAJOEEe951/ve+d53v/8d8IHnO88CfwoxHljLYr/V
X9TuyqDsGu0D4flAfj5xXD0jDfwxJAGKFgEM0t3TBJi0tUlfetMnMgEbYAADJIC9
1mcPexP4ANAYMIHa1972q9e9qT3Qew9swPcbADn9Om2Fb5cd+WRP+/LLvfAmI8IK
K1GPYOen5egNP9bFkcDqHRe5JH6AcpBjAPhXX+rdn9/UwSzSvTAo6VcrGic69/Vq
jJGMhge9+URPAyLoUynkGpYj6uH6sq9EDCADLMBxKOdxWm/7tq/UIgf9ItADaO4B
7iUJEI/4aG0u5G/n9KIviv8C/4bO3JyP4npFyn5EN0hBmPbM00aJABfkA4TGABSQ
ARUQ9h6w/MYvAoeGBycAAwuuh3LuAx9u54ow+UwjEObPKHpNBJ0MEbIhAdyFo9Qg
AFsQ+14QKwJAU3aj3hbmMiyDCQAmHRimoDbFV95P28ZuGZAh11LDNUAQ4ZDwDc0F
+kpEAF0QCzlDCxfAuLbEUJbAfNIBaLZG5QxAIgxsPpoARPKmIdBQ8eJP/yJRGOpw
Qe7wCvNwI0orjwTgEGcBSqTCHXKPEA1g5QauZvAGG4LpB4uvCiTRFQeBEvPDEjFR
MjRxAGyJX9ZBET/EHSCg9rYGAkiRaS5ja96nEYMHCMH/AKJekRnbIBazowC4ZQBp
MStKy0DYwXsMbVM049+g4BhbMRm5YBkJgvJw7Q3PUecgDtjckDUqrx3NUfImT+3U
4BmLowA0YhqpESsaB3LoQxh+7wE8IB+45gouIBy3YByHQQkTjg3xIB0bsgnzTyKN
UAQXkh7lLSYcwAGgDg/1MSYmYHIwsgquxwNeBvE0khV7ByhKgyHXjiKFDiLjsS88
cASPItjMbf9EciMMslPy0SPjIQD48QP80RB8T3SawWSM7x5T0v6QzyJx8iU70NuO
UConUvmYbw3q0R43shU78ifBQXGoSCwpSYrGcorKygEOEiGFEDU60CZ7rf4ccvJa
/zIq+UAmR1AO21Dy+EErOcMgudInv/IbTg/arCAts8zg1DA1XJIZPvDWGo8uHXIe
7RIJAYMvdZIj0tIBsMErBfOzNDMmEvJGIs7nqPL4ipAIJa4N2/IiQSUtC4ADOtMz
ayoBNBMzE3PxVlIvXYki8wLt8pI15BIrzw4qGTMi+zI7arMAHEBTZrOmquE1EXOV
FFM4y+4me7Mtn9Ixx80i7w8eg1Me5zAnN+YCXrMAzhM901M915M929M93xM+41M+
55M+63M+NVI67YctXRIi3bIch7A4IxInU1MQrlMZLnNjEgACMNA5G9RC9vM74xIv
41AhKfQqq5MlWXM8NSYwHf/UOUWzGZkROfOjQz3UM0E0RF1xRJNTNk1UMFE0RSNx
RYujRF30J2E0RoluRjmjRm1UH3G0OoEzLklwNSNUHf/TwnZUMnrUR2kRSLfTNILU
MRfOQCOTDm8TK5i0SfPwSR8TNR5vNWlyJr90xpSULbR0S1+wS7lzKn1CQ4GT8ZLv
55IUS2MCTdM0+7pUQiW0KcHDO62yBBO0RfGUSyHU/ngzPMWzQr3UKIzTURCgEhSI
yPLGEsziEglVTQ2VNEgDUXM0K8/HhDjn5FKFK0biUjE1TzXV8aQ0Ufn0UIu0SCkO
pibJLGvVVnej5QYVVVOVOtPRNH9TQA80IkmQTBCACDL/CFmTVVmXlVmX1YNkzruS
SlqnlVqr1VqnVa6k1UjU7wEgys3eNEAVDkr71AiJVUcQoOrszfBQwiQCzl3fFV7j
VV7nlV7r1V7v1V1JYQNMSEtMAs2CxF5NJgM2xQAQAAK8lVwjVDXnMEMtNFFnTDb+
bFQFRha+giWOwAAoYGI3lmM7dlSLZQIoYI1UISQGRWNF9SU2jiIK9mAzwVMl0ULI
EC2cimZr1mab6l+kYGtulmd71meb6ssmxgutRWYXRmjHMGi5q2ZbCIZWhSyKJJhO
hRV+tqkawkkwaAE661tf9twspBJE5hLIKKrmY6RO6p/ONmoAaoGIbYXSlm3T9p/a
/1auzhajAGqFDsuB1Mq7timg9nZt9Vat5CYtsEgq9jZa3dalYi6MOisauLbR0CSC
LKJYJqKSPK4CN6AJPMAJ2IQUVEGGHGAcAKU5osMskKBKlsOLUoIkXOWXHkAjm2Bf
qaQUHiBkNTaDVkVA7uVeFED1FgBhYkGEgHZBGaYJYIhIOIBfdhasmodhmiolyNB5
82ZTgHYBLgADtmZqNYU/LOBe+AVKvOAUJAamumcBJsAVVGFxuMKE+i1eL4BxG9dx
uxa0IsABAGDlMtYAPXfUOkBjVY8BKtADdgMDIIA9QAIBbCkDCoBkEQBdTUgshGAI
lEB68CQDKoCBNbZnXHc5L//3ACii90yBgUNHIx1gAT6JAi5gAyhnAipg9WRuYArW
WJFgCWrpAiaAkygiiiyi94SgUGKBN4AvOFyF81TP7lgCFwkJ+FYCAZimFdxlNzIW
YcaHAdaBFDklag4WAJaHaZqkAjaAJUCCAjrAlgqRhQslYUhCY0U2FYzkfVsxfiG2
DBpgAhCgZF2BCGa4dB/A/B7gejdgATDAdA/WWGXIEEGCFGnXCIggJMICCRbgPNuH
FDV2OVxXI7v4cSgCAibgKULYdTvAAfgjY7nXcTKJATbAhUeBgsHChJpgQYGvkXRx
VVDYjzEIYRhnAwgsioZ4AyaCCJSAK2rYA8bKAIqECSDlYIDNtyvMAY29KJQlFQIO
wFgrIhYoYhwsQCMLkZYL0QIY4GRXgiRsiYSgtY3f5I11BWwQoIZLxd8Upmj8mJC4
N5grcGAw9yNSoqtG7SN2o5CIQAqSmSsoYiK+ApkGYGsod1McgEMU4Pc2hSwUIGRv
WYxkgZ67OJMiwF1GrWmTgJJ4Jp9ZzomaIzmEJJKUhzd2pqe6Ijg4WoyKZGeeonw9
2hS6IsAmBYLGqlScyE+KhguhxCL22QmM12QMKmIaYJx31SZCGKmTWqmXmqmb2qmf
GqqjWqqnmqqr2qqvGquzWqmNukSCAAA7

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="head2-1.gif"
Content-ID: <head2-1.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="head2-1.gif"

R0lGODlhSwBcAOYAAP////39/e34//T09u/v7//nzvfe1v/epd7e3r7l+dzc3Lri
/v/WhP/Ozr3e59bW1q/f963e99bWzv/OnNbWnM7O1s7OzqXW75zW/8vLy+/Gc9bG
vcbGxrXG3pzG5729vbe3t5y9xtatnLW1pc61Wq2tra2ttZStpW+0yc6clKWlpWuv
1VKu70qw8WOrxJycnJyce5SchDyp6mahrbWMhEWk3YyUlJ6Ok06f1DSj7WaarX2V
oKWMYymg5zOd44yMhCmf3nuMhEWR0kGVu4yEe4SEhHGKhxeb7BeZ7AWb/gWb/wWZ
+w2X8AyX8gCZ/5R7YxuS4COO01qElHt7e3t7c3t7a5xzUntzc1p7e2B1cntrSmtr
a2trY15mbGNjY2NjWlpjY1pjUlpaWlpaUlpKY2NKOUZOVEpKSkpKQkpKOUpKKUpC
MUJCQms5ITk5OUoxITExMQY4VSkpKUohCAYuRCEhISEYGAgQEAAAAP4BAgAAAAAA
AAAAAAAAAAAAAAAAACH5BAUUAHkALAAAAABLAFwAAAf/gACCg4SFhoQEd1tTU0R2
KoeFY292Y2t4HJGFKnARABGgCQILmqWHdmRFU092maYqeCkABVNopoIWd3ZsJ5+f
nre3CFdwUkVXrbcbdgAHBSN2BMJ2JFp3Hr7Bph9ydXV2VyIbalTCcBsF6XBXt1dy
BwdadhcAGNqaH3UqBAQIDc5cytwiAIdCugIiFJWycScFAwYH7oTIdq/QgzsvBhEo
4EyEnQ2mCMhBlw5AijtTpBVCIEcOCQYTYKoJ4glYxUEg2HB0RuKJgXRpxpji8i6d
swIU0NTZoqJECRVi7mg50GDSGxFaglC8KSjDmQMTRMAos+bAzw1rziA4RODHHZIH
/w/CsLRmjRst6A6ImPOEB4M1WrfeVHCmwAQt3dAcTTfmjpszNghUULGlZYp0Pwtk
jsuZ40kNeufZ5CpogBwCEyYc4JHGwGLDH9zZqYNmTIzOHDdj5uxMzZMDZc5IG036
jgSwB2jYWfz6wIbXmKEX2BCDbpW48eS8YeOA9KEziuFNgPHPgHnX8Kg6O7rZtfln
b+RwoUFkDRqD6U5qrekdUZ0xE+hmlGsNpIacAQ0YhdsIT+xWQBl1mMWRHA7YRBxp
BNlhQwlaaMGRUeKlZiA86ST4IW4H1XGZOr0I1p8gL7BxBhx3OPOPYalpIKKJmf0k
YGdpcHHQGIG9aIocIuRGlf+IIpLIXDrSoAgHDUNiYeQtU3L0D1hMwmOihJphF2Y6
FHx0UBo2uHjlIFiksZ5rTKqWIJgoxrWBHF8cZIAdHaxZykUUrKeenM78RKdrChYA
Axdh2HHdQU+44acpXrihpVmYmlfoQdBlRkMYWqx4kBtgAKDSpN/lmamEi7mHm3Ml
6aZCHY9ZgKomcojBaWevGZrOF7PZsUYY7CVkhAxQ0JHmrYYgwIYbI+wqHWcjvIUU
DWfYES0McUThxLc51JERs4YUQRsRScbV45sI2VFCkrM48oMdTHxrLwt32EruSlu4
UUcaMWzwI2cxsOEYDOg8UUcN3zaxhL1diLFvJASYawf/HGN8oUXAE0ggggpEoIEA
NFW4YakBctihSxtI2IuDpBObQsUW/QZrRxqQAfAGF7OYCMe3QBxhrxM+wByzdxzo
Uka6BcAhxNDfJrEDG0f3dwZeYdymWR1DQO1EC3BAUjVpddzh00Ef2NED1CiYccbY
3rnBxRlUFgAAGFlAvYI7a8HN1RRqGDBLASXcccMMLujwrV2n+l0RARdbQcQZutQx
xxxvqGFHqY57h0ARYpxBhAQAWPBUCSY80PnqrLfu+uuwxy777LTXbvvtuOeu++68
9+7778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUV2/99dhnr/323Hfv/ffghy/+
CPjkl2++n4EAADs=

--ufsnltbcmiqtetjk
Content-Type: image/gif; name="head2-2.gif"
Content-ID: <head2-2.gif>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="head2-2.gif"

R0lGODlhswGBAPcAAAAAAP///+TU3BcMFPXs9Pz0/AUFB+zs9vT0/AcMEMjo/K3d
9AwUFBocHPT8/Oz09PT89OTs5Oz06PT87Oz03Ozs0vz85AwMC+zs3OTk1Pz87PT0
5Pz89PT07Ozs5OTk3Kysq9zUrPz0zMvEp+rky+TdxPz129TMstzUuvTs1PbkudzV
xNvEl8i0i9TMvOzk1OTczPTs3Pz05OnUrNzMs+zcwvzs09uoXOfVuszEuNq3iMq2
mtjEqvfkytWYSsyUTOfFmvXUq9zVzBsUDMqWWo5tS8aoifbVtNTEtNzMvOTUxOzc
zPTk1Pzs3NTMxOzk3OTc1Pz07PTs5JCPjtrZ2Md2LLt0Mdqldui2iOjIqffZvMq4
qMqFStiVW8mVaeeqedm3mffcxa1bHLhmKqtkLMh2OsqIV0s0ItiYaMaaePXAmei6
lvXKqfxsDPl+KfiIPNmGSsd8SLlzQ+mVWdiLV+ecZ+yjb/mveva4jNiph+bLuLmk
ldzEtPzk1PxkBPx1HMZnK5tVKNV2O7hoN9Z7RKtmOoNXOrl9VsWLZtabduarhta6
qO3UxFQsFKhZKsdzRWs/JicgHOW8pZZFHFwsFMhpN6dbNd99TW9JNteslpR6bPbL
tbCUhciomBoWFNTEvNzMxOzc1OTUzPTk3Pzs5KhHHLhXKtZsOYdFJZlYOlk4KNmL
ZoRkVYk1FKhKJdZgMMVaLHg3HJhIJmk0HZpsWHdWSOyrkaAwCLZKI4c4HLlaNVwt
HEglGDskG7GHd5QsDJc5HGgsGVEsIEo3McKYilJDPtzEvO3UzPXc1Pzk3HokCowp
DEcUBlYbCqg6HHgrFlQjFIg8Jax5atW8tcW7uJYwFYYsF2skEl8jFKA8JKRSP6Nf
TZVXSKprWz4rJsWspuTMxkgcEjgYEZdJOIpIOXAcDFQkHNSspV8jHBYMC9zExOzU
1Pzk5NTExNzMzOzc3OTU1Pzs7PTk5Pz09PTs7Ozk5OTc3HRxcc7MzMbExPz8/PT0
9Ozs7OTk5GRkZP///yH5BAEAAP8ALAAAAACzAYEAAAj/ABc4CKBAQYCDCBMqXMiw
ocOHECNKnEixosWLGDNqdKivo8eOHELOGxmlZDx6UlKOWskkVKglSxgpUaKnph4+
fCQtWgSmJ5hMQPPkMTI0DTGjSI36SsPJl9OmT51OiTp1CqerWLNyIraH655OxDqJ
PfftnNlpaNMaM6bOGLi3ouKug+Ly3ZMn9eTVS0mvb4cO+/bNEzyPQwHDHxN3DKDv
oMeNkCNLnky5suXLlBcnFjlyXpQOUVCmjLFy1AuXS44xkmkTpyQeknwCDUrUiJE0
uHPj9oXIqVNpvoFL00S8uPHjxH1p8nWVOVZfxLYSmx5W7FizZneqnbYWFNy4otaF
/4Lyzm5eD/L6qu9AQDDheYcPK/7IODHjiAsC5MfMv7///wD+N58+HBTWGWgdpDQa
S6cdE9NqNt0kiU6yBSVUGkYkgpuGaSDioYfSICLNISNKI003J9KiiYoqasKKizCu
iBxyJgrn21XU5Vidddidox1aa7H1nSjw1FXeXfJ4wNd6+wA2WGeGcTDglI0FaOWV
WGap5UMfScmZZ5/FoyBpoyDDBEyqQXjTTYvEVqFQt+HmxZwf1nkIIiQecgiK3dDS
Jy2ABsoNK4SyUkuhiCYK6J+BalKjib7Y6JuO04FlXVnYLQIkd8Z4B05c8EARannm
5YWSeuoFFtiThcUnJZWPIf+U335b1mrrrbgupFhIBZL0WQdixkAmE8iguRoOEWYx
oZsWFpWGF1fosMYaOuRxhRdm6KltN3p24+02RYAL7qCGcHOouYfWou666bLSTRo6
zKBFGDjMoEMah2zDzaIn9mtib5FOSumOnfT4I6fqqOMdePAUSeoH9USsJKp+Oele
Z/MQWACVuXbs8ccBNrZZgb3+KqZKozDRkrGM2JRFTm321GweaSSSiBd5ZNGDDPPI
4LMMNmgBhA6JEBGHHIUkbQk3qaTCdLnl1mKIIZhITQ4mVFetLtaHXBFEGH30QQop
JUVhQg8sILJNKtts46e3KPoboqTQQaejdQUbDKQxnyj/7J07cYlK3sN41eNBX+kx
qerFUc53EK0gRy755BKJ/JGBJIF2shQsrbwaI8jWpOyEMs+s4c3QHtGHDU3EM/Zf
HXSkgQUypKACECzogC3SqRgyjiHkkBMNJphcTfzxxJOTyiFrHKGF8yqEYQPrTUQR
T2EmBGFEvtq03Tbc4JP4aIi+2U0p3mVt4WNaCP8NeMOjklp4xPTII4Vf9AC2qmDy
xUr5/wCknOW6xJlfJWhBKTvTg0AnutExSyhCOZ2cPIQGNWxCC1roASmaEIOxkUIG
Y4tHPKJQgABwQAMakMHZbqeDaOmgBWrDBCRmCAkZQsIQh8DCEYKwCTZcMINh6IEN
/zxYkgLMwwI9AAIiCsEN7zkRfHATH4oiBZzy3W1HZUkf+z7RN4W5AxzuEAKRGgYF
e9jlHRFL4+HW055VySeAcIxjx0ZGspH8BSX2Y8lLUnOsBi6rdBDMA4fm5AUPmcEL
X8CDGtjABh46L4h9aEIy+sAEGzChBz2IpBQ2AJoTzk4GXrKAFq5AC6dtoxteUEP0
nofBMGQQk5lMgbCuV7YocMACKsjDIbTBy+458ZRQhNv4yucUYpiPOpcii/q22EVQ
gMId0BSFEMhYRnvMrx6oYo8b9SPHbnrTPwMESZTs2AHRqERle/ycy5bFrGpFsGaE
NCQizGAGNHwBC3jAghrUMP+tfS4yCM7D4PMCGsQeIKMPmGRCE0hBjxGGxAQiiKgJ
LGCCJkxvddOjXhM2yrqxyaADnpleMmSgAREAwQuHKIQ2LMHLbfjSe8Hk0zCr+JTo
5OgrYvmGTtW3BWaqox3OjOY0G2YPa9YDLx5Yo/6+ydSmZqY+GitZmBS0EmScZoGh
04MDwbCGnwTydPGcJz31ZIYrfOGsX1AEFu55T3yuwZ9s8Oc+fXiEutY1DEyI5EaF
ZdHp9cCV8xLovIKYjIV+0LApGWEUbBAGFfQgHre0QRYSkdJeWtalmP1eMOUWsPJJ
RzqVyqlOd7qFnqLlE+1ohxfDCL+iotFw6nGqbGdbkV3/Ye4zoinNVbHqR9J1NZBX
sFlYxZqtQ8QhDl1A61ntwNwv3MG5Z8UnFqQ7XTxYV65qCMJge1DJsP0VsIIl6Lwy
uVFSxEMGUfiZCKXQhL+SNwoolCxlCyGLcVj2sk+MadxqRMxigja0nRjtaE07DS6q
9pnuIKM9PlA4etD2wRDWlUe+9CvRkKlBn2uZ6P7YVSx8Vbh0Im62jvsIOXABDXVI
cR2Yy2LlttgO0L2DWhWRT0XOta7j5S4sM9mHMIC3ldLrqAijEMKSdAC9ZmtCCqaX
Ap7dsgdZuEJKxyGL++I3v5vdb2efgiPQduIrAt4pNU6bWgQT1agRTvNsw0mgAwEL
/2WmCcUxVEOT3saGWsANbiLQQKdV0DNbXDjuIeRQYjPcAA1dQHEXVMxiO6j40Yxu
9D3hStdHYhDHgfUxeH3cgyakBIT0IEUHrzfCBMmgCXnVawqaYIJW92AGV5BDfcdh
36ZZuW0vBSYU5VZFmmJlOtLZA5gHTI2e5uATTnjmNMuo5mZ/czOHIefJSMOEq7Km
JnzIwuh84k5FWEvPhFwFHf4c6OPK4WhWsMKJEV2HLnRhDihOMYoVPQc60GEO756D
vh/dXLXqc5FssGsPGUlw523ih63sdJGJHIONjnCEh2WCK6W3UUzaQAMcqEEi6JuN
bNhXG7TWBtN4yY1cY7lP3v/iNRVvpJXpCFvAWxgzap0QRig4++ZwHFnmzLkSa1+b
D7AhHRh0oANvC+UKeuazF4iAJz0d9+klHgQgrIBcedNhFXMQN77zTQc4XOISXqfD
JeYAB3zX2+wrbu49FcnIIDBy4HBVAx7YcOntFlaEruOgLBdqPVLYoAcq2MQR8Cqs
FDAhCvMwwQzygAhLZCMatE7FxyNv35Jzo4new7zb/iTM8dGUyzjyioBlrloh4Pz0
k9vMSJp0QM6hk4+tCbpsjP7tPaMBDUTwM9MRQQupXX4bSTOxGcpgBTrUAdFd6Doc
li92QhDiEs6PvvO/vvzqX8Lec4g0jJ2LT0rHNZ/P1af/4AM6r0giue8b5KAUxhaD
Hmxirlrow/qlEIMNyMACKZisHAIhi/qCnNaTxw3j4DSXV4BNdIBuEyiL4igMyF9V
lBXCtgdiNg3t4ASod4Ee0yVPsg+foRJPcFWq0Rp/9BOZAEFIZzO3d3tdQATjNla9
VwuYUAzFQDxFwAlf4QVocAPJ13XSJwiVAAivcApCOIRD+HxwMH1wcG9JeG/ZF2lf
YAdmZV1AkAX8hAXbp0jaNV56ZV4mURIKskExIHFqgAV3sEhaUD3zwF4fBEJasAZL
ZAmuAIAAGAgACHKpAHIGmIe/RwsJqIDFMRzK4RxXEYFi9gkYeIi20iUIMBh3RH+m
/1Es6iQhFDIzwRVcKegFK2gG48YFnEgEKFUEMBiDxVAL/qAJxHAF7dYFy0cIgnAK
lfAIlQALuIALsFAJr/AKleCKuVgJgtCLveh8R0gIzJd87tZudaBviQZjirAG1qVc
NNZIzpNQo2BewKJYRDY2StYDRzCG02VBTEA2RLZ3QMMEbbhxwAAMkCeH6iiHAkiA
eliAgZKAmtANDQh6hPgN1ICI+nglibGIgVFOHphOGpZtbuJVJmgztpdoLEhPnFhu
x+WJiFAEUyOKxcAKXqCDPCgIsFgJlaALsKALzlANrgALJMmRQmiSHAkIgMCLvigI
wJiEZod9XWdvxpdiyrVizv+VXVroadZzEtaTXuzXfirABtW1SGHADvOQIBvFQQsl
A1IQBm5IX+gYDbNGa+QAgFcpgFY5Du9YgKywL4EyHMOxHIL4ct+wj2gpIB6xOAB5
VE/wEsdQZ1oldCVoLTVTM3uGiQu5iZz4dGXwl+qGdIdANcPgDcVwCHbwbsvngxyp
C6ZgCrqAC85gDdYwkiXpiisZiyXJkRxZBi0pjNUXml4XmqsQbynWhInUSFrIOjEg
BTIwZOk1GgilBUEABASnBclQNunXVynQZLYzWYUQDcIJeVeJCuMQPMd5lcGTCsET
PAVIDgb4lazgh2LJchKYlth5GR+hKh3AD/zgllc1Exv/JhsQlAbgNid7yZANGQd/
2Z7plm5ecC+G4A3eUAQoVm9H6IMk+Zim4AqukA3WcA25wJ+mQJKOSZKwMAa6oAuD
oAucyZm/KIwSGoxgJ33D+G43sGJsB1BBtJQdRDYeBEJ+93c9gAM7pF1McD0bsH4y
0HDeJUsVpQJq4AVyMAnAkAvCKTzCOQ7R0JzNmZzBUwvQmYfS2SgPGBY+kp1KKhke
4QAFEBj0wA8eUA8f8AFQAAWiUGc8ABsyA0GngzqY+GeauJ7s2Z7EVwlWAAiDMAZj
wAUvJIOLlnxeRwgcWaD96Z+lAKDNgA3AMIv86Qq4QKBicKeP6ZGb+ZeC4Jmn4JI9
/6iRjioIMHkDdrCMAPdIemVY5rUBpKCp7CUsCOVKziM2MmB/ahgFHGVJrKNCPcAG
V2AG9GWjO8qjkJejqOCjtjqkBugnwEEMmQAGQrekwJoRHlEAEBAYD/Cd/fAB9gAP
caGlBVmXNgNPhSSm6hlohGCmgJlugMCmbCoGVnAItHAI7WZv0OeKsPCnpeAKNvoM
4SAO1yALuFAK6YoLrnCn6eqfrlAKgUqgsKCSKQkIv9iSZaCLlfCXoDkHdnAH+sRI
g5dQq7ZQ6xdCHpR+nxo9TNBkrnNeDYeN2ZhXq3Zqr8Z4SCMLw1mrwhM8PXqr3ACd
Q4oiaZAHy8hVQGEEnRCsNv9bWx1RrPvgnfXQD0UlBEKwAqCQBDjBE151gvAkYtXK
BYRQpu1ZBVYAtds6BlMrBmMgBmIQBzqIn6zIkbJIr/6ZDef4DOIwBOIQDJMgC/l6
r/+ZDaXQf5Pgtvm6r3Z6rrXYma7og62Yi6fgmb+YhF0AY3iwBgGXcHlVXh9kXgpC
f72JSTXgWIX1UcKysbuJSVqgAtGTqmfDBjqABodgCZYQCLxUXyYLpD7KLYiQCHkw
Le4EQUdxs7ALEWs5GMfas/ZABULgDkOLE1xal4IkrUxHBEsbB037l1zwtFUwdds6
tdxKBmNgBWUnp6xorqYQr/5po61gDew6BAMgDpSQC7L/YKM2Gr6TMAmuEL7A0HHy
SrePGai16K8PWrDtea0uuXz7lrBYYJt3hUl9QBodNH+iRgrsZVEp8F141ZTpZwMP
25ocBXgCxV2s83dHMDRX0CGDlgqgmwqFsA1yoCepuwZYoAMeVp66kQexe8IS1hGq
IqX9QAW4iw9O8AlIgAQ8wBN1WcF5Oa3q+XRxcLxmWgVADLXpxq3dirVYywXjmp9C
CAiPma/AIAvnaA2xEAzNIA7pYADpwAuzkAutkAte7MU3io6TEA1hrLau4AjVy74e
uZJ/yZkG+5JLaHzNtbDaBUmUJCweVF6GFQMF3AMYpFCjugF7FQMKzAQN13CVhEma
/xZE09MEq/NXR7AJayBIiXAFQkEtawAE0+JheoaQCGkEKBzKUKUPK9yzLowP+JAP
OVBsO/ETRIEbSidWXGAGPczDT1sGQQzEabq8RFzEVbB1dMCKsAgI5xqvNhrG1hAM
2NCu6XABBnABQxAOjRAM1PwMzxAMzzALsbDNsfAMOAoM+OqfaVyvpjAI8duZbyyM
95aKdTBpi0RQPJYChcWUMXBqk4tqsMQELCrAG5XIl5RqCAVLQTTQBbXIgGVXQRAE
WQAEQ0N0lnwzCImXaSDKJ7ydgeGdPksFqJwP1FBsW7ADnZAJr0xI2LK0DenDuIzL
QayS25qm3Xq1RjwGcLCDl//Qi+Z6rk78xblwzdAQDp5wAQkA1AbwzEPgCWUrDuHA
C9Cw1NjQ1NjwDLGQtmaMp+lazoOwpo45BujsfFywhO+2zomkBrZZuJxWSYg7Nuu3
lL2pMtw1aqLGx5S0Y/kMSzVg0AdtomygbXmtLJo8LYpQibbnBcKFGxQdux4xGDvL
DxmNyh09Wl9hGzTzLMTFiT/wA12ggzfgA5q92WXABbmcy1bArUaMtWXw1XCwtz/4
pzbqxdaszOZgxUF9Ac18Ac481LSdDmaL1OGw20odDN8Mzm4rt+SMxo5QCpBpzvMr
mmUnqWs3V1kISTYwChDrQQ03GmGYUJ62fg3Xx+4l13//lWk1IFCRPANZEFeSAARy
hwUg/NdXcHt5yWeeSEiFfbMg8aSJnawancrUAAL8LWy2ESeFNE+UTQRIR3QGrgNf
cAMKruCbzeA+8AMqDbUwPQZ0IKewSJJj0MTpOgmt0ArWfA3XAA1W/Mzp0MwlfuKz
Ldu4LQ5IDQ28EA7QgA7WnAvnSOPpKwtsWwqTUAqOMAZXXbA9DAdMC5p0wNw09lZ0
9cCUVF6jsUH0FwNx3dYbtEGP/Fc10N0GrAXhrQU4MFCRrG0LDcJYcAWKoAhfgHQp
SASZOE8fMt/BatHHit8bvd/9vQfSISclTU9dYFb5y9ALrW0MjTvTNV2C3kIKXtnH
//ueyMWDlVC98+oKYqDjUXzN1xAM0DAEt30BAyDbm54OAzAAnhDqQ3DiZosOszAL
jbDb0FDN3kzjaRu3pXCOsoDGDcqgZVC8nT2MdWBW0TXWAfdImWTIeCzA2HjdBWXI
7GV4BdxY341B4R0GW+7lm1De5c1Pa8DeSNfe7Y1owjtWh0BPiODmwHrYF23KGs3R
/A0CWoHn2VLZN6ADLAAEM4ADOFAD9k7v9D4D+q7vKjDv+p4FuYN0N0AEiP4Dq1gG
jR6Sy2ANspANk1ANwNDNIE7N7cq96cAADHABDBDqHN/xnhAJDeAJZisMsYAKqK7q
5kDN2/zN0fDFs07cx92ZwP8ojPjGaPqE5DwkL5Ak7EzZ8ySqaT1QWKNgeIrcWKwk
WOF1BNTO0NxY5kh3fIiGewxpXN/uweK+pCBx0R7QwudO5yAwBWDfHL4Q4ERABGgA
7/Ju7yTABCSw9hXQ9iSwBDUA9xXwAm1/7zPAAjyQOy3U3vn5g7I4meXQDNcQC7mg
vdeczSLO4iw+BI5f4gzg+BwfCZRf+ZXfC6oQDbEwCz3d4k2Nzd0M1VTpCoHgCGeM
xpZg64/wCMdVfck3B5PG9G83WGGTDKRRXohM9JqmMoVnuUgvUF0ucG6X12zQ12Nu
Vu3tbuR2NOfWwdpy9dh5OfsQpVyfyvmQ7mAP9snBG3P/Ei3xPgMlsAQk8AK9OQoY
QBopgAGjMLmtORoY8AJ2L/fIMgNbygJXwAWJWqf9CQzPABDYmDGDhu5ZrFizoDET
15BhuIbiPDFg4MmipwaRNHrj2LGXN2GQICkMVxLaSXPY0AWLFU3WS5iBXFkaVLNS
zTJlCOmE08XOFzxrhK7JwuZImDA9mDBpwjRGkxR9ljLpEUZL0qUpmCDVouXI168z
wm6awaYoELRrFH35cgVNFzpmzHCJU1fOXbx3Dx0K0NfvX8CBBQ8mXNjwYcSJFS9m
3NixYX2R5+3rwK/fByr48uUD0XnKZ02hNUlDlOaKDhZAZtRY8uJFihgxpMymTXuD
/5QOG27TxhDjBQkSNWrgwKFHhxlBZSoBgmXKlTNgz5o5hLbLHERxJbWHOwkNYqQh
6SpG8qRxY8dh6YepUjVyl/ft4qBhQxgNVbRouXJNCmRJFxlLHBFwjEFMGcMKQriA
o44vsFjDQTaMuqqHHqRaqg+tlqKwKqSw2rAGr46YQYsZiorwiCyyAIINobDAwi0i
uuiCCy7KiOMROQbBq6a85ODrMSCDFHJIIos0srDIIuNgMno86IeKzPKhxrPP7rlH
tNJaYCEEPYQj4YXYZqNnttt06+BMNOlBM7fZYnviiRdCWYKELLoQpJLldHGllGyA
seYa7CJyaDvuTmqGkmAogf+ml0jEa+BR8yLxRr1hikmvmPZUuQ6+7LC5JphnngkG
1GdygemlSSYpxRVXJnHFwEHK4KKLKxqEcJMjGEGKQqqmompXq7rqasMwamCEkU0i
jBCINdJSa60rrpDRjDiojSOnmqywoiYd8zpEjiPDFXdccstVTJ8AlJxnnsrqsSfK
KUH4bApNrLzSlxZaCAEHRlzrDYPaOpBiAzXV7EDNySY7s+DaZhslhlGeqAEN5SrR
xRRcnHEmm1aeEUgchgYadD5KsKGEklkQQmXlQDARRjyLIM1IUvWKsdlScYYYIiLu
sMHmPZ+xYWm/aIDZbxJUgUm1FAMrKYMONH5ysKhNdE3/SqkNiVVBCxCFxeGqGjrE
4SwXsVDkRTTSlnFGOuiqsYxHuK2JjEHoLuTuQnxE11y++/b778WULGDJg+vBTLN4
5a3yHlY0SaMFHvidswKAZ4tHN90MXnhNNPfx3GB6QpfCA9o8eCGPiivBJWPoqrGm
HPgCbQgaRINJGRVZAqHbijJOOcUUWSiJZICYZz6vUks9MeAC5tPZuTpsYi8IIf1y
iSUX/PLTT2lWm9apizoUWcOso6zelSoKh/OqKxCDiPBr9lHMwkW3vngLLjhorCun
Mrade5AxjIEMdsPb3boBOAQmUIF8S5I+CNekJ1BBCJvpjOKmYCVNcKIFI6ABa1wj
/xsphA50B+McZQiQps0V7GAipE09apCInOBpdRoDhp+ugY1mNIMZJQFZM6pDiUbE
QhZygAMd5gCHSwiCObBYXTZm0YviGU9SHGnA8hLAPCw6rxfa2SE0WHK9Z1jjevqJ
RamKprRslIJpg0hQF75gi/Ed4SqMWMJWitUhLXxNjmHQg7PYsAktMIJEWXjQFW4A
ly7kry47KQNOAAhAMvynbpIkQyEsUYhUpGKBm+RkJxvTwCWxSwrugheVLhgaTuyA
Bkr4EgYqJzrarGmEnENhwURIwjHxYxRrMEMMdYGLUmisGtV4hjJ85p3scGcX72kG
fQphhi4ckRBKhAUTMwaMVv9YIxi8yBlGIBUpT2Axi+nA4s6yM5+DBOMaiDrIM64R
qoOMcT+lgIXTCEEHO4hPEpsA5FW4UqyuiAUHM8AVIa+QB/FlASwzAALa4EKjnPjv
kXUTUN3qFslKFgJAmUyFITz5UZCGtC9JWhdlxvQEKLhDSqbUxBT2sIMT4AAGGcDA
EwimOYHZJnQk7MDlaKNCW96SHrsZnR6uAIfkWMwUwRymNdx5w2aEgxk+XCY0fPiM
QHCBDnAgBCFOUc3VuaJP1iCr9UYCxShqpAHhFKc4E7A854nDHOoMGjZE5TNR0fWd
rVCV9xbUoGZJgnyC1JVXCFqiogTBoGiolfhWZBa1pG3/Lm975BgcQQZHWPayAqKJ
RgFkiVQEwhCo8KhITXvavyVpcPuIgsCe8A4hOCFe85pCKk+wgtZggHSzQVPDpKBb
MbHQt2LCZQhDyI/fYmAJecgfF6owiF9mzHXWUMY1rIuNngVDINy5BioGAQeu3qkS
S91YDbOZC2tgLxu6owUrhhGei0TiUZ4ITxYvkA5yXnEA6ThnOJqBDnM0U7s3fOck
DAQIKwDCnj25wtmGQjXiHKGgKjJRitZgP7gw9goOEooi3DKjGzWSW6YQUIkFhFlL
DDAQKybHyiCBCdTGWMbhUi0H9nHC2aBUCO1IHCdeelsYvOAJrxSYmmgTAzgJeciV
/zMuxML0U9GBbjYegJMkEgmHaw2iOdJ13VOj57OE+NBT0SCDggixHCa6YrrTbQVf
UTEJMsThCyowQQk4UYxGOa88j1rrANp6AQas1QBwNWdJ0HHDZ0TDETrpale5kKAi
ooFBDhYKEFJUlBSZZVmWJuQXbkAHOsgobQc1W7Ticq1GmgK6mHWEK0oMIAGtOBAr
iwUqRALjGeda159MEgQ8l9MnhEIUoMjBN0Cwhz1sAcgvYDIujewBJP8GBtPOgGuG
7DAmjELbwRXhmJo0ppq+IAtoMHMclApMYTrVndGjBEK0CypUOOIRXD0FIGZIzFBt
L1WyKIUVvACEFHhgAxrggP8JduCPXoQnHRbRyEWa1zyKXGDQBsCvfEolizEQgqvg
Ba+C1laHOtiB1GWzBYf3SUgHSUIoZgGCIu73g1CDugtq68Jc4nCXSWrWxCVe8UtW
ZmuRiGTXQyc6YRo4mX2EjspxUsInprGFLSDBBSsIcpg2sKZ45PS3cIJBCZSwArBP
e6ZCrikGRhHLW055NjXNAA6usNWdPOImGBPmdMvxqU9BIhbowEYuCnGIGt0JEOTt
sjJKtbRSjOEHOiDB1YssBRkU/ASaKEZ4DDCAjKzVIn8GNPMGfYEh7IIMcJjDGzju
gzmIGuRtqUOtvqAI2CMU9inv8Oz1CQQdfLhtoJaLXNr/RiM59A+Am925rAMhi5+j
AiEiYU/Rnf98JSHgc/yox5uEnYQkIIEGKAhyb0J4dc2Nae0YeMG0lUCD7YMdBWAv
QQaGHAPgFkwC/BB/2d/0BBx8AbzTxBOe6J5udfuiaCiZYCgENaiTKvgqJnKGYWoF
/eCrzLICLriCGcCAq0u60NkA+JMCDrAAEtiDWvCGdKC48pAvTyAnzvO85ekFVCCi
OXhBGQG51qsV14O9s/GwRLiCHHQQMPAwt5hBB8HBtemCGCGCU6sLVJODbfkPMeA5
R5C1SaA1hEiIWdiFWVCF58vCXVOtX6O+eniHUFACJSCOErA23qIlI5OCaFsCGFgB
/xRIAvRbvxIoAfbrvoCRMg9wpRdYgmpjBEWgg2kSr0p4hOiqO7Jqp5aYBfoIBETY
BEmgg3qjO2AYJu5xhUFAAx1YgxmoAJ46kw3ojdjYQA7ggAlwAV+ovEGLGQbAolX8
s7cCAAPwBFUohDmwgzsQOba4gp9gi7awQYSKFmA8mzyQFqgJNTRokCuog7RZRjSQ
ix9AQt7ZkQEysZ5DPilcvlnIxubTQm5ErSRxgC6sh36wByhYAuGooyejJRLijfJr
wzeEQxrAPiWAASigwxKww90CvybZuvKrARjQA1tADkEQrzHAky0zRKdSGUiYj2iQ
gzRwuTJgDi6rBmDAuEGIA/8dqAHY2AAb8xxfU0cIgIAHgIBRhIAPZAVvgEVyWh5A
izhxEo8LSACVFIZUQAM8uIO1WMaZ0zAa5MllXAWdlLmZgz23iBZmlAskjAO5oahY
CwSkQT79UL4pzMYrFAYs7EasBCku9Bx+iIB+gAIogIHWYIIwUcfNaZNggwElWD/s
QwG3dMsS+JKuozoSGLLdkoCByUPyK78SwIEVsDJB8B08GTz/QzcGtIZlICv72Ltm
uIYhSoQ8oAOJZKpfoEhTkAMzwAJO3AdRigEmCAVkWAJGqAEl0INjaY0noIdR/AsI
EIIpGAaJc6sEYIAruiLZNAAAuIBeYIVEwAM7qIMZcTT/qEGDREgbZbyfuICm+xE1
n3wLIlAbuaCLa1FCAaoknluxKPy5loiFkajCXRAG8MxK8eSkBvK1feAHyyDHUAAT
2XA8zqQMzjmpUDC/FVAC7MO++nRDFFAC98uArqO2JeONvew6MVxL5grMU/A/VRsv
1pnE6cqFldkF/3qGcXiERPhDa2LAZViGbBgDLggfNkCKY5kBlXsQs/kCO/hN5lyF
0kgDYtiBaQAFKIgNFOCESMjNtqLNVhQnBvAz3LyASICEQogmOOgfG+ECoEQDIliF
mmsbM4gLY/SCLvACDXs9GJmL5IwDurgLEWM1noOJlbEPW6PKZQJPXvCG8UxTBDo6
/65Mzw+4NtxAk3VhFzQ5oTF5gRI4AR44AReIx/tEAVEIS7iEgSfwTzqcqWtzJTgh
ga7zOuLAgSTIA6+qN+ZYqoL8v6ZKL/sgCWywBlmwUFu4hAUcpktcg03AI35KFjVQ
AzzAAyxA0d+cgzo4oiLaKuUQIEsALW4wBENAxbayTVZMQdy8PFVIhTi4BEJ4hEcg
hDhgUjMAylWIkZljTp6Mlthzi7mwFrvonxy5qCd0BEtAmuy0HioMBuswB3PghV74
CDVtVwYiKc95AMv4gA8gHTSJgjllFxOSJdNJghHYAYBdhB0YAR5AAhwowydoQ6rL
AIalNiULtz2cw/osUDe8gv/ANEg9AQZTGK9gqiHX4atoCAYdgoZrUDQL/YI4wIVq
uAVdUISj8IoISVV+YoNVbVUXgdVZndUjktUri8ibIINACNlwGMEU5NE/a8XP6wVu
gCYFWYVojVZm1MmZS0Zg1LD74QKbqwve8R+6YTXjs0Zay8ZdwIZ05QV1VdczcFe1
HZckQQBfowd+8IB68ADNKamEOZPWik/TWQEa0FMeGIEWMIIN4j4h808UaD+GZViy
Kz//ND8xnEPI5QM08CqDXKpqcIWLCSYGpMhJiAYJ3SG7igZdMINESIRKcIZfgIU7
0II+aN0wOAI2sAU4wgM1oNma/YI7gFVZ1dmdfUG4iyH/KzCFWcMGccAvLEoA5M1R
2jxaz7sAXkiFVaCDVcDFtgBGt5C0tGmL4lTSIkRKt7k5K+jW/3lCMXDK7ESIbDRX
dBWGcFhX90XTtY3fIQGleEXPul0SCEgYfKXTgwmhg7mNaCOBOaSBETCCxzmBIEMp
OlwB97u/AX3LAh1U14ABGqAYwXMOV8AmV0A3SpSFaMChkmimRBvdRFgFU7gFXJgD
PDjVUSAFeogHduiDTVCLO6Ddm0VRkHvBF1yQIxKE1CsipEoO4XOESZgFc8gZhYvN
os1RH10eYTiEUVMEHbjWXMzBOkiEtkCDVaAWatGfujADOQBfbtGo65w1qZyFUdkF
/0UxW3Vt33WFX/mNY17TBwcogM+533lYklC62zOpDd0oHQ/Iw9nIgBVoAU5IgxFg
4EK1R5qqqRyDARTgATAYAYLlgXi8xyF7ARpYhaQaL+fwk1ZglT6pSFmQjhAW4Ul4
pjpYhYwRhDq4AzUIA2QYBXZghxhgh1FAhk1QBDtYVU+TwTlAPaQihB0uojkANfCC
G6exGCLOBXPlBewYAoljSbeKybZaOAYYtGKAPThykaHAAtmr3rQ5NRv5Yum0i24d
II2SNVmIQnJFY5N5D2g2W3FwX3aVY3xOjAayY8/xnDyeBwfggMFZEs5ck9baDYAJ
ZN2CNtz4tSdwgXwZARSAAv84CUvFfQLSeRNIHgEW+FeAHVgagAEMqD4+6IKcuBMS
m4RseidTyZ27iYVryCGfeSfRXYVEoANcMIVLqEVb4CekQAagRgZ5IAU2iBpeLuZj
9gGkOgXwotVj3r87SdCLcYRSmATrMZlwgOZeyBmJS96iTV5pbgBV8AJffD0HcREf
fAtrSdZH+OLoDGMlHIRCYMp2jsIpjIVROZmyNduttmeOyGfARpJey1/OHEWBPmyC
Lqm8XceGEWRXioEO6GcMgAEXsOT2exMlW0/7K7+13D4a4IEdCFwWQAFmy4BHTKoC
ESv0cqd42oY0OIRcuCEcsi5PlQObvgRTYOoXtANbqF3/ZXHEMHiHTViFncYfQeC4
IH6FrhpIQYA7LFMiPBkDU3AOq7Ye7eoOaEhXiBhB5AVWcbKiaUYFOxjnJ13Gqq25
c0ZC6dQfzxqEXH1Cn0MFCHW3RDkJsy0Je/brwN5vwEgSDkCAeSgAkuQA/1YXkixo
Nvkp4/ItV2poyoiAxnW/0bk/CoeThp2TOVkBHmiBNNgB7vNPHeCCOymQT1a3dkIF
X2ABRECFayiHmb4GT9UFm6YDORCES7jx6X0jNZBd2ZUESVAEryIEZA3ErjqFwBwD
QFAiJM+JZd0J5oAuEmsVd8Zrc12Jg8gPSNiF4h207k7BBGgELT1nL37S6KwLZU3K
/5vb0ppY5+N7M6lE35PpDmh244Z434+AY/4O7H0mcAIv8FEsgHnI3zltreRq8Mc+
Q8pwJQ/oAALgSioDLrTEbGnLACiwNkV/ghIIbYl2PxjIA3NjZlbxE3VDiEIAA0ZA
hEl4KusKI1kYhFXYsD88hUuQ9RyHvS8oXdlNhEeoJiO/WAUbPHujJ4zJaVgoyEEA
BMuKcqqu62iYSqqsNVQIhMsKhFko3tj07mnehUFQ1kdQDriRuzPXVm29kZsD37kG
WqeUb3LF66oqWzrv6/z+iGHI8/1uIAey9z23MaSjDEJ3JX+vqQq4tsjeh+TagH2Q
PnqIDUGuBym4P9do3C+xy/9ApofJPoGYqoAY8IAMyARzk+5Qz6ZQSS9ZQIQgS4NU
V/UwygZXX4MeeIFEeAWYl/XdXWWnLd1VGK9qAoQEBQSeZ9Bg2mA1WhWmMYX/EBAM
dsp2VvcpbPalX5mZcARUaARrn7jZTIAhQAVd0AUd2fodkYO2NgMcQUIcuYuxp6hZ
sx7rmQVRiXNoYOO+rud69us7x3N6j2N8x3c+H8VA59/eIpgFJ51ww4AOkL4OcCU1
gU92bFixgwFGrTZFF5M8zAASoCncoIcnUIS4uZhQJ6uy8jse+K08kAXDgydW1wU6
yILW+gKYh3kcJ+4bv4RnNYPoMgVY4PlKtaZSqIZV6ZP/qgaGUhAQVnEFMdiT43uJ
6iGju77rMMoFvoptiKgviqMERyAxmtCRue7WMEZnHRn7HNkRSzh7vEbjkwGik8jq
LYp3v+6ISal7fL77u9d7QaeM34I/+Gtw/43swneNgad4DAAIeh327ZPg4eATEiVK
oFCipAQOJTBIYMBAT4oUCRc9VLTYoQOCUYnKVDKFyxWwXNaesWyVywuJDk/AWLJm
k+WzVq4GdZkxb18mWEJhvTp16RKhS4906Xo0SFepUrhMUQVkSoyYqKWqASsFLGXK
Sa4mTSoVSBZasqhyrc0V7W2uWCxnPQt2LZjda9eeWcuV6xmlcOKCoXIlK5ArR5Yc
/ynWVUjOoMdyHskhE3kQ5siFLFkKhCpWLLzBsGGDZppXOMHieolb7boXbG+yvQ2j
HeA27ty6d/Pu7fs38ODChxMvbvx4bn3K9SVfro9DAQ7zIMz7ua/DhhgdMaTA8OIF
hg3zEOyjl6HChoEdDnr4+FEKvYsVXpCov7DEChQlYgjssJGjB/AR0EEU9ICzylOm
GAZMNSvx1YolLFDA0SKFtGLTStYA44ouaOBADwR6VCIULrgQVckpr4yIC1MoOTMV
VVSdFBWDX7XiUi6tREMWWbJM4qNfbAUZDVvRgHZkXaLNQhdLsbhFZFqo/CjLjoad
pVghkmG2GWeWZJlKIJ6BFv8MJZSYEw40jfCyJi+wwbaam25608tswwxTDHJ56rkn
n336medyuDm3HAeFSrfPT9a51wFGHsQQQ31SDHTdExW09xF7EvgX30cCSbGBFBxV
BAMKKFjEDz38iBoqRq0yAQYhlehyUjbA3GRTLohQ9MQLWRxi660bVnJFDQMxYYaJ
zrw4FInZZDNONq04E5UYCmr1FTAuXahtLpMQ6dda34IWZFx+GXkkus+Myxa6QTrp
lrmxEInKjj6OEyZnm20WJpiofBbLLGSellqbb7IWp5yz0WZnMXj++TDEEUs8MW/M
DcrBcz8xGqB7/XX8UQUlVDBpBxhQ1OlBn4qKQQwYxSf/6UfX0QNDCCQ0elGrrGIU
AyOJPLJirQ3yZQ2EYHxXHw1mRIuhNZPowsUaLzzBsiSz4qKssiXiUquG2HZViiuu
eJUt0yyppKNafjl5pFvoug2augA/M4u8ayN599t5x4IKWofhG6a/RwbcCDQEF9wa
4gjHNqdsdt7ZMMWRSz455b1ZTGjG0q0HAwxLeP4deC1POo8HMLww6T5SgIdqpy9j
MN9822EgRRQE7YOBfhgE+OmincokCR0/KxhtNRfaJIsXOLwQSgYvHJMHGdU0aE01
pQxyxQwkvLAECUvkUYqyXEn/1fQ2iQ/Mj2SRjZPZOZL7mbp0ofsv3HUlKRr+SwaM
//9deNF9ZDDU1aQA/s9t/jogaJa0izJBAzXheJM4IuEmOCXMG2dwHMMwwYrKcbCD
HtSTxQJwsXkcah70eIJDSkUDGiShVDhYwgZsJ4UM2Mw9UqgI6zyGs4v8xzsY6EAB
flI6GEwtZfE5okDmMYo1cEFWJ/lKX/oCjG2woAQZuOITUoADL5TiF0TLBhnQkIUS
wKAENZhIDfKAi1vcgmkZwlCOboS+lPzlGXvBid1aga78BVBu+CMgXq5BmtKYxhyD
PKRo5BKMJeVvf/ujxC5msUBGBmMXkdSfJdUUjsO9SYIIm80ZLug4TBiCFoi4wgdT
qcpVJuc2F9OHxt6jOhisIP8/K+QBLnmAgxSgzmTtKchGNuCBqekOI/4hwIDcs4HX
xZA89Hgdy1gWKvZUhHah+EKsdIESBlHvK8irARS+Q80kIMISk3CEHPKQhSXch3MZ
mB0ffqWMeTqIJW4kml/YZz+54A1gZMJGmchUpjL1zy6iwcZoCGmawqUGGgAlzSIp
6T/8QRIdloRkmTJJiUY0YqMX3UUjzLGmXjxQcYuzYCjtpApIlNILadABTJnDypnS
VHKXI1R1ZNaoYb4gA5yDgRJOkMuakcxkP2ydBG5IH/o0bzsCIQCiPGAz6/Cjdx1I
as4q8gI9oGFFY4titwqhAxzAQHeo4ocUnrACFuQhEzT/ICs7yWi6J3iAHhLAAB98
kYpYzFMZ+sRJPXGyF/yh46DNYAZiE6tYZjTDodjYBZkOSgmFhqMZll0oNCaLUD5W
spKWTBM0zGGaBZqjtLswR0jNIQxLCkMYbGpTweR0BguiVBgrrQUt0nAFmPJWBzX9
LXD9JNNBwZIjT5jacZP7hA984AXNTcIIFsEDGpCAHtdZTwaeIJD+eEoK2okB6I52
un2QpwPggU+oOEWPDXDqI1FglMkkwQWrXI18UgzEFVa4ArryQ1UR8IBP21lGzn1H
dwHyQASaywgwSGOvennwHQP4x9FMFhqWTSwlIKHBInBiD9/YwQ44oQlWqAKxliWN
/2YHaZrUsLihpkHHIPGywIxC1pIgTdNpQ5vaRpy2EcLwMS983NqR9oJNFuSFN1xr
W1Ka8qW91QELsMCC4FK5ysQZrnM09wQoQEEItVxBEmoZTgN7QAlgiC4PSiCF63oA
PP/xLnyQiLNQlRED47lOBYopuxiM4lHG1BikwCAIWNQ3JX2pnhdqEAFaluDAGGCu
T4HqEIl8JwYHrgcGrrgCJLRgD0bwhTSKYIgxCdKypj7sYpmxC0iwQhrfEMUGNKAB
4jKHAzEYAS0gYWIUL7TFqREHizObWRQvsDSTvShoF8rR0KLWxs7exZCVvCbaupYX
qiBlEaThhRY8GaYsYAEQvv9t5XGTu2JZ5sB1N7JlL58ACVv4xglegOB+QEEJKwwB
Dtqz3QDR4wNl1F7oWuWx26FgZATBGaiiyTJeeedk5CHdC+RboqDZpBWTgAlBJMCQ
DHzgipzLTxJoIFQaEJE9B+k4DNwxgj1oogguf7nLc2sEI6TBF7SgRRFYQQtfcIIT
O6DBCzRwGwc4AAEIKIDRC4B0BzxgHxCAgHI2gARNNKIZm/w14rLu4oWiFrPIJhxo
OWqOHNtYkvpTxS5UgfYztLYXoVxTI65dhDQY4cksgPK3w633cJe77+S+HLqv65+N
IeS4UHABJ4zQ6OX+FwO8stRHqgofjtBHIQupz0RmR57/ffDDdB0ggF2PuKmXtUqq
4yUPRxhxhUF4pXh9mcQhZjCBo3cgAyvgnJdVeIIThHwEOxACmT3wASiswAVb2AMn
fKH8lsNcEy3IQAcgMAENRKH6E8AYlguAqJwG8ekQcPr3tR+z5/BA11k/f0PHTrhl
e92iz36/syEBiVnIX/5qv3+1z6D2WhTBF3XvNkwBgZR9W94BgQH6HQJSmXM803F9
wHFJTXINk0V8APKhQD10HF3RQ3u0RzJ1QH+pSqtYWqb1FA6gQAoQhH/Uh1aBjjTd
UF3FzO3AgAeg4DNhwBJIghfIwWIUAiLoQAgwAUiUBwbAQPP8FAyIgigoAcetwA6c
/4Du1MNyZYAQGN/xGUELjMAIGAHzvRwnoEB2Od4HVMQM2g4ZliF5jYfSWYfgJRU9
TAAKGAJDARuwrQlqiZZI2SGbONvYwd+z0V/9/WH9rdS18Z8m+F8LHCIi6gC3gQEB
gpsBPmIWsEAWJCAl0hROrUc9+JQQOIELuEAO8F4oeEA9CB/y8QCkoVwGeABUbUAG
mBF4PMHNgB7HbAAMnAAJ2A4BPBrlVV59aA/31BBBzNAPXceBqcoTLAEKvFUM0CIM
xNADaGDzfMcSQAEMHEMowOI+eEAOIEEqLleXOcEnuBsWuoAQZEAO+ALMcRg3Ltco
rtdAJAqixKMaTof2aZ/tdP/AA6DMEJIACxTBLIQWL6jWkL0WL1RbQUIba7WWQtpW
2i0J2i2J/KECJPhL/RkCIfJczyXezHXCzHHbIjbiI+pdFoRAFkxiJZ6kBzlHTqWb
KPrbCuTAHuyBEzLXB+SAz2UAl0GBE4xAzYSHFKwADYRAqejHQkzECwiITJxACeBj
qhyYd1macYFOCZ7gwXWcdihXeM3OQBxABJTACxDAMLFTCa4QH/DAIgDdPhwAPQjB
CUBBpsGAEIACKCQBXcolDDAXE/ZcTBrBDrjAB4ziL5mhYBLEw5Fhx8QHeAXVDnCb
FmKCmryWm7DJQk4mZa4W2qndLKyUhpESJmACS/FcTMb/ZIclnqdZ4SFmwmIy4t7p
HUmWZEmGAErGZuVkzD1uSqMcV119w01CGuLtAQxwmRB4WfOkjFaRQBkNJQ3wQAi8
AArWAwqsgOOFF3jIgzwInAdoBAlQ1wMcwHrQx30shBLggHgG5QvY1e2Q0RPAQBKY
JRgsZidIVwvswAvwAwJ0Hjm6pFwiwTRswSeAgihAAcoJwYDVEhEeBOoY3WCSIXVs
XrrZpsmgAA+0gBHkARhkwRHwgCZgAmwgmWsl2UKeQUHa1odS5mVq5h+GEit02A6E
JovO3B50wg6gZguAwSKwAA9kwY26Jg8AwUhmwQzMgB7IppBSjHKw2TANHxQ0z9TU
/0ME0EMOTMEerMDwSWHPoQAVUAFzzdUo0BV8oMpBbOmW8cAO4IAHHkQZvQBQlaCa
3gf3YIBGyIR+SAEB8IN38CLnlIASrEAJ8AAYoMB1aiBQJQESLEKMzhxfJoEo5MA3
wECq8AMVcKJcTsMibEGI+cI3OAEVCEGSvhM/SICnSkCnwmCCmiF5UAcNdkqoPMGe
7kBH2ugKiScYZKgwzMasysa0WdAwsF1KCcMF6d/9CaLaFYMqhNIZaMIegFhMdlqy
ghizglh7SteN0sAMhMC0zkCPZsFbieeQbuvDqGR5CJ89bGIO5EASPEGCZQA+9JwL
dFmXIZ9fPsEGQAEurVBDlP+A51yjPHCERiTBz2GAqgxTdvEKDXHOQyQjD1SRpNBD
PZQAddUpfSxBKEBBKITCEvzmB5TACJzAE2SiEiBBe3IkMaSBS2VCEhDRCmxBEowi
FLgbiHWCy+7AInBCiroAPmjqFdWVy/THqCbo9wleqvjHDYUCCiyChM6oJPDBCiVn
FujBDMRqLahCwShMkmEQ1WKQsKrCnajC1RZDLfgcpVIqiH3D1+6A2G4BmiEBDyAt
DeiBeOoB07ItkK6teNYAt9btnpybxmzEB3zCHmyBlOZkz51ApgZnDozAO2mV7uXS
UCmPRZTZDixncx1XRWys4z0gDTEBv4ZADPADFJYAvon/pxLQZdLiEh/8ZgaIgu+h
ACiwKjEonxf4QhqkQfJ1ghBQARSIwhb4rRMgwQ5w5MxlAhjwwclqAifkgBOUY5J2
HJdxzD48486SIQJ8n+/0h0EMIe/+7iIgbRIg7Y2a5SJIAhCAgS9oQi3UxsJY7eMU
A9Wqb8MUAybUAvyygi9sARIgwQjk7n7mrrtNQ+Gibf3SAB/wAV2CrnjObQHPbQ3Q
rd0u8JXhlBoCrUBQAQhcqj1wmT2AgCZswSYer5IOE24eF05CAZ5CaHyaigf0AwyM
AA8A5XQlAdtGBCPUAPdIzajsAA9AAQjTUqnowS0RKhhIqBGEWaTOXOsqXxoQAxK/
/+cWdBgSuAPhbsGkLsI5nEOMwuw2eiInTAE1BCfyHt4IOIF2WRdU7cMYP6/MaOCn
YESmJQHRWiEYTBcLBXAAS9ci0CgYMCIYdIIvsEItsG/7/jEg+0Mx+EMtsMI9aAIi
+0ILuICgIsEnhCMk168jP/IjMzJdJsGkKUEMJ7AMc7LnyPASMLAoB4dyQEfeimJd
aaAHXPAe5ECX1e4IGCsHYwBQPudEkIByNeA7wcBikhyXSRqphEDShoDi4pLy9BQM
iCkKoKlchacSlGV73vEOIDHK6ifrGmoLdMI5SNcneCLybUE7zOWgLsIiSOqk8oAj
I0EOdOI3Hy8MDK4TOAEUVP/VRzwj6jzvz7oMRvibmLrxjfJw0sqxWXpvFGeCQXdC
6yIyIfuDP9zDPTA0Qzs0IieyERvBCIDDCsxlJ3ZiEnTzJSfBXNYlKOSpEiQhGXkO
Sqf0EmzPd4yyS1tOKctMS+JwS9oDNezBCHDxFEKpFQ0TdI1Ae9rodDWE6YhTBiyC
EfAAEV6RdG7PnS4ECvwwGFhRCYgC79JAeCaj2uKSJDAiObMqJ7znpO7ANpOzdEkq
f4LCI3+Dh/WnMdTvNEwDD0wDEry1JH9CmFEDJ3wDOep0KtLDnH5ezGzX4JXxPSLR
TmUAdDmrJMitCyctAMtxWZo1FU9xJkzxObhshyGxiCH/8hRgJDG8qMtmwha4ABLW
klyOdGqvNihk9AqUtEMgIedQ7ErXNvesNBMwwQvk9kv3dnPA0sGBK5fVQz8wF0x+
wwpssBOcQFlBmk8VbA8vpg0vAQbUw8ry5Qm4AAowAg4sRG0/bMV2Dw/wJVnV0nrm
EjnfcR2DWCaQ8ze8LMzKNS4hQQDTpTHENV5/Qg7o7ycYwyfwgTHwAX3btTpXsguA
ggvsAQgYLz5g6gfUFT/kY1XRgz0HNj9ch2G+DM6qMQzQgA8PdUQ0BF3qwUcHeADH
tVmneFmfg6Seg25yAgjE5Ht/w4dR8VkqwRIgoRCctpeddi0l4Y6LwhH+FJeFwvKE
/5du77aSj0KfxYBvP7krPUd8gKvtLlcF44OCu0A8B6fEXuMTYNEVXZEIw0AoLGYL
AF1wnoAN8+kOtCezQutbOQRc0sBi8oAlJ2NyluV04VIWEG0nvBtbQ3Ha1rdIq/Yn
TMMj54BHG4N9G4OjJ4F/66eiu0A3H68T0Dg1bPmDewCqpIqnVxU9CwQ9o8zu5AwK
udsbx3kmg4NDpLYSgMMlqwOkP3Jc17qtSypb07jYngMU6yd9YzLnCLmQw6WwB7ls
D3tO5qSRg84TgGmzNzuTNzlGQPmTLwfngaumMlcFU0FM5oCmYoATgJgKY7USdHnn
+BQUjMIJhDUP5KkLvHZE5P8HnuOS73UkGLDQ9vbuImAyDkB2AOc592Y22W7BNAQw
Xof0q4MDq8dlOCK6E4x0EsB6SMtlR0PyJzx8PB+vEMAkNeSDENjDX9ZDPajKB36g
pzvvpoBgyrQKFICCpCJBnA85SSNhEjqEEICDKCj8aqsDzzu6oz+yOkwDNQw9NSC6
gTM6Jhu5mOdkCP+y0ye7kU8sDufycTX5o0RTy7QKtb/0Tc0D536APcCDEIC9PWTq
BEtpdonCCdxv784ciEkXyaEpDLjAzO27C0jET4HnpGFy6O5BGnQCH7gA2oItHZMz
LsF9WQbwFvz5pAowJrt6q4O0O6R2N/tnzSvBSL/6XFL/cuWDtFyuwPHudw64Q06+
gwP2A2CyR3zwg1rq1DRV5+SlZyPzPeegtLD/FM3nfs7r/Go/fGq3w6EDvayDAyiw
OquLQjRG4wsk75EvP/MU+fLwyjsErHLVgzzMTtZLAeznzLRvvUtnmcJ+wOBCQdlz
OccxF5ehqRJ4WSdOw4oSA19+mQt0Aie0AKXyadq6sB6kEAoARBI9SZJ0MmKEB5It
fPjwcPjQ4aKIEhVu2YIkCTglG0UpgSEKRkhw4FYIAQVqBSiQID8K6agEVJJPn04m
OXnTSU4nLpyoFPITij17H4jWM+rBAz9+HfbRo4fUqBQp8qTUe6EECUYlS5aE8roE
/wrLJTCgfFwZVpTLn+7cgWKrkm1bdWzBuRR1F2+oJ3v3vvjAl689wIMJ743hQQoG
qYsZS3HawWkAyZMpV7Z8GXNmzZs5d/b8GXRozfpIl+Ywr4OHD/Co2IMC5e+H1zAy
ZHgNRUhIJaJC8TDCyQgNFzmQLNrCY9GOFgYPNt+xQ+IJhTsO7thCgyAN7En40NDj
XUmSrNMUTkuycffKj2TLrv2ZG0qosmVDfrx5/+SKlCvc7ex5kq334HltqHf2qgcp
p57yYC+k5EHsCRhiOo+lUDKQT7744svwNvbw+tAdvOwK8cO7QprvhScwUBGDFfdy
sTC+XFyxRcQQa2wxyHTsYP9H0Xz8EcgghRwStNL04aAACOaBYB8eF/QAiqxoQMKF
JFBYQZQV0NMPChf2AG6REUbACAUUwiszCRd4GIGFLYwgxojnLPqmk04W6Y6PrPhI
YjuCzhNvPJte0shEUebDTS0hbvPqNQ7Tumk/lIRwZ1JQdALnUVBMcus9Q187ECkP
6nnxxqoiJMgj2zjM4IUXQnkhPlhve20d9m6DRwh4dIVHgF0HnFXD+FT04LDDnqin
RgSRavEJUUWtEanFSkWMHqno4XHHKDrQdp955iES3HDFHVdcIzlwADUdr+VHVFhX
kKmi555bJIm0hPCSkzS2GFO6JIzxkyAXwBEIq+aM2+H/m3mRW0SihBjakyBQZnLh
pLTuys1Wi4FttFWi+MrQ4vdEfi8lJ/TbKCX8KLWXrL9G/etYeaJKDIqUPHoN1lb9
egLDC3PGML53CIRCgNuEGjqoYF+10MAnqJIi2lCjhloqqUOlWtocr8XWyW237bZb
bzkgl+yyzT57MiP1KWAefhC8dsFR9yKqrBX4yGGLPeKkeKZvgFuuzk7mbRgJPoxh
qDi9BbcII2NoMBxgPzGySZ2TlHDpNllte8E2YIV6IkXA3slAaCh+fe3iREf+SYmU
8eOPZcGeIPDYo6SKsHVDLeSZ5w/eecHApZ8Q7B2YDfT9nXeEWp555ZuO8UGoS21s
//rpcVSQ66235tHbsOcBmwPS0B6f/PJDU5uDJq8NVe7YZt/4G723wHuEfUdI7rnm
DtLbCDuR22IRBhEcDwAGDlCMRAmY0o0LjHGSntQnc69yFc8meBuYxeh9G5sNDFzC
QZZYTBT5uclIUBIiRXXuNb6LyoMiJIQVwKBVT3ge6ADjPgw+wYa+02HxCjMqBDnG
KdZ6ioIe4yQgqkt7XNsR177XPW8pSWwFCJ8+zFdFK14xAGpb0vfoMapbqQckwNoC
J/ZwkYtgJCZV8pMLtIMEHnwpTsbZwjfiWDjE+UkjHHmUE2ACn0NlwDVQKF4odggz
BCHoWIP5S/GKp0FbzUYtu/9pHabqkiUsJQ03VAgKqLwYFhi8aoY3HIxR5EbKuc2N
lD5MpbOihT0lKhFu2ZPlKzuQLm+hpolbXNKR1IZFX/6SbOiT4j6awiB7wCMlLvhE
VqgUEiE4YRpw+sYWyJMVF6iRYhEDxVZ2oDfrbME61gkTM/MEsG3ypyQdBFYM5waF
FPGQk8dylin58oEUkU6Gt1EUsE5klhCq5WKemg2BXFYPeWRQZ6I8kFFqR0oGpbKh
qTyKsq62mCJ2LYm01GgtuQe2XHp0HhwQaUjDV4BeYkYLWohCAPqgBTxwRgsstcxK
gfmjJghJC2rQDBWosI8A+JQfRVKbkogJmaeMyjbPrIj/ppS6hz0I7qlOrZOcFlG4
iCUhb3ESZ58mdJ7dmIQmWCoJez6gl74oEgqndKjMPPAgmSGSMDrE4W1sI8PZcWhW
ZGnJPlE3IAEMpaFPsE0GBkMjFR2WWBioR1VEdRQWIguyUJGoVH54o2pdlAD7yGyT
mILLbtWySU0E6WhFexolQUCkECjAapGkNipqxg+xle0cxEeZPuCBprF1Q20lc4eX
BuAOf/iDTslHU8k0IQpzuMMdKtMELfTBuWp4w29/dIfYviEKr62MP/yRj31wdwq8
5Yy5RGtUtzF0L5+wCE+cMBO8IQFvzwmcU/cAp07wYCZZ6cQerEPAmOSndXoMyznx
/wKFC8EmFIA90Chrh5jouRUxBoUKBj9AWMIES4O3Kd2smkbKDyiYRg5q64ghHL3F
imoqV2Plg6wGtcsSEXvbw6UTPUpaGhM1fablwGlPgyQphm+KUyzNZvTRBtnG9g77
qG1yY9uGZHAgtnZQsnbf4Ic5RMG6fmDCPLRrtjfMgQ1sqLI+rmvSyWjhyLE9Apd9
1IQjz8HMkqHCFKjB3XtMgbsgULJQ9fE9zjrlvC97Qj/cQY0tUKy9FHNdTq6ZlYSM
kRg7yMr94gedquoJYFoqVMUumSG73pCUlH3aZaH2IGRRhX3oRS8Gj7cXe3Quhp2r
a+0SGTqDVg3Ch0RxqarVVv/HeKBaT/M1P+QBY0A/xpXErLFoSxtSHu8Y2lAcqUh7
HFIuA7mkrhVvZsjshy/oQQlfyAI/9hyAORzZyLFVA7lfq48/+KEN8rBuG/jxgC6X
rcqy/UMHkMyPOLs5zYywt4/wcOR9a5cK3FU4nv0BAnZjBgQgCG/aeMnFo34YsPX4
sBAM/YlEU0wdOTkJxZT5CReswAlf2sGYqAlOi1hkEdU0RlYaaC8XsmRDoeOLxnc+
WXo8zTHSgrD0qCIPVPsQaokc1UFPecEavs/ptAbMUSJM4qlcnVpVcXHQiciPYxsb
blsjAI+UHbZld6vHphVbtdmOWim+nZdANqlptO2ZHqT/2Q/jLneUsyxbIUSg3GyI
LR4iYN039MPf91aKZvDRj8n0AwSjyfd1+xHbLzw8AAXA+wf4webQVPkNfIgt4F+b
cIU3/B4N1/O95YznKUw5i+QtZj06NxTXCCEH1MjBNOb4Dd8nbJrURIIxKAYKF8Sv
E8IfvkwihxID+mubNxfoqww5UYlWtGpBTxCwcS0VqijL6COW8A8PCVGFLpShH1ir
r72ftSH+Goi9VhAQ42/srkGmScq+pdnTLtIkSfHajuTtkIQA1ybueMm1hMy1PkML
7qANJs8PoODh0MwPYEAR4O3c2sAe6qHczu0N7KEfPHAO1MABKiMfuCsfWE8y8OzO
/1Lv9VQwi95ttuwhtiShH8oNyqzMDmKLCvgBATYjpipDH9zA26ggtvqBAF4LH07v
HkAg9bhr4AKAp/LBCacAzxyu3EqjANDle3ikHlzD9l6jUnLiE/BmTuiEvrbA48pw
C4ihE0aAPGbuqu4jRKBgYFTCRF5DaGClw44FaiaqrajixSzq2OKP66ol+xARa6iG
xRzKalREbtDv+mSm1G6EWoII2OYviMDO/mLp/jLrlvZPbLbo/1jLpFpr7rSNNBSQ
7lTRSLIIFjtjB/+gytxAEb4A8QpAMmTgutLtunpQFwMA4D6wHyZvE8otAPjh9KiB
9fSB4RROz+JMCP+gDizvDf/yTQlu8LXCILaEAB9iyx74YWzOzA2W6w7eoA1oq8uK
zMok4Qj5gYr0AR9YMPWWUOE8YM9Or+Gu0Lvi0TSS5Hsy6wth48NMR1f2qCfaweTg
K2/24BtyYCbU66lebhp4jzw+IWICalOwRJ1SCDYMhJRKTFo4URPBrv6cAtgyURHn
rzGKTlSOztRuLcKyD/4O0RDBzqhiDJZ2ZOyUrbM8Skl2bABbS6QQ8ACBzChdUSnF
Bwa5jQjxzsoggDQK4CnT7AP5oQQDYPIkIQKqUgk6oN1A4PReUAifUOGoQRsvQx/2
YQfdAB92EBzJ7cxiSxHWwA/egPO6jAKbzA/uwPMkQx//8s3I/iAvJeO7/AEfUq/O
/MEKtdEZl/EZxdFc+uw0iooeZKN4XIMKJsUJ4sJSdmImeoKOyij3psHQrCP4Wo6a
LhJT3qNiwqhRfkcSEcStSo3UOFECSNLYTnI3b5NqfO0lj8pG2K+LXqw3jfOikC3s
eGTsCIAecKmzQjEU024ApcgAWXEps9MVY1E09OEI2MAO6sANqjLJ4lEN0q0O+IAI
66AfHmBsBE+23qAeYmsOCDPxssgFXQ/zJCMCpiAfqMEJ/QEtkZEy1rLK2sAdzi0u
4+wIrNIeDmAcJWMvZUvvtEsfFDTKEO+1CiDPUu8E/YEKGs/eHnMKeIoKzPLhzAVs
/5rEbQpyLcgwImeiHUKuM0GhIatqGnYPDqspK2bCJmSCJtIjD4XFnQajsRysrd6P
EEnylWLJSZGIExkDOa0l65ATEw+RSa8lHrS0A+LhE7VFWzyre4iptFTLx7BTO1Ux
9tSUO4dkLfnBDt7NDcDgC/5g3OauA8KND3gqQ5MwANLtC+iTB1vjASBAMuyBu/Ch
zqYgLSfD9E6PCkhPLZNBthThGuGtB7MyAAoO3TSUMtCMFmVQEvZTHzZBttpgBW4w
GB2ACRez8TiQNPCMGniqH1wPBBpVCzkAAfwMMhjq9iylDA3N0OYn5NrBCXIgfqhp
9+CLOIZv+K7pJIRAJrbpQ/8eaXhA8igarJWm1EqhFNmgdOyeNOxIEkvhr0qxlIiM
akfCzku7lDk7gACiYB7idcaYzXuqjW2oraSQMk0xY9sKtN1gMR5/ZG2kwBfdgKck
cMr2gR/6oTXs0g/swDGPwA3aQAiIMN9aQ1KlMFHF8h4aNYseVeF60Kcwo+/+QAnc
8fDEETD7TrY+IAqziA02wUSJcFSRcS2zwA3+YBGEAA9oCzDNcgrEUkDbk4r2Ac/y
wR7w4US7iwpAdhWHaV6NqrGU5zVwxVJyb5ogUiE/wfdeDmzJQ+YAZOQqBqBm5S/S
ikFMra3q4ecuUTdzconURUfClW5hzFtNUjf3Vl3pwUv/23Vbxg41wPSzaqyWpBPH
kqQo5w5NX3FgC1RgIXdgm5JI9KHg3GAF3k0I+gFWAXMfDgAPpqsf9EASYHUtl6AO
qEAR5kBBnzYJlRC88sxo08b07qEFwzEYZ8rI0m0OAtUNCjOL7CAd7QAMFKEOPgAZ
uqwAGtZhq+xmW5YWr3Fnr4vL9MEBqMEFqSBA8+HhCsD16pG7qIDz9kwfIG9tzoVt
iAklPQwKqABXfgIe2sEicqAd2oE4DM33EOb3wHYRaAI/zulyTiRD7IGHADF6VDJd
k8g542Hs6pYAHtg5u6Y57XZ7sMUT83Zv01WJ/hYytKWBvXTsokBwb+lwo4C0dCyk
/+COcZWyTWtKM7ixDdbAyEb1ARDAQqtyDj4A8aZseeuhHzbiD4gwHJFRZBsOZANg
CZsQQBkVKzFDDejz3f5gBw8PQiWDFu9AErJ4dWnRASyUmJSiyvRuMlz2yN6AKUjj
AahgVqkgH1ojF+PRLAWUu/rBaKlIGUFUyZCESdTnvGToaHaFCpyg4+q3DHOUOKYB
Dt2oIhd5Gvw3PyoJ52AjdAzJWaInbh9DcJuTKRoYW+Y1IOH1XTXZbtWlgROYEy1Y
XbbUbzHKg8OUo7xFXsX0xraIAAeQ7hpXBSnXhQtABmNLCdhNu574yEIB89aSYZHh
DbCACvhgdifDAczyHkCQQP8XU+E+dh8itDKyTBF2UBJArx/AMouqMs3Kk+L0waVm
WC6ziIzj03T3AR8kjhoigI4BLyv1oZqtMHzTOQAW0x665Ui6xznPqyAHRJPc1x3s
lyZitCJ3ryJjVCbIwyboAoQ8xSsmaKFG7NcG0RPp4YGLKpOZ4id5tQs1C5TLK/8g
+IFBOnucVDmLyEu1xWteGbTmIZZD8XAP14lCCu1S2P/kDpfX0YVDAwKeoBbtAHcr
wwPt4d0qNG04AC69jXNxtgCa9h7aeD8dgGgX7ogpYx/QjA/c4Q+oQE5nNzChMmKL
2QFja6nT+UL1jQjn4MvSUh+IFh/qjUzbjTHbWHtREB7/AXPO4pkeeJioIINdvvCY
cuVqnyk0uxYil1VskcBHI7KB7gMk4MFWdmfqHmSIjM1LLxheP7nsmEL/DLdbRDm0
mQiUPZGD749HGJg5USNeNZl7ZHrGzI6Wb9tMezoV1XRyg1o0CmAf+sEeaDVmJcMD
xTrv+vpTO/U+0yaNQaCNmxkwn9HOthowlxcLhGINPiB6kTAezTpiN1Yr/aAqn9e4
3+AC34AI/2AOnpZ8Tc8eHmDKtAsB6JhWrRAE6pq+GzYCEm8Vx3R9CzJp3PeZGDsH
GJr3qOEiZ8IYGtwmbuJDFuVVjBTYvG4Tl8iDDxcUS3rZQpFMR9t7RjqkyRSmsaWz
/0G5gWW7lsIUlmlaOl/ctq3tiXj6x853FevucX2bYCGAHuR5h9dRmJ/yl6URuDAw
trJgH7rYMJWMYR32xwuUziLOP9GyuAt0H55AKbCcjul4z6JAt85tTutAinH1DWix
DepAEbCAredhndeAZOPRHt9YCBmWH/r7aZ8WHtuNzud7bRwgfalW45gHN+LCCbrW
vYjjExr6E4jvwS0nPcjCK8xKRhTDouJPXeW1Jws3l+zVz/TPXlfU0zs9bEB6al8Z
NfIPl2oapw931HM6xqlNSf7Pp6cyO1tYxwkWAcru3vSBCco4HA01baosdYkwC+gB
4RpuVpVCvvvZyiGPMZl2P/8to1SjrAPqXCn2LBnUIAskoS2ZlgpEoZivUb1p9T7X
cp1t0D39eo6VAgSooEDTh5hyXSlIdS13+8ZXdH3l5o/fty1yQh0+YUYdGhQq5zXt
YlEIAwNYrGqKaGtEuKRFu+z8jNM9nNNDXOL3b7RZvQu9xdRNXUxjnNlmfMe85ceo
reStk197KcdvXUhOqkDnAQfaIB15IBcLtMrmYAVq0N8cVR8hVbt8kB/E8lbl3F8p
EA/KLgvpId+Ey437O87cDfSe9hjsQMkDgM3xLlKR0R7xGTF5y7WUbduGbE1Lg6j4
uLEM+1YmZVLaAif+C8IjvFEo6EWGZXqqpW5BeMWbCKf/Kx7jP2rizy7UozO0btqj
onPTvce2pe22+6+WBbDWV57lx0cf+IEReEqa13Hp47Jk9eFDe94fMI8xJS6v3zkF
NYMCK9Tr96EWyV2+y026/CCKyzy2PE8f4lQRQpQH9VkfihgxCVQI/1Ut/zF91Sdu
RuVo0j4tKMUdSkJT8OIjFgV4CgvVlvSVPoumQYrvO9zaQrzaEH/TRSvGw//wRbHZ
glLkaVy3bzkpVT7yr+hNt/wB/lKdyxjxfjCLsrrn5drzUdD3ASKAwABH/Pjpx2+f
voED9b3x84ZKvwj7CuhbKPCOwY0b3TxQGEAfGw/2qFAxaI9fAYb5/Ll8iU8lRoY0
/2vaDHnxIgcI8+bt60CPHj9+9Yo++fDOnj0oTJmKegpDFAx4TUNZffcka1YpXOVJ
8cBVCr0OUoCa7dmhp9p9PnuynccB7jyedNvyZIs3Lt62bOu+/bu2rVrBbwfPPaw2
7twCHBg75tCYgz7JknNavhwy883NnDt7/gw6NEN9+/Z9nDdToD4pbgz+4fOBHwfV
1GrbBjHFZeyVVF76dokP5M2CflLus+nQjx17FC+O1shx45t6IPXNGxqhn8HYDhqC
8HdvCjV8Evl1F7154eUCeH8G5efBQ9F6We09Wbq0KVOroZ5g1SrPE/V4IA9YYHHV
AVkJLhhFWnsR5lNcDszDXv8BhsmVmGMUVhQZYmrVxcE+cd0V14iHhWgiXSXCBcFO
FEIGGVyMQWbRZTbaqBl6Ou7IY480YfbjPh7YsYZJ/QinDwL89GNSk/lMkZID+uDz
m2/5JJQaQ8TtFkUfPz5kRz8HSHFHFM9x9Icbf/jhxpHqOVDaPkwYhNBsquUDQpNU
2HOknT7+qNNkE/r0E1BB0RPfgPRpxWijAH4VVqRiJTjWggsKdiGGPbm4UwEQMMah
pxaq+OmnbFko6qcrKrbppmytmJhcqz42o2MWQabPrZPteqNz6qmW45/CDkssZw7Q
w2R5FqnmwAPY8ZNdP9KCRM0UIFxb2xT3+EMNljfhYdD/HHfY0YYWqSX3xxtvtOGH
c6o9NIcOTuBDHh9f9PMARpYRpwQ/M5GWHZ8R8PPAssWqZhljPLlV6KFByZeoUfTV
U2A9YR0oFj2TWsrxPGlB+OphKjpQgK2OlRqZySU3djKnjC326VyN8URjyjKrSmvK
kUWmk2SM8dqrZTgFe3DRRg+bq7MJCYdwaQjs87SzHy2kpEklNQnClcchBx1Hm6DW
UGvRdYDkJi9cLdGe02YZgBpqYMGIv6PtM9RHNR6N8GUIKBbngg5rLKmkf1fK8aUf
82Xiqi8+VnPNjk32M4w158ryyozDtbOMjtNo+c4w7uozZUGPnhnbeJ+OumgXiWq6
/7urN4ZRiEsOHK20MiFnR3R+sFFwQ7ofhCTd0g5M8FAVsV0AUQSv1FCSlZle9GU+
O8Bqe5aONbjDZjGYoMdRuIUWXyf2xLjOFj2e863o50q5dZ+D/nOtoc/YuOg+sx85
0PqTrh70qf8PwPT4Lz0NYU+cnka3qd0kOdHp19YCwIHfxUZfpIlTjYQGKLrRg2mj
CWDzLAO7nYTIMH0rHMcapJbDYYpmktOc40o2GfuBbob3a5/9zke589EIcqvjFQ4T
lhMZjm6IpdPMrzyIxCQSK2h3Q84b3GAHRYABC3UAR0IGooU/zEES9BLCnvL1wZw0
b4EccAACBpjE0d0KRYXJlPkb23iiGJWofD2kzA57iMM8so9nsNMhDXelq0DdT4ZC
HKIhS3dEoilxkYwUlrsWuI966EkiYBRIATqQrJJMhIM8QmMjcXIjHMaoRX1BXFsk
J0LFxfAx+BOd9IJGSCC6EpZBfKUhbyk0Mf7Kk5/spS+RRrfsLMl4/wrmUAh2vF/+
r38gxCNl6Oe59InuZ4KcIS6vic1sanOXQyuivoClzHCKs0dJilNpmoiTA7KPl+P8
k6+u+bxCBmqe26ynPbfpzXxys4Pt7Kc/Q3OjmmDwn3g712juidCEKrRX+ixisNhJ
0IhKdKL/bN1C+efNd170mhl1KGggSlG8BQQAOw==

--ufsnltbcmiqtetjk--



From fil@rezo.net  Fri Jun  8 09:55:47 2001
From: fil@rezo.net (Fil)
Date: Fri, 8 Jun 2001 10:55:47 +0200
Subject: [Mailman-Developers] admlogin.html missing in the current cvs (2.1a2) for i18n
Message-ID: <20010608105547.B15028@orwell.bok.net>

Just to mention that the admlogin.html template is missing in the languages
templates (I had to copy it from templates/en/admlogin.html to
templates/fr/admlogin.html). 

-- Fil



From darrell@grumblesmurf.net  Fri Jun  8 18:21:59 2001
From: darrell@grumblesmurf.net (Darrell Fuhriman)
Date: 08 Jun 2001 10:21:59 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <20815.991975466@kanga.nu>
References: <E157kPm-0005FE-00@mail.python.org> <18710.991865049@2wire.com>
 <15134.44739.463393.527457@anthem.wooz.org> <18118.991883523@kanga.nu>
 <15135.35955.641425.315789@anthem.wooz.org> <6892.991931179@kanga.nu>
 <200106072132.f57LW3r27985@quill> <20815.991975466@kanga.nu>
Message-ID: <tsh66e6khu0.fsf@pickwick.pdx.osdl.net>

J C Lawrence <claw@kanga.nu> writes:

> baggage than I consider justifiable for an MLM or for sites which
> have no other reason (or wish) to run Zope.

I couldn't agree more.  Zope is a very complex piece of software
that I have no use for on my site, and no wish to maintain.  I'd
really rather see Mailman be able to run with nothing more than
python and the Mailman tar ball.

Darrell



From chuqui@plaidworks.com  Fri Jun  8 18:49:01 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 8 Jun 2001 10:49:01 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <tsh66e6khu0.fsf@pickwick.pdx.osdl.net>
Message-ID: <200106081748.KAA08934@scv1.apple.com>

On Friday, June 8, 2001, at 10:21 AM, Darrell Fuhriman wrote:

> J C Lawrence <claw@kanga.nu> writes:
>
>> baggage than I consider justifiable for an MLM or for sites which
>> have no other reason (or wish) to run Zope.
>
> I couldn't agree more.  Zope is a very complex piece of software
> that I have no use for on my site, and no wish to maintain.

There are very good reasons for doing someething like this, especially 
for those crazy people like me trying to integrate mailman into a 
larger, integrated environment.  But the point is a good one -- this 
stuff should be optional, so people running "lake-witchita-
friends@witchita.org" don't need to hire someone like me to install 
mailman..

The default should be simple and straightforward -- and the key is to 
build interfaces and APIs that allow users to plug in replacement 
modules for functionality...




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

When an agnostic dies, does he go to the "great perhaps"?



From claw@kanga.nu  Fri Jun  8 19:48:52 2001
From: claw@kanga.nu (J C Lawrence)
Date: Fri, 08 Jun 2001 11:48:52 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Fri, 08 Jun 2001 10:49:01 PDT." <200106081748.KAA08934@scv1.apple.com>
References: <200106081748.KAA08934@scv1.apple.com>
Message-ID: <32082.992026132@kanga.nu>

On Fri, 8 Jun 2001 10:49:01 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Friday, June 8, 2001, at 10:21 AM, Darrell Fuhriman wrote:
>> J C Lawrence <claw@kanga.nu> writes:

>>> baggage than I consider justifiable for an MLM or for sites
>>> which have no other reason (or wish) to run Zope.

>> I couldn't agree more.  Zope is a very complex piece of software
>> that I have no use for on my site, and no wish to maintain.

> There are very good reasons for doing someething like this,
> especially for those crazy people like me trying to integrate
> mailman into a larger, integrated environment.  But the point is a
> good one -- this stuff should be optional, so people running
> "lake-witchita- friends@witchita.org" don't need to hire someone
> like me to install mailman..

There's also the small fact that the environment one is integrating
into may be (is in my case) Zope unfriendly.  Requiring Zope would
require me to move away from other designs I'd much rather not.

> The default should be simple and straightforward -- and the key is
> to build interfaces and APIs that allow users to plug in
> replacement modules for functionality...

Quite.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From barry@digicool.com  Sat Jun  9 05:30:48 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Sat, 9 Jun 2001 00:30:48 -0400
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
References: <tsh66e6khu0.fsf@pickwick.pdx.osdl.net>
 <200106081748.KAA08934@scv1.apple.com>
Message-ID: <15137.42616.946686.509801@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> The default should be simple and straightforward -- and the
    CVR> key is to build interfaces and APIs that allow users to plug
    CVR> in replacement modules for functionality...

I couldn't agree more.

-Barry


From extacyhigh152@webtv.net  Sat Jun  9 08:28:33 2001
From: extacyhigh152@webtv.net (calexico ca.)
Date: Sat, 9 Jun 2001 00:28:33 -0700 (PDT)
Subject: [Mailman-Developers] thank you guys for showing me the way.
Message-ID: <15009-3B21D021-2026@storefull-106.iap.bryant.webtv.net>


From nb@thinkcoach.com  Sat Jun  9 12:54:58 2001
From: nb@thinkcoach.com (Norbert Bollow)
Date: Sat, 9 Jun 2001 13:54:58 +0200
Subject: [Mailman-Developers] Re: [Mailman-Users] Re: MIME messages
In-Reply-To: <32082.992026132@kanga.nu> (message from J C Lawrence on Fri, 08
 Jun 2001 11:48:52 -0700)
References: <200106081748.KAA08934@scv1.apple.com> <32082.992026132@kanga.nu>
Message-ID: <200106091154.f59Bswt05724@quill>

J C Lawrence <claw@kanga.nu> wrote:
> There's also the small fact that the environment one is integrating
> into may be (is in my case) Zope unfriendly.  Requiring Zope would
> require me to move away from other designs I'd much rather not.

Yes.  Zope should not be _required_, but I think it is not a
problem if some changes like e.g. replacing template texts
require shell access unless you have Zope.

BTW I don't think that Mailman should be married to Zope in any
way.  When another (Free Software) application server framework
becomes very popular, I think it would be good for Mailman to be
compatible with framework, too.  The choice of application
server framework (if any) would be an installation-time
configuration option.

Chuq Von Rospach <chuqui@plaidworks.com> had written:
> > The default should be simple and straightforward -- and the key is
> > to build interfaces and APIs that allow users to plug in
> > replacement modules for functionality...

Greetings, Norbert.

-- 
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59     Fax +41 1 972 20 69      nb@freedevelopers.net


From linuxsoftlandindia@hotpop.com  Mon Jun 11 13:25:21 2001
From: linuxsoftlandindia@hotpop.com (Murali Kumar)
Date: Mon, 11 Jun 2001 17:55:21 +0530
Subject: [Mailman-Developers] Mailman v2.0.5
Message-ID: <5.1.0.14.2.20010611175434.00a01ec0@pop.hotpop.com>

--=====================_3143919==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


Dear Sir,

Congratulations for Your Excellent Software ( Mailman v2.0.5     )
Your software has been selected in the category "Email ------> Email List 
Management" by our editorial team. Come to 
http://www.softlandindia.com/Linux/    Onestop site for Softwares; See the 
Winners.

Our Home Page: http://www.softlandindia.com/Linux/

Your Excellent Software Located 
at:  http://www.softlandindia.com/Linux/EmailList.htm

Editors Pick Logo at:

http://www.softlandindia.com/editorspick.gif

Please inform us of updates and trial versions. We would like to review
them early for our readers.


Thanking You,

With Kind Regards,

K.Murali Kumar
Webmaster
www.softlandindia.com
Email Ids: info.softlandindia@hotpop.com and softlandindia@hotpop.com
----------------------------------------------------------------------------------------------------------------
To unsubscribe, send email to: softlandindia@hotpop.com
SubJect: Unsubscribe


--=====================_3143919==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
Dear Sir, <br><br>
Congratulations for Your Excellent Software ( <b>Mailman v2.0.5
&nbsp;&nbsp;&nbsp; </b>) <br>
Your software has been selected in the category &quot;<b>Email ------&gt;
Email List Management&quot; </b>by our editorial team. Come to
<a href="http://www.softlandindia.com/Linux/" eudora="autourl"><font color="#0000FF">http://www.softlandindia.com/Linux/</a></font>&nbsp;&nbsp;&nbsp;
Onestop site for Softwares; See the Winners. <br><br>
<b>Our Home Page</b>:
<a href="http://www.softlandindia.com/Linux/" eudora="autourl"><font color="#0000FF">http://www.softlandindia.com/Linux/</a><br><br>
</font><b>Your Excellent Software Located at: </b>
<a href="http://www.softlandindia.com/Linux/EmailList.htm" eudora="autourl">http://www.softlandindia.com/Linux/EmailList.htm</a><br><br>
Editors Pick Logo at: <br><br>
<font color="#0000FF"><a href="http://www.softlandindia.com/editorspick.gif" eudora="autourl">http://www.softlandindia.com/editorspick.gif</a></font>
<br><br>
Please inform us of updates and trial versions. We would like to review <br>
them early for our readers.<br><br>
<br>
<font face="arial">Thanking You,<br><br>
With Kind Regards,<br><br>
K.Murali Kumar <br>
Webmaster <br>
</font><font color="#0000FF"><u><a href="http://www.softlandindia.com/" eudora="autourl">www.softlandindia.com</a></u></font><font face="arial"> <br>
Email Ids: info.softlandindia@hotpop.com and softlandindia@hotpop.com<br>
----------------------------------------------------------------------------------------------------------------<br>
To unsubscribe, send email to: softlandindia@hotpop.com <br>
SubJect: Unsubscribe<br><br>
</font></html>

--=====================_3143919==_.ALT--




From marc_news@valinux.com  Tue Jun 12 05:52:48 2001
From: marc_news@valinux.com (Marc MERLIN)
Date: Mon, 11 Jun 2001 21:52:48 -0700
Subject: [Mailman-Developers] site-wide list configuration...
In-Reply-To: <200105251716.f4PHGaq17092@lists.apple.com>; from chuqui@plaidworks.com on Fri, May 25, 2001 at 10:18:16AM -0700
References: <200105251716.f4PHGaq17092@lists.apple.com>
Message-ID: <20010611215248.A7594@moremagic.merlins.org>

On Fri, May 25, 2001 at 10:18:16AM -0700, Chuq Von Rospach wrote:
> But take this as a real-world case where splitting out content admin 
> from list admin from site admin and allowing the folks higher up in the 
> hierarchy to delegate or freeze what sub-admins can do. Because while 
> it's nice to think everyone will play nice and follow instructions, in 
> the real world, it doesn't always happen.

While built in support  in mailman would be nice, in  the meantime, it's not
very hard to reset  all the settings to the approved  defaults every 10mn or
so with config_list

Marc
-- 
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger marc_f@merlins.org for PGP key


From yanuar-n@unisosdem.org  Tue Jun 12 11:41:14 2001
From: yanuar-n@unisosdem.org (Yanuar Nugroho)
Date: Tue, 12 Jun 2001 11:41:14 +0100
Subject: [Mailman-Developers] adding anonymity features?
Message-ID: <054101c0f32c$344c4c60$1fa95882@halls.umist.ac.uk>

Hi there!

A short introduction: I am a MSc student in Information Systems Engineering
at UMIST, Manchester, UK, who is now doing my dissertation on applying
anonymity in mailing list communication to examine the communication
behaviour among participants.

The idea is basically hiding the identity of the sender so that the
communication will be based on what is being communicated and not who is
communicating in the group. The possible usage in the future might range
from decision making within organisation (or network/group) to conflict
resolution.

I am interested in Mailman (GNU milist mgt system) to be developed or
equipped with anonymity features. Is it possible to add "anonym feature" in
Mailman? Can you give me a clue from where should I start? I have with me
now the source-code of Mailman (written in Python) together with its
documentation.



Cheers,
Yanuar
ps. I am an NGO activist in Indonesia, where the possible advantageous usage
of this feature might be huge among many NGO/non-governmental/non-commercial
group that exist.

Yanuar Nugroho
http://yanuar-nugroho.mainpage.net
http://www.yanuar-n.net
----------------------------------------
PG. Stud. MSc. Information Systems Engineering,
Dept. of Computation, UMIST, Manchester - UK




From marc_news@valinux.com  Wed Jun 13 07:42:25 2001
From: marc_news@valinux.com (Marc MERLIN)
Date: Tue, 12 Jun 2001 23:42:25 -0700
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010601120743.64585@scfn.thpl.lib.fl.us>; from jra@baylink.com on Fri, Jun 01, 2001 at 12:07:43PM -0400
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us>
Message-ID: <20010612234225.F7594@moremagic.merlins.org>

On Fri, Jun 01, 2001 at 12:07:43PM -0400, Jay R. Ashworth wrote:
> On Fri, Jun 01, 2001 at 11:54:15AM -0400, Barry A. Warsaw wrote:
> > Yes.  Just yesterday I checked in changes to the MM2.1alpha tree to
> > support user-disabling of reminder messages, on a per-list, or
> > per-virtual domain basis.
> 
> Well, damnit Barry, what took you so long?

BTW, at sourceforge, every month, we get mail from users asking who we dared
sending them their mailman password in cleartext by mail.

I've gotten tired to answer them, and wrote this:
http://marc.merlins.org/netrants/mailman-password.txt

Feel free to steal and re-use while you're still running mm 2.0.

This also goes for the other fine stuff available here:
http://marc.merlins.org/netrants/

:-)

Marc
-- 
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger marc_f@merlins.org for PGP key


From thomas@xs4all.net  Wed Jun 13 09:51:08 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 13 Jun 2001 10:51:08 +0200
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010612234225.F7594@moremagic.merlins.org>
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <20010612234225.F7594@moremagic.merlins.org>
Message-ID: <20010613105108.A1659@xs4all.nl>

On Tue, Jun 12, 2001 at 11:42:25PM -0700, Marc MERLIN wrote:

> BTW, at sourceforge, every month, we get mail from users asking who we dared
> sending them their mailman password in cleartext by mail.

> I've gotten tired to answer them, and wrote this:
> http://marc.merlins.org/netrants/mailman-password.txt

You missed the other aspect of the monthly reminders: informing people what
lists they're subscribed to. I don't care about getting my most-insecure
password mailed to me, but I do very much care about the overview of lists
I'm subscribed to, lest I forget some.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From jra@baylink.com  Wed Jun 13 17:16:41 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Wed, 13 Jun 2001 12:16:41 -0400
Subject: [Mailman-Developers] why no user disable of the monthly reminder?
In-Reply-To: <20010612234225.F7594@moremagic.merlins.org>; from Marc MERLIN <marc_news@valinux.com> on Tue, Jun 12, 2001 at 11:42:25PM -0700
References: <3B17B4E6.4871098F@laubster.org> <15127.47783.269611.179914@anthem.wooz.org> <20010601120743.64585@scfn.thpl.lib.fl.us> <20010612234225.F7594@moremagic.merlins.org>
Message-ID: <20010613121641.35557@scfn.thpl.lib.fl.us>

On Tue, Jun 12, 2001 at 11:42:25PM -0700, Marc MERLIN wrote:
> BTW, at sourceforge, every month, we get mail from users asking who we dared
> sending them their mailman password in cleartext by mail.

Well, alas, merely telling them "do not use a valuable password" isn't
really good enough, and I'm on the "ask a reminder question" side of 
this fence, myself.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Thu Jun 14 19:27:42 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 14 Jun 2001 14:27:42 -0400
Subject: [Mailman-Developers] forwarded message from Guido van Rossum
Message-ID: <15145.542.502856.11584@anthem.wooz.org>

--OwxX7sxeZ1
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit


For those of you concerned in these sorts of issues, this is great
news.  I've done some limited testing of MM2.0.5 and MM2.1alpha
against Python 2.0.1 and it all seems to work.  I think we can finally
put the GPL-compatibility issue to bed.

-Barry


--OwxX7sxeZ1
Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 7bit

Return-Path: <python-dev-admin@python.org>
Delivered-To: barry@wooz.org
Received: from mail.python.org (mail.python.org [63.102.49.29])
	by mail.wooz.org (Postfix) with ESMTP id 54D47D35F0
	for <barry@wooz.org>; Thu, 14 Jun 2001 13:34:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 3.21 #1)
	id 15AazQ-0004gd-00; Thu, 14 Jun 2001 13:33:04 -0400
Received: from [208.184.249.89] (helo=odiug.digicool.com)
	by mail.python.org with esmtp (Exim 3.21 #1)
	id 15AazJ-0004gC-00; Thu, 14 Jun 2001 13:32:57 -0400
Received: from odiug.digicool.com (guido@localhost)
	by odiug.digicool.com (8.11.0/8.11.0) with ESMTP id f5EHUgX03621;
	Thu, 14 Jun 2001 13:30:42 -0400
Message-Id: <200106141730.f5EHUgX03621@odiug.digicool.com>
Errors-To: python-dev-admin@python.org
Precedence: bulk
List-Help: <mailto:python-dev-request@python.org?subject=help>
List-Post: <mailto:python-dev@python.org>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
	<mailto:python-dev-request@python.org?subject=subscribe>
List-Id: Python core developers <python-dev.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
	<mailto:python-dev-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-dev/>
From: Guido van Rossum <guido@digicool.com>
Sender: python-dev-admin@python.org
To: python-announce@python.org, python-list@python.org,
	python-dev@python.org
Subject: [Python-Dev] Python 2.0.1c1 - GPL-compatible release candidate
Date: Thu, 14 Jun 2001 13:30:42 -0400
X-BeenThere: python-dev@python.org
X-Mailman-Version: 2.0.5 (101270)

With a sigh of relief I announce Python 2.0.1c1 -- the first Python
release in a long time whose license is fully compatible with the GPL:

    http://www.python.org/2.0.1/

I thank Moshe Zadka who did almost all of the work to make this a
useful bugfix release, and then went incommunicado for several weeks.
(I hope you're OK, Moshe!)

Note that this is a release candidate.  We don't expect any problems,
but we're being careful nevertheless.  We're planning to do the final
release of 2.0.1 a week from now; expect it to be identical to the
release candidate except for some dotted i's and crossed t's.

Python 2.0 users should be able to replace their 2.0 installation with
the 2.0.1 release without any ill effects; apart from the license
change, we've only fixed bugs that didn't require us to make feature
changes.  The SRE package (regular expression matching, used by the
"re" module) was brought in line with the version distributed with
Python 2.1; this is stable feature-wise but much improved bug-wise.

For the full scoop, see the release notes on SourceForge:

    http://sourceforge.net/project/shownotes.php?release_id=39267

Python 2.1 users can ignore this release, unless they have an urgent
need for a GPL-compatible Python version and are willing to downgrade.
Rest assured that we're planning a bugfix release there too: I expect
that Python 2.1.1 will be released within a month, with the same
GPL-compatible license.  (Right, Thomas?)

We don't intend to build RPMs for 2.0.1.  If someone else is
interested in doing so, we can link to them.

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev

--OwxX7sxeZ1--


From mtearle@tearle.com  Fri Jun 15 04:16:05 2001
From: mtearle@tearle.com (Mark Tearle)
Date: Fri, 15 Jun 2001 11:16:05 +0800 (WST)
Subject: [Mailman-Developers] Re: auto aprroval
In-Reply-To: <E159m5D-0006Gk-00@usw-sf-web2.sourceforge.net>
Message-ID: <Pine.LNX.4.31.0106151103560.6241-100000@tartarus.uwa.edu.au>

On Tue, 12 Jun 2001, Marcin Bujak wrote:

> hi
> i'm having a problem with your patch "Auto Approval of
> subscriptions for certain domains"
>
> cd mailman-2.0.5/Mailman
> patch < None.txt
> cd ..
> make clean
> make install
>
> if i choose a privace options from privacy options section
> mailman send a bug in ....
>
> can you help me ?
>

Hiya

The patch is buggy and I should really get around to updating the
Sourceforge web page about it.  It works OK if you create a new list
but doesn't detect if the field is missing in an existing list
and add it unfortunately.

I'm CC'ing mailman-developers to ask for advice, I know it goes
somewhere in the versioning code, but where?  And how do I do it such
that future upgrades etc don't break?

Yours
Mark
-- 
Mark Tearle - mark@tearle.com

 "The only good is knowledge and the only evil is ignorance." - Socrates



From barry@digicool.com  Fri Jun 15 05:46:56 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 15 Jun 2001 00:46:56 -0400
Subject: [Mailman-Developers] Re: auto aprroval
References: <E159m5D-0006Gk-00@usw-sf-web2.sourceforge.net>
 <Pine.LNX.4.31.0106151103560.6241-100000@tartarus.uwa.edu.au>
Message-ID: <15145.37696.227562.505393@anthem.wooz.org>

>>>>> "MT" == Mark Tearle <mtearle@tearle.com> writes:

    MT> The patch is buggy and I should really get around to updating
    MT> the Sourceforge web page about it.  It works OK if you create
    MT> a new list but doesn't detect if the field is missing in an
    MT> existing list and add it unfortunately.

    MT> I'm CC'ing mailman-developers to ask for advice, I know it
    MT> goes somewhere in the versioning code, but where?  And how do
    MT> I do it such that future upgrades etc don't break?

The trick is to bump the DATA_FILE_VERSION in Mailman/Version.py and
to add a little bit of code to Mailman/versions.py.

versions.py is the file that essentially updates the (logical)
database schema when it changes.  In the past there has been radical
surgery in the schema, but these days it's mostly just adding new
attributes to older lists.  Look for function NewVars() in versions.py
to see where you can add default settings for your new attributes.

When a MailList object is instantiated, its database -- which is kept
as a marshaled dictionary on disk -- contains an attribute
data_version which is compared against DATA_FILE_VERSION.  If the
latter is greater, then versions.py's Update() function is called.

This works fairly well in practice, but it breaks down when you have
multiple patches each bumping DATA_FILE_VERSION, e.g. your patch
cranks it to 23 while I make changes to the CVS to bump it to 27.
It's probably not enough of a pain to fix, since it's quite likely
that the whole mechanism will be overhauled for Mailman 3.0.

Cheers,
-Barry


From y.nugroho@student.umist.ac.uk  Fri Jun 15 14:52:36 2001
From: y.nugroho@student.umist.ac.uk (Yanuar Nugroho)
Date: Fri, 15 Jun 2001 14:52:36 +0100
Subject: [Mailman-Developers] anonymity features
References: <053701c0f32b$daf4e640$1fa95882@halls.umist.ac.uk> <15142.9927.869879.114118@anthem.wooz.org>
Message-ID: <01c001c0f5a2$6fc59260$1fa95882@halls.umist.ac.uk>

Dear folks,

I'm doing a research on "how anonymity in CMC influences communication
behaviour among participants/communicators". This will be done in
asynchronous mode, and I have chosen to use GNU Mailman rather than any
other systems.

This is the list of the "anonymity feature" requirements that should be
ideally able to include.
1. Removing the sender identities (it has been solved, i think. in "privacy"
setting and cleanse.py, right?)
2. Archiving sent message (how is actually a message archived in Mailman?)
3. Adding additional text from a database into a message before being
distributed (is it possible to create text-based database and include a
particular data to the message? how can Mailman query and retrieve a data to
be included -- how can Mailman "scan" a message and find a "keyword" and use
the keyword to retrieve relevant data?
4. Other idea for the no.3 above, using "phantom messages" as the database.
The problem is how can Mailman automatically add a phantom message to a
message?
5. How to customise the text-wrapping (text area in the email) in Mailman?
How to set, for example, the LEFT Margin to be 5 characters?

I think I have to stop. It has been too much. Sorry-sorry-sorry very much if
this realy bothers you. I am desperate in doing this research ... :) I don't
know how to do this. Not even a clue. I'm totally a new comer in Mailman,
Python and this GNU environment, but I want to learn. Anyone can help me?
(thanks to Barry Warsaw who encouraged me to join this milist. also for
Yaron Zarfati, Detlef Neubauer & JC Lawrence who tried to solve my previous
problems in handling the header. thanks!:)).

Cheers /Yanuar.
PS. If any of you need further info, I can send my preliminary works/report
via your individual emails. This probably helps you to know the context of
my research.


Yanuar Nugroho
http://yanuar-nugroho.mainpage.net
http://www.yanuar-n.net
----------------------------------------
PG. Stud. MSc. Information Systems Engineering,
Dept. of Computation, UMIST, Manchester - UK



From dang@mindsqueeze.net  Fri Jun 15 19:56:37 2001
From: dang@mindsqueeze.net (Danny Graham)
Date: Fri, 15 Jun 2001 11:56:37 -0700
Subject: [Mailman-Developers] Configuring mailman without the scripts?
Message-ID: <002c01c0f5cc$fa42f700$6401a8c0@cx199427a>

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01C0F592.3B4609D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I am unable to find the config files on the server that is hosting me.  =
They would probably not appreciate it if I changed them anyways :)  Is =
there anyway for me to customize and change the welcome message to =
subscribers?  Basically I just want to give them a URL to unsubscribe at =
and remove the info about how to post to the list...  Help would be =
TOTALLY appreciated.

-- Cheers

- Danny Graham

-------------------------------------------------------------------------=
-------=20

//liberate possibility::.
     --MIND SQUEEZE INTERACTIVE

     //::




------=_NextPart_000_0029_01C0F592.3B4609D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DVerdana size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>I am unable to find the config files =
on the=20
server that is hosting me.&nbsp; They would probably not appreciate it =
if I=20
changed them anyways :)&nbsp; Is there anyway for me to customize and =
change the=20
welcome message to subscribers?&nbsp; Basically I just want to give them =
a URL=20
to unsubscribe at and remove the info about how to post to the =
list...&nbsp;=20
Help would be TOTALLY appreciated.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>-- Cheers</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>- Danny Graham</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana=20
size=3D2>----------------------------------------------------------------=
----------------=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>//liberate=20
possibility::.<BR>&nbsp;&nbsp;&nbsp;&nbsp; --MIND SQUEEZE=20
INTERACTIVE</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
//::</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D2><BR></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0029_01C0F592.3B4609D0--



From dang@mindsqueeze.net  Fri Jun 15 20:01:24 2001
From: dang@mindsqueeze.net (Danny Graham)
Date: Fri, 15 Jun 2001 12:01:24 -0700
Subject: [Mailman-Developers] Configuring mailman with the scripts?
Message-ID: <003c01c0f5cd$a57edf30$6401a8c0@cx199427a>

I am unable to find the config files on the server that is hosting me.  They
would probably not appreciate it if I changed them anyways :)  Is there
anyway for me to customize and change the welcome message to subscribers?
Basically I just want to give them a URL to unsubscribe at and remove the
info about how to post to the list...  Help would be TOTALLY appreciated.

-- Cheers

- Danny Graham

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

//liberate possibility::.
     --MIND SQUEEZE INTERACTIVE

     //::






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

//liberate possibility::.
     --MIND SQUEEZE INTERACTIVE

     //::



From carson@taltos.org  Fri Jun 15 23:55:59 2001
From: carson@taltos.org (Carson Gaspar)
Date: Fri, 15 Jun 2001 15:55:59 -0700
Subject: [Mailman-Developers] Postfix DSN handling
Message-ID: <483113867.992620559@ZATHROS>

mailman 2.0.5 does not handle Postfix DSN messages for delayed mail. Has 
this been fixed in the development tree, or should I attempt to patch the 
code myself?

-- 
Carson Gaspar - carson@taltos.org
Queen trapped in a butch body


From thomas@xs4all.net  Sat Jun 16 00:15:45 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 16 Jun 2001 01:15:45 +0200
Subject: [Mailman-Developers] Braindump on new archiver
Message-ID: <20010616011545.B8098@xs4all.nl>

I've been thinking about re-doing the whole archiver thing in Mailman for a
while now, and I need to start writing these things down before I forget
about them. What follows is basically a braindump, for your amusement and
free to comment on.

First off, I have a couple of handicaps. Some are severe. The first one is
that I have very little time, which is one of the reasons I'm writing this
braindump: I don't have time to implement it right now :P The other is that,
for a living, I build and maintain large to very large, high-performance
internet servers (mostly Apache webservers with bells 'n whistles.) This
means I am usually too performance oriented. And lastly: I like the
'Maildir' mailbox format very much. This is a handicap because,
unfortunately, not all mail programs support it. 'Pine', specifically, is
boycotting the Maildir format (don't ask me why, I gave up on them.)

The good thing about the Maildir format is that it's very NFS secure. All of
our customers (except a handful who refuse to upgrade from 'elm' to 'mutt')
have a maildir mailbox, and we have 6 SMTP delivery boxes, 5 POP retrieval
boxes, one IMAP retrieval box (used only for our webmail server, which is
why it's only one right now) and several shell servers that have all kinds
of UNIX mail clients running. The mailspool itself is a dedicated NFS server
(a NetApp Filer.) We have a patched version of Pine that works with maildir
whether it likes it or not :)

Maildir works by making every message a file on its own. A mailbox is a
directory with three subdirectories, 'cur', 'new' and 'tmp'. Messages in
'new' are unread, messages in 'cur' are read, and messages in 'tmp' are in
transit. Message-metadata and state is maintained using the name of the
message-file itself. Delivery is done by creating a new file in
mailbox/tmp/, writing all data to it, and when it's done, moving it to
'new'. Writing data to a file is not trustworthy, over NFS, but renaming and
moving files are.

What I'm thinking for a Mailman archiver (or just any email-webarchiver, in
fact) is something like the following:

- Mail delivery can happen on any host. The Mailman process, after doing its
normal pre-delivery stuff, 'delivers' the message by dropping it in a
Maildir folder (rather than appending it to an 'mbox' mailbox) _and_
cgi-escaping/header-cleaning the message and dropping it in a
monthly/weekly/daily archive directory. The names are generated from uniq
data, like the time of day, the machine name and the process-id, possibly
hashed for obscurity. No locking is necessary. The URL to that _specific_
message is known as soon as Mailman calculates that name, and so it can be
inserted into the message that will be sent out to the list. (A common
feature request :)

- Non-text attachements could be saved as separate files, and replaced by
URLs to them in the archives. This should be possible to do both based on
type and on size, of course.

- The web archives are indexed once every [X] minutes, by looking at all the
new messages and processing them. Processing them consists of creating
indexes based on threads, subjects, author, etc, exactly like now. State
data could be stored in a .db (berkeley db, marshall, pickle, whatever) and
need not even be protected by a lock, if done properly: When started, the
indexing process should compare the mtime of the .db file with the current
time, as well as the last added new message. If the .db file is too new, it
should not run. If the .db file is old, and the newest message is newer, it
should touch the .db file (leaving it exactly as it is, just updating mtime)
and start working, keeping in mind to touch the file every now and then. The
new .db file should be written to a temporary name, and rename()'d when it's
done.

- The individual archive message URL's would actually call a CGI script that
looks up state data from the .db file, grab the cgi-escaped file, prepend
and append standard header and footer containing 'next in thread', 'next in
subject' and the like generated from the .db file, and feed that to the
browser. If state data is absent, but the message itself is there, teh
standard header and footer are added with a note saying that the message is
too new to have links to other messages -- but at least the message will be
visible.

Mail delivery and the Web-interface can be run on multitudes of servers, all
sharing data over NFS, and still be able to communicate in a sane way,
without waiting for eachother's locks forever. The only thing that can go
wrong is for a message to be archived and sent out, and then read and looked
up in the archives before the actual NFS data (the content of the message)
is visible on the web-interface machine(s). Given the average speed of SMTP,
I do not consider this a serious problem :)

One thing should run on a single server, however, and that's the
archive-indexing process. Given that news-feeding and mailing out passwords
should also be done on a single server, I don't see that as a problem either.
And all of the above should work just as fine on a single machine doing
everything on a local disk.

While under the 'the filesystem as the database' spell (hell, I'm still
under that one) I also considered using the filesystem to index messages
based on thread, subject, author, etc: a directory for each category, in
which symlinks point to messages. To go from message 'X' to the next message
in the thread, check where the symlink 'next-threads/X' points. The same for
previous-thread, next-author, etc. I'm not sure if it will managable without
adding a lockfile, nor how efficient it would be to generate overviews from
such data.

Another thing for consideration is the 'downloadable mailbox' link. Should
it download the maildir mailbox, or generate an mbox one on demand ? The
maildir mailbox is *very* useful for incremental updates, since all that
takes is checking which files you've already read. But, like I said, it's
not as widely supported as the crappy ol' mbox format. 

End-of-rant--we-will-now-return-to-your-regular-scheduled-static-ly y'rs,
 ;)
-- 
Thomas Wouters <thomas@xs4all.net>

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


From barry@digicool.com  Sat Jun 16 00:21:49 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 15 Jun 2001 19:21:49 -0400
Subject: [Mailman-Developers] Postfix DSN handling
References: <483113867.992620559@ZATHROS>
Message-ID: <15146.39053.54807.220914@anthem.wooz.org>

>>>>> "CG" == Carson Gaspar <carson@taltos.org> writes:

    CG> mailman 2.0.5 does not handle Postfix DSN messages for delayed
    CG> mail. Has this been fixed in the development tree, or should I
    CG> attempt to patch the code myself?

I didn't think Postfix /did/ DSN.  Hmm, maybe the new version does.

In any event MM2.0.5 does have a DSN bounce detector /and/ a Postfix
bounce detector.  Do you have an example of a message that's getting
through?  Can you forward it to me with full headers intact?

-Barry


From carson@gnac.com  Sat Jun 16 00:38:37 2001
From: carson@gnac.com (Carson Gaspar)
Date: Fri, 15 Jun 2001 16:38:37 -0700
Subject: [Mailman-Developers] Delayed Mail (still being retried) (fwd)
Message-ID: <188222687.992623117@ZATHROS>

--==========188240297==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Attached is one of the postfix messages that the bounce handler misses.

-- 
Carson Gaspar - carson@gnac.com
Security Architect - Global Networking and Computing, Inc.
--==========188240297==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is the Postfix program at host mail.knoware.nl.

####################################################################
# THIS IS A WARNING ONLY.  YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################

Your message could not be delivered for 4 hours.
It will be retried until it is 5 days old.

For further assistance, please contact <postmaster@knoware.nl>

			The Postfix program

	--- Delivery error report follows ---

<bashakst@knoware.nl>: temporary failure. Command output: bashakst: Over quota
    _

	--- Undelivered message follows ---

Received: from imail.ision.nl (imail.ision.nl [195.64.48.18])
	by mail.knoware.nl (Postfix) with ESMTP id 8B71E39740
	for <bashakst@knoware.nl>; Fri, 15 Jun 2001 20:44:19 +0200 (CEST)
Received: from lists.gnac.net (pluto.gnac.com [209.182.195.144])
	by imail.ision.nl (Postfix) with ESMTP id 4913626632
	for <bashakst@knoware.nl>; Fri, 15 Jun 2001 20:44:19 +0200 (CEST)
Received: from lists.gnac.net (localhost [127.0.0.1])
	by lists.gnac.net (Postfix) with ESMTP
	id 8F270106E4; Fri, 15 Jun 2001 11:40:00 -0700 (PDT)
Delivered-To: firewalls@lists.gnac.net
Received: from femail3.rdc1.on.home.com (femail3.rdc1.on.home.com [24.2.9.90])
	by lists.gnac.net (Postfix) with ESMTP id 11BDD106AD
	for <firewalls@lists.gnac.net>; Fri, 15 Jun 2001 11:30:28 -0700 (PDT)
Received: from Jason ([24.42.170.206]) by femail3.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010615183025.FVHI15293.femail3.rdc1.on.home.com@Jason>
          for <firewalls@lists.gnac.net>; Fri, 15 Jun 2001 11:30:25 -0700
From: "Jason Brown" <jason@onsidekick.com>
To: <firewalls@lists.gnac.net>
Subject: Network Sniffers
Message-ID: <000f01c0f5c9$ab247a20$6500a8c0@onside.tor>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: firewalls-admin@lists.gnac.net
Errors-To: firewalls-admin@lists.gnac.net
X-BeenThere: firewalls@lists.gnac.net
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:firewalls-request@lists.gnac.net?subject=help>
List-Post: <mailto:firewalls@lists.gnac.net>
List-Subscribe: <http://lists.gnac.net/mailman/listinfo/firewalls>,
	<mailto:firewalls-request@lists.gnac.net?subject=subscribe>
List-Id: Firewalls <firewalls.lists.gnac.net>
List-Unsubscribe: <http://lists.gnac.net/mailman/listinfo/firewalls>,
	<mailto:firewalls-request@lists.gnac.net?subject=unsubscribe>
List-Archive: <http://lists.gnac.net/pipermail/firewalls/>
Date: Fri, 15 Jun 2001 14:33:26 -0400

--==========188240297==========--



From Dale Newfield <Dale@Newfield.org>  Sat Jun 16 18:34:02 2001
From: Dale Newfield <Dale@Newfield.org> (Dale Newfield)
Date: Sat, 16 Jun 2001 13:34:02 -0400 (EDT)
Subject: [Mailman-Developers] Braindump on new archiver
In-Reply-To: <20010616011545.B8098@xs4all.nl>
Message-ID: <Pine.SUN.4.33.0106161327070.5110-100000@adder.cs.Virginia.EDU>

On Sat, 16 Jun 2001, Thomas Wouters wrote:
> Maildir works by making every message a file on its own. A mailbox is
> a directory with three subdirectories, 'cur', 'new' and 'tmp'.
> Messages in 'new' are unread, messages in 'cur' are read, and messages
> in 'tmp' are in transit.

What about file system limitations to the maximum number of files in a
directory?

I've not been a student at CMU for a long time, now, but while their mail
system also does a file per message it is on a special FS--AFS.

-Dale



From claw@kanga.nu  Sat Jun 16 20:35:08 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sat, 16 Jun 2001 12:35:08 -0700
Subject: [Mailman-Developers] Braindump on new archiver
In-Reply-To: Message from Dale Newfield <Dale@Newfield.org>
 of "Sat, 16 Jun 2001 13:34:02 EDT." <Pine.SUN.4.33.0106161327070.5110-100000@adder.cs.Virginia.EDU>
References: <Pine.SUN.4.33.0106161327070.5110-100000@adder.cs.Virginia.EDU>
Message-ID: <16575.992720108@kanga.nu>

On Sat, 16 Jun 2001 13:34:02 -0400 (EDT) 
Dale Newfield <Dale@Newfield.org> wrote:

> On Sat, 16 Jun 2001, Thomas Wouters wrote:
>> Maildir works by making every message a file on its own. A
>> mailbox is a directory with three subdirectories, 'cur', 'new'
>> and 'tmp'.  Messages in 'new' are unread, messages in 'cur' are
>> read, and messages in 'tmp' are in transit.

> What about file system limitations to the maximum number of files
> in a directory?

Typically this is an inode limit for the whole filesystem, not a
directory size issue.  Directory size is a performance issue that
different filesystems handle variously well (eg Ext2FS badly,
ReiserFS fairly well).  

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From thomas@xs4all.net  Sat Jun 16 22:05:48 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 16 Jun 2001 23:05:48 +0200
Subject: [Mailman-Developers] Braindump on new archiver
In-Reply-To: <16575.992720108@kanga.nu>
Message-ID: <20010616230548.C8098@xs4all.nl>

On Sat, Jun 16, 2001 at 12:35:08PM -0700, J C Lawrence wrote:
> On Sat, 16 Jun 2001 13:34:02 -0400 (EDT) 
> Dale Newfield <Dale@Newfield.org> wrote:
> 
> > On Sat, 16 Jun 2001, Thomas Wouters wrote:
> >> Maildir works by making every message a file on its own. A
> >> mailbox is a directory with three subdirectories, 'cur', 'new'
> >> and 'tmp'.  Messages in 'new' are unread, messages in 'cur' are
> >> read, and messages in 'tmp' are in transit.
> 
> > What about file system limitations to the maximum number of files
> > in a directory?

> Typically this is an inode limit for the whole filesystem, not a
> directory size issue.  Directory size is a performance issue that
> different filesystems handle variously well (eg Ext2FS badly,
> ReiserFS fairly well).  

Exactly. The NetApps we use have their own filesystem, which doesn't have an
inode limit (the WAFL filesystem is a very cool thing). They also use btree
directory indexes, so large directories are not a problem. I believe
ReiserFS and XFS (SGI's journalling filesystem, which is also ported to the
Linux kernel) also use btree directories.

That said, yes, for lists with a lot of small messages, inodes could become
a problem. I think most UNIX filesystems default to around
8k-bytes-per-inode nowadays, whereas the median size in my mailbox is about
2k. (Trust me.. it's a big enough sample size :-) I forgot to mention this,
but the number of files was one of the reasons not to go for the
directories-with-symlinks for archive data. Still, the problem can be
avoided by removing the maildir mailbox (converting it to an mbox one) when
the month (or week, or year, or whatever) ends and the archive is up to
date. If it turns out to be a problem.

Don't forget that the current system is also pretty inode-heavy, since every
archived message is already a file on its own. And don't think I'm
forgetting about non-Linux, non-NetApp-attached systems :) Our listservers
run BSDI and FreeBSD, both not brilliant in filesystem performance.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From chuqui@plaidworks.com  Sun Jun 17 08:46:47 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 00:46:47 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: <15146.28093.61335.281545@anthem.wooz.org>
Message-ID: <200106170738.f5H7cah28586@plaidworks.com>

On Friday, June 15, 2001, at 01:19 PM, Barry A. Warsaw wrote:

>     CVR> points. but we need to quantify what those points are and
>     CVR> what the impact is, so we can decide just how to move forward
>     CVR> on this.

> I'd love to see any statistic you (or anybody) gathers on this
> subject.  It's definitely intriguing, but right now I don't have the
> time or systems to do this kind of data gathering.
>

Okay, here's a first cut at some data.

I'm going to assume the following:

1000 subscribers -- no digest subscribers to simplify this. Assume just 
individual messages.

The message size is 10K, including header.

The bandwidth needed to generate a connection to send a message is 1K 
(which is pretty close)

The bandwidth needed to add an address to an existing message is about 
1/10 of a K (also pretty close).

The practical limit to the number of messages you can piggyback is 100, 
since this is specified in RFC2821 as the smallest number a site is 
REQUIRED to take. In practice, due to non-conformant sites, you have to 
be careful setting it beyond 50 these days, because sites set this 
number down because they think it slows down the spammers (I'm yet to be 
convinced it makes a damn bit a difference, especially since MTAs like 
postifx recognize the 452 and auto-adjust now. This is another place 
where sendmail seems behind the technology curve, FWIW)

How much bandwidth is used depends on these factors:

what your piggyback value is (in mailman, it's SMTP_MAX_RCPTS)

how many domains have > 1 subscriber.

Here's how plaidworks breaks down:

3101 subscribers across 1287 domains. that's an average of 2.3 
subscribers per domain, but the numbers skew wildly, so averages are 
meaningless.


Here's how my site breaks down:

# of subscribers			# of domains/# of users
---------------------			-----------------
1						263/263
2						142/284
3						40/120
4						19/76
5						16/80
6						10/60
7						7/49
8						3/24
9						6/54
10						2/20
11						2/22
12						2/24
13						1/
14						1/
16						1/
17						1/ (worldnet.att.net)
22						1/(juno.com)
29						1 (mindspring.com)
30						1 (pacbell.net)
35						1 (plaidworks.com)
43						1 (sympatico.ca)
53						1 (earthlink.net)
150						1 (home.com)
173						1 (yahoo.com)
228						1 (hotmail.com)
441						1 (aol.com)

if you're scoring at home, 37% of subscribers come from that last 4 
domains: 5% for home and yahoo, 7% for hotmail, and 14% for aol. those 
are your 500 pound gorillas (AOL is 800 pounds), and piss them off at 
your own risk.

At the other end, 8% of your users are the only subscriber from a 
domain. 16% are 1 or 2 per domain. 26% are on sites with 5 or fewer 
subscribers.

Time for some numbers.

Back to the 1000 member list for simplicity. The subscriber list breaks 
down to:

85	- 	1/85
45	-	2/90
12	-	3/36
6	-	4/24
[...]
48	-	1
55	-	1
73	-	1
142	-	1

That's 553, or 55% of the subscribers, wedged tightly on both ends of 
the curve. We can extrapolate what they'll do to bandwidth from the end 
cases if we need to.

Extreme case: SMTP_MAX_RCPTS = 1.

1000 subscribers * (10K message size + 1K overhead) = 11,000K bytes 
bandwidth.

Extreme case: SMTP_MAX_RCPTS = 100

These get sent  down the line this way:

85 * 11K
45 * (1 * 11K + 1 * .1K)
12 * (1 * 11K + 2 * .1K
6 * (1 * 11K + 3 * .1K)
[...]
1 * 11K + 47 * .1K
1 * 11K + 54 * .1K
1 * 11K + 72 * .1K
2 * 11K + 140 * .1K

Do you see how I got these numbers? In the case of the 12 domains with 
three subscribers, you have to make an 11K connection for the first 
message, and piggy back on the other two addresses at .01K each. You 
don't really see huge savings until the big domains, and you'll see AOL 
goes over the 100 address limit so gets split into two different 
messages.

For this 55%, the SMTP=1 is 6050K. For 100, it's 1711K bytes. That's 28% 
of the first number, so we're cutting 72% of the bandwidth by chunking 
at 100. The tradeoff is performance, though -- it takes a lot longer to 
deliver those AOL addresses, because if you split it into two batches, 
you can't parallelize the delivery. Package up 100 AOL addresses in one 
batch, none of them get delivered until all 100 addresses are sent to 
AOL and accepted. It's much faster to send them as ten batches of ten in 
parallel -- but that's the trade off here. Cut network bandwidth but 
slow delivery to the larger domains.

Okay, let's look at a case in the middle. SMTP_MAX = 5. The ones with 
less than 5 don't change, but the big domains do

85 * 11K
45 * (1 * 11K + 1 * .1K)
12 * (1 * 11K + 2 * .1K
6 * (1 * 11K + 3 * .1K)
[...]
1 * (10 * 11K + 38 * .1k)
1 * (11 * 11K + 44 * .1K)
1 * (15 * 11K + 58 * .1K)
1* (29 * 11K + 113 * .1K)

that works out to (trust me) about 2378K, or about a 60% reduction.

Let's try SMTP_MAX = 2.

85 * 11K
45 * (1 * 11K + 1 * .1K)
12 * (2 * 11K + 1 * .1K
6 * (2 * 11K + 2 * .1K)
[...]
1 * (10 * 11K + 38 * .1k)
1 * (11 * 11K + 44 * .1K)
1 * (15 * 11K + 58 * .1K)
1* (29 * 11K + 113 * .1K)

that works out to 2575K, or about a 57% cut.

By a rough look at those domains in the middle, I'd say these numbers 
are good +-10%.

What's this mean? Here's the executive summary:

The network penalty between SMTP_MAX = 1 (effectively VERP) and any kind 
of batching (SMTP > 1) is roughly 50%. To get VERP or customized footers 
or customized anything, you double your network bandwidth.

There is very little advantage to setting SMTP_MAX > 5, UNLESS your 
subscriber base is heavily stratified onto very few sites. If you have 
really large groups of subscribers on AOL or Hotmail, it can help cut 
network bandwidth, but at best, it seems to be about a 10% improvement. 
If you plot the numbers I did on a curve, you can see just how little 
advantage you get by increasing the number. You get almost all of the 
advantage by going to 2, and the line past 5 is very flat....

Interesting -- I honestly didn't expect to see THIS big a difference -- 
I was expecting more like 25-30% increase in bandwidth for a VERP-type 
delivery.

My thoughts on what this means to future directions:

Customized messages (VERPing, or encoded unsub URLs, or all of that...) 
should definitely be an option in Mailman 2.1.

I would set Mailman's 2.1 default to have this turned ON, giving us the 
customized unsub links and etc, but to document this for users so they 
know to turn it off on slow networks.

If users turn it off, I recommend that SMTP_MAX be set by default to 5, 
and that we document that it makes little sense to change it unless a 
site is horribly network limited, because even setting to the max only 
gains them another 10% (and if they're THAT network limited, they're 
seriously asking for trouble anyway), and only if their subscriber base 
fits a profile that lends itself to the compression. Setting it large 
also leaves them open to spamblocking by systems that don't necessarily 
follow the standards or act right, too.

We should ALSO note here that some MTAs (postfix, for instance) might 
override SMTP_MAX anyway -- you could set it to 100, but postfix might 
be configured smaller, so they have to be aware of those potential 
interactions. you then get into the issues of tuning all this, with few 
delivery threads with lots of addresses vs many threads in parallel.. 
and all that fun -- I guess I'm trying to say that you can't tune 
mailman in isolation from the MTA (and down that road lies a huge 
rathole of attempting to document this stuff...)

But from these numbers, any 2.0.x version of mailman should set SMTP_MAX 
to between 2 and 5, unless they're horribly network limited. it makes no 
sense to be larger than 5, and it makes no sense to be 1 unless you've 
done some kind of VERPing patch.

for 2.1, we want to implement these customizations and default them on, 
but with a 50% network hit, we definitely want to make it clear what's 
going on and make it possible for them to turn it off and return to a 
generic URL and non-customized e-mail.

Barry's mileage may vary on his preferences for default, of course, and 
it's his show. I think the advantages of the customized URL/email 
capability is a huge one and most sites will benefit from it -- but the 
network hit might kill some sites, so we have to give them an easy 
ability to turn the feature off.

What do y'all think? I've included mailman-developers on this reply, 
since while this started on mm-users, it really ought to be discussed on 
the developers list...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Yes, I am an agent of Satan, but my duties
are largely ceremonial.




From fil@rezo.net  Sun Jun 17 11:20:03 2001
From: fil@rezo.net (Fil)
Date: Sun, 17 Jun 2001 12:20:03 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106170738.f5H7cah28586@plaidworks.com>; from chuqui@plaidworks.com on Sun, Jun 17, 2001 at 12:46:47AM -0700
References: <15146.28093.61335.281545@anthem.wooz.org> <200106170738.f5H7cah28586@plaidworks.com>
Message-ID: <20010617122003.C3895@orwell.bok.net>

@ Chuq Von Rospach (chuqui@plaidworks.com) :
> Okay, here's a first cut at some data.

Very interesting! Doubling the bandwith needed might or not be a problem. My
systems delivers 10K messages at the mean rate of 18000 per hour. When I
send a message down a 130 000 subscribers' list, well, I have to wait quite
long befoore it's gone ; maybe I should buy some more bandwith. I'm ready to
take up the VERP approach, even if it means twice longer sends.

However there's another performance issue: how does postfix react when it's
got sent 130 000 emails to store and forward? Currently I send it about
10000 messages that it breaks up one by one using. I don't know about memory
or disk issues there, but 130 000 * 10k = 1.3 Gbytes on disk: there might be
more to consider than speed issues. I'd love to see it working that way
though. Would spare a lot users' and admin's nerves.

(By the way currently my larger lists aare not handled by Mailman but by
sympa, 'coz I needed to keep a copy of the subscribers' names in order to
spot them easier in the list when they want to unsubscribe and don't know
what their address was...)

> What do y'all think? I've included mailman-developers on this reply, 
> since while this started on mm-users, it really ought to be discussed on 
> the developers list...


-- Fil



From alex@phred.org  Sun Jun 17 14:21:32 2001
From: alex@phred.org (alex wetmore)
Date: Sun, 17 Jun 2001 06:21:32 -0700 (PDT)
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas
 swords
In-Reply-To: <200106170738.f5H7cah28586@plaidworks.com>
Message-ID: <20010617061400.S4983-100000@phred.org>

On Sun, 17 Jun 2001, Chuq Von Rospach wrote:
> For this 55%, the SMTP=1 is 6050K. For 100, it's 1711K bytes. That's 28%
> of the first number, so we're cutting 72% of the bandwidth by chunking
> at 100. The tradeoff is performance, though -- it takes a lot longer to
> deliver those AOL addresses, because if you split it into two batches,
> you can't parallelize the delivery.

Please don't make this assumption.  It is true for the commonly used
Unix MTAs, but it is not true for all MTAs.  My MTA has no problems
with parallelizing delivery out of a single recieved message.

I agree that a smaller number would make sense for the default though,
as I'm probably the only one here who isn't using a Unix-based MTA to
do their deliveries.  As long as it is still configurable I am happy.

Your method for figuring out bandwidth usage is interesting, and I
think I'll do something similar for the recipient base and message
sizes on my system.  10k is much larger than my average message size,
but doing the same thing for digests (30k, and 65% of my readers are
in digest mode) would be interesting.  I'll report back to the list
with my results if anyone else is interested.

> I would set Mailman's 2.1 default to have this turned ON, giving us the
> customized unsub links and etc, but to document this for users so they
> know to turn it off on slow networks.

I would argue that it should default to OFF, as this is how Mailman
has behaved for a couple of years.  As long as I can easily turn it
off before completing the install (by changing mm_cfg.py for instance)
I am happy.

alex



From chuqui@plaidworks.com  Sun Jun 17 16:29:50 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 08:29:50 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: <20010617061400.S4983-100000@phred.org>
Message-ID: <200106171521.f5HFLdh06227@plaidworks.com>

On Sunday, June 17, 2001, at 06:21 AM, alex wetmore wrote:

> Please don't make this assumption.  It is true for the commonly used
> Unix MTAs, but it is not true for all MTAs.

you're misreading what I was doing here -- I'm looking at this based on 
how it goes over the wire, not how it's delivered to the MTA. So it 
doesn't matter if your MTA repackages it going over the wire or not -- 
I'm assuming it doesn't for simplicity, but if it does, you simply have 
to change the values to take that into consideration (and, for what it's 
worth, I did point out that postfix CAN do this, although I didn't 
clearly tie that back to this, because I thought the message was too 
long and opaque already...)

> Your method for figuring out bandwidth usage is interesting, and I
> think I'll do something similar for the recipient base and message
> sizes on my system.

It's just a rough attempt to get in the ballpark, but I think the 
numbers are going to be fairly good for the general SMTP protocol.

> 10k is much larger than my average message size,

true. It was convenient (especially for me, since I needed that data for 
my big emarketing machine anyway, and our messages are 10-14K and 
35-45K). If you go to smaller messages, the advantages of the 
buddying-up drops (for a 1K message, instead of  N * 11K + M * .1K, it's 
N*2K + M * .1K) and the protocol overhead becomes more important. For 
larger messages, the advantage grows completely. For 1-2K messages, you 
might see the advantage drop to 30% or less, I haven't done the math.

This also ignores the MTA's ability to cache connections, by the way. 
But that's really a random process and impossible to model this way.

> I would argue that it should default to OFF

I'm not surprised. It's Barry's call, but I think the customized URL is 
useful enough we want people to use it unless they have to turn it off, 
we don't want to have to try to convince the people who install stuff 
and leave everything defaulted to turn it on.


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

It's not the pace of life that concerns me, it's the sudden stop at the 
end.



From chuqui@plaidworks.com  Sun Jun 17 16:41:56 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 08:41:56 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <20010617122003.C3895@orwell.bok.net>
Message-ID: <200106171533.f5HFXjh06371@plaidworks.com>

On Sunday, June 17, 2001, at 03:20 AM, Fil wrote:

>  My
> systems delivers 10K messages at the mean rate of 18000 per hour. When I
> send a message down a 130 000 subscribers' list, well, I have to wait 
> quite
> long befoore it's gone ; maybe I should buy some more bandwith.

It depends on how time sensitive the stuff is and when you send it. If 
you send out at 10PM and expect people to read it when they wake up, 
does it matter if they actually get it at 3AM or 6AM? But if it's time 
sensitive -- you have to worry about that issue. If the delay adds a few 
minutes, no big deal (but if it adds a few minutes * 100 messages a day; 
big deal, especially for the messages at the end of the day where you 
can get the "bad weather over O'hare" problem...)

> However there's another performance issue: how does postfix react when 
> it's
> got sent 130 000 emails to store and forward?

Disk I/O. That's the other issue here. You're adding to yoru network 
usage, you're also adding to your Disk I/O problem.

>  Currently I send it about
> 10000 messages that it breaks up one by one using. I don't know about 
> memory
> or disk issues there, but 130 000 * 10k = 1.3 Gbytes on disk:

It's a problem. network and disk are (IMHO) the two big performance 
issues in delivering e-mail (at least the two under your control. The 
third is the speed at which receiving machines will accept messages, but 
you can't buy everyone in the universe faster e-mail servers...)

the amount of disk it takes isn't an issue (within reason) -- remember, 
it's going to start sending right away, so message will be gone out of 
the queue. You don't queue it all up and then start delivery. But this 
generates disk IO, and that can start bogging you down if you don't tune 
things properly. That means taking advantage of sub-folders in your mail 
queue for any MTA that allows them (the #1 performance death for a 
typical sendmail system: write-locks on /var/spool/mqueue, since every 
sendmail process has to create files in that directory. If you haven't 
set up subfolders, you are (I say this in a nice way) an idiot. if you 
aren't using a version of sendmail that allows for them, I'll call you 
an idiot in a not-nice way. Anyone not running at least 8.10 is hosed, 
so forget them...

Most MTAs are sensitive to this and work to minimize the impact. Even 
sendmail finally figured it out. But you still need, in large e-mail 
environments, to look at splitting this across heads and spindles. My 
experiments have indicated you're better off having mail on separate 
spindles than you are building a RAID using those same spindles, for 
whatever that's worth. And if you have lots of RAM, you can start using 
ram disks, and then you have lots of fun... (yes, I've done that. It's 
amazing how much faster sendmail is when you remove the disk I/O on 
those directory inodes...)


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

95% of being a net.god is sounding persuasive
and convincing people you know what you're talking about, even when 
you're
making it up as you go along. (chuq von rospach, 1992)





From claw@kanga.nu  Sun Jun 17 17:22:40 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 09:22:40 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 00:46:47 PDT." <200106170738.f5H7cah28586@plaidworks.com>
References: <200106170738.f5H7cah28586@plaidworks.com>
Message-ID: <1411.992794960@kanga.nu>

On Sun, 17 Jun 2001 00:46:47 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Friday, June 15, 2001, at 01:19 PM, Barry A. Warsaw wrote:

> I would set Mailman's 2.1 default to have this turned ON...

Agreed.

> Barry's mileage may vary on his preferences for default, of
> course, and it's his show. I think the advantages of the
> customized URL/email capability is a huge one and most sites will
> benefit from it -- but the network hit might kill some sites, so
> we have to give them an easy ability to turn the feature off.

You also ignore local physical resource consumption.  Network
bandwidth and expense are not always the only constraining factors.
Mail systems tend to be disk IO constrained in addition to network
bound with file creat()/open() being the biggies.  Given a busy box
that tends to maintain a significant backlog, under VERP/RCPT_TO=1
inode exhaustion becomes a more probable case than with larger
envelopes (similar/identical curves to above).

  Yes, real mail admins know to mkfs /var/spool with a higher inode
  count than the rest of their systems.  I'll let you guess what
  percentage of mail admins actually do.

There are quite a few lists out there running off i486 boxes with
small disks.  Some of them have nice bandwidth but have horrible
disk IO.

  ObExample: Up until fairly recently svlug.org (which runs mailman)
  was an i486.  Excellent outbound bandwidth.  Lousy local physical
  resources.  Subscriber base there is in the low/middle single
  digit thousands IIRC.  (Thanks to VA things are much better now)

The README should enclude notes on these factors as well.

> What do y'all think? 

I suspect Nigel Metherington is going to chime in here,

I'm interested in also seeing the percentage case, if only for
better bounce handling.

> I've included mailman-developers on this reply, since while this
> started on mm-users, it really ought to be discussed on the
> developers list...

Damned right.

> Yes, I am an agent of Satan, but my duties are largely ceremonial.

How topical.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Sun Jun 17 17:32:33 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 09:32:33 -0700
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join without specifying pas swords
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 08:29:50 PDT." <200106171521.f5HFLdh06227@plaidworks.com>
References: <200106171521.f5HFLdh06227@plaidworks.com>
Message-ID: <17409.992795553@kanga.nu>

On Sun, 17 Jun 2001 08:29:50 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Sunday, June 17, 2001, at 06:21 AM, alex wetmore wrote:

>> I would argue that it should default to OFF

> I'm not surprised. It's Barry's call, but I think the customized
> URL is useful enough we want people to use it unless they have to
> turn it off, we don't want to have to try to convince the people
> who install stuff and leave everything defaulted to turn it on.

I spent some time on both sides of the fence as to which way to
default it.  I came out out on the ON side.

Reasons:

  There's a significant feature gain.

  Most of those new features help list members.

  All of them help the list owners.

  With VERP they also help the system over the longer term.

  Mailman becomes even more user friendly (by default).


The default to OFF case has the biggie:

  For most people, nothing will break and they'll have no surprises.

This is caveated by the fact that the only people that things will
break for are those that didn't read the README.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Sun Jun 17 17:39:47 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 09:39:47 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 08:41:56 PDT." <200106171533.f5HFXjh06371@plaidworks.com>
References: <200106171533.f5HFXjh06371@plaidworks.com>
Message-ID: <30333.992795987@kanga.nu>

On Sun, 17 Jun 2001 08:41:56 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> the amount of disk it takes isn't an issue (within reason) --
> remember, it's going to start sending right away, so message will
> be gone out of the queue. 

This is not a safe assumption.  Exim for instance will defer
deliveries if more than N messages are received in a single
connection.  As a result, you typically get no outbound deliveries
going on during a qrunner broadcast.

> You don't queue it all up and then start delivery.

Uhh.

> But this generates disk IO, and that can start bogging you down if
> you don't tune things properly. That means taking advantage of
> sub-folders in your mail queue for any MTA that allows them (the
> #1 performance death for a typical sendmail system: write-locks on
> /var/spool/mqueue, since every sendmail process has to create
> files in that directory. If you haven't set up subfolders, you are
> (I say this in a nice way) an idiot. if you aren't using a version
> of sendmail that allows for them, I'll call you an idiot in a
> not-nice way. Anyone not running at least 8.10 is hosed, so forget
> them...

Great READ/FAQ topic.

> Most MTAs are sensitive to this and work to minimize the
> impact. Even sendmail finally figured it out. But you still need,
> in large e-mail environments, to look at splitting this across
> heads and spindles. My experiments have indicated you're better
> off having mail on separate spindles than you are building a RAID
> using those same spindles, for whatever that's worth. 

I've done similar experiments with news spools.  The values are
incredibly subjective to RAID stripe size.  Bob Mende IIRC did some
interesting work here which I think he presented at LISA.  

  FWIW We ended up with a 1Meg strip size as the sweet spot, much
  bigger than we'd expected.

> And if you have lots of RAM, you can start using ram disks, and
> then you have lots of fun... (yes, I've done that. It's amazing
> how much faster sendmail is when you remove the disk I/O on those
> directory inodes...)

Silicon disks are another one.  At Critical Path we used solid state
disks for /var/spool and Qmail fairly, umm, whirred.  

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun 17 17:53:28 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 09:53:28 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <30333.992795987@kanga.nu>
Message-ID: <200106171645.f5HGjGh07300@plaidworks.com>

On Sunday, June 17, 2001, at 09:39 AM, J C Lawrence wrote:

> Exim for instance will defer
> deliveries if more than N messages are received in a single
> connection.  As a result, you typically get no outbound deliveries
> going on during a qrunner broadcast.

IMHO, I consider that seriously broken.

> I've done similar experiments with news spools.  The values are
> incredibly subjective to RAID stripe size.  Bob Mende IIRC did some
> interesting work here which I think he presented at LISA.
>
>   FWIW We ended up with a 1Meg strip size as the sweet spot, much
>   bigger than we'd expected.

I know someone who did the same, and found the best perforamnce iwth (I 
kid you not) 32 meg strip sizes.

> Silicon disks are another one.  At Critical Path we used solid state
> disks for /var/spool and Qmail fairly, umm, whirred.

But what I've found, for really large e-mail installations, there's 
always another bottleneck. The bigger/faster machine paradigm just 
doesn't scale after a while, so what I'm working on now is a new setup 
that I'm calling the "army of smurfs" design. I'm going to be buying 
lots of small/fast/cheap boxes, and not going to try to try to keep 
making that single monolithic machine do incrementally more.


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Funny, I don't remember being absent minded.




From jra@baylink.com  Sun Jun 17 17:57:20 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Sun, 17 Jun 2001 12:57:20 -0400
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106171645.f5HGjGh07300@plaidworks.com>; from Chuq Von Rospach <chuqui@plaidworks.com> on Sun, Jun 17, 2001 at 09:53:28AM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <20010617125720.47842@scfn.thpl.lib.fl.us>

On Sun, Jun 17, 2001 at 09:53:28AM -0700, Chuq Von Rospach wrote:
> But what I've found, for really large e-mail installations, there's 
> always another bottleneck. The bigger/faster machine paradigm just 
> doesn't scale after a while, so what I'm working on now is a new setup 
> that I'm calling the "army of smurfs" design. I'm going to be buying 
> lots of small/fast/cheap boxes, and not going to try to try to keep 
> making that single monolithic machine do incrementally more.

If you're talking about generic large mail farms, Chuq, you *really*
need to go find the Earthlink white paper on that and read it, if you
haven't already.  They have one on news, too.  Don't recall the URL;
Ask The Web<tm>.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From nb@thinkcoach.com  Sun Jun 17 19:45:53 2001
From: nb@thinkcoach.com (Norbert Bollow)
Date: Sun, 17 Jun 2001 20:45:53 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106171645.f5HGjGh07300@plaidworks.com> (message from Chuq Von
 Rospach on Sun, 17 Jun 2001 09:53:28 -0700)
References: <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <200106171845.f5HIjr916255@quill>

Chuq Von Rospach <chuqui@plaidworks.com> wrote (in two different
messages):

> >  Currently I send it about
> > 10000 messages that it breaks up one by one using. I don't know about 
> > memory
> > or disk issues there, but 130 000 * 10k = 1.3 Gbytes on disk:
> 
> It's a problem. network and disk are (IMHO) the two big performance 
> issues in delivering e-mail (at least the two under your control. The 
> third is the speed at which receiving machines will accept messages, but 
> you can't buy everyone in the universe faster e-mail servers...)
> 
> the amount of disk it takes isn't an issue (within reason) -- remember, 
> it's going to start sending right away, so message will be gone out of 
> the queue. You don't queue it all up and then start delivery.

I think it is certainly an issue - the disk partition with the
mailqueue must be big enough that even if there are network
problems at the time when all your digests are mailed out, all
the digests can be stored without problem.

This is not a problem with the qmail trick which I've explained
at http://mailman.cis.to/qmail-verh/ because there only one copy
of the message is stored in the mailqueue, which is then
customized by means of pattern substitutions on-the-fly when
qmail talks SMTP with the receiving mailservers.

But if Mailman customizes messages and passes one message per
recipient to the MTA, then you had better make sure that you
have a big enough mailqueue partition.

> that I'm calling the "army of smurfs" design. I'm going to be buying 
> lots of small/fast/cheap boxes, and not going to try to try to keep 
> making that single monolithic machine do incrementally more.

Ezmlm-idx has some really neat features for that, which I'd love
to see implemented in Mailman.

Greetings, Norbert.

-- 
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59     Fax +41 1 972 20 69      nb@freedevelopers.net


From fil@rezo.net  Sun Jun 17 19:58:58 2001
From: fil@rezo.net (Fil)
Date: Sun, 17 Jun 2001 20:58:58 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <200106171645.f5HGjGh07300@plaidworks.com>; from chuqui@plaidworks.com on Sun, Jun 17, 2001 at 09:53:28AM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <20010617205858.A7580@orwell.bok.net>

@ Chuq Von Rospach (chuqui@plaidworks.com) :
> But what I've found, for really large e-mail installations, there's 
> always another bottleneck. The bigger/faster machine paradigm just 
> doesn't scale after a while, so what I'm working on now is a new setup 
> that I'm calling the "army of smurfs" design. I'm going to be buying 
> lots of small/fast/cheap boxes, and not going to try to try to keep 
> making that single monolithic machine do incrementally more.

On my setup (postfix) there's a heavy use of the /etc/postfix/transport
feature, that redirects all domains with which I have a problem (like those
that are not always accepting mail I send) to a slave machine that is very
near (in terms of bandwidth) the first one. It reduces A LOT the disk
problems (mostly mailqueue becoming very heavy) -- maybe I should continue
this way with more domains being handled to slave machine(s). Is that the
option you're describing?

-- Fil



From claw@kanga.nu  Sun Jun 17 21:23:48 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 13:23:48 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 09:53:28 PDT." <200106171645.f5HGjGh07300@plaidworks.com>
References: <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <7111.992809428@kanga.nu>

On Sun, 17 Jun 2001 09:53:28 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Sunday, June 17, 2001, at 09:39 AM, J C Lawrence wrote:

>> Exim for instance will defer deliveries if more than N messages
>> are received in a single connection.  As a result, you typically
>> get no outbound deliveries going on during a qrunner broadcast.

> IMHO, I consider that seriously broken.

Its configurable.

>> I've done similar experiments with news spools.  The values are
>> incredibly subjective to RAID stripe size.  Bob Mende IIRC did
>> some interesting work here which I think he presented at LISA.
>> 
>> FWIW We ended up with a 1Meg strip size as the sweet spot, much
>> bigger than we'd expected.

> I know someone who did the same, and found the best perforamnce
> iwth (I kid you not) 32 meg strip sizes.

Not surprised.  Among other things its going to be sensitive to
number of spindles, RAID type, and feed characteristics.

>> Silicon disks are another one.  At Critical Path we used solid
>> state disks for /var/spool and Qmail fairly, umm, whirred.

> But what I've found, for really large e-mail installations,
> there's always another bottleneck. The bigger/faster machine
> paradigm just doesn't scale after a while, so what I'm working on
> now is a new setup that I'm calling the "army of smurfs"
> design. I'm going to be buying lots of small/fast/cheap boxes, and
> not going to try to try to keep making that single monolithic
> machine do incrementally more.

I've noticed that E-Machines are getting popular for precisely that
use/need.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From chuqui@plaidworks.com  Sun Jun 17 22:23:32 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Sun, 17 Jun 2001 14:23:32 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <20010617205858.A7580@orwell.bok.net>
Message-ID: <200106172115.f5HLFJh10888@plaidworks.com>

On Sunday, June 17, 2001, at 11:58 AM, Fil wrote:

> On my setup (postfix) there's a heavy use of the /etc/postfix/transport
> feature, that redirects all domains with which I have a problem

what's known as the "bog" (a term I ripped off from Infobeat's 
architecture). Try to deliver it once, exile it to the bog for non-real 
time delivery.

Infobeat's actually kinda nice, if you want ot get really hard-core 
about it. They deliver right out of the database into the client SMTP 
port, effectively sucking up the outgoing MTA into the application 
system. I've looked hard at doing that as well, but you start getting 
into the grimy details of dealing with all the MX weirdness and the 
like, and I've decided not to right an MTA right now, but instead to let 
the MTA writers figure out how to best do that. )

> problems (mostly mailqueue becoming very heavy) -- maybe I should 
> continue
> this way with more domains being handled to slave machine(s). Is that 
> the
> option you're describing?
>

Not really, but it's a good, legitimate option. When I was under 
sendmail 9, I implemented special slow queues as bogs and moved things 
there after 3 delivery tries. Under sendmail 8.11, I don't, because the 
sub-directory stuff allowed me to do away with having to deal with that 
from a performance standpoint.

What I'm designing is a system that will cause a daemon on a central 
server to connect to a bunch of machines in a farm and use them to 
simultaneously generate messages out into multiple SMTP queues -- you 
effectively hand a remote machine (an smtp smurf) a message template, 
then feed it data as fast as it can send. You get a very compact 
protocol between the two (since all you send over is the data to fill 
the template), and each one is noting but a mail-creation process 
feeding an MTA on a dedicated machine. And the rest, as they say, is 
simply tuning for maximum perforamnce without thrashing.

This isn't a discussion-list system, but the delivery setup could be 
adapted to that fairly easily. If you were going to do something similar 
on Mailman, you could do it by having a farm of SMTP outgoing machines 
under a round-robin with a short time-out, and making sure qrunner 
re-looks up the IP after every message. Do that, and then extend to 
allow for parallel qrunners, and you can buidl a heck of a mail list 
farm. 2.1 will do most of that fairly easily, the rest is figuring out 
and configuring the SMTP smurf farm and its round-robin.

In my case, I need to be able to take 40K length messages, and be able 
to build a system that'll ship out ~1,000,000 addresses an hour, with 
full customization (i.e. no piggybacking of adresses). Which might 
explain why I did 3+ hours of math last night on the bandwidth question; 
I needed it anyway, I'd been meaning to get to it, and as long as we 
were talking about it, it was a great excuse to build a model for my 
'real' work. My current system only does ~350-400,000 an hour with 
limited piggybacking of addresses, and doesn't do the full 
customization. But it also depends on a monolithic machine architecture, 
which simply can't scale infinitely. Right now, my big bottleneck on 
that machine is that my 100BaseT is full. I'm going to be bringing up a 
quad ethernet soon, but from there, unless you start talking about fiber 
and or trunking solutions, you're done. So rather than trying to eek out 
another 2% at ever greater engineering cost, we're moving to a smurf 
model, because you can buy a bunch of small, fast machines for the cost 
of a big honker with gigabit ethernet and a trunking system.

The downside is you add administrative complexity, plus you need to 
engineer getting the data where it needs to be (and the security of 
making sure nobody else uses your smurfs...). But those seem to be 
manageable. My current design includes three flavors of smurfs 
(smtp-out, smtp-in, and web), and I'm actually working on whether it 
makes sense take over a delegated sub-domain and run my own DNS, so I 
can dynamically move the smufts into whatever function I need -- it'd 
make a LOT of sense, from machine-usage terms, to be able to dedicate 
all but one or two smurfs to SMTP-out during the early delivery, and 
then start shunting them off one at a time into SMTP-in role or web-role 
to handle returned bounces, postmaster mail and user unsubscription 
requests. And once the bulge is done, take them offline and turn them 
into bounce-processing smurfs.... I could do more with fewer machines, 
but my office would end up looking like the Johnson Space center at 
launch time... (grin).





--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

USENET is a lot better after two or three eggnogs. We shouldn't allow
anyone on the net without a bottle of brandy. (chuq von rospach, 1992)



From claw@kanga.nu  Mon Jun 18 05:46:02 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 21:46:02 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 09:53:28 PDT." <200106171645.f5HGjGh07300@plaidworks.com>
References: <200106171645.f5HGjGh07300@plaidworks.com>
Message-ID: <18598.992839562@kanga.nu>

On Sun, 17 Jun 2001 09:53:28 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> On Sunday, June 17, 2001, at 09:39 AM, J C Lawrence wrote:

>> Exim for instance will defer deliveries if more than N messages
>> are received in a single connection.  As a result, you typically
>> get no outbound deliveries going on during a qrunner broadcast.

> IMHO, I consider that seriously broken.

It can also be viewed as an advantage.  Given a large inbound mail
load, Exim throttles itself to try and be maximally
available/responsive for any other large mail events that might
happen synchronously.  This is a seemingly fairly standard
philosophy of Exim's: Make sure you can always play nice.  

> Funny, I don't remember being absent minded.

Neither did I.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Mon Jun 18 05:50:23 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 21:50:23 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Fil <fil@rezo.net>
 of "Sun, 17 Jun 2001 20:58:58 +0200." <20010617205858.A7580@orwell.bok.net>
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>  <20010617205858.A7580@orwell.bok.net>
Message-ID: <22952.992839823@kanga.nu>

On Sun, 17 Jun 2001 20:58:58 +0200 
fil  <fil@rezo.net> wrote:

> On my setup (postfix) there's a heavy use of the
> /etc/postfix/transport feature, that redirects all domains with
> which I have a problem (like those that are not always accepting
> mail I send) to a slave machine that is very near (in terms of
> bandwidth) the first one. 

Back when I used to do this under Exim by parsing the mainlog for
messages which arrived long before their delivery time.  Given a
frequent high enough score on this, I'd then do a domain route to a
similar Bad Mail box.

It was nice to automate it.  No attention required.

> It reduces A LOT the disk problems (mostly mailqueue becoming very
> heavy) -- maybe I should continue this way with more domains being
> handled to slave machine(s). 

Did you have any automated way to collect and maintain the slow MX
list?  One thing I never did was to implement a system to rescind
the "slow" verdict on MXes should they come back to life for a
reasonable period.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From claw@kanga.nu  Mon Jun 18 05:59:08 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sun, 17 Jun 2001 21:59:08 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com>
 of "Sun, 17 Jun 2001 14:23:32 PDT." <200106172115.f5HLFJh10888@plaidworks.com>
References: <200106172115.f5HLFJh10888@plaidworks.com>
Message-ID: <31789.992840348@kanga.nu>

On Sun, 17 Jun 2001 14:23:32 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:

> This isn't a discussion-list system, but the delivery setup could
> be adapted to that fairly easily. If you were going to do
> something similar on Mailman, you could do it by having a farm of
> SMTP outgoing machines under a round-robin with a short time-out,
> and making sure qrunner re-looks up the IP after every message. Do
> that, and then extend to allow for parallel qrunners, and you can
> buidl a heck of a mail list farm. 2.1 will do most of that fairly
> easily, the rest is figuring out and configuring the SMTP smurf
> farm and its round-robin.

Its arguably cheaper/easier to instead us a load balancer box as the
SMTP target which then does a per-transaction round-robin to the
target nodes in the farm.  Fairly easy to do, just a little proxy,
and then let rip.  Mailman never knows any different, you've got
management abstraction in the proxy box, and can add, remove, and
fail out nodes transparently without any cacheing problems torquing
the queues.

> The downside is you add administrative complexity, plus you need
> to engineer getting the data where it needs to be (and the
> security of making sure nobody else uses your smurfs...). 

Sit the smurf farm behind a router that redirects all inbound port
25 connections to <where-ever>.  At that point the only access to
the smurfs is from the inside via your proxy box as above.  

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From Nigel.Metheringham@InTechnology.co.uk  Mon Jun 18 10:11:59 2001
From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham)
Date: 18 Jun 2001 10:11:59 +0100
Subject: [Mailman-Developers] Re: [Mailman-Users] Allowing users to join
 without specifying pas swords
In-Reply-To: <1411.992794960@kanga.nu>
References: <200106170738.f5H7cah28586@plaidworks.com>
 <1411.992794960@kanga.nu>
Message-ID: <992855524.19134.1.camel@gaspode.localnet>

On 17 Jun 2001 09:22:40 -0700, J C Lawrence wrote:
> I suspect Nigel Metherington is going to chime in here,

Definitely - you mispelt my name - I *hate* that :-)

Seriously, I've just come back to this fresh and its a big chunk to
take in at one reading.  What I will do is take a weeks logs from
the exim.org lists - which have a few lists of verious sizes, and
run the figures on deliveries and bandwidth uses.

	Nigel.

--
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ ----- Security is not an add-on -- security is a way of life ----- ]



From fil@rezo.net  Mon Jun 18 10:49:42 2001
From: fil@rezo.net (Fil)
Date: Mon, 18 Jun 2001 11:49:42 +0200
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <22952.992839823@kanga.nu>; from claw@kanga.nu on Sun, Jun 17, 2001 at 09:50:23PM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com> <20010617205858.A7580@orwell.bok.net> <fil@rezo.net> <22952.992839823@kanga.nu>
Message-ID: <20010618114942.E16222@orwell.bok.net>

> > It reduces A LOT the disk problems (mostly mailqueue becoming very
> > heavy) -- maybe I should continue this way with more domains being
> > handled to slave machine(s). 
> 
> Did you have any automated way to collect and maintain the slow MX
> list?  One thing I never did was to implement a system to rescind
> the "slow" verdict on MXes should they come back to life for a
> reasonable period.

Nope, I just eye-scan the postfix statistics and pick up some domains that
appear as painful. I wish I had an automatic pilot on this ;)

-- Fil



From claw@kanga.nu  Mon Jun 18 17:48:52 2001
From: claw@kanga.nu (J C Lawrence)
Date: Mon, 18 Jun 2001 09:48:52 -0700
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: Message from "Jay R. Ashworth" <jra@baylink.com>
 of "Sun, 17 Jun 2001 12:57:20 EDT." <20010617125720.47842@scfn.thpl.lib.fl.us>
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com>  <20010617125720.47842@scfn.thpl.lib.fl.us>
Message-ID: <23241.992882932@kanga.nu>

On Sun, 17 Jun 2001 12:57:20 -0400 
Jay R Ashworth <jra@baylink.com> wrote:

> On Sun, Jun 17, 2001 at 09:53:28AM -0700, Chuq Von Rospach wrote:
>> But what I've found, for really large e-mail installations,
>> there's always another bottleneck. The bigger/faster machine
>> paradigm just doesn't scale after a while, so what I'm working on
>> now is a new setup that I'm calling the "army of smurfs"
>> design. I'm going to be buying lots of small/fast/cheap boxes,
>> and not going to try to try to keep making that single monolithic
>> machine do incrementally more.

> If you're talking about generic large mail farms, Chuq, you
> *really* need to go find the Earthlink white paper on that and
> read it, if you haven't already.  They have one on news, too.
> Don't recall the URL; Ask The Web<tm>.

http://www.earthlink.net/about/papers/mailarch.html
http://www.earthlink.net/about/papers/scalenews.html

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jra@baylink.com  Mon Jun 18 18:34:18 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Mon, 18 Jun 2001 13:34:18 -0400
Subject: [Mailman-Developers] Re: To VERP or not to VERP?
In-Reply-To: <23241.992882932@kanga.nu>; from J C Lawrence <claw@kanga.nu> on Mon, Jun 18, 2001 at 09:48:52AM -0700
References: <30333.992795987@kanga.nu> <200106171645.f5HGjGh07300@plaidworks.com> <20010617125720.47842@scfn.thpl.lib.fl.us> <jra@baylink.com> <23241.992882932@kanga.nu>
Message-ID: <20010618133418.43542@scfn.thpl.lib.fl.us>

On Mon, Jun 18, 2001 at 09:48:52AM -0700, J C Lawrence wrote:
> > If you're talking about generic large mail farms, Chuq, you
> > *really* need to go find the Earthlink white paper on that and
> > read it, if you haven't already.  They have one on news, too.
> > Don't recall the URL; Ask The Web<tm>.
> 
> http://www.earthlink.net/about/papers/mailarch.html
> http://www.earthlink.net/about/papers/scalenews.html

Them was the ones; thanks, Joe.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From carson@taltos.org  Mon Jun 18 22:09:06 2001
From: carson@taltos.org (Carson Gaspar)
Date: Mon, 18 Jun 2001 14:09:06 -0700
Subject: [Mailman-Developers] Handling non-fatal "bounces"
Message-ID: <438450968.992873346@ZATHROS>

So we converted the firewalls mailing list to mailman, and we're now being 
inundated by bounce messages that mailman isn't handling. I'm going to 
write bounce modules for the actual bounces, but I can't figure out how to 
handle non-fatal errors (message could not be delivered, will retry soon, 
etc.).

What I want to do is ignore the bounce (don't flag the list member), but 
_not_ forward the message to the list admins. The current API seems 
incapable of doing this. Am I missing something?

-- 
Carson Gaspar - carson@taltos.org
Queen trapped in a butch body


From barry@digicool.com  Mon Jun 18 22:21:19 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 18 Jun 2001 17:21:19 -0400
Subject: [Mailman-Developers] Handling non-fatal "bounces"
References: <438450968.992873346@ZATHROS>
Message-ID: <15150.28879.872996.317919@anthem.wooz.org>

>>>>> "CG" == Carson Gaspar <carson@taltos.org> writes:

    CG> So we converted the firewalls mailing list to mailman, and
    CG> we're now being inundated by bounce messages that mailman
    CG> isn't handling. I'm going to write bounce modules for the
    CG> actual bounces, but I can't figure out how to handle non-fatal
    CG> errors (message could not be delivered, will retry soon,
    CG> etc.).

    CG> What I want to do is ignore the bounce (don't flag the list
    CG> member), but _not_ forward the message to the list admins. The
    CG> current API seems incapable of doing this. Am I missing
    CG> something?

First off, I consider it very bad manners for a side to send non-fatal
warnings (i.e. retries) for messages coming from a list.  IOW, if the
message has "Precedence: bulk" a site should /not/ send a try
notification.  Most MTAs I believe either suppress these by default,
or can be configured to do so.  I seem to remember a discussion
concerning an Exim configuration variable to control this a while back
(perhaps Nigel can elaborate).

In general, I haven't added bounce handlers to detect these kinds of
messages, and you're correct that the interface in BouncerAPI.py
doesn't really support an "ignore this, they're bogus" return value.
Usually when I'm bombarded by these, I send a, er, nicely worded
message to the postmaster and the warnings usually stop.

It'd be fairly easy to extend BouncerAPI.py to handle ignorable
bounces, so I'll try to add something for 2.1.

One question: should Mailman support doing an (optional) auto-kvetch
back to the site's postmaster?

-Barry


From jra@baylink.com  Mon Jun 18 22:42:31 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Mon, 18 Jun 2001 17:42:31 -0400
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: <15150.28879.872996.317919@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Mon, Jun 18, 2001 at 05:21:19PM -0400
References: <438450968.992873346@ZATHROS> <15150.28879.872996.317919@anthem.wooz.org>
Message-ID: <20010618174231.05757@scfn.thpl.lib.fl.us>

On Mon, Jun 18, 2001 at 05:21:19PM -0400, Barry A. Warsaw wrote:
> One question: should Mailman support doing an (optional) auto-kvetch
> back to the site's postmaster?

Two words: "Sorcerer's Apprentice".

Cheers,
-- jr 'IE: "no" :-)' a
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From chuqui@plaidworks.com  Mon Jun 18 23:37:14 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Mon, 18 Jun 2001 15:37:14 -0700
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: <20010618174231.05757@scfn.thpl.lib.fl.us>
Message-ID: <200106182235.f5IMZV414826@lists.apple.com>

On Monday, June 18, 2001, at 02:42 PM, Jay R. Ashworth wrote:

> On Mon, Jun 18, 2001 at 05:21:19PM -0400, Barry A. Warsaw wrote:
>> One question: should Mailman support doing an (optional) auto-kvetch
>> back to the site's postmaster?
>
> Two words: "Sorcerer's Apprentice".
>

treat them as hard bounces and if someone gets unsubscribed, encourage 
them to whine at their admin.

sending stuff to the admin directly from the outside will only piss off 
the admin. it won't solve anything, and you're kvetching on a point that 
is arguable depending on who's side of the argument you're on (if you 
want to kvetch at things, kvetch at places that send stupid vacation 
messages to the entire universe, endlessly, or places that send 
"confirming we read your message" messages to mail lists. Those are a 
LOT less ambiguously screwed up than the not-delivered-yet 
pain-in-the-necks...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

I'm really easy to get along with once you
people learn to worship me.



From claw@2wire.com  Tue Jun 19 01:04:15 2001
From: claw@2wire.com (J C Lawrence)
Date: Mon, 18 Jun 2001 17:04:15 -0700
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: Message from "Jay R. Ashworth" <jra@baylink.com>
 of "Mon, 18 Jun 2001 17:42:31 EDT." <20010618174231.05757@scfn.thpl.lib.fl.us>
References: <438450968.992873346@ZATHROS> <15150.28879.872996.317919@anthem.wooz.org>  <20010618174231.05757@scfn.thpl.lib.fl.us>
Message-ID: <26230.992909055@2wire.com>

On Mon, 18 Jun 2001 17:42:31 -0400 
Jay R Ashworth <jra@baylink.com> wrote:

> On Mon, Jun 18, 2001 at 05:21:19PM -0400, Barry A. Warsaw wrote:
>> One question: should Mailman support doing an (optional)
>> auto-kvetch back to the site's postmaster?

> Two words: "Sorcerer's Apprentice".

Limit one per day.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From admin@xpertindexing.com  Tue Jun 19 08:18:21 2001
From: admin@xpertindexing.com (admin@xpertindexing.com)
Date: 19 Jun 2001 07:18:21 -0000
Subject: [Mailman-Developers] search engine indexing is crucial to success!
Message-ID: <20010619071821.17140.qmail@ns2.differentworlds.victoria.bc.ca>

	Search engines can account for up to 80% of website
traffic. Having a beautiful site is important but without
the traffic there is no one to appreciate it and
consequently NO BUSINESS.
	Indexing with the search engines seems as simple as filling
in the blanks but getting good positions is NOT as easy! Our
staff can research your site and get you serious shoppers by
getting your site up in the top 15 positions with keyword
strings that work.
	Please visit our site to see how we can help you get the
exposure you need to be successful.

	http://www.xpertindexing.com

	Thank you for your time and attention

Kind Regards,
Graeme Skinner - Administration
admin@xpertindexing.com

To be removed from our email list please click here http://www.xpertindexing.com/X/remove.html?email=mailman-developers@python.org


From Nigel.Metheringham@InTechnology.co.uk  Tue Jun 19 09:42:06 2001
From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham)
Date: 19 Jun 2001 09:42:06 +0100
Subject: [Mailman-Developers] Handling non-fatal "bounces"
In-Reply-To: <15150.28879.872996.317919@anthem.wooz.org>
References: <438450968.992873346@ZATHROS>
 <15150.28879.872996.317919@anthem.wooz.org>
Message-ID: <992940131.11387.1.camel@gaspode.localnet>

On 18 Jun 2001 17:21:19 -0400, Barry A. Warsaw wrote:
> First off, I consider it very bad manners for a side to send non-fatal
> warnings (i.e. retries) for messages coming from a list.  IOW, if the
> message has "Precedence: bulk" a site should /not/ send a try
> notification.  Most MTAs I believe either suppress these by default,
> or can be configured to do so.  I seem to remember a discussion
> concerning an Exim configuration variable to control this a while back
> (perhaps Nigel can elaborate).

Sure.

Exim can send delay warning messages out at configurable intervals - see
  http://www.exim.org/exim-html-3.20/doc/html/spec_11.html#SEC201

A condition variable also controls what types of messages do get delay
warnings sent out.  By default this does not send warnings out in
response to messages with Precedence: set to bulk, list or junk.

Older versions of exim (I guess pre-3.x - which are prehistoric now) did
not have the defaults appropriately set.  If you are using a version of
exim that old then you should upgrade, or if this is impossible then set
delay_warning_condition appropriately - documentation for this (from the
3.2x documentation - but this hasn't changed since its original
introduction) is at
  http://www.exim.org/exim-html-3.20/doc/html/spec_11.html#SEC202

> It'd be fairly easy to extend BouncerAPI.py to handle ignorable
> bounces, so I'll try to add something for 2.1.

That would be good.  Is there a way of hacking it now?  [return an
impossible address for example]

> One question: should Mailman support doing an (optional) auto-kvetch
> back to the site's postmaster?

My evil twin says yes to this... however since those people that have
their systems so badly configured that they send bounce messages for
list mail also don't respond to postmaster mail - one site that is
causing me particular problems in that respect currently I now blacklist
completely.  Autoresponses in error conditions are a good way of
building serious mail loops.

	Nigel.

--
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ ----- Security is not an add-on -- security is a way of life ----- ]



From Dale Newfield <Dale@Newfield.org>  Tue Jun 19 12:45:47 2001
From: Dale Newfield <Dale@Newfield.org> (Dale Newfield)
Date: Tue, 19 Jun 2001 07:45:47 -0400 (EDT)
Subject: [Mailman-Developers] searching is crucial to success
In-Reply-To: <20010619071821.17140.qmail@ns2.differentworlds.victoria.bc.ca>
Message-ID: <Pine.SUN.4.33.0106190738380.3715-100000@adder.cs.Virginia.EDU>

While I know this was spam, the subject points to something I've been
thinking of bringing up.  I've only just started using a mailman
installation that has archiving turned on, and pipermail seems reasonable
enough, but what it really seems it needs is a search engine.  Has anyone
integrated some "grep -l" style script to give it one?

-Dale



From Nigel.Metheringham@InTechnology.co.uk  Tue Jun 19 13:12:00 2001
From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham)
Date: 19 Jun 2001 13:12:00 +0100
Subject: [Mailman-Developers] searching is crucial to success
In-Reply-To: <Pine.SUN.4.33.0106190738380.3715-100000@adder.cs.Virginia.EDU>
References: <Pine.SUN.4.33.0106190738380.3715-100000@adder.cs.Virginia.EDU>
Message-ID: <992952725.11629.2.camel@gaspode.localnet>

On 19 Jun 2001 07:45:47 -0400, Dale Newfield wrote:
> 
> While I know this was spam, the subject points to something I've been
> thinking of bringing up.  I've only just started using a mailman
> installation that has archiving turned on, and pipermail seems reasonable
> enough, but what it really seems it needs is a search engine.  Has anyone
> integrated some "grep -l" style script to give it one?

There are some patches in the patch
archive at sourceforge to add htdig
indexing to pipermail.

Have a look at
	http://www.exim.org/pipermail/exim-users/

for a demo

	Nigel.

--
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ ----- Security is not an add-on -- security is a way of life ----- ]



From etoffi@users.sourceforge.net  Wed Jun 20 16:20:03 2001
From: etoffi@users.sourceforge.net (Aluo Nowu)
Date: Wed, 20 Jun 2001 08:20:03 -0700
Subject: [Mailman-Developers] (no subject)
Message-ID: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>

From: etoffi jones <etoffi@bigfoot.com>
To: mailman-developers@python.org
Reply-To: etoffi@bigfoot.com
Organization: my company
Date: Wed, 20 Jun 2001 08:12:13
Subject: bounce with me
X-Priority: 3 (Normal)
Cc: etoffi jones <etoffi@softhome.net>
X-Mailer: Foobar 1.0 (Foobar Enterprises Inc Ltd Pty GmbH)
Content-Type: text/plain; charset="us-ascii"

please keep me on cc:

wouldn't it be just great if Mailman lists could tell you what messages you 
have bounced (and provide a way to get them of course =P), just like ezmlm?

wouldn't it?

for example, the Return-Path could be modified like so:

<foobar-return-500-lazyman=mailserver.org@lists.baz.quux>

(somebody should create a quux tld)

1) list name
2) 'return'
3) msg num
4) email addr (with = instead of @)

if any experts might be able to tell me that this is not to much to 
implement, i might be obliged to look into it myself. hehe.
-or-
for the ones where the latter doesnt apply, is this a good idea?  has there 
been any problems with this type of feature that you are aware of?


--
etoffi <http://oluworld.sourceforge.net/>



From claw@kanga.nu  Wed Jun 20 17:18:26 2001
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 20 Jun 2001 09:18:26 -0700
Subject: [Mailman-Developers] (no subject)
In-Reply-To: Message from Aluo Nowu <etoffi@users.sourceforge.net>
 of "Wed, 20 Jun 2001 08:20:03 PDT." <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
Message-ID: <29278.993053906@kanga.nu>

On Wed, 20 Jun 2001 08:20:03 -0700 
Aluo Nowu <etoffi@users.sourceforge.net> wrote:

> wouldn't it be just great if Mailman lists could tell you what
> messages you have bounced (and provide a way to get them of course
> =P), just like ezmlm?

Sure.

> <foobar-return-500-lazyman=mailserver.org@lists.baz.quux>

Message numbers are the relatively uninteresting case as they are an
arbitrary value that Mailman may not (usually doesn't) actually know
at the time of broadcast, and which further, doesn't actually apply
or necessarily exist for those using external archivers.

Message-IDs would be a better and more guaranteed portable route and
in the general case don't need to be embedded as you can already
find them in the bounce.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From etoffi@softhome.net  Thu Jun 21 06:33:36 2001
From: etoffi@softhome.net (etoffi@softhome.net)
Date: Thu, 21 Jun 2001 05:33:36 GMT
Subject: [Mailman-Developers] (no subject)
In-Reply-To: <29278.993053906@kanga.nu>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
 <29278.993053906@kanga.nu>
Message-ID: <20010621053337.24065.qmail@softhome.net>

please keep me on cc: etoffi@bigfoot.com

J C Lawrence writes:

> On Wed, 20 Jun 2001 08:20:03 -0700 
> Aluo Nowu <etoffi@users.sourceforge.net> wrote:
> 

[snip]

> Message numbers are the relatively uninteresting case as they are an
> arbitrary value that Mailman may not (usually doesn't) actually know
> at the time of broadcast, and which further, doesn't actually apply
> or necessarily exist for those using external archivers.

so mailman does _no_ storage of messages after they are sent?
if so, i applaud task separation.

> Message-IDs would be a better and more guaranteed portable route and
> in the general case don't need to be embedded as you can already
> find them in the bounce.

given that mailman does _not_ hold onto messages, a separate
program/component/thingydoodle would be the best way to go, or modifing the
code directly?  

maybe a separate, "virtual" list?

ps: i'm quite sure i should start looking at the code now.

> -- 
> J C Lawrence                                       claw@kanga.nu
> ---------(*)                          http://www.kanga.nu/~claw/
> The pressure to survive and rhetoric may make strange bedfellows


--
etoffi <http://oluworld.sourceforge.net/>



From claw@kanga.nu  Thu Jun 21 08:31:40 2001
From: claw@kanga.nu (J C Lawrence)
Date: Thu, 21 Jun 2001 00:31:40 -0700
Subject: [Mailman-Developers] (no subject)
In-Reply-To: Message from etoffi@softhome.net
 of "Thu, 21 Jun 2001 05:33:36 GMT." <20010621053337.24065.qmail@softhome.net>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net> <29278.993053906@kanga.nu>  <20010621053337.24065.qmail@softhome.net>
Message-ID: <28562.993108700@kanga.nu>

On Thu, 21 Jun 2001 05:33:36 GMT 
etoffi  <etoffi@softhome.net> wrote:

> J C Lawrence writes:

>> On Wed, 20 Jun 2001 08:20:03 -0700 Aluo Nowu
>> <etoffi@users.sourceforge.net> wrote:

>> Message numbers are the relatively uninteresting case as they are
>> an arbitrary value that Mailman may not (usually doesn't)
>> actually know at the time of broadcast, and which further,
>> doesn't actually apply or necessarily exist for those using
>> external archivers.

> so mailman does _no_ storage of messages after they are sent?  if
> so, i applaud task separation.

Mailman has an internal archiver which may or may not be enabled for
a given list.  By default it is enabled.  In my case it is disabled
as I use an external archiver (MHonArc) which operated asynchroously
with regard to the list.  

Archiving using the internal pipermail archiver takes place under
the qrunner context when the message is broadcast.

>> Message-IDs would be a better and more guaranteed portable route
>> and in the general case don't need to be embedded as you can
>> already find them in the bounce.

> given that mailman does _not_ hold onto messages...

It *may* not.  More specifically it does not (when using the
internal archiver) in a format friendly to re-access/sending (web
and mbox).

> a separate program/component/thingydoodle would be the best way to
> go, or modifing the code directly?

> maybe a separate, "virtual" list?

> ps: i'm quite sure i should start looking at the code now.

You're trying to solve the wrong problem.  MessageIDs effectively
uniquely identify messages.  They are what you are looking for:  A
way of identifying a message.  Don't try and re-invent a poor shadow
of something that is already there.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From etoffi@softhome.net  Fri Jun 22 02:35:22 2001
From: etoffi@softhome.net (etoffi@softhome.net)
Date: Fri, 22 Jun 2001 01:35:22 GMT
Subject: [Mailman-Developers] (no subject)
In-Reply-To: <28562.993108700@kanga.nu>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net>
 <29278.993053906@kanga.nu>
 <20010621053337.24065.qmail@softhome.net>
 <28562.993108700@kanga.nu>
Message-ID: <20010622013522.1507.qmail@softhome.net>

(just in case any new people reply, please keep me on cc!)

J C Lawrence writes:

> You're trying to solve the wrong problem.  MessageIDs effectively
> uniquely identify messages.  They are what you are looking for:  A
> way of identifying a message.  Don't try and re-invent a poor shadow
> of something that is already there.

well i for one actually think message numbers are nice to say the least.
but the difference between [message numbers and message ids] id 
irrelevant in this context.  one thing i would like to say about message
numbers before leaving this part of the conversation is that i can create 
my own list archive, which is automatically synced with all others because 
i have a "master" number.  maybe this could be an option (for people
who like this point)

either way, my idea is to have a unique value that represents each 
message accepted to a list and a map of subscriber addresses and missed
message [unique values].  Mailman could then try for, let's say, two 
weeks, then automatically unsubscribe the bounced user or put them 
"on hold."

> -- 
> J C Lawrence                                       claw@kanga.nu
> ---------(*)                          http://www.kanga.nu/~claw/
> The pressure to survive and rhetoric may make strange bedfellows


--
etoffi <http://oluworld.sourceforge.net/>



From carson@taltos.org  Fri Jun 22 02:51:18 2001
From: carson@taltos.org (Carson Gaspar)
Date: Thu, 21 Jun 2001 18:51:18 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
Message-ID: <714582734.993149478@ZATHROS>

As I understand it, mailman operates by receiving mail to one of 3 
addresses (list, list-request, list-admin), flagging the message as a post, 
request, or bounce/admin message, and adding it to qfiles. qrunner then 
processes qfiles and handles everything.

This doesn't work for large lists. It has 2 major problems:

- large numbers of bounces prevent list mail and list requests from being 
processed
- a flat directory structure is a performance nightmare on non-btree dir 
filesystems

To be specific, the firewalls mailing list had accumulated over 20,000 
bounces in qfiles, which was preventing anything from getting done, and 
making the machine _very_ unhappy.

So I recommend a quick fix of splitting the queue into 3 parts, and a 
medium term fix of adopting one of the tiered directory structures 
(postfix, new sendmail, etc.).

-- 
Carson Gaspar - carson@taltos.org
Queen trapped in a butch body


From chuqui@plaidworks.com  Fri Jun 22 04:24:44 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 21 Jun 2001 20:24:44 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <714582734.993149478@ZATHROS>
Message-ID: <200106220316.f5M3GLh30327@plaidworks.com>

On Thursday, June 21, 2001, at 06:51 PM, Carson Gaspar wrote:

> So I recommend a quick fix of splitting the queue into 3 parts, and a 
> medium term fix of adopting one of the tiered directory structures 
> (postfix, new sendmail, etc.).
>

it's actually not a quick fix, but if you check the archives, you'll see 
it's already part of 2.1...


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

The first rule of holes: If you are in one, stop digging.



From claw@kanga.nu  Fri Jun 22 05:57:13 2001
From: claw@kanga.nu (claw@kanga.nu)
Date: Thu, 21 Jun 2001 21:57:13 -0700
Subject: [Mailman-Developers] (no subject)
In-Reply-To: Message from etoffi@softhome.net
 of "Fri, 22 Jun 2001 01:35:22 GMT." <20010622013522.1507.qmail@softhome.net>
References: <E15Cjlz-0000qI-00@usw-pr-shell2.sourceforge.net> <29278.993053906@kanga.nu> <20010621053337.24065.qmail@softhome.net> <28562.993108700@kanga.nu>  <20010622013522.1507.qmail@softhome.net>
Message-ID: <12002.993185833@2wire.com>

On Fri, 22 Jun 2001 01:35:22 GMT 
etoffi  <etoffi@softhome.net> wrote:

> J C Lawrence writes:

> one thing i would like to say about message numbers before leaving
> this part of the conversation is that i can create my own list
> archive, which is automatically synced with all others because i
> have a "master" number.  maybe this could be an option (for people
> who like this point)

There is little preventing you from using MessageIDs to and for the
same purpose.  The only difference is that literal numbers are a bit
more human friendly than MessageIDs.  I argue that this is a false
economy as, handled properly the MessageID's would never have to be
human processed but could be embedded in URLs and pre-canned
commands ready to email.

> either way, my idea is to have a unique value that represents each
> message accepted to a list and a map of subscriber addresses and
> missed message [unique values].  

Not a bad idea.  I've got a CGI that does MessageID based lookups on
MHonArc archives (give it the MessageId it returns the archive
page).  It wouldn't be difficult to ad a mapping back to the
original message.

  In fact I'm about to be doing precisely this by adding a function
  to my archives such that you can have the original copy of any
  list post emailed to you.

As for the tracking of missed messages by subscribers this requires
VERP support as you can't guarantee taht the MessageID is available
in a bouce.  VERP support is currently under discussion as a
possible future optional feature -- it comes with a number of other
fairly chunky disadvantages.

> Mailman could then try for, let's say, two weeks, then
> automatically unsubscribe the bounced user or put them "on hold."

Automatic resends of bounced/missed posts my the MLM is an
interesting idea.  I don't like it from an abstraction/layering
model, but I can see why the interest.  Given a VERP supporting MLM
I'd prefer a pattern ala:

  -- Member bounces N messages
  -- Member successfully receives M messages as determined by the
  fact that no bounces for them is received for Q days.
  -- Mailman emails a list of the missed MessageIDs to the member
  along with instructions on how to retrieve/read the missed
  messages.  

The contents of the "how to retrieve X message" would have to be
tailored fairly heavily depending on the configuration of the list
in question (eg archiver turned on or off, use of an external
archiver, use of a subscribed archiver, external retrieval methods,
etc).

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From barry@digicool.com  Fri Jun 22 06:59:28 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 01:59:28 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
References: <714582734.993149478@ZATHROS>
Message-ID: <15154.57024.617224.686817@anthem.wooz.org>

>>>>> "CG" == Carson Gaspar <carson@taltos.org> writes:

    CG> So I recommend a quick fix of splitting the queue into 3
    CG> parts, and a medium term fix of adopting one of the tiered
    CG> directory structures (postfix, new sendmail, etc.).

Mailman 2.1's queue is split into at least 7 subdirectories,
specifically for:

- incoming posts from the MTA

- incoming commands (i.e. bounces, -request, -owner, -admin, -join, -leave)

- outgoing mail to the MTA

- outgoing mail to the archiver

- outgoing to the nntpd

- the "shunt" queue (for uncaught system errors)

- the "virgin" queue (for messages crafted by Mailman)

It's fairly easy to add more queues, although I'm not sure what else
would be useful.  Some other features of the 2.1 queue system:

1) FIFO order is guaranteed

2) Files are "randomly" distributed in a 120 bit hash space for
   no-lock cooperative multiprocessing.

3) Different qrunners can be assigned different priorities (i.e. you
   can run your incoming posts and MTA-bound queues more often then
   your archiver, nntpd, or command processing queues).

4) The qrunners are long running processes, monitored by a cron
   spawned watchdog.  Pros: on a warmed up system, delivery occurs
   almost immediately, with start up delays amortized over the life of
   the qrunner (Python 2.0's cyclic garbage collector helps keep
   memory usage under control).  Cons: debugging is, er, more
   challenging because you have to kill the master qrunner whenever
   you (really, I ;) make a change to the code.

All in all, while I have field tested it yet, I think the 2.1 queue
runner is miles ahead of what's in 2.0.

Cheers,
-Barry


From chuqui@plaidworks.com  Fri Jun 22 07:22:04 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Thu, 21 Jun 2001 23:22:04 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <200106220613.f5M6Dfh32559@plaidworks.com>

On Thursday, June 21, 2001, at 10:59 PM, Barry A. Warsaw wrote:

> It's fairly easy to add more queues, although I'm not sure what else
> would be useful.

Here's one -- multiple outqueuess to the MTA. Why?

Take a really large mailman system, one that's outgrown a single 
machine. Add a dedicated delivery machine. Now, outgrow that. So add a 
second. Right now, you'd have to do that with some DNS round-robin 
magic, or hacking the code. Instead, allow defining 1-N outgoing queues 
to different MTAs, and have mailman place every outgoing message in one 
of them either in sequence or random (or make it configurable. Maybe 
nthe best way to do this is to do it randomly, but assign a percentage 
to each queue, so you could weight towards faster/bigger machines and 
away from smaller/slower ones.

Then, each one has a qrunner tihng delivering into that SMTP port. And 
for redundancy, if the server it's supposed to send to is down, that 
qrunner could requeue to the other outgoing queue(s), so a down machine 
wouldn't affect you.

Run it one weird step further out, and you could define outgoing queues 
that are NEVER used, unless the main SMTP queue is down. Sort of like a 
fallback MX.

All of this is possible outside of mailman -- but it seems like it ought 
to be fairly easy to build into mailman, so you don't have to fall into 
DNS magic or proxies or any of the stuff we talked about last week...

> 3) Different qrunners can be assigned different priorities (i.e. you
>    can run your incoming posts and MTA-bound queues more often then
>    your archiver, nntpd, or command processing queues).

Can you define bounce processing to time the server is otherwise idle?


--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Always look away from the obvious answers, because if you don't find
a better one, you can always go back to them on short notice.




From vizisz@freemail.hu  Fri Jun 22 11:42:29 2001
From: vizisz@freemail.hu (Vizi Szilard)
Date: Fri, 22 Jun 2001 12:42:29 +0200
Subject: [Mailman-Developers] Two versions on the same host
Message-ID: <20010622124228.C1844@freemail.hu>

Hy Everyone,

Previosly I asked Barry, but he could not answer yet.

I have installed to my machine the latest version from the CVS beside 
to the perfectly working 2.0.5. I want to play with the newest version,
but I do not want to bust up the working version. So I used the following
options in the configure:
./configure --prefix=/home/mailman2 --with-username=mailman2 --with-groupname=
mailman2 --with-cgi-gid=233 --with-mail-gid=12

In the Apache conf for the ScriptAlias I gave /mailman2 since /mailman is
for the version 2.0.5. I changed the crontab to prevent 2 different
versions running in the same time.

Mailman in the new directory working almost perfectly, but when I click
to a link the url would be like this (eg. in the listinfo page):
   http://tatooin.sol.vein.hu/mailman/admin
But it have to be like this for the proper working:
   http://tatooin.sol.vein.hu/mailman2/admin  

So I could not play with the beta version.
Any suggestion how can I solve this problem?
(You can take a look at this problem in the above URLs, if our net
is working. The bad weathers ruined our network early on this week.)

Bye,.

Szilard Vizi
-------------
mailto:vizisz@freemail.hu             UIN:10676592


From thomas@xs4all.net  Fri Jun 22 12:14:08 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 22 Jun 2001 13:14:08 +0200
Subject: [Mailman-Developers] Two versions on the same host
In-Reply-To: <20010622124228.C1844@freemail.hu>
References: <20010622124228.C1844@freemail.hu>
Message-ID: <20010622131408.L8098@xs4all.nl>

On Fri, Jun 22, 2001 at 12:42:29PM +0200, Vizi Szilard wrote:

> Previosly I asked Barry, but he could not answer yet.

> I have installed to my machine the latest version from the CVS beside 
> to the perfectly working 2.0.5. I want to play with the newest version,
> but I do not want to bust up the working version. So I used the following
> options in the configure:
> ./configure --prefix=/home/mailman2 --with-username=mailman2 --with-groupname=
> mailman2 --with-cgi-gid=233 --with-mail-gid=12
> 
> In the Apache conf for the ScriptAlias I gave /mailman2 since /mailman is
> for the version 2.0.5. I changed the crontab to prevent 2 different
> versions running in the same time.
> 
> Mailman in the new directory working almost perfectly, but when I click
> to a link the url would be like this (eg. in the listinfo page):
>    http://tatooin.sol.vein.hu/mailman/admin
> But it have to be like this for the proper working:
>    http://tatooin.sol.vein.hu/mailman2/admin  
> 
> So I could not play with the beta version.
> Any suggestion how can I solve this problem?
> (You can take a look at this problem in the above URLs, if our net
> is working. The bad weathers ruined our network early on this week.)

Try editing 'DEFAULT_URL' in Mailman/Defaults.py.

-- 
Thomas Wouters <thomas@xs4all.net>

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


From vizisz@freemail.hu  Fri Jun 22 12:45:35 2001
From: vizisz@freemail.hu (Vizi Szilard)
Date: Fri, 22 Jun 2001 13:45:35 +0200
Subject: [Mailman-Developers] Re: Two versions on the same host
In-Reply-To: <20010622131408.L8098@xs4all.nl>; from thomas@xs4all.net on Fri, Jun 22, 2001 at 01:14:08PM +0200
References: <20010622124228.C1844@freemail.hu> <20010622131408.L8098@xs4all.nl>
Message-ID: <20010622134534.D1844@freemail.hu>

Thomas Wouters wrote:
> On Fri, Jun 22, 2001 at 12:42:29PM +0200, Vizi Szilard wrote:
> > Mailman in the new directory working almost perfectly, but when I click
> > to a link the url would be like this (eg. in the listinfo page):
> >    http://tatooin.sol.vein.hu/mailman/admin
> > But it have to be like this for the proper working:
> >    http://tatooin.sol.vein.hu/mailman2/admin  
> > 
> 
> Try editing 'DEFAULT_URL' in Mailman/Defaults.py.
Nop, still does not work.
Even with DEFAULT_URL='http://tatooin.sol.vein.hu/mailman2/' in mm_cfg.py

It is still searching my test list under 
http://tatooin.sol.vein.hu/mailman/listinfo/testing

The version is 2.1a2 
bin/check_perms says no trouble
 
Szilard Vizi
-------------
mailto:vizisz@freemail.hu             UIN:10676592


From thomas@xs4all.net  Fri Jun 22 13:11:41 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Fri, 22 Jun 2001 14:11:41 +0200
Subject: [Mailman-Developers] Re: Two versions on the same host
In-Reply-To: <20010622134534.D1844@freemail.hu>
References: <20010622124228.C1844@freemail.hu> <20010622131408.L8098@xs4all.nl> <20010622134534.D1844@freemail.hu>
Message-ID: <20010622141141.M8098@xs4all.nl>

On Fri, Jun 22, 2001 at 01:45:35PM +0200, Vizi Szilard wrote:
> Thomas Wouters wrote:
> > On Fri, Jun 22, 2001 at 12:42:29PM +0200, Vizi Szilard wrote:
> > > Mailman in the new directory working almost perfectly, but when I click
> > > to a link the url would be like this (eg. in the listinfo page):
> > >    http://tatooin.sol.vein.hu/mailman/admin
> > > But it have to be like this for the proper working:
> > >    http://tatooin.sol.vein.hu/mailman2/admin  
> > > 
> > 
> > Try editing 'DEFAULT_URL' in Mailman/Defaults.py.
> Nop, still does not work.
> Even with DEFAULT_URL='http://tatooin.sol.vein.hu/mailman2/' in mm_cfg.py

> It is still searching my test list under 
> http://tatooin.sol.vein.hu/mailman/listinfo/testing

That should work. Have you tried looking for /mailman/ yourself ? How about
looking at the script that generates those messages ? I don't have time to
haunt it down myself right now, but if you want to run 2.1-CVS, you better
get used to editing and fixing problems yourself, because the tree is pretty
unstable, still ;)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From jra@baylink.com  Fri Jun 22 14:29:02 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 22 Jun 2001 09:29:02 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 22, 2001 at 01:59:28AM -0400
References: <714582734.993149478@ZATHROS> <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <20010622092902.62487@scfn.thpl.lib.fl.us>

On Fri, Jun 22, 2001 at 01:59:28AM -0400, Barry A. Warsaw wrote:
> 4) The qrunners are long running processes, monitored by a cron
>    spawned watchdog.  Pros: on a warmed up system, delivery occurs
>    almost immediately, with start up delays amortized over the life of
>    the qrunner (Python 2.0's cyclic garbage collector helps keep
>    memory usage under control).  Cons: debugging is, er, more
>    challenging because you have to kill the master qrunner whenever
>    you (really, I ;) make a change to the code.

With just a little caution on locking, that's going to make my rate
limit throttling stuff much easier to implement, isn't it?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From barry@digicool.com  Fri Jun 22 16:26:40 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 11:26:40 -0400
Subject: [Mailman-Developers] Two versions on the same host
References: <20010622124228.C1844@freemail.hu>
Message-ID: <15155.25520.471194.240368@anthem.wooz.org>

>>>>> "VS" == Vizi Szilard <vizisz@freemail.hu> writes:

    VS> Mailman in the new directory working almost perfectly, but
    VS> when I click to a link the url would be like this (eg. in the
    VS> listinfo page): http://tatooin.sol.vein.hu/mailman/admin But
    VS> it have to be like this for the proper working:
    VS> http://tatooin.sol.vein.hu/mailman2/admin

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> Try editing 'DEFAULT_URL' in Mailman/Defaults.py.

Oh Thomas, you're so close you should be able to smell it! :)

Changing DEFAULT_URL in mm_cfg.py fixes the problem for any new lists
you create, but won't fix it for lists you created before changing
that variable.  Once a list is created, that variable is stuffed into
the MailList object's m.web_page_url attribute.  (Note that
m.host_name comes from DEFAULT_HOST_NAME which might also have to be
changed.)

To fix this, run bin/withlist like so:

% python -i bin/withlist -l mylist
Loading list mylist (locked)
>>> m.web_page_url
'http://www.mysite.com/mailman/'
>>> m.web_page_url = 'http://www.mysite.com/mailman2/'
>>> m.Save()
>>> ^D
Unlocking (but not saving) list: mylist
Finalizing

Cheers,
-Barry


From barry@digicool.com  Fri Jun 22 16:54:11 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 11:54:11 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
References: <15154.57024.617224.686817@anthem.wooz.org>
 <200106220613.f5M6Dfh32559@plaidworks.com>
Message-ID: <15155.27171.371284.205447@anthem.wooz.org>

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> Take a really large mailman system, one that's outgrown a
    CVR> single machine. Add a dedicated delivery machine. Now,
    CVR> outgrow that. So add a second. Right now, you'd have to do
    CVR> that with some DNS round-robin magic, or hacking the
    CVR> code. Instead, allow defining 1-N outgoing queues to
    CVR> different MTAs, and have mailman place every outgoing message
    CVR> in one of them either in sequence or random (or make it
    CVR> configurable. Maybe nthe best way to do this is to do it
    CVR> randomly, but assign a percentage to each queue, so you could
    CVR> weight towards faster/bigger machines and away from
    CVR> smaller/slower ones.

I /think/ this could all be accomplished with the current setup
without having to create a separate qfiles subdirectory.  Here's how:

Remember that every file in a qfile subdirectory is assigned a sha1
hash value, based currently on the message's content, the list name
and time.time().  Because of sha1's hashing properties the
distribution of files into the hash space should be effectively random
(I'm sure Tim Peters, if he were a member of this list, would chime in
with all the mathematical rigor I'm glossing over here. :)

Now, when a Runner asks its Switchboard for the list of files it
should process, it will receive the files sitting in some slice of
this hash space.  Currently, the code splits the hash space up evenly,
but there is no reason why someone couldn't subclass Switchboard to
allow for weighted hash space slices.

    CVR> Then, each one has a qrunner tihng delivering into that SMTP
    CVR> port. And for redundancy, if the server it's supposed to send
    CVR> to is down, that qrunner could requeue to the other outgoing
    CVR> queue(s), so a down machine wouldn't affect you.

So now what you do is subclass OutgoingRunner so that it knows about
all the parallelism and redundancy you want to build in, i.e.  the
assignments of hash space slices to SMTP ports.  Because each
OutgoingRunner will only process the files in its hash space slice,
you don't have to worry about any locking access to the files in
qfiles/out.

    CVR> Run it one weird step further out, and you could define
    CVR> outgoing queues that are NEVER used, unless the main SMTP
    CVR> queue is down. Sort of like a fallback MX.

If you really wanted to do this, then you /would/ have to define a
separate queue.  I'm not sure it's worthwhile (since the same goal
can probably be accomplish in other ways), but it's easy to do
something like:

- subclass OutgoingRunner so that if the SMTPDirect delivery failed
  due to non-responsiveness of the SMTP host, requeue the message to a
  `backoff' queue.  New queues (i.e. qfiles/subdirs) are trivial to
  define.

- Run a low-grade OutgoingRunner that only looks in qfiles/backoff for
  files to deliver.

    CVR> All of this is possible outside of mailman -- but it seems
    CVR> like it ought to be fairly easy to build into mailman, so you
    CVR> don't have to fall into DNS magic or proxies or any of the
    CVR> stuff we talked about last week...

I agree that it should be easy to do, and claim that the current
architecture could support it, if the sufficiently motivated Python
hacker were willing to spend a couple of hours on it.  I don't think
it's of general use to the majority of Mailman sites, so I don't
intend to implement it myself.  As always, patches are welcome. :)

    >> 3) Different qrunners can be assigned different priorities
    >> (i.e. you can run your incoming posts and MTA-bound queues more
    >> often then your archiver, nntpd, or command processing queues).

    CVR> Can you define bounce processing to time the server is
    CVR> otherwise idle?

Currently, bounce processing is tied in with the CommandRunner, but it
probably makes a lot more sense to split these into separate queues.
Given the current semantics (that bounces go to -admin, which may also
receive legitimate correspondence) some non-bounce email might get
delayed delivery, but I'm trying to sanitize the return addresses for
Mailman generated messages, so that responses from users go to the
-owner address (which doesn't do bounce processing), while errors go
to the -admin address (which does).

As far as delaying bounce processing for system idle periods, once the
bounce runner is split from the command runner, a strategy would be to
override the default BounceRunner's _doperiodic() and _snooze()
methods so that it only wakes up and starts processing during idle
times (however that's calculated for your particular OS).

I'm convinced almost all the nuts and bolts are there for you to build
whatever erector set frankenstein you want. :)

-Barry


From barry@digicool.com  Fri Jun 22 17:02:29 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 12:02:29 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
References: <714582734.993149478@ZATHROS>
 <15154.57024.617224.686817@anthem.wooz.org>
 <20010622092902.62487@scfn.thpl.lib.fl.us>
Message-ID: <15155.27669.599549.319832@anthem.wooz.org>

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    >> 4) The qrunners are long running processes, monitored by a cron
    >> spawned watchdog.  Pros: on a warmed up system, delivery occurs
    >> almost immediately, with start up delays amortized over the
    >> life of the qrunner (Python 2.0's cyclic garbage collector
    >> helps keep memory usage under control).  Cons: debugging is,
    >> er, more challenging because you have to kill the master
    >> qrunner whenever you (really, I ;) make a change to the code.

    JRA> With just a little caution on locking, that's going to make
    JRA> my rate limit throttling stuff much easier to implement,
    JRA> isn't it?

I believe so, but I can think of one refinement that would help you.
The Runner base class calls _doperiodic() after each file is
processed.  In here you could do the rate limit calculation, but
currently there's no protocol for _doperiodic() to tell the for loop
in __oneloop() to break out early.  I think I can easily add one.

-Barry


From chuqui@plaidworks.com  Fri Jun 22 17:53:12 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 22 Jun 2001 09:53:12 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15155.27171.371284.205447@anthem.wooz.org>
Message-ID: <200106221651.f5MGpVf02456@lists.apple.com>

On Friday, June 22, 2001, at 08:54 AM, Barry A. Warsaw wrote:

> I /think/ this could all be accomplished with the current setup
> without having to create a separate qfiles subdirectory.  Here's how:
>

Kewl. It's great to see that whenever I come up with one of these 
weird-ass boundary cases, Mailman at least has the capability to be 
kicked into shape to deal with it... that's great!

chuq

--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

"When his IQ reaches 50, he should sell."




From barry@digicool.com  Fri Jun 22 17:59:46 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Fri, 22 Jun 2001 12:59:46 -0400
Subject: [Mailman-Developers] Splitting -owner and -admin handling
Message-ID: <15155.31106.81604.326952@anthem.wooz.org>

Mail destined for the -owner and -admin addresses for a list are
handled differently because -admin mail flows through the bounce
detector, and only if that fails is it forwarded on to the list
owners.  Mail for -owner goes directly to the list owners.

For historical reasons, Mailman conflates these two addresses by
having the same script (mailowner) deal with both.  In MM2.0.5, I
parsed the incoming message to see if it was destined for -admin or
-owner, and I added an appropriate bit message metadata before queuing
the message.

In MM2.1, I don't parse the message in mailowner.  This has the
advantage of reducing the amount of time the MTA program has to
consume, which I think is a good thing.  The problem is that the
determination of -owner vs. -admin doesn't happen until the qrunner
processes the message.  If I want to split bounce processing into a
separate queue, the best place to do this is as early as possible,
i.e. in the MTA program script.

There are two options:

1) Parse the message in mailowner, or at the very least, look for the
   To: field to see if it was destined for -owner or -admin, and then
   put the message in the proper queue.  We can mitigate the parsing
   costs by storing the message as a pickle instead of plain text, so
   the qrunner slurping messages out of the queue doesn't need to
   reparse it.  Pros: backwards compatibility with existing alias
   files.  Cons: mailowner has to do more work, has a higher
   opportunity for uncaught exceptions (exposed as MTA bounces), and
   can be fooled by Bcc's.

2) Add a new script, maybe called `mailadmin' which gets associated
   only with -admin messages.  The mailowner script would thus only
   accept messages for -owner.  Pros: keeps things simple, and splits
   bounce processing into a separate queue early on, with minimal
   chance of problems.  Cons: breaks backwards compatibility with
   existing alias files, since they'd have to be changed to point the
   -admin addresses at mailadmin instead of what they currently point
   to (mailowner).  Mitigate this with the auto-alias-file
   regeneration scripts already in Mailman (i.e. bin/genaliases).

Thoughts?  Preferences?  Other suggestions?

-Barry


From Dan Mick <dmick@utopia.West.Sun.COM>  Fri Jun 22 19:19:30 2001
From: Dan Mick <dmick@utopia.West.Sun.COM> (Dan Mick)
Date: Fri, 22 Jun 2001 11:19:30 -0700 (PDT)
Subject: [Mailman-Developers] Splitting -owner and -admin handling
Message-ID: <200106221819.LAA18137@utopia.West.Sun.COM>

I like 2) better, as anything that helps bounce processing be
more efficient is a big win for low-end machines, especially if
it can avoid the relatively-huge Python startup time.

> Mail destined for the -owner and -admin addresses for a list are
> handled differently because -admin mail flows through the bounce
> detector, and only if that fails is it forwarded on to the list
> owners.  Mail for -owner goes directly to the list owners.
> 
> For historical reasons, Mailman conflates these two addresses by
> having the same script (mailowner) deal with both.  In MM2.0.5, I
> parsed the incoming message to see if it was destined for -admin or
> -owner, and I added an appropriate bit message metadata before queuing
> the message.
> 
> In MM2.1, I don't parse the message in mailowner.  This has the
> advantage of reducing the amount of time the MTA program has to
> consume, which I think is a good thing.  The problem is that the
> determination of -owner vs. -admin doesn't happen until the qrunner
> processes the message.  If I want to split bounce processing into a
> separate queue, the best place to do this is as early as possible,
> i.e. in the MTA program script.
> 
> There are two options:
> 
> 1) Parse the message in mailowner, or at the very least, look for the
>    To: field to see if it was destined for -owner or -admin, and then
>    put the message in the proper queue.  We can mitigate the parsing
>    costs by storing the message as a pickle instead of plain text, so
>    the qrunner slurping messages out of the queue doesn't need to
>    reparse it.  Pros: backwards compatibility with existing alias
>    files.  Cons: mailowner has to do more work, has a higher
>    opportunity for uncaught exceptions (exposed as MTA bounces), and
>    can be fooled by Bcc's.
> 
> 2) Add a new script, maybe called `mailadmin' which gets associated
>    only with -admin messages.  The mailowner script would thus only
>    accept messages for -owner.  Pros: keeps things simple, and splits
>    bounce processing into a separate queue early on, with minimal
>    chance of problems.  Cons: breaks backwards compatibility with
>    existing alias files, since they'd have to be changed to point the
>    -admin addresses at mailadmin instead of what they currently point
>    to (mailowner).  Mitigate this with the auto-alias-file
>    regeneration scripts already in Mailman (i.e. bin/genaliases).
> 
> Thoughts?  Preferences?  Other suggestions?
> 
> -Barry
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers



From claw@kanga.nu  Fri Jun 22 21:41:32 2001
From: claw@kanga.nu (claw@kanga.nu)
Date: Fri, 22 Jun 2001 13:41:32 -0700
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw)
 of "Fri, 22 Jun 2001 12:59:46 EDT." <15155.31106.81604.326952@anthem.wooz.org>
References: <15155.31106.81604.326952@anthem.wooz.org>
Message-ID: <2315.993242492@2wire.com>

On Fri, 22 Jun 2001 12:59:46 -0400 
Barry A Warsaw <barry@digicool.com> wrote:

> Mail destined for the -owner and -admin addresses for a list are
> handled differently because -admin mail flows through the bounce
> detector, and only if that fails is it forwarded on to the list
> owners.  Mail for -owner goes directly to the list owners.

Why not split those functions?

> In MM2.1, I don't parse the message in mailowner.  This has the
> advantage of reducing the amount of time the MTA program has to
> consume, which I think is a good thing.  The problem is that the
> determination of -owner vs. -admin doesn't happen until the
> qrunner processes the message.  If I want to split bounce
> processing into a separate queue, the best place to do this is as
> early as possible, i.e. in the MTA program script.

> There are two options:

And a third: 

  3) Remove bounce processing from -admin and move it to its own
  -bounce address.

I prefer this approach.  The insertion of a management point (via
the new address) adds all sorts of new capabilities (eg process
deferment, dedicated bounce processor nodes, customised bounce
processing (eg integration with other external systems such as CRM
or billing), etc etc.  The pain is that extant installations would
have to add the new alias/MTA config as part of their upgrade.  

That's an acceptable upgrade cost.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jra@baylink.com  Fri Jun 22 22:02:57 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Fri, 22 Jun 2001 17:02:57 -0400
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15155.27669.599549.319832@anthem.wooz.org>; from "Barry A. Warsaw" <barry@digicool.com> on Fri, Jun 22, 2001 at 12:02:29PM -0400
References: <714582734.993149478@ZATHROS> <15154.57024.617224.686817@anthem.wooz.org> <20010622092902.62487@scfn.thpl.lib.fl.us> <15155.27669.599549.319832@anthem.wooz.org>
Message-ID: <20010622170257.53564@scfn.thpl.lib.fl.us>

On Fri, Jun 22, 2001 at 12:02:29PM -0400, Barry A. Warsaw wrote:
>     JRA> With just a little caution on locking, that's going to make
>     JRA> my rate limit throttling stuff much easier to implement,
>     JRA> isn't it?
> 
> I believe so, but I can think of one refinement that would help you.
> The Runner base class calls _doperiodic() after each file is
> processed.  In here you could do the rate limit calculation, but
> currently there's no protocol for _doperiodic() to tell the for loop
> in __oneloop() to break out early.  I think I can easily add one.

It would be oh, so nice if I could get *you* to write this code instead
of me having to do it.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From carson@taltos.org  Fri Jun 22 23:52:55 2001
From: carson@taltos.org (Carson Gaspar)
Date: Fri, 22 Jun 2001 15:52:55 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>
References: <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <69573828.993225175@athyra>


--On Friday, June 22, 2001 1:59 AM -0400 "Barry A. Warsaw" 
<barry@digicool.com> wrote:

> - incoming commands (i.e. bounces, -request, -owner, -admin, -join,
> -leave)

> It's fairly easy to add more queues, although I'm not sure what else
> would be useful.  Some other features of the 2.1 queue system:

I _really_ want bounces and commands in 2 different queues. The firewalls 
mailing list gets _tons_ of bounces, and it clogs up everything else.

-- 
Carson



From chuqui@plaidworks.com  Sat Jun 23 00:02:47 2001
From: chuqui@plaidworks.com (Chuq Von Rospach)
Date: Fri, 22 Jun 2001 16:02:47 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <69573828.993225175@athyra>
Message-ID: <200106222301.f5MN15512753@lists.apple.com>

--Apple-Mail-499853444-1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	format=flowed;
	charset=us-ascii


On Friday, June 22, 2001, at 03:52 PM, Carson Gaspar wrote:

>
> I _really_ want bounces and commands in 2 different queues. The 
> firewalls mailing list gets _tons_ of bounces, and it clogs up 
> everything else.


Have you looked at why? Is it just that large a list -- or do you have a 
continuing problem with bounces floating through the system that you 
think mailman is handling but mailman isn't?

Mailman doesn't handle all bounces. Unfortunately, it's not good at 
telling you this right now (and we haven't really figured out a good way 
to deal with this, since it seems there are two modes: silently dropping 
this stuff or inundating the admin with it). I had this problem until I 
started analyzing the system and realized I had a bunch of stuff that 
was going to bounce forever -- and when I cleaned that stuff up (by 
tracking down the addresses that had changed enough to not be 
recognized, the stuff being forwarded (and forwarded.. and forwarded) 
and etc), a huge part of my bounce 'problem' went away.

start by taking the bounce log, and grepping for "not a member", and 
clean up as much of that as you can. You may find a huge difference in 
your performance and backlogs....




--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

You know, I Remember When I Used To Speak In Capitals, Too. It's 
addictive.
It also encourages people to poke sticks at you. Justifiably. (chuq, 
1992)

--Apple-Mail-499853444-1
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=us-ascii


On Friday, June 22, 2001, at 03:52 PM, Carson Gaspar wrote:


<excerpt>

I _really_ want bounces and commands in 2 different queues. The
firewalls mailing list gets _tons_ of bounces, and it clogs up
everything else.

</excerpt>


Have you looked at why? Is it just that large a list -- or do you have
a continuing problem with bounces floating through the system that you
think mailman is handling but mailman isn't?


Mailman doesn't handle all bounces. Unfortunately, it's not good at
telling you this right now (and we haven't really figured out a good
way to deal with this, since it seems there are two modes: silently
dropping this stuff or inundating the admin with it). I had this
problem until I started analyzing the system and realized I had a
bunch of stuff that was going to bounce forever -- and when I cleaned
that stuff up (by tracking down the addresses that had changed enough
to not be recognized, the stuff being forwarded (and forwarded.. and
forwarded) and etc), a huge part of my bounce 'problem' went away.


start by taking the bounce log, and grepping for "not a member", and
clean up as much of that as you can. You may find a huge difference in
your performance and backlogs....




<color><param>0000,0000,DEB7</param>

</color>-- 

Chuq Von Rospach, Internet Gnome <<http://www.chuqui.com>

[<<chuqui@plaidworks.com> = <<me@chuqui.com> = <<chuq@apple.com>]

Yes, yes, I've finally finished my home page. Lucky you. 


You know, I Remember When I Used To Speak In Capitals, Too. It's
addictive.

It also encourages people to poke sticks at you. Justifiably. (chuq,
1992)


--Apple-Mail-499853444-1--


From thomas@xs4all.net  Sat Jun 23 09:51:47 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Sat, 23 Jun 2001 10:51:47 +0200
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: <2315.993242492@2wire.com>
References: <15155.31106.81604.326952@anthem.wooz.org> <2315.993242492@2wire.com>
Message-ID: <20010623105147.P8098@xs4all.nl>

On Fri, Jun 22, 2001 at 01:41:32PM -0700, claw@kanga.nu wrote:

> And a third: 

>   3) Remove bounce processing from -admin and move it to its own
>   -bounce address.

> I prefer this approach.  The insertion of a management point (via
> the new address) adds all sorts of new capabilities (eg process
> deferment, dedicated bounce processor nodes, customised bounce
> processing (eg integration with other external systems such as CRM
> or billing), etc etc.  The pain is that extant installations would
> have to add the new alias/MTA config as part of their upgrade.  

> That's an acceptable upgrade cost.

No.... Currently, the Sender and Return-Path headers (or the 'From ' header,
if you wish) get set to list-admin, not list-bounce. Changing it to
list-bounce will screw up every one of my mailman-list-filters, and I'm not
the only one doing that ;P 

-- 
Thomas Wouters <thomas@xs4all.net>

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


From claw@kanga.nu  Sat Jun 23 10:38:19 2001
From: claw@kanga.nu (J C Lawrence)
Date: Sat, 23 Jun 2001 02:38:19 -0700
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: Message from Thomas Wouters <thomas@xs4all.net>
 of "Sat, 23 Jun 2001 10:51:47 +0200." <20010623105147.P8098@xs4all.nl>
References: <15155.31106.81604.326952@anthem.wooz.org> <2315.993242492@2wire.com>  <20010623105147.P8098@xs4all.nl>
Message-ID: <11492.993289099@kanga.nu>

On Sat, 23 Jun 2001 10:51:47 +0200 
Thomas Wouters <thomas@xs4all.net> wrote:

> No.... Currently, the Sender and Return-Path headers (or the 'From
> ' header, if you wish) get set to list-admin, not
> list-bounce. 

Correct.  I'm suggesting that be changed.

> Changing it to list-bounce will screw up every one of my
> mailman-list-filters, and I'm not the only one doing that ;P

Might I suggest that List-ID: is a far better field to filter on,
asides from actually being intended for that purpose?

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jeb@ocha.net  Sat Jun 23 16:33:24 2001
From: jeb@ocha.net (Jeb Bateman)
Date: Sat, 23 Jun 2001 08:33:24 -0700
Subject: [Mailman-Developers] Mailman queue design problem?
In-Reply-To: <15154.57024.617224.686817@anthem.wooz.org>; from barry@digicool.com on Fri, Jun 22, 2001 at 01:59:28AM -0400
References: <714582734.993149478@ZATHROS> <15154.57024.617224.686817@anthem.wooz.org>
Message-ID: <20010623083324.A8703@ocha.net>

On Fri, Jun 22, 2001 at 01:59:28AM -0400, Barry A. Warsaw wrote:
> 4) The qrunners are long running processes, monitored by a cron
>    spawned watchdog.  Pros: on a warmed up system, delivery occurs
>    almost immediately, with start up delays amortized over the life of
>    the qrunner (Python 2.0's cyclic garbage collector helps keep
>    memory usage under control).  Cons: debugging is, er, more
>    challenging because you have to kill the master qrunner whenever
>    you (really, I ;) make a change to the code.

I'm curious, would it be possible to make the delivery pipeline fork a
qrunner (after checking that one is NOT already running) ??

The advantage would be no cron, and qrunner could start immediately
whenever it's needed, (if one is not already running), and then die
naturally (freeing the processor and memory) when it's not.  (There
could be a configurable amount of time for it to 'sleep' before it
exits after it's work is finished, and it finds no new work to do...)

I remember reading that Postfix kills programs it starts if they run
too long, but does that also apply to forked processes?

Thanks,
-jeb


From jeb@ocha.net  Sat Jun 23 19:22:45 2001
From: jeb@ocha.net (Jeb Bateman)
Date: Sat, 23 Jun 2001 12:22:45 -0600
Subject: [Mailman-Developers] Splitting -owner and -admin handling
In-Reply-To: <11492.993289099@kanga.nu>; from claw@kanga.nu on Sat, Jun 23, 2001 at 02:38:19AM -0700
References: <15155.31106.81604.326952@anthem.wooz.org> <2315.993242492@2wire.com> <20010623105147.P8098@xs4all.nl> <thomas@xs4all.net> <11492.993289099@kanga.nu>
Message-ID: <20010623122245.A82107@buyorganic.org>

I support option 1) with backward compatability and To: parsing (with
Bcc's being processed in the admin queue, since the current system
works), plus an optional feature for enabling # 3) as J C pointed out
to turn off parsing and tune performance; especially since having a
-bounce alias would also be natural for reliable bounce handling
sender addresses sometime... <list-bounce-foo=bar.com@lists.net>

Thus, no alias changes are necessary, but -bounce aliases *can* be
added site-wide for performance.  Existing installations could have
the -bounce alias option turned off by default, and new installations
can have it turned on in Defaults.py.

I think it's too confusing to do option 2) since it makes a technical
distinction between two things which were understood by users and
admins to be exactly the same for a long time, and I think the
necessary alias changes would be more confusing as well.

Regards,
-jeb

PS: This method would not break existing users setups by default, but
would allow a site admin to do so, and deal with the complaints ;-)

On Sat, Jun 23, 2001 at 02:38:19AM -0700, J C Lawrence wrote:
> Thomas Wouters <thomas@xs4all.net> wrote:
> > No.... Currently, the Sender and Return-Path headers (or the 'From
> > ' header, if you wish) get set to list-admin, not list-bounce.
> 
> Correct.  I'm suggesting that be changed.
> 
> > Changing it to list-bounce will screw up every one of my
> > mailman-list-filters, and I'm not the only one doing that ;P
> 
> Might I suggest that List-ID: is a far better field to filter on,
> asides from actually being intended for that purpose?



From friends@openxxx.net  Sun Jun 24 04:19:48 2001
From: friends@openxxx.net (friends@openxxx.net)
Date: 23 Jun 2001 22:19:48 -0500
Subject: [Mailman-Developers] Hello, your friend recommended openxxx to you
Message-ID: <FRENCHYV1qdiixjnzi900000023@frenchy>


You have been invited to check out this adult site
by one of your friends who visited us.

our URL is http://www.openxxx.net/
enjoy,
OpenXXX TEAM 2001




From dvschalk@ing.sun.ac.za  Mon Jun 25 14:35:26 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Mon, 25 Jun 2001 15:35:26 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
Message-ID: <3B373E1E.6C966C95@ing.sun.ac.za>

Hi

It is 6:02 AM Sat. and I'm fairly fed-up.

I have the following situation : 

Mailman 2.0.5 
Python 2.0
MTA : postfix

I set Mailman up, created a test list and played with it for a while.
Then I send it a big "whopper" 5MB e-mail. I watched the logs and saw
postfix running the wrapper. The cron started qrunner and all hell broke
lose (over dramatizing a bit). It started running at 100% CPU, where it
stayed until I killed it. The message was queued in $prefix/qfiles, it
and its little .db file. I had to remove those as well as the locks in
$prefix/locks before I could successfully use the list again.

So I thought, "well maybe the pipermail thingy can't handle the huge
mime thingies I'm sending it". So I send a smaller attachment <150kb.
Things went fine (except for the ugly html page:) ) Send it a 1MB
attachment. qrunner started spinning it's wheels again. Had to seek and
destroy again.

So I replaced pipermail with MHonArc (With PUBLIC_EXTERNAL_ARCHIVER ,
PRIVATE_EXTERNAL_ARCHIVER , PUBLIC_ARCHIVE_URL in mm_cfg.py and the
appropriate thingies in httpd.conf). Small messages worked fine. Big 
whoppers = no joy i.e. still the same with big messages. So at least it
is not the archiving bit that messes up.

So I upgraded my Python ;) Ermm, to version 2.0. Still the same.

Has anyone had the same problem? Can anyone confirm this as a bug by
sending a 2MB file to a 2.0.5 testlist? 

How do I do a trace in Python? (i.e. it is as familiar to me as the
bacteria in my stomach (I runs on my machine and there endeth the
relationship))

Any pointers? Anything? I need to get this list running before monday
(yes this is for a business). Please!!!??

Sorry if this e-mail was not formal enough, the 48 hours strait is
getting to me.

Greets

Dirko

Lab E352
E&E Engineering
Univ. of Stellenbosch
South Africa


From james@gilbertwalker.com  Mon Jun 25 18:49:27 2001
From: james@gilbertwalker.com (James Dinan)
Date: Mon, 25 Jun 2001 10:49:27 -0700
Subject: [Mailman-Developers] HTML Issue
Message-ID: <004101c0fd9f$3d913dd0$3202a8c0@station12>

This is a multi-part message in MIME format.

------=_NextPart_000_003C_01C0FD64.8168A650
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I posted this message to mailman-users, and then the more I was thinking =
about it, the more I began to think this was a question for developers.  =
Please tell me what you think:

I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with =
the Subscribe Results Page (/mailman/subscribe/listname).  More =
specifically, I have edited the HTML and whenever I view the page, =
mailman appears to be prepending the following to the source:

<HTML>
<HEAD>
</HEAD>
<BODY
<BODY bgcolor=3D"#ffffff">

which I'm sure you can imagine is wreaking havoc on the rest of my HTML. =
 Has anyone else had this problem, or is this fixed in future releases?  =
Since I am not an admin on the server I am configuring it will be =
difficult (Redhat installs mailman in /var/mailman) to recompile =
mailman.

I have just checked =
http://mail.python.org/mailman/subscribe/mailman-users and you can see =
for yourself that this is also happening with the version of mailman =
that serves this list.

- jim dinan.
-----------------------------------------------------------------------
James Dinan <james@gilbertwalker.com>
Gilbert Walker Group: Lenox, MA  U.S.A
Available:  http://www.gilbertwalker.com

------=_NextPart_000_003C_01C0FD64.8168A650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I posted this message to mailman-users, =
and then=20
the more I was thinking about it, the more I began to think this was a =
question=20
for developers.&nbsp; Please tell me what you think:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>I am running Mailman 2.0.1 on Redhat =
6.2 and I am=20
having difficulty with the Subscribe Results Page=20
(/mailman/subscribe/listname).&nbsp; More specifically, I have edited =
the HTML=20
and whenever I view the page, mailman appears to be prepending the =
following to=20
the source:</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><BR>&lt;HTML&gt;<BR>&lt;HEAD&gt;<BR>&lt;/HEAD&gt;<BR>&lt;BODY<BR=
>&lt;BODY=20
bgcolor=3D"#ffffff"&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>which I'm sure you can imagine is =
wreaking havoc on=20
the rest of my HTML.&nbsp; Has anyone else had this problem, or is this =
fixed in=20
future releases?&nbsp; Since I am not an admin on the server I am =
configuring it=20
will be difficult (Redhat installs mailman in /var/mailman) to recompile =

mailman.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have just checked <A=20
href=3D"http://mail.python.org/mailman/subscribe/mailman-users">http://ma=
il.python.org/mailman/subscribe/mailman-users</A>&nbsp;and=20
you can see for yourself that this is also happening with the version of =
mailman=20
that serves this list.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>- jim dinan.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>----------------------------------------------------------------=
-------<BR>James=20
Dinan &lt;<A=20
href=3D"mailto:james@gilbertwalker.com">james@gilbertwalker.com</A>&gt;<B=
R>Gilbert=20
Walker Group: Lenox, MA&nbsp; U.S.A<BR>Available:&nbsp; <A=20
href=3D"http://www.gilbertwalker.com">http://www.gilbertwalker.com</A></F=
ONT></FONT></DIV></DIV></BODY></HTML>

------=_NextPart_000_003C_01C0FD64.8168A650--



From thomas@xs4all.net  Mon Jun 25 16:47:58 2001
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 25 Jun 2001 17:47:58 +0200
Subject: [Mailman-Developers] HTML Issue
In-Reply-To: <004101c0fd9f$3d913dd0$3202a8c0@station12>
References: <004101c0fd9f$3d913dd0$3202a8c0@station12>
Message-ID: <20010625174758.V8098@xs4all.nl>

On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:

> I posted this message to mailman-users, and then the more I was thinking
> about it, the more I began to think this was a question for developers. 
> Please tell me what you think:

> I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with
> the Subscribe Results Page (/mailman/subscribe/listname).  More
> specifically, I have edited the HTML and whenever I view the page, mailman
> appears to be prepending the following to the source:
> 
> <HTML>
> <HEAD>
> </HEAD>
> <BODY
> <BODY bgcolor="#ffffff">

Yes. This is an open bug, and an old one. It still requires a Pronouncement
from Barry. The problem is that Mailman creates a HTMLgen Document instead
of a HeadlessDocument, for the list page. From the top of my head the fix is
to change 

    doc = Document()

into

    doc = HeadlessDocument()

in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
is reluctant to fix it because of possible breakage (people might have made
template files with the (Headfull)Document in mind.) Barry ? :)

-- 
Thomas Wouters <thomas@xs4all.net>

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


From tollef@add.no  Mon Jun 25 20:07:35 2001
From: tollef@add.no (Tollef Fog Heen)
Date: 25 Jun 2001 21:07:35 +0200
Subject: [Mailman-Developers] HTML Issue
In-Reply-To: <20010625174758.V8098@xs4all.nl>
References: <004101c0fd9f$3d913dd0$3202a8c0@station12>
 <20010625174758.V8098@xs4all.nl>
Message-ID: <8766dk2xag.fsf@arabella.dep.no>

* Thomas Wouters 

| in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
| is reluctant to fix it because of possible breakage (people might have made
| template files with the (Headfull)Document in mind.) Barry ? :)

Actually, the fix is in htmlformat.py, around line 281:

        output.append('%s</HEAD>' % tab)
        output.append('%s<BODY' % tab)
	quals = []
	for k, v in kws.items():
	    quals.append('%s="%s"' % (k, v))
        output.append('%s<BODY %s>' % (tab, string.join(quals, ' ')))
        output.append(Container.Format(self, indent))

ok, first, we append '<body' to the output.  then we run in a little
loop, before we append another <body> with any arguments.  I raised
the problem on April 16th, and you told me about the headless problem,
but just commenting out

        output.append('%s<BODY' % tab)

has worked fine for me (and any users of Mailman on Debian).

-- 

Tollef Fog Heen
You Can't Win


From barry@digicool.com  Mon Jun 25 21:03:17 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 25 Jun 2001 16:03:17 -0400
Subject: [Mailman-Developers] HTML Issue
References: <20010625174758.V8098@xs4all.nl>
Message-ID: <15159.39173.331416.882488@yyz.digicool.com>

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:

    TW> Yes. This is an open bug, and an old one. It still requires a
    TW> Pronouncement from Barry. The problem is that Mailman creates
    TW> a HTMLgen Document instead of a HeadlessDocument, for the list
    TW> page. From the top of my head the fix is to change

    TW> doc = Document()

    TW> into

    TW> doc = HeadlessDocument()

    TW> in Mailman/Cgi/listinfo.py, function listinfo_overview(). I
    TW> believe Barry is reluctant to fix it because of possible
    TW> breakage (people might have made template files with the
    TW> (Headfull)Document in mind.) Barry ? :)

Well, with MM2.1 I'm certainly less concerned about any theoretical
breakages, especially since changing this will probably accomplish
exactly the opposite! :)

>>>>> "TFH" == Tollef Fog Heen <tollef@add.no> writes:

    TFH> ok, first, we append '<body' to the output.  then we run in a
    TFH> little loop, before we append another <body> with any
    TFH> arguments.  I raised the problem on April 16th, and you told
    TFH> me about the headless problem, but just commenting out

    TFH> output.append('%s<BODY' % tab)

    TFH> has worked fine for me (and any users of Mailman on Debian).

This is certainly one of the problems, which will affect any
Document()-based web page.  However, Thomas is also right that any
page that is generated from a template (e.g. subscribe.html) either
must not include the header stuff, or must use a HeadlessDocument().
Fixing this is going to take a bit of grunt work, especially if we
want to allow the html templates to go either way.

Let's make our lives simple and say that any templated html file must
include its own html armor (and thus will be HeadlessDocument()
based), while all non-templated script-generated ones will be
Document() based to get the standard header and footers.

If you agree, I can start fixing the web ui to conform to this rule.

The more I think about the web ui, the more certain I am that we need

1) api's so sites can supply any web ui they want, with adaptors for
   the Mailman "classic" ui.

2) Mailman's classic ui should be based on something like Zope's
   Presentation Templates (ZPT).  My understanding is that these will
   /not/ require sucking in all of Zope (i.e. they can be used
   standalone), they are quite powerful, and allow for html editing to
   live nicely with script specialization.  There's the little matter
   of ZPL/GPL incompatibility that's currently holding me back from
   investigating this avenue further.

-Barry


From james@gilbertwalker.com  Tue Jun 26 00:20:19 2001
From: james@gilbertwalker.com (James Dinan)
Date: Mon, 25 Jun 2001 16:20:19 -0700
Subject: [Mailman-Developers] HTML Issue
References: <20010625174758.V8098@xs4all.nl> <15159.39173.331416.882488@yyz.digicool.com>
Message-ID: <010e01c0fdcd$79373c80$3202a8c0@station12>

> Let's make our lives simple and say that any templated html file must
> include its own html armor (and thus will be HeadlessDocument()
> based), while all non-templated script-generated ones will be
> Document() based to get the standard header and footers.
>
> If you agree, I can start fixing the web ui to conform to this rule.

I certainly agree with that.  In fact, right now I am in the process of
hacking together a custom ui for MM2 which, I am surprised to find, is much
harder than I imagined.  One problem that I have is that somtimes funny
things will happen inside the <MM-...> tags.  Some tags leave white space
after themselves, and I can't really control the presentation of the content
inside of the tags (i.e. font, size, etc) directly, often I have to wrap
them in a container.

I wonder if there might be some way to pull these <MM-...> tags out of the
source and stick them into a library of some sort that you can sustomize for
each list.  I know this would probabbly mean quite a lot of work, but think
of how cool that would be.  ;)  You could have the configuration program
modify the text in the libraries for less advanced users and for more
hardcore hackers they can edit the XML/HTML themselves.

If you're interested to see how far I've gotten, the mailing list I'm
working on (for my summer job) is available at
http://www.gilbertwalker.com/mailman/listinfo/advisorbits.  Assuming I
haven't broken it again it should still be up.  But, you will notice that
there are still many error messages which I cannot touch the HTML for.  :/

Oh yeah, one other idea I had (this really pertains to my particular site
architecture) is that it would be incredibly convenient to have a
customizable page header and footer that could be called via an <MM-...> tag
that you could wrap any sort of content in.  Sort of like making
HeadlessDocument() customizable I guess.

Thanks for all your help!

- jim.

-----------------------------------------------------------------------
James Dinan <james@gilbertwalker.com>
Gilbert Walker Group: Lenox, MA  U.S.A
Available:  http://www.gilbertwalker.com


> This is certainly one of the problems, which will affect any
> Document()-based web page.  However, Thomas is also right that any
> page that is generated from a template (e.g. subscribe.html) either
> must not include the header stuff, or must use a HeadlessDocument().
> Fixing this is going to take a bit of grunt work, especially if we
> want to allow the html templates to go either way.
>
>
> The more I think about the web ui, the more certain I am that we need
>
> 1) api's so sites can supply any web ui they want, with adaptors for
>    the Mailman "classic" ui.
>
> 2) Mailman's classic ui should be based on something like Zope's
>    Presentation Templates (ZPT).  My understanding is that these will
>    /not/ require sucking in all of Zope (i.e. they can be used
>    standalone), they are quite powerful, and allow for html editing to
>    live nicely with script specialization.  There's the little matter
>    of ZPL/GPL incompatibility that's currently holding me back from
>    investigating this avenue further.
>
> -Barry



From Samuel" <coudrayf@noos.fr  Mon Jun 25 21:29:25 2001
From: Samuel" <coudrayf@noos.fr (Samuel)
Date: Mon, 25 Jun 2001 22:29:25 +0200
Subject: [Mailman-Developers] Re: Mailman-Developers digest, Vol 1 #917 - 3 msgs
References: <E15EYnW-0008AP-00@mail.python.org>
Message-ID: <037a01c0fdb5$870789e0$e23d84c3@cybercable.fr>

unsubscribe
----- Original Message -----
From: <mailman-developers-request@python.org>
To: <mailman-developers@python.org>
Sent: Monday, June 25, 2001 6:01 PM
Subject: Mailman-Developers digest, Vol 1 #917 - 3 msgs


> Send Mailman-Developers mailing list submissions to
> mailman-developers@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/mailman-developers
> or, via email, send a message with subject or body 'help' to
> mailman-developers-request@python.org
>
> You can reach the person managing the list at
> mailman-developers-admin@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mailman-Developers digest..."
>
>
> Today's Topics:
>
>    1. qrunner -- problem with huge mail messages (Dirko van Schalkwyk)
>    2. HTML Issue (James Dinan)
>    3. Re: HTML Issue (Thomas Wouters)
>
> --__--__--
>
> Message: 1
> Date: Mon, 25 Jun 2001 15:35:26 +0200
> From: Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
> Reply-To: dvschalk@ing.sun.ac.za
> To: mailman-developers@python.org
> Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
>
> Hi
>
> It is 6:02 AM Sat. and I'm fairly fed-up.
>
> I have the following situation :
>
> Mailman 2.0.5
> Python 2.0
> MTA : postfix
>
> I set Mailman up, created a test list and played with it for a while.
> Then I send it a big "whopper" 5MB e-mail. I watched the logs and saw
> postfix running the wrapper. The cron started qrunner and all hell broke
> lose (over dramatizing a bit). It started running at 100% CPU, where it
> stayed until I killed it. The message was queued in $prefix/qfiles, it
> and its little .db file. I had to remove those as well as the locks in
> $prefix/locks before I could successfully use the list again.
>
> So I thought, "well maybe the pipermail thingy can't handle the huge
> mime thingies I'm sending it". So I send a smaller attachment <150kb.
> Things went fine (except for the ugly html page:) ) Send it a 1MB
> attachment. qrunner started spinning it's wheels again. Had to seek and
> destroy again.
>
> So I replaced pipermail with MHonArc (With PUBLIC_EXTERNAL_ARCHIVER ,
> PRIVATE_EXTERNAL_ARCHIVER , PUBLIC_ARCHIVE_URL in mm_cfg.py and the
> appropriate thingies in httpd.conf). Small messages worked fine. Big
> whoppers = no joy i.e. still the same with big messages. So at least it
> is not the archiving bit that messes up.
>
> So I upgraded my Python ;) Ermm, to version 2.0. Still the same.
>
> Has anyone had the same problem? Can anyone confirm this as a bug by
> sending a 2MB file to a 2.0.5 testlist?
>
> How do I do a trace in Python? (i.e. it is as familiar to me as the
> bacteria in my stomach (I runs on my machine and there endeth the
> relationship))
>
> Any pointers? Anything? I need to get this list running before monday
> (yes this is for a business). Please!!!??
>
> Sorry if this e-mail was not formal enough, the 48 hours strait is
> getting to me.
>
> Greets
>
> Dirko
>
> Lab E352
> E&E Engineering
> Univ. of Stellenbosch
> South Africa
>
>
> --__--__--
>
> Message: 2
> From: "James Dinan" <james@gilbertwalker.com>
> To: <mailman-developers@python.org>
> Date: Mon, 25 Jun 2001 10:49:27 -0700
> Subject: [Mailman-Developers] HTML Issue
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> I posted this message to mailman-users, and then the more I was thinking =
> about it, the more I began to think this was a question for developers.  =
> Please tell me what you think:
>
> I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with =
> the Subscribe Results Page (/mailman/subscribe/listname).  More =
> specifically, I have edited the HTML and whenever I view the page, =
> mailman appears to be prepending the following to the source:
>
> <HTML>
> <HEAD>
> </HEAD>
> <BODY
> <BODY bgcolor=3D"#ffffff">
>
> which I'm sure you can imagine is wreaking havoc on the rest of my HTML. =
>  Has anyone else had this problem, or is this fixed in future releases?  =
> Since I am not an admin on the server I am configuring it will be =
> difficult (Redhat installs mailman in /var/mailman) to recompile =
> mailman.
>
> I have just checked =
> http://mail.python.org/mailman/subscribe/mailman-users and you can see =
> for yourself that this is also happening with the version of mailman =
> that serves this list.
>
> - jim dinan.
> -----------------------------------------------------------------------
> James Dinan <james@gilbertwalker.com>
> Gilbert Walker Group: Lenox, MA  U.S.A
> Available:  http://www.gilbertwalker.com
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META content=3D"text/html; charset=3Diso-8859-1" =
> http-equiv=3DContent-Type>
> <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>I posted this message to mailman-users, =
> and then=20
> the more I was thinking about it, the more I began to think this was a =
> question=20
> for developers.&nbsp; Please tell me what you think:</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>
> <DIV><FONT face=3DArial size=3D2>I am running Mailman 2.0.1 on Redhat =
> 6.2 and I am=20
> having difficulty with the Subscribe Results Page=20
> (/mailman/subscribe/listname).&nbsp; More specifically, I have edited =
> the HTML=20
> and whenever I view the page, mailman appears to be prepending the =
> following to=20
> the source:</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2><BR>&lt;HTML&gt;<BR>&lt;HEAD&gt;<BR>&lt;/HEAD&gt;<BR>&lt;BODY<BR=
> >&lt;BODY=20
> bgcolor=3D"#ffffff"&gt;</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>which I'm sure you can imagine is =
> wreaking havoc on=20
> the rest of my HTML.&nbsp; Has anyone else had this problem, or is this =
> fixed in=20
> future releases?&nbsp; Since I am not an admin on the server I am =
> configuring it=20
> will be difficult (Redhat installs mailman in /var/mailman) to recompile =
>
> mailman.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>I have just checked <A=20
> href=3D"http://mail.python.org/mailman/subscribe/mailman-users">http://ma=
> il.python.org/mailman/subscribe/mailman-users</A>&nbsp;and=20
> you can see for yourself that this is also happening with the version of =
> mailman=20
> that serves this list.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>- jim dinan.</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>----------------------------------------------------------------=
> -------<BR>James=20
> Dinan &lt;<A=20
> href=3D"mailto:james@gilbertwalker.com">james@gilbertwalker.com</A>&gt;<B=
> R>Gilbert=20
> Walker Group: Lenox, MA&nbsp; U.S.A<BR>Available:&nbsp; <A=20
> href=3D"http://www.gilbertwalker.com">http://www.gilbertwalker.com</A></F=
> ONT></FONT></DIV></DIV></BODY></HTML>
>
> ------=_NextPart_000_003C_01C0FD64.8168A650--
>
>
>
> --__--__--
>
> Message: 3
> Date: Mon, 25 Jun 2001 17:47:58 +0200
> From: Thomas Wouters <thomas@xs4all.net>
> To: James Dinan <james@gilbertwalker.com>
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] HTML Issue
>
> On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:
>
> > I posted this message to mailman-users, and then the more I was thinking
> > about it, the more I began to think this was a question for developers.
> > Please tell me what you think:
>
> > I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with
> > the Subscribe Results Page (/mailman/subscribe/listname).  More
> > specifically, I have edited the HTML and whenever I view the page,
mailman
> > appears to be prepending the following to the source:
> >
> > <HTML>
> > <HEAD>
> > </HEAD>
> > <BODY
> > <BODY bgcolor="#ffffff">
>
> Yes. This is an open bug, and an old one. It still requires a
Pronouncement
> from Barry. The problem is that Mailman creates a HTMLgen Document instead
> of a HeadlessDocument, for the list page. From the top of my head the fix
is
> to change
>
>     doc = Document()
>
> into
>
>     doc = HeadlessDocument()
>
> in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
> is reluctant to fix it because of possible breakage (people might have
made
> template files with the (Headfull)Document in mind.) Barry ? :)
>
> --
> Thomas Wouters <thomas@xs4all.net>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
>
>
>
> --__--__--
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
>
>
> End of Mailman-Developers Digest
>



From Samuel" <coudrayf@noos.fr  Mon Jun 25 21:29:31 2001
From: Samuel" <coudrayf@noos.fr (Samuel)
Date: Mon, 25 Jun 2001 22:29:31 +0200
Subject: [Mailman-Developers] Re: Mailman-Developers digest, Vol 1 #917 - 3 msgs
References: <E15EYnW-0008AP-00@mail.python.org>
Message-ID: <038101c0fdb5$8a459de0$e23d84c3@cybercable.fr>

unsubscribe
----- Original Message -----
From: <mailman-developers-request@python.org>
To: <mailman-developers@python.org>
Sent: Monday, June 25, 2001 6:01 PM
Subject: Mailman-Developers digest, Vol 1 #917 - 3 msgs


> Send Mailman-Developers mailing list submissions to
> mailman-developers@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/mailman-developers
> or, via email, send a message with subject or body 'help' to
> mailman-developers-request@python.org
>
> You can reach the person managing the list at
> mailman-developers-admin@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mailman-Developers digest..."
>
>
> Today's Topics:
>
>    1. qrunner -- problem with huge mail messages (Dirko van Schalkwyk)
>    2. HTML Issue (James Dinan)
>    3. Re: HTML Issue (Thomas Wouters)
>
> --__--__--
>
> Message: 1
> Date: Mon, 25 Jun 2001 15:35:26 +0200
> From: Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
> Reply-To: dvschalk@ing.sun.ac.za
> To: mailman-developers@python.org
> Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
>
> Hi
>
> It is 6:02 AM Sat. and I'm fairly fed-up.
>
> I have the following situation :
>
> Mailman 2.0.5
> Python 2.0
> MTA : postfix
>
> I set Mailman up, created a test list and played with it for a while.
> Then I send it a big "whopper" 5MB e-mail. I watched the logs and saw
> postfix running the wrapper. The cron started qrunner and all hell broke
> lose (over dramatizing a bit). It started running at 100% CPU, where it
> stayed until I killed it. The message was queued in $prefix/qfiles, it
> and its little .db file. I had to remove those as well as the locks in
> $prefix/locks before I could successfully use the list again.
>
> So I thought, "well maybe the pipermail thingy can't handle the huge
> mime thingies I'm sending it". So I send a smaller attachment <150kb.
> Things went fine (except for the ugly html page:) ) Send it a 1MB
> attachment. qrunner started spinning it's wheels again. Had to seek and
> destroy again.
>
> So I replaced pipermail with MHonArc (With PUBLIC_EXTERNAL_ARCHIVER ,
> PRIVATE_EXTERNAL_ARCHIVER , PUBLIC_ARCHIVE_URL in mm_cfg.py and the
> appropriate thingies in httpd.conf). Small messages worked fine. Big
> whoppers = no joy i.e. still the same with big messages. So at least it
> is not the archiving bit that messes up.
>
> So I upgraded my Python ;) Ermm, to version 2.0. Still the same.
>
> Has anyone had the same problem? Can anyone confirm this as a bug by
> sending a 2MB file to a 2.0.5 testlist?
>
> How do I do a trace in Python? (i.e. it is as familiar to me as the
> bacteria in my stomach (I runs on my machine and there endeth the
> relationship))
>
> Any pointers? Anything? I need to get this list running before monday
> (yes this is for a business). Please!!!??
>
> Sorry if this e-mail was not formal enough, the 48 hours strait is
> getting to me.
>
> Greets
>
> Dirko
>
> Lab E352
> E&E Engineering
> Univ. of Stellenbosch
> South Africa
>
>
> --__--__--
>
> Message: 2
> From: "James Dinan" <james@gilbertwalker.com>
> To: <mailman-developers@python.org>
> Date: Mon, 25 Jun 2001 10:49:27 -0700
> Subject: [Mailman-Developers] HTML Issue
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> I posted this message to mailman-users, and then the more I was thinking =
> about it, the more I began to think this was a question for developers.  =
> Please tell me what you think:
>
> I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with =
> the Subscribe Results Page (/mailman/subscribe/listname).  More =
> specifically, I have edited the HTML and whenever I view the page, =
> mailman appears to be prepending the following to the source:
>
> <HTML>
> <HEAD>
> </HEAD>
> <BODY
> <BODY bgcolor=3D"#ffffff">
>
> which I'm sure you can imagine is wreaking havoc on the rest of my HTML. =
>  Has anyone else had this problem, or is this fixed in future releases?  =
> Since I am not an admin on the server I am configuring it will be =
> difficult (Redhat installs mailman in /var/mailman) to recompile =
> mailman.
>
> I have just checked =
> http://mail.python.org/mailman/subscribe/mailman-users and you can see =
> for yourself that this is also happening with the version of mailman =
> that serves this list.
>
> - jim dinan.
> -----------------------------------------------------------------------
> James Dinan <james@gilbertwalker.com>
> Gilbert Walker Group: Lenox, MA  U.S.A
> Available:  http://www.gilbertwalker.com
>
> ------=_NextPart_000_003C_01C0FD64.8168A650
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META content=3D"text/html; charset=3Diso-8859-1" =
> http-equiv=3DContent-Type>
> <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>I posted this message to mailman-users, =
> and then=20
> the more I was thinking about it, the more I began to think this was a =
> question=20
> for developers.&nbsp; Please tell me what you think:</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>
> <DIV><FONT face=3DArial size=3D2>I am running Mailman 2.0.1 on Redhat =
> 6.2 and I am=20
> having difficulty with the Subscribe Results Page=20
> (/mailman/subscribe/listname).&nbsp; More specifically, I have edited =
> the HTML=20
> and whenever I view the page, mailman appears to be prepending the =
> following to=20
> the source:</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2><BR>&lt;HTML&gt;<BR>&lt;HEAD&gt;<BR>&lt;/HEAD&gt;<BR>&lt;BODY<BR=
> >&lt;BODY=20
> bgcolor=3D"#ffffff"&gt;</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>which I'm sure you can imagine is =
> wreaking havoc on=20
> the rest of my HTML.&nbsp; Has anyone else had this problem, or is this =
> fixed in=20
> future releases?&nbsp; Since I am not an admin on the server I am =
> configuring it=20
> will be difficult (Redhat installs mailman in /var/mailman) to recompile =
>
> mailman.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>I have just checked <A=20
> href=3D"http://mail.python.org/mailman/subscribe/mailman-users">http://ma=
> il.python.org/mailman/subscribe/mailman-users</A>&nbsp;and=20
> you can see for yourself that this is also happening with the version of =
> mailman=20
> that serves this list.</FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>- jim dinan.</FONT></DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>----------------------------------------------------------------=
> -------<BR>James=20
> Dinan &lt;<A=20
> href=3D"mailto:james@gilbertwalker.com">james@gilbertwalker.com</A>&gt;<B=
> R>Gilbert=20
> Walker Group: Lenox, MA&nbsp; U.S.A<BR>Available:&nbsp; <A=20
> href=3D"http://www.gilbertwalker.com">http://www.gilbertwalker.com</A></F=
> ONT></FONT></DIV></DIV></BODY></HTML>
>
> ------=_NextPart_000_003C_01C0FD64.8168A650--
>
>
>
> --__--__--
>
> Message: 3
> Date: Mon, 25 Jun 2001 17:47:58 +0200
> From: Thomas Wouters <thomas@xs4all.net>
> To: James Dinan <james@gilbertwalker.com>
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] HTML Issue
>
> On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:
>
> > I posted this message to mailman-users, and then the more I was thinking
> > about it, the more I began to think this was a question for developers.
> > Please tell me what you think:
>
> > I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with
> > the Subscribe Results Page (/mailman/subscribe/listname).  More
> > specifically, I have edited the HTML and whenever I view the page,
mailman
> > appears to be prepending the following to the source:
> >
> > <HTML>
> > <HEAD>
> > </HEAD>
> > <BODY
> > <BODY bgcolor="#ffffff">
>
> Yes. This is an open bug, and an old one. It still requires a
Pronouncement
> from Barry. The problem is that Mailman creates a HTMLgen Document instead
> of a HeadlessDocument, for the list page. From the top of my head the fix
is
> to change
>
>     doc = Document()
>
> into
>
>     doc = HeadlessDocument()
>
> in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry
> is reluctant to fix it because of possible breakage (people might have
made
> template files with the (Headfull)Document in mind.) Barry ? :)
>
> --
> Thomas Wouters <thomas@xs4all.net>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
>
>
>
> --__--__--
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
>
>
> End of Mailman-Developers Digest
>



From barry@digicool.com  Mon Jun 25 21:34:37 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Mon, 25 Jun 2001 16:34:37 -0400
Subject: [Mailman-Developers] HTML Issue
References: <20010625174758.V8098@xs4all.nl>
 <15159.39173.331416.882488@yyz.digicool.com>
 <010e01c0fdcd$79373c80$3202a8c0@station12>
Message-ID: <15159.41053.297672.574049@anthem.wooz.org>

>>>>> "JD" == James Dinan <james@gilbertwalker.com> writes:

    JD> One problem that I have is that somtimes funny things will
    JD> happen inside the <MM-...> tags.

Have I mentioned how much I dislike the <mm-> tags?  Or how much I
reaaally hate having both those and normal Python %()s string
substitutions? ;)

    JD> If you're interested to see how far I've gotten, the mailing
    JD> list I'm working on (for my summer job) is available at
    JD> http://www.gilbertwalker.com/mailman/listinfo/advisorbits.
    JD> Assuming I haven't broken it again it should still be up.
    JD> But, you will notice that there are still many error messages
    JD> which I cannot touch the HTML for.  :/

I'll have to check this out when I get home.  I don't have an easy way
to do Javascript here.

    JD> Oh yeah, one other idea I had (this really pertains to my
    JD> particular site architecture) is that it would be incredibly
    JD> convenient to have a customizable page header and footer that
    JD> could be called via an <MM-...> tag that you could wrap any
    JD> sort of content in.  Sort of like making HeadlessDocument()
    JD> customizable I guess.

I agree.  At this point though, I just want to get the basics of the
web ui fixed.  I don't think I'll have the cycles to completely revamp
the whole thing.

-Barry


From claw@2wire.com  Tue Jun 26 06:22:17 2001
From: claw@2wire.com (J C Lawrence)
Date: Mon, 25 Jun 2001 22:22:17 -0700
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
In-Reply-To: Message from Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
 of "Mon, 25 Jun 2001 15:35:26 +0200." <3B373E1E.6C966C95@ing.sun.ac.za>
References: <3B373E1E.6C966C95@ing.sun.ac.za>
Message-ID: <16417.993532937@2wire.com>

On Mon, 25 Jun 2001 15:35:26 +0200 
Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> wrote:

> I set Mailman up, created a test list and played with it for a
> while.  Then I send it a big "whopper" 5MB e-mail. I watched the
> logs and saw postfix running the wrapper. The cron started qrunner
> and all hell broke lose (over dramatizing a bit). It started
> running at 100% CPU, where it stayed until I killed it. The
> message was queued in $prefix/qfiles, it and its little .db
> file. I had to remove those as well as the locks in $prefix/locks
> before I could successfully use the list again.

> So I thought, "well maybe the pipermail thingy can't handle the
> huge mime thingies I'm sending it". So I send a smaller attachment
> <150kb.  Things went fine (except for the ugly html page:) ) Send
> it a 1MB attachment. qrunner started spinning it's wheels
> again. Had to seek and destroy again.

Having run lists which had posts with attachments in the 100Meg+
range (some people use mail as a file transfer protocol), and had
them work (admittedly more than a year ago) I'm fairly certain that
this is not a Mailman problem.  Its likely to be an MTA problem or a
system problem (eg spool space).  

Try sending such a post with such a large attachment to yourself
through that same mail server.  Now try the same thing, but with say
50 copies of the same message being sent to yourself in very rapid
succession.  What your system closely.  What happens?

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


From jarrell@vt.edu  Tue Jun 26 15:16:31 2001
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 26 Jun 2001 10:16:31 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
Message-ID: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>

I thought 2.0.5 was safe under python 2.1?  I just copied my mailman installation over to
a new machine, which had 2.1 installed on it.  Most stuff works, although cron is giving me
a slew of warnings about deprecated things and syntax warnings.  But admin passwords are
failing entirely.. I'm getting:

admin(25762):     if not self.ValidAdminPassword(pw):
admin(25762):   File "/home/mailman/Mailman/SecurityManager.py", line 47, in ValidAdminPassword
admin(25762):     return type(pw) == StringType and \
admin(25762): TypeError: argument 2 must be string without null bytes, not string
admin(25762): [----- Python Information -----]
admin(25762): sys.version    = 2.1 (#1, Jun 12 2001, 07:59:49) 
[GCC 2.95.2 19991024 (release)]



From barry@digicool.com  Tue Jun 26 15:36:38 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 26 Jun 2001 10:36:38 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <15160.40438.191682.907698@anthem.wooz.org>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> I thought 2.0.5 was safe under python 2.1?  I just copied my
    RJ> mailman installation over to a new machine, which had 2.1
    RJ> installed on it.  Most stuff works, although cron is giving me
    RJ> a slew of warnings about deprecated things and syntax
    RJ> warnings.  But admin passwords are failing entirely.. I'm
    RJ> getting:

Be sure you re-run configure; make install and that Python 2.1 is
first on your path, or that you use --with-python.  I run MM2.0.5
under Py2.1 so I know it works.

-Barry


From barry@digicool.com  Tue Jun 26 15:38:51 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 26 Jun 2001 10:38:51 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <15160.40571.661124.156912@anthem.wooz.org>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> Python Information -----] admin(25762): sys.version = 2.1 (#1,

Oops, should have looked closer at your output.  I bet something's
messed up with your crypt library.  Like, your older Python
installation didn't have crypt, but your new installation does?

Try setting USE_CRYPT.
-Barry


From jarrell@vt.edu  Tue Jun 26 15:49:13 2001
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 26 Jun 2001 10:49:13 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
In-Reply-To: <15160.40438.191682.907698@anthem.wooz.org>
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <5.1.0.14.2.20010626103834.05d7ca30@lennier.cc.vt.edu>

At 10:36 AM 6/26/01 -0400, Barry A. Warsaw wrote:

>>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:
>
>    RJ> I thought 2.0.5 was safe under python 2.1?  I just copied my
>    RJ> mailman installation over to a new machine, which had 2.1
>    RJ> installed on it.  Most stuff works, although cron is giving me
>    RJ> a slew of warnings about deprecated things and syntax
>    RJ> warnings.  But admin passwords are failing entirely.. I'm
>    RJ> getting:
>
>Be sure you re-run configure; make install and that Python 2.1 is
>first on your path, or that you use --with-python.  I run MM2.0.5
>under Py2.1 so I know it works.

Downloaded a clean 2.0.5 tarball, did the configure, make, make install.
*Then* complained that it still wasn't working :-).

There's only ever *been* one python on this machine, and that's the
2.1.   Perms are all correct.



From jarrell@vt.edu  Tue Jun 26 16:03:52 2001
From: jarrell@vt.edu (Ron Jarrell)
Date: Tue, 26 Jun 2001 11:03:52 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
In-Reply-To: <15160.40571.661124.156912@anthem.wooz.org>
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
Message-ID: <5.1.0.14.2.20010626105034.06af5c00@lennier.cc.vt.edu>

At 10:38 AM 6/26/01 -0400, Barry A. Warsaw wrote:

> >>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:
>
>     RJ> Python Information -----] admin(25762): sys.version = 2.1 (#1,
>
>Oops, should have looked closer at your output.  I bet something's
>messed up with your crypt library.  Like, your older Python
>installation didn't have crypt, but your new installation does?
>
>Try setting USE_CRYPT.

Ok, my USE_CRYPT has always been set to 1 (as advised in the comments, I 
just let configure set it.)

My old machine was running 1.5.2, and I thought I'd turned everything on, 
but given the module config file has about 174,000 poorly documented bits 
to flip on or off, apparently I didn't.  I just went back to that machine 
and did a "from crypt import crypt", and sure enough, got an 
ImportError.  However, on my new machine, which also has the USE_CRYPT set 
to 1, it turns out that yes, I can import crypt.  So I guess I got screwed 
by the fact that python actually has half a clue now as to what it's doing 
when it builds itself.

However, I suspect the comments are wrong.  I ignored it back then because 
I didn't know, and the comment suggested that configure would do the right 
thing.  Obviously it didn't.  In fact, looking at the Defaults.py.in, it's 
just hard coded to *1*.

 From looking at the code, what's doing the right thing is the Crypt.py 
module, which, if mm_cfg.USE_CRYPT is set, tries to import it, traps the 
error, and resets it on the fly.

The comment in Defaults should probably be changed to "If you don't know, 
leave it at 1, and Crypt.py will do the right thing.  But if you don't have 
crypt, then upgrade python to include crypt, admin.py will start blowing up 
in strange and mysterious ways until you change this back to 0"...




From barry@digicool.com  Tue Jun 26 16:59:24 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Tue, 26 Jun 2001 11:59:24 -0400
Subject: [Mailman-Developers] 2.0.5 and python 2.1?
References: <5.1.0.14.2.20010626101350.0400e070@lennier.cc.vt.edu>
 <5.1.0.14.2.20010626105034.06af5c00@lennier.cc.vt.edu>
Message-ID: <15160.45404.945128.378299@anthem.wooz.org>

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> My old machine was running 1.5.2, and I thought I'd turned
    RJ> everything on, but given the module config file has about
    RJ> 174,000 poorly documented bits to flip on or off, apparently I
    RJ> didn't.  I just went back to that machine and did a "from
    RJ> crypt import crypt", and sure enough, got an ImportError.
    RJ> However, on my new machine, which also has the USE_CRYPT set
    RJ> to 1, it turns out that yes, I can import crypt.  So I guess I
    RJ> got screwed by the fact that python actually has half a clue
    RJ> now as to what it's doing when it builds itself.

Yes.  By default, Python 2.1 will compile in everything it can find.
This wasn't the case for 1.5.2.

    RJ> However, I suspect the comments are wrong.  I ignored it back
    RJ> then because I didn't know, and the comment suggested that
    RJ> configure would do the right thing.  Obviously it didn't.  In
    RJ> fact, looking at the Defaults.py.in, it's just hard coded to
    RJ> *1*.

    RJ>  From looking at the code, what's doing the right thing is the
    RJ> Crypt.py module, which, if mm_cfg.USE_CRYPT is set, tries to
    RJ> import it, traps the error, and resets it on the fly.

    RJ> The comment in Defaults should probably be changed to "If you
    RJ> don't know, leave it at 1, and Crypt.py will do the right
    RJ> thing.  But if you don't have crypt, then upgrade python to
    RJ> include crypt, admin.py will start blowing up in strange and
    RJ> mysterious ways until you change this back to 0"...

A good explanation for why MM2.1 doesn't use crypt at all.  I'd add
this to the FAQ but I don't think there will be a MM 2.0.6 release.

-Barry


From ricardo.kustner@adcore.com  Tue Jun 26 22:42:12 2001
From: ricardo.kustner@adcore.com (Ricardo Kustner)
Date: Tue, 26 Jun 2001 23:42:12 +0200
Subject: [Mailman-Developers] hotmail & MIME-digests
Message-ID: <20010626234212.H21483@localhost>

I don't know if this has been discussed before, but am I correct to assume
that hotmail.com (and maybe other webmail services too?) doesn't correctly
handle MIME digests send by Mailman? I always thought some people just 
didn't "see" the attached messages, but now I test it myself in hotmail 
i noticed it only shows the footer of the digest and something that looks
like a lost MIME seperator (--212.206.25.241.1015.180.993549624.729.13400--)
I'm sure the digests are send correctly cause when I read them with Mutt as
the client they are ok...
Any ideas? I couldn't really find something in the bug database...

Regards,

Ricardo



From dvschalk@ing.sun.ac.za  Wed Jun 27 15:42:56 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Wed, 27 Jun 2001 16:42:56 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com>
Message-ID: <3B39F0F0.A632C944@ing.sun.ac.za>

J C Lawrence wrote:

> > again. Had to seek and destroy again.
> 
> Having run lists which had posts with attachments in the 100Meg+
> range (some people use mail as a file transfer protocol), and had
> them work (admittedly more than a year ago) I'm fairly certain that
> this is not a Mailman problem.  Its likely to be an MTA problem or a
> system problem (eg spool space).
> 
> Try sending such a post with such a large attachment to yourself
> through that same mail server.  Now try the same thing, but with say
> 50 copies of the same message being sent to yourself in very rapid
> succession.  What your system closely.  What happens?

My MTA (postfix) works fine.


I humbly apologize. It seems that I was to hasty in my definition of
qrunner "spinning" its wheels. 

I made some time measurements :

1 236 202 bytes took 2 minutes to process
4 053 188 bytes took 19 minutes to process

I this normal? Am I missing some option that I can turn of.
What is qrunner doing all this time?

Greets

Dirko


From jra@baylink.com  Wed Jun 27 16:37:07 2001
From: jra@baylink.com (Jay R. Ashworth)
Date: Wed, 27 Jun 2001 11:37:07 -0400
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
In-Reply-To: <3B39F0F0.A632C944@ing.sun.ac.za>; from Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> on Wed, Jun 27, 2001 at 04:42:56PM +0200
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com> <3B39F0F0.A632C944@ing.sun.ac.za>
Message-ID: <20010627113707.06527@scfn.thpl.lib.fl.us>

On Wed, Jun 27, 2001 at 04:42:56PM +0200, Dirko van Schalkwyk wrote:
> I humbly apologize. It seems that I was to hasty in my definition of
> qrunner "spinning" its wheels. 
> 
> I made some time measurements :
> 
> 1 236 202 bytes took 2 minutes to process
> 4 053 188 bytes took 19 minutes to process
> 
> I this normal? Am I missing some option that I can turn of.
> What is qrunner doing all this time?

I might guess "swapping", if I knew how much RAM you had.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows


From dvschalk@ing.sun.ac.za  Wed Jun 27 18:04:34 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Wed, 27 Jun 2001 19:04:34 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com> <3B39F0F0.A632C944@ing.sun.ac.za> <20010627113707.06527@scfn.thpl.lib.fl.us>
Message-ID: <3B3A1222.BDC0A69C@ing.sun.ac.za>

"Jay R. Ashworth" wrote:

> > I this normal? Am I missing some option that I can turn of.
> > What is qrunner doing all this time?
> 
> I might guess "swapping", if I knew how much RAM you had.  :-)
> 

Got plenty :*)

I would appreciate it if anyone can do similar time tests?


Greets 

Dirko

--------
cat /proc/cpuinfo

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 3
model name      : AMD Athlon(tm) Processor
stepping        : 0
cpu MHz         : 600.046
cache size      : 64 KB
bogomips        : 1196.03

cat /proc/meminfo

        total:    used:    free:  shared: buffers:  cached:
Mem:  402161664 233144320 169017344        0 123678720 43839488
Swap: 262103040        0 262103040
MemTotal:    392736 kB
MemFree:     165056 kB
MemShared:        0 kB
Buffers:     120780 kB
Cached:       42812 kB
BigTotal:         0 kB
BigFree:          0 kB
SwapTotal:   255960 kB
SwapFree:    255960 kB

-----


From claw@kanga.nu  Wed Jun 27 18:50:37 2001
From: claw@kanga.nu (J C Lawrence)
Date: Wed, 27 Jun 2001 10:50:37 -0700
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
In-Reply-To: Message from Dirko van Schalkwyk <dvschalk@ing.sun.ac.za>
 of "Wed, 27 Jun 2001 16:42:56 +0200." <3B39F0F0.A632C944@ing.sun.ac.za>
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com>  <3B39F0F0.A632C944@ing.sun.ac.za>
Message-ID: <6771.993664237@kanga.nu>

On Wed, 27 Jun 2001 16:42:56 +0200 
Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> wrote:

> I made some time measurements :

> 1 236 202 bytes took 2 minutes to process 4 053 188 bytes took 19
> minutes to process

> I this normal? Am I missing some option that I can turn of.  What
> is qrunner doing all this time?

Are you swapping?

Aside: Qrunner is written in Python and operates by loading the
entire subject message into memory before processing.  This also may
be at the core of the problem.  

-- 
J C Lawrence                                             claw@kanga.nu
---------(*)                                http://www.kanga.nu/~claw/
I never claimed to be human.


From dvschalk@ing.sun.ac.za  Wed Jun 27 19:08:24 2001
From: dvschalk@ing.sun.ac.za (Dirko van Schalkwyk)
Date: Wed, 27 Jun 2001 20:08:24 +0200
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za> <16417.993532937@2wire.com>  <3B39F0F0.A632C944@ing.sun.ac.za> <6771.993664237@kanga.nu>
Message-ID: <3B3A2118.D60060A0@ing.sun.ac.za>

J C Lawrence wrote:

> Are you swapping?
> 
> Aside: Qrunner is written in Python and operates by loading the
> entire subject message into memory before processing.  This also may
> be at the core of the problem.

No.
I got +-340 MB RAM and 40MB/s fast and wide SCSI DISKS.

Greets

Dirko


From barry@digicool.com  Wed Jun 27 19:11:00 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Wed, 27 Jun 2001 14:11:00 -0400
Subject: [Mailman-Developers] qrunner -- problem with huge mail messages
References: <3B373E1E.6C966C95@ing.sun.ac.za>
 <16417.993532937@2wire.com>
 <3B39F0F0.A632C944@ing.sun.ac.za>
 <6771.993664237@kanga.nu>
 <3B3A2118.D60060A0@ing.sun.ac.za>
Message-ID: <15162.8628.903466.326444@anthem.wooz.org>

>>>>> "DvS" == Dirko van Schalkwyk <dvschalk@ing.sun.ac.za> writes:

    DvS> No.
    DvS> I got +-340 MB RAM and 40MB/s fast and wide SCSI DISKS.

You may have to do more digging then.  Start by adding syslog() calls
to print debugging information to e.g. logs/debug.

-Barry


From y.nugroho@student.umist.ac.uk  Thu Jun 28 16:58:33 2001
From: y.nugroho@student.umist.ac.uk (Yanuar Nugroho)
Date: Thu, 28 Jun 2001 16:58:33 +0100
Subject: [Mailman-Developers] archive
Message-ID: <00b601c0ffeb$2eedaea0$9baa5882@halls.umist.ac.uk>

Hi,

How is the principle of archiving in Mailman? Is it related to storing and
retrieving data when the archives are accessed thru the website?
Can mailman take a particular message in the archive and stick it to new
message to be distributed?


Yanuar



From barry@digicool.com  Thu Jun 28 17:27:03 2001
From: barry@digicool.com (Barry A. Warsaw)
Date: Thu, 28 Jun 2001 12:27:03 -0400
Subject: [Mailman-Developers] archive
References: <00b601c0ffeb$2eedaea0$9baa5882@halls.umist.ac.uk>
Message-ID: <15163.23255.104834.675174@anthem.wooz.org>

>>>>> "YN" == Yanuar Nugroho <y.nugroho@student.umist.ac.uk> writes:

    YN> How is the principle of archiving in Mailman? Is it related to
    YN> storing and retrieving data when the archives are accessed
    YN> thru the website?  Can mailman take a particular message in
    YN> the archive and stick it to new message to be distributed?

Mailman is designed so that either its internal Pipermail archiver, or
an external archiver of the site's choice, can be used.  Pipermail is
pretty braindead simple: it simply creates the indices and html-ifies
the message.  It has the advantage that it's written in Python and
easily bundled for the one-stop-shopping crowd.  It has several
disadvantages though, and many serious Mailman sites use a separate
3rd party archiver instead.

IOW, it would be the backend archiver's responsibility to implement
things like thru-the-web replies.  Mailman supports direct injection
of messages from any external source (and MM2.1 will be even better in
this regard).  I'd love to see something like this added so its On The
List, but who knows when there will be time to devote to it?

Cheers,
-Barry


From y.nugroho@student.umist.ac.uk  Fri Jun 29 03:36:09 2001
From: y.nugroho@student.umist.ac.uk (Yanuar Nugroho)
Date: Fri, 29 Jun 2001 03:36:09 +0100
Subject: [Mailman-Developers] layout
Message-ID: <026f01c10044$414806a0$9baa5882@halls.umist.ac.uk>

Hi folks,

Is it possible to change the layout of the message body in Mailman? (e.g.
changing the left & right margin of the body message)
Is it also possible to insert certain text into the body but _not_ header or
footer?

Currently my Mailman 2.1 is running on my unix-apache-sendmail configuration
very very well ...:)

-Yanuar-